Free KCSA Practice Test Questions and Answers (2026)

Soft multitenancy is a model where multiple tenants share the same Kubernetes cluster and its control plane, with logical separation enforced by native Kubernetes objects like Namespaces, RBAC, ResourceQuotas, and NetworkPolicies. The primary advantage and reason for choosing this model is to maximize resource utilization and operational efficiency. By allowing tenants to share the underlying infrastructure (nodes, control plane, etc.), organizations can reduce overhead and costs. This approach is suitable when tenants are trusted, such as different teams within the same enterprise, and the main goal is resource management and sharing, rather than strict, security-focused isolation.

B. When the priority is enabling complete isolation between tenants.

This describes the primary goal of hard multitenancy, which uses physically or virtually separate infrastructure (e.g., dedicated clusters, nodes, or virtual control planes) to achieve strong isolation.

C. When the priority is enabling fine-grained control over tenant resources.

While soft multitenancy uses tools like ResourceQuotas for control, this is not its unique differentiator. Hard multitenancy can also offer fine-grained control, making this statement less precise.

D. When the priority is enabling strict security boundaries between tenants.

This is the main objective of hard multitenancy. Soft multitenancy provides logical boundaries that are not considered as secure or strict against malicious or compromised tenants.

1. Kubernetes Official Documentation

"Multi-tenancy": The documentation distinguishes between soft and hard multitenancy. It implicitly supports that soft multitenancy is for shared environments

stating

"In a soft multi-tenancy model

tenants are aware of each other

but are prevented from interfering with each other by policies... This is often used by different teams within an enterprise." This context of internal teams highlights the focus on shared

efficient resource usage over absolute isolation.

Source: Kubernetes Authors. (n.d.). Multi-tenancy. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/concepts/security/multi-tenancy/

2. CNCF Kubernetes Policy Working Group

"Multi-Tenancy in Kubernetes Whitepaper": This paper discusses the spectrum of multitenancy. It frames soft multitenancy (referred to as "Namespace as a Service") as a model that "provides a good balance between isolation and resource sharing

" emphasizing that the sharing aspect is a key characteristic.

Source: CNCF Kubernetes Policy Working Group. (2021). Kubernetes Policy Management White Paper. Section: "Multi-Tenancy". Available at https://github.com/cncf/tag-security/blob/main/whit epapers/policy/CNCF-Policy-WhitePaper-v1.pdf

3. Red Hat OpenShift Documentation (Official Vendor Documentation)

"About multitenancy": The documentation explains that multitenancy allows an administrator to "use the cluster for multiple applications

teams

and departments

which saves money on infrastructure and administration." This directly links the multitenancy concept

particularly the shared-cluster (soft) model

to efficiency and resource sharing.

Source: Red Hat. (n.d.). About multitenancy. OpenShift Container Platform 4.14 Documentation. Retrieved from https://docs.openshift.com/container-platform/4.14/multitenancy/about-multitenancy.html

On a client machine, the kubectl command-line tool, by default, stores its configuration in the $HOME/.kube directory. This directory contains the config file, which holds sensitive information required to connect to one or more Kubernetes clusters. This information includes cluster API server endpoints, user credentials (such as client certificates and keys or authentication tokens), and context definitions. Access to this directory should be restricted as it grants cluster access.

A. /etc/kubernetes/ is the default directory on control-plane and worker nodes for Kubernetes component configuration files and static Pod manifests, not for client credentials.

C. /opt/kubernetes/secrets/ is not a standard or default directory used by Kubernetes for storing any type of configuration or credential information.

D. $HOME/.config/kubernetes/ is not the default location for kubectl configuration. While some applications follow the XDG Base Directory Specification, kubectl uses $HOME/.kube by default.

1. Kubernetes Documentation

"Organizing Cluster Access Using kubeconfig Files": This official documentation explicitly states

"By default

kubectl looks for a file named config in the $HOME/.kube directory." This file contains the credentials.

Source: Kubernetes Authors

"Organizing Cluster Access Using kubeconfig Files

" Kubernetes Documentation

tasks/access-application-cluster/configure-access-multiple-clusters.html.

2. Kubernetes Documentation

"kubectl Cheat Sheet": The cheat sheet reinforces this by showing commands that interact with the default configuration path. It notes that the KUBECONFIG environment variable can override this default path.

Source: Kubernetes Authors

"kubectl Cheat Sheet

" Kubernetes Documentation

reference/kubectl/cheatsheet.html

Section: "Config & Context".

Pod Security Policy (PSP) was a built-in admission controller in Kubernetes used to enforce security policies on pods at the cluster level. It was deprecated in Kubernetes v1.21 and completely removed in v1.25. The functionality provided by PSPs has been replaced by the built-in Pod Security Admission (PSA) controller, which enforces the Pod Security Standards (PSS). Therefore, Pod Security Policy is the direct precursor to the current Pod Security Standards model.

A. Container Runtime Security: This is a broad security domain concerning the container runtime (e.g., containerd, CRI-O), not a specific, deprecated Kubernetes API object that preceded Pod Security Standards.

B. Kubernetes Security Context: A securityContext is a current and valid field in the Pod and Container specifications used to define privilege and access controls. PSS uses these settings for validation, but it is not the predecessor.

C. Container Security Standards: This is a generic phrase and not the official name of the specific Kubernetes feature that was deprecated and replaced by the Pod Security Standards.

1. Kubernetes Documentation

"Pod Security Policy Deprecation": This official blog post explicitly details the deprecation timeline and states

"PodSecurityPolicy is being deprecated in Kubernetes v1.21

and will be removed in v1.25." It discusses the transition to the new built-in solution. (Source: Kubernetes Blog

April 6

2021).

2. Kubernetes Documentation

"Pod Security Admission": The official documentation for the replacement mechanism states

"Pod Security Admission is a built-in admission controller that implements the security controls outlined in the Pod Security Standards. This admission controller is enabled by default... As a replacement for PodSecurityPolicy

it offers a more ergonomic and maintainable approach to enforcing Pod security." (Source: Kubernetes Concepts

Security

Pod Security Admission

Section: "Pod Security Admission").

3. Kubernetes Documentation

"Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller": This guide provides direct instructions for the migration

reinforcing that Pod Security Admission (which enforces PSS) is the successor to Pod Security Policy. (Source: Kubernetes Tasks

Security

"Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller").

The PodSecurity admission controller is the built-in, native Kubernetes mechanism for enforcing the Pod Security Standards (PSS). This controller is enabled by default in modern Kubernetes versions. Administrators can enforce specific PSS levels (Privileged, Baseline, or Restricted) on a per-namespace basis by applying labels to the namespace metadata. For example, labeling a namespace with pod-security.kubernetes.io/enforce=restricted will cause the admission controller to reject any new pods in that namespace that do not conform to the Restricted policy. This method does not require any third-party software.

A. Kyverno and OPA are powerful third-party policy engines, not native Kubernetes components. The question specifically asks for a method without third-party tools.

C. This is false. The PodSecurity admission controller is a native, built-in feature of Kubernetes that can enforce the Pod Security Standard without external tools.

D. This is incorrect. Enforcement is not automatic. An administrator must explicitly configure which policy to apply to each namespace by setting the appropriate labels.

1. Kubernetes Documentation

"Pod Security Admission": This official document states

"Pod Security Admission is a built-in admission controller that implements the security controls outlined in the Pod Security Standards." It further explains the enforcement mechanism: "The desired policy is configured on a per-namespace basis by adding labels to a namespace." (See sections: "Pod Security Admission" and "Configuring Pod Security Admission").

2. Kubernetes Documentation

"Pod Security Standards": This page defines the standards themselves and notes their enforcement via the built-in PodSecurity admission controller. (See section: "What's next?").

3. Kubernetes Documentation

"Admission Controllers Reference": The PodSecurity controller is listed as a recommended

enabled-by-default admission controller. (See section: "PodSecurity").

A container breakout, also known as a container escape, is a security exploit where a process running within a container successfully bypasses the isolation boundaries enforced by the host kernel's namespaces and cgroups. The primary objective of such an attack is to gain unauthorized access and code execution capabilities on the underlying host operating system. This is considered a critical security failure, as it nullifies the main purpose of containerization—process isolation. A successful breakout often results from exploiting a kernel vulnerability, a misconfigured container runtime, or excessive permissions granted to the container (e.g., running in privileged mode).

A. Accessing a Pod's network traffic is a form of network attack within the Pod's scope, not the definition of escaping the container's process isolation to the host.

B. Reaching resource limits is a function of cgroups that results in process throttling or termination (e.g., OOMKilled), not a security escape.

C. Accessing the cloud provider's infrastructure is a potential, more severe consequence of a container breakout, but the breakout itself is the act of compromising the immediate host.

1. National Institute of Standards and Technology (NIST) Special Publication 800-190

"Application Container Security Guide":

Section 3.2.2

Kernel Exploits: "The kernel provides the core isolation and resource management for containers. If a container has a kernel exploit

it can break out of the container and gain control of the host. This is the most damaging type of container compromise." This directly defines a breakout as gaining control of the host.

2. Kubernetes Official Documentation

"Pod Security Standards":

Section: Privileged: The documentation for the privileged control states

"Privileged containers have access to host devices and can perform nearly any action on the host that the root user can... The primary risk of privileged containers is the ease of container breakout and host compromise." This links the concept of breakout directly to host compromise.

3. Red Hat Official Documentation

"What is a container breakout vulnerability?":

Article: "A container breakout is a situation where a malicious actor is able to escape the confines of a container and access the underlying host system. This can happen if there is a vulnerability in the container runtime

the host operating system

or the application running in the container." This source explicitly defines a breakout as accessing the host system.

Defining security policies using a declarative, "as-code" approach is the most effective method for achieving consistency, minimizing toil, and reducing misconfigurations. This methodology allows security rules to be written in a high-level, human-readable language, stored in version control systems (like Git), and applied automatically across the environment. This process enables peer reviews, automated testing, and consistent enforcement, which significantly lowers the risk of human error inherent in manual configurations. It treats policy management like software development, bringing rigor and repeatability to security operations, thereby reducing the manual, repetitive work known as toil.

B. Relying on manual audits and inspections for security policy enforcement.

This is a reactive, not preventative, approach. It is labor-intensive (high toil) and prone to human error, failing to ensure consistent enforcement.

C. Manually configuring security controls for each individual resource, regularly.

This method is not scalable, is highly susceptible to human error, and leads to configuration drift, directly contradicting the goal of consistency.

D. Implementing security policies through manual scripting on an ad-hoc basis.

"Ad-hoc" implies a lack of a systematic, version-controlled process, leading to inconsistent application and a higher probability of misconfiguration than a formal "as-code" framework.

1. Kubernetes Official Documentation

"Declarative Management of Kubernetes Objects Using Configuration Files." This document outlines the advantages of the declarative approach

stating

"The declarative approach is supported by kubectl apply... The written configuration is maintained in a source control system... This allows for more robust change management." This principle of robust

version-controlled management directly applies to security policies.

Source: Kubernetes Documentation > Concepts > Overview > Working with Kubernetes Objects > Declarative Management.

2. Open Policy Agent (OPA) Official Documentation

"Introduction." OPA is a CNCF graduated project for policy enforcement in cloud-native environments. The documentation states

"OPA uses a high-level declarative language called Rego to codify policies... By decoupling policy from service code

you can release

analyze

and review policies (which are written as code) independently." This highlights the "policy-as-code" benefit of consistency and reduced operational burden.

Source: OPA Documentation > Introduction > What is OPA?

3. University of Virginia

CS 6501: Cloud Computing Courseware

"Lecture 03: Cloud Infrastructure & IaC." The course materials explain the principles of Infrastructure as Code (IaC)

the parent concept of Policy-as-Code. It emphasizes that declarative IaC models "reduce the risk of manual errors and ensure consistency."

Source: University of Virginia

Department of Computer Science

CS 6501: Cloud Computing

Lecture 03 slides on Infrastructure as Code.

The MITRE ATT&CK® framework is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. Its specific purpose is to categorize and describe the actions an attacker might take within a network, which are commonly referred to as Tactics, Techniques, and Procedures (TTPs). This model is unique among the options as it is structured entirely from the adversary's (offensive) perspective to help defenders understand and counter specific threats. The other frameworks focus on defensive controls, risk management, or vulnerability awareness rather than offensive procedures.

B. OWASP Top 10: This is a standard awareness document focusing on the most critical security risks to web applications, not a comprehensive knowledge base of offensive TTPs.

C. CIS Controls: This is a prescriptive, prioritized set of defensive cybersecurity best practices and safeguards that organizations can implement to improve their security posture.

D. NIST Cybersecurity Framework: This provides a high-level policy framework of standards and guidelines to help organizations manage cybersecurity risk; it is fundamentally a defensive and risk management tool.

1. MITRE. (2023). About ATT&CK. The MITRE Corporation. Retrieved from https://attack.mitre.org/about/. The homepage and "About" section state

"MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations."

2. NIST. (2018). Framework for Improving Critical Infrastructure Cybersecurity

Version 1.1. National Institute of Standards and Technology. p. 1

Section 1.1. DOI: https://doi.org/10.6028/NIST.CSWP.04162018. The document introduces the framework as a tool for "managing cybersecurity risk."

3. Center for Internet Security (CIS). (2023). CIS Critical Security Controls. Retrieved from https://www.cisecurity.org/controls/. The introduction describes the controls as "a prioritized set of Safeguards to mitigate the most prevalent cyber-attacks."

4. OWASP Foundation. (2021). OWASP Top 10 - 2021. Retrieved from https://owasp.org/Top10/. The introduction states

"The OWASP Top 10 is a standard awareness document for developers and web application security."

The Kubernetes project has officially migrated its container image registry from k8s.gcr.io to registry.k8s.io. As of April 3, 2023, the k8s.gcr.io registry was frozen, meaning no new images or updates are published to it. Consequently, any attempt to pull image versions released after this date from the old k8s.gcr.io address will fail because they do not exist there. The cluster must be updated to pull images from the new registry.k8s.io endpoint to access the latest versions.

A. A network issue would likely cause all image pulls from the registry to fail, not just those for more recent versions.

B. While a bug is possible, the announced and implemented deprecation of the registry is a far more direct and certain cause for this specific issue.

C. Images on k8s.gcr.io are public, and pulling them does not typically require authentication credentials, making this an unlikely cause.

1. Kubernetes Blog. (2023

March 20). k8s.gcr.io Redirect to registry.k8s.io - What You Need to Know. Kubernetes.io. Retrieved from https://kubernetes.io/blog/2023/03/10/image-registry-redirect/. In the "What is changing?" section

it states

"On Monday

April 3

2023

we will redirect traffic from k8s.gcr.io to registry.k8s.io."

2. Kubernetes Documentation. Registry k8s.io: replacing k8s.gcr.io. Retrieved from https://kubernetes.io/docs/reference/k8s-api/workload-resources/pod-v1/#registry-k8s-io. The documentation explicitly states

"The Kubernetes project runs a container image registry at registry.k8s.io to host the container images it manages. This replaces the legacy registry

k8s.gcr.io."

3. Kubernetes Blog. (2022

November 28). k8s.gcr.io is going away

what you need to know. Kubernetes.io. Retrieved from https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/. The "Timeline" section details the plan to freeze the k8s.gcr.io registry in April 2023.

A RoleBinding must list the subject (bob) in the subjects array with exactly

kind: User, name: bob, apiGroup: rbac.authorization.k8s.io, and must point to the existing Role by setting roleRef.kind: Role, roleRef.name: pod-reader, roleRef.apiGroup: rbac.authorization.k8s.io.

Option B is the only snippet that contains all these mandatory, case-sensitive fields and values, thereby correctly binding user bob to the Role pod-reader in the namespace.

Option A – subjects.kind is ServiceAccount, not User; therefore does not bind the user bob.

Option C – roleRef.kind is ClusterRole; binds to a ClusterRole, not the namespace-scoped Role requested.

Option D – apiGroup is omitted in subjects/roleRef; absent apiGroup defaults are not allowed, rendering the binding invalid.

1. Kubernetes Documentation

“RBAC › RoleBinding and ClusterRoleBinding

” examples 1–3

lines showing “kind: User … roleRef: kind: Role”

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding

2. Kubernetes API Reference v1.29

rbac.authorization.k8s.io/v1 RoleBinding schema

fields subjects[] and roleRef

Section “Required Fields”

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#rolebinding-v1-rbac-authorization-k8s-io

3. The Linux Foundation (LFD459) “Kubernetes Security Fundamentals

” Chapter 3

Slide 27

“Binding a User to a Role” (shows identical YAML).

Implementing Pod Security Standards (PSS) is a critical action for minimizing security issues in Kubernetes. This is achieved by defining security policies within the Pod's YAML configuration, specifically using the securityContext field. This allows administrators to enforce the principle of least privilege by restricting a Pod's capabilities, such as preventing it from running as the root user (runAsNonRoot: true), disallowing privilege escalation (allowPrivilegeEscalation: false), and applying specific seccomp or AppArmor profiles. These controls directly harden the Pod's runtime environment, reducing its attack surface and mitigating potential vulnerabilities.

A. Sharing sensitive data broadly increases the risk of exposure and violates the principle of need-to-know, directly contradicting security best practices.

B. Running Pods with elevated privileges is a major security anti-pattern that breaks container isolation and can lead to host compromise.

D. Obfuscating Pod names through randomization is not a security control; an attacker with cluster access can easily list and identify all Pods.

1. Kubernetes Documentation

"Pod Security Standards": This document outlines the three standard policies (Privileged

Baseline

and Restricted) designed to cover a broad spectrum of security requirements. The 'Restricted' policy

for example

enforces current Pod hardening best practices. (Source: kubernetes.io/docs/concepts/security/pod-security-standards/)

2. Kubernetes Documentation

"Configure a Security Context for a Pod or Container": This guide provides specific examples of how to use the securityContext field in a Pod's specification to set security parameters like runAsUser

runAsNonRoot

and allowPrivilegeEscalation. (Source: kubernetes.io/docs/tasks/configure-pod-container/security-context/

Section: "Set the security context for a Pod")

3. The Linux Foundation

"Introduction to Kubernetes (LFS158x)" Courseware: This official course

often used as a basis for KCSA

emphasizes the principle of least privilege. Module 11

"Security

" discusses using Security Contexts to limit container permissions as a fundamental security measure. (Source: edX

LFS158x

Module 11: Security)

Container image signing provides a cryptographic guarantee about the origin and state of an image. The process involves a trusted entity (a developer or an automated build system) signing an image digest with a private key. Verification, typically performed by an admission controller in a Kubernetes cluster before deployment, uses the corresponding public key to confirm two critical security properties:

1. Authenticity: The signature is valid and was created by the holder of the private key, verifying the image's source.

2. Integrity: The image's current digest matches the digest that was originally signed, ensuring the image has not been altered or tampered with since it was created.

B. The primary purpose is establishing trust through authenticity and integrity, not defining legal or organizational ownership, which is a misinterpretation of the concept.

C. Image signing is a security best practice, not a universal mandate. Cloud providers and Kubernetes do not deny unsigned images by default; this enforcement requires explicit configuration.

D. The signature metadata adds a negligible amount to the registry storage, not the image layers, and verification occurs at deployment time, having no impact on the application's runtime performance.

1. Red Hat OpenShift Documentation: In the section on "Signing container images for trusted software supply chains

" it states

"You can use image signatures to resist tampering and to ensure that you are using a trusted image... When you verify the signature before you use the image

you can be sure that the image has not been tampered with and that it is from a trusted source." (Source: Red Hat OpenShift Container Platform 4.14 Documentation

Chapter 3. Signing container images for trusted software supply chains).

2. Google Cloud Documentation (Binary Authorization): "Binary Authorization is a deploy-time security control that ensures only trusted container images are deployed... By checking for verifiable attestations

Binary Authorization enforces that images have successfully passed required processes... before they are deployed." This directly links verification to ensuring integrity and authenticity in a cloud environment. (Source: Google Cloud

Binary Authorization documentation

"Overview").

3. The Linux Foundation (Sigstore/Cosign Project): The official documentation for Cosign

a project for signing container images

states its goal is to make signatures "invisible infrastructure" to "verify the authenticity and integrity of the artifacts." (Source: Sigstore Documentation

"Cosign" section).

4. Kubernetes Documentation: The mechanism for enforcing signature verification is the admission controller. The documentation on "Dynamic Admission Control" explains how webhooks can be used to "validate... requests

" which is the technical foundation for implementing policies that check image signatures before allowing a pod to run. (Source: Kubernetes Documentation

Reference > API Access Control > Dynamic Admission Control).

A Pod within a Kubernetes cluster can discover and attempt to connect to the API server using the automatically mounted ServiceAccount credentials and internal service discovery. However, this connection is subject to network-level controls. Kubernetes Network Policies are the standard mechanism for enforcing network segmentation. A properly configured egress Network Policy can explicitly deny traffic from a Pod (or a group of Pods) to the API server's endpoint, thereby blocking the connection attempt. This is a critical security practice to limit the potential impact of a compromised workload by preventing it from interacting with the cluster's control plane.

A. Kubernetes does not have a built-in feature to automatically detect a "compromise" and then isolate the Pod. This functionality requires external security monitoring and response tools.

B. This is incorrect because Network Policies can, and in a secure environment often do, place restrictions on which Pods are allowed to communicate with the API server.

D. This is fundamentally incorrect. Kubernetes operates on a principle of least privilege. A Pod's ServiceAccount is granted minimal (often no) permissions by default via RBAC.

1. Kubernetes Official Documentation

"Network Policies": This document explains how Network Policies control traffic flow. The section on "Egress rules" details how to specify destinations that Pods are allowed to connect to. A policy could be written to deny egress traffic to the API server's IP range for most Pods. (See: kubernetes.io/docs/concepts/services-networking/network-policies/#egress-rules)

2. Kubernetes Official Documentation

"Accessing the Cluster": This page describes how a Pod can communicate with the API server. The section "Accessing the API from a Pod" states

"When accessing the API from a pod

the location of the API server is injected into the pod...". This confirms the Pod can attempt the connection

which Network Policies can then block. (See: kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod)

3. The Linux Foundation

"Kubernetes and Cloud Native Security" (LFS260 Courseware): University-level courseware developed by the Linux Foundation often covers these principles. For instance

modules on cluster security emphasize using Network Policies for micro-segmentation to limit the "blast radius" of a compromise

including restricting access to the control plane (API server) as a primary defense strategy. The KCSA exam curriculum explicitly lists "Understand Network Policy" under the "Cluster Security" domain.

The act of "trojanising" a container image is a direct manipulation and unauthorized modification of its contents. The STRIDE threat modeling framework categorizes threats based on the type of security property violated. In this scenario, the integrity of the container image is compromised. The Tampering category specifically addresses the unauthorized modification of data or code. By injecting malicious code into the image on the build server, the attacker has tampered with the asset, violating its integrity.

A. Repudiation: This threat involves an attacker denying they performed a malicious action. It does not describe the act of modifying the image itself.

B. Spoofing: This involves impersonating another user, component, or entity. While the tampered image might be used to spoof a legitimate service, the core act of modification is tampering.

C. Denial of Service: This threat focuses on making a system or resource unavailable to legitimate users. The modification itself is not a DoS, although the resulting trojan could potentially cause one.

1. Microsoft Documentation: In the official description of the STRIDE model

Tampering is defined as the "modification of data." The scenario describes a modification to the data and code within the container image.

Source: Microsoft

"The STRIDE Threat Model

" Security Development Lifecycle. Section: "Tampering."

2. University Courseware: University security courses define tampering as a violation of integrity. Modifying a container image to include a trojan is a classic example of an integrity violation.

Source: University of Washington

Paul G. Allen School of Computer Science & Engineering. CSE 481D: Systems and Security

Lecture 2: Threat Modeling

Slide 15

"STRIDE

" defines Tampering as "Modification of data (integrity)."

3. Academic Publication: Foundational security literature and academic papers on threat modeling consistently link the unauthorized modification of assets to the threat of tampering.

Source: Shostack

A. (2008). Experiences Threat Modeling at Microsoft. MODSEC. Section 2.1

"STRIDE

" describes Tampering as "If an attacker can change my data

that's a violation of integrity." The container image is the data in this context.

A RoleBinding grants permissions within a specific namespace. While the cluster-admin ClusterRole contains permissions for all actions on all resources cluster-wide, using it in a RoleBinding constrains those powerful permissions to the single namespace where the RoleBinding is created. This grants the subject (e.g., user, service account) complete control over all resources within that namespace, which explicitly includes the ability to modify the namespace object itself (e.g., its labels and annotations).

A: This is incorrect because the cluster-admin role's wildcard permissions ( on resources) include the namespaces resource, thus granting control over the namespace object itself within the binding's scope.

B: This describes the effect of using the cluster-admin role with a ClusterRoleBinding, which grants cluster-wide access. A RoleBinding is strictly namespace-scoped and cannot grant permissions across all namespaces.

D: This describes the default admin role, which is more limited. The admin role specifically disallows write access to resource quotas and the namespace object, unlike the unrestricted cluster-admin role.

1. Kubernetes Documentation

"Using RBAC Authorization": Under the section "Default Roles and Role Bindings

" the cluster-admin role is described: "When used in a RoleBinding

it gives full control over every resource in the RoleBinding's namespace

including the namespace itself." This directly validates answer C. The same section describes the admin role

confirming the description in option D belongs to a different role.

2. Kubernetes Documentation

"Using RBAC Authorization": The distinction between a RoleBinding and ClusterRoleBinding is fundamental. The documentation states

"A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants them cluster-wide." This confirms that a RoleBinding cannot provide the cluster-wide access described in option B.

Static Pods are managed directly by the kubelet daemon on a specific node, bypassing the Kubernetes control plane components like the API server and the scheduler for their creation. The kubelet watches a specific path on the node's filesystem (e.g., /etc/kubernetes/manifests) for Pod manifest files. When a manifest appears, the kubelet creates the Pod on that node without any intervention from the kube-scheduler. Because they are not managed by standard API-driven controllers (like Deployments or ReplicaSets), their lifecycle is tied directly to the kubelet on a single node, which makes centralized tracking, scaling, and management more difficult compared to standard Pods.

A. Static Pods are, by definition, confined to the single node where their manifest file resides and are managed by that node's kubelet; they cannot span multiple nodes.

B. There is no specific, predefined limit of 5 static Pods per node. The number of Pods a node can run is determined by its resources and the general --max-pods kubelet configuration.

D. The kubelet deploys static Pods as soon as it detects their manifest files in its configured directory, regardless of the kube-scheduler's operational status.

1. Kubernetes Documentation

"Static Pods": "Static Pods are managed directly by the kubelet daemon on a specific node

without the API server observing them. [...] the kubelet on each node watches a specific directory for static pods. The kubelet on each node acts as the scheduler and controller for its own static pods." This confirms that the kubelet manages them locally

bypassing the central scheduler.

Source: Kubernetes Authors. (n.d.). Static Pods. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/

2. Kubernetes Documentation

"Kubelet": The kubelet configuration options

specifically --pod-manifest-path

define the mechanism for discovering static Pods. There is no mention of a specific numerical limit for static Pods

nor is their deployment conditional on the scheduler's state.

Source: Kubernetes Authors. (n.d.). kubelet. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/