CCNA Kubernetes Security Fundamentals Questions

Multi-Selecthard

Which TWO mechanisms help secure Kubernetes Secrets against unauthorized access or exposure?

Select 2 answers

A.Granting cluster-admin to all application service accounts

B.Enabling encryption at rest using KMS or AES-CBC providers

C.Storing secrets in plaintext ConfigMaps for easier auditing

D.Disabling the Kubernetes audit log

E.Applying strict RBAC least-privilege roles to limit secret reading

AnswersB, E

Encryption at rest with KMS or AES-CBC providers protects etcd-stored Secret data, so anyone reading the underlying storage or a backup cannot recover plaintext credentials. This satisfies the constraint of preventing exposure when the storage layer itself is compromised.

Why this answer

Option B is correct because enabling encryption at rest with a KMS provider or the AES-CBC encryption provider ensures that Secret objects stored in etcd are encrypted on disk, so an attacker who gains access to the etcd data or its backups cannot read secret values in plaintext. Option E is correct because Kubernetes Secrets are protected primarily by RBAC authorization; applying least-privilege Roles and RoleBindings that restrict get, list, and watch on secrets to only the workloads and users that truly need them prevents unauthorized principals from reading Secret data through the API server. Option A is wrong because granting cluster-admin to all application service accounts massively over-privileges workloads and would let any compromised pod read every Secret in the cluster.

Option C is wrong because ConfigMaps are not designed to hold sensitive data and are stored unencrypted and broadly readable, so moving secrets into plaintext ConfigMaps increases exposure rather than securing them. Option D is wrong because disabling the Kubernetes audit log removes the record of who accessed or modified Secrets, eliminating detection and forensic capability instead of adding protection.

Exam trap

KCSA often tests the misconception that Kubernetes Secrets are encrypted by default, leading candidates to overlook encryption-at-rest and RBAC as the two real protective mechanisms.

Practice this question →

Multi-Selecteasy

Which TWO tools or built-in Kubernetes features are used to secure container privileges and behaviors?

Select 2 answers

A.Pod Security Standards

B.PersistentVolumeClaim

C.SecurityContext

D.HorizontalPodAutoscaler

E.IngressController

AnswersA, C

Pod Security Standards define the Privileged, Baseline and Restricted profiles enforced via Pod Security Admission, restricting privilege escalation, host namespaces and capabilities at the namespace level, satisfying the requirement to secure container privileges and behaviours.

Why this answer

Pod Security Standards (A) are correct because they are built-in Kubernetes policies (Privileged, Baseline, Restricted) enforced via the Pod Security Admission controller to restrict container privileges such as hostPath, hostNetwork, and privileged mode at the namespace level. SecurityContext (C) is correct because it lets you define pod- and container-level security settings like runAsUser, runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation, and Linux capabilities directly in the Pod spec to control container privileges and behaviors. PersistentVolumeClaim (B) is incorrect because it only requests storage resources and has no role in privilege or behavior security.

HorizontalPodAutoscaler (D) is incorrect because it scales workloads based on metrics like CPU utilization, not security. IngressController (E) is incorrect because it manages external HTTP/HTTPS routing into the cluster, not container privilege enforcement.

Exam trap

KCSA often tests confusion between admission-time controls (Pod Security Standards/PSA) and runtime container configuration (SecurityContext), tempting candidates to select storage or scaling resources that sound security-adjacent.

Practice this question →

MCQeasy

An administrator needs to restrict access so that a specific ServiceAccount in the production namespace can only list pods, but cannot delete or modify them. Which core Kubernetes API resource should be configured to achieve this using RBAC?

A.ValidatingWebhookConfiguration

B.ClusterRole combined with a ClusterRoleBinding

C.PodSecurityPolicy

D.Role combined with a RoleBinding

AnswerD

A Role defines the permitted verbs (list) on pods within the production namespace, and a RoleBinding grants that Role to the ServiceAccount. Namespaced RBAC therefore restricts the account to listing pods only, denying delete and modify actions.

Why this answer

A Role combined with a RoleBinding is the correct choice because RBAC in Kubernetes uses Role to define permissions within a specific namespace, and RoleBinding to grant those permissions to a subject (like a ServiceAccount) within that namespace. This allows the administrator to restrict the ServiceAccount to only list pods in the production namespace, without granting cluster-wide permissions. ClusterRole and ClusterRoleBinding would grant permissions across all namespaces, which is not desired here.

Exam trap

KCSA often tests the distinction between namespace-scoped and cluster-scoped RBAC resources, causing candidates to incorrectly choose ClusterRole and ClusterRoleBinding when the requirement is to restrict access to a single namespace.

How to eliminate wrong answers

Option A is wrong because ValidatingWebhookConfiguration is used to validate API requests via external webhooks, not to define RBAC permissions. Option B is wrong because ClusterRole combined with a ClusterRoleBinding grants permissions cluster-wide, which would allow the ServiceAccount to list pods in all namespaces, violating the requirement to restrict access to the production namespace only. Option C is wrong because PodSecurityPolicy (deprecated) was used to control pod security settings, not to manage RBAC permissions for listing pods.

Practice this question →

Multi-Selecteasy

Which THREE methods can be used to inject Kubernetes Secrets into a running pod?

Select 3 answers

A.Injected as environment variables

B.Compiled directly into the container image binary

C.Mounted as files inside a volume

D.Injected via projected volumes

E.Injected through kernel sysctl parameters

AnswersA, C, D

Environment variables inject secret values directly into a container's process environment at pod start, satisfying the requirement that secrets reach a running pod without extra volume mounts. Kubernetes populates them from the Secret via `envFrom` or `valueFrom.secretKeyRef`, making this one of the three supported injection methods.

Why this answer

Option A is correct because Kubernetes natively supports exposing a Secret's key-value pairs as environment variables in a container via the env or envFrom fields with valueFrom.secretKeyRef or secretRef, making the data available to the process at runtime. Option C is correct because a Secret can be mounted as a volume (secret volume type), which writes each key as a file inside the container's filesystem, a common pattern for config files and credentials. Option D is correct because projected volumes allow combining multiple sources—including Secrets, ConfigMaps, downwardAPI, and serviceAccountToken—into a single mounted volume, and Secrets are explicitly one of the supported projection sources.

Option B is incorrect because baking secrets into a container image embeds them in the image layers, which is not an injection method at runtime and is considered an anti-pattern since the image is static and shared. Option E is incorrect because kernel sysctl parameters are tunable kernel settings exposed via the sysctl interface and have no mechanism for delivering Kubernetes Secret data into a pod.

Exam trap

KCSA often tests whether candidates confuse Secret delivery mechanisms with image build practices, so watch for distractors like 'compiled into the image' or 'sysctl' that sound technical but have no relationship to how the kubelet injects Secret data.

Practice this question →

MCQmedium

By default, how are Kubernetes Secrets stored in etcd when created without additional encryption-at-rest configurations?

A.Hashed using SHA-256 with a random salt

B.Encrypted using the node's TPM chip

C.Encrypted using AES-256 automatically

D.Encoded in Base64 plaintext

AnswerD

Kubernetes Secrets are stored in etcd as Base64-encoded strings, which is reversible encoding, not encryption. This satisfies the default-behaviour constraint: without configuring an EncryptionConfiguration with a KMS or aescbc provider, anyone with etcd access can decode the values.

Why this answer

By default, Kubernetes Secrets are stored in etcd as Base64-encoded strings, which is an encoding, not encryption. Anyone with read access to etcd or the ability to fetch the Secret via the API can trivially decode the value, which is why encryption at rest must be explicitly configured via EncryptionConfiguration.

Exam trap

KCSA often tests the distinction between encoding and encryption — candidates see 'Base64' and assume it implies some security, but Base64 is reversible by anyone and provides no confidentiality whatsoever.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not hash Secret values — hashing is one-way and would make the Secret unusable, since the kubelet must retrieve the original plaintext to inject it. Option B is wrong because Kubernetes has no built-in TPM-based encryption for etcd data; TPMs are used for node identity and disk encryption at the OS level, not for Secret storage. Option C is wrong because AES-256 encryption at rest is not automatic — it requires an explicit EncryptionConfiguration with an aescbc, aesgcm, or KMS provider and the --encryption-provider-config flag on the apiserver.

Practice this question →

Multi-Selectmedium

Which THREE of the following are official Pod Security Standard enforcement levels recognized by Kubernetes?

Select 3 answers

A.baseline

B.isolated

C.privileged

D.restricted

E.secure

AnswersA, C, D

baseline is one of the three official Pod Security Standard levels. It blocks known privilege escalations while permitting default pod configurations, sitting between the permissive privileged level and the hardened restricted level, and is enforced via namespace labels.

Why this answer

The three official Pod Security Standard enforcement levels defined by Kubernetes are privileged, baseline, and restricted. Option A (baseline) is correct because it is the minimally restrictive policy that prevents known privilege escalations while allowing default pod configurations. Option C (privileged) is correct because it is the unrestricted policy allowing the widest possible permissions, intended for trusted workloads such as system-level components.

Option D (restricted) is correct because it is the most restrictive policy, enforcing current hardening best practices like requiring non-root users and dropping capabilities. Options B (isolated) and E (secure) are not recognized enforcement levels; they are not part of the Kubernetes Pod Security Standards, which only define privileged, baseline, and restricted.

Exam trap

The trap here is confusing the Pod Security Standard levels with other security concepts like network isolation or generic terms like 'secure', leading candidates to select non-existent options.

Practice this question →

Multi-Selecteasy

Which TWO actions can be performed using Kubernetes RBAC rules?

Select 2 answers

A.Granting permission to create deployments cluster-wide

B.Encrypting secret values stored in etcd

C.Allocating storage capacity for PersistentVolumes

D.Enforcing Pod Security Standards on namespaces

E.Granting permission to read ConfigMaps in a namespace

AnswersA, E

Kubernetes RBAC supports ClusterRole and ClusterRoleBinding resources, which grant permissions across all namespaces rather than within one. Creating deployments cluster-wide therefore maps directly to a ClusterRole bound via ClusterRoleBinding, satisfying the stem's requirement for an action achievable through RBAC rules.

Why this answer

RBAC (Role-Based Access Control) in Kubernetes governs who can perform which verbs on which resources via Roles/ClusterRoles bound with RoleBindings/ClusterBindings, so option A is correct: a ClusterRole granting the 'create' verb on 'deployments' (apps API group) bound cluster-wide allows creating deployments in any namespace. Option E is also correct: a Role granting the 'get'/'list'/'watch' verbs on 'configmaps' in a specific namespace, bound via a RoleBinding, permits reading ConfigMaps only in that namespace. Option B is wrong because encryption of Secret data at rest in etcd is handled by the API server's EncryptionConfiguration (EncryptionConfiguration with an aescbc/aesgcm/kms provider), not RBAC.

Option C is wrong because PersistentVolume capacity is provisioned by StorageClasses, CSI drivers, or static PV definitions, not by RBAC rules. Option D is wrong because Pod Security Standards are enforced via the Pod Security Admission controller using namespace labels (pod-security.kubernetes.io/enforce), not RBAC.

Exam trap

KCSA often tests the boundary between authorization (RBAC) and other control-plane functions — candidates incorrectly attribute encryption, storage, or admission enforcement to RBAC because those are all 'security-adjacent' concepts.

Practice this question →

MCQhard

You want to ensure that a newly created Role in namespace 'finance' cannot be modified or deleted by regular developers who have edit permissions. Which RBAC feature or design prevents unauthorized privilege escalation through Role manipulation?

A.Enabling Pod Security Standards on the finance namespace.

B.Setting the Role resource to immutable via 'immutable: true'.

C.A mandatory MutatingWebhookConfiguration that strips administrative verbs.

D.The API server's built-in privilege escalation prevention check, which blocks users from granting permissions they do not hold.

AnswerD

Kubernetes' API server enforces privilege escalation prevention: a user cannot create or update a Role granting permissions they do not already hold, unless they have the escalate verb. This blocks developers with edit rights from crafting a Role that exceeds their own privileges, preventing escalation through Role manipulation.

Why this answer

Kubernetes RBAC has a built-in privilege escalation prevention check: the API server blocks a user from creating or updating a Role/ClusterRole that grants permissions the user does not already hold (unless they have the 'escalate' or 'bind' verb). This prevents a developer with edit rights from crafting a Role that grants cluster-admin and then binding to it.

Exam trap

The trap is inventing non-existent features (immutable Roles) or misapplying unrelated controls (Pod Security Standards, webhooks) instead of recognizing Kubernetes' native privilege escalation prevention.

How to eliminate wrong answers

Option A is wrong because Pod Security Standards govern pod security contexts (privileged, hostPath, etc.), not RBAC role manipulation. Option B is wrong because Kubernetes Role/ClusterRole objects do not support an 'immutable: true' field — that field exists on ConfigMaps and Secrets, not RBAC resources. Option C is wrong because a MutatingWebhookConfiguration is not a built-in RBAC control and would be a custom, fragile workaround rather than the native mechanism.

Practice this question →

Multi-Selectmedium

Which THREE fields are required when defining a standard Kubernetes NetworkPolicy resource? (Choose THREE)

Select 3 answers

A.metadata

B.securityContext

C.kind (set to NetworkPolicy)

D.imagePullSecrets

E.apiVersion

AnswersA, C, E

The metadata field is mandatory in every Kubernetes object, supplying the name and optional namespace, labels and annotations that identify the NetworkPolicy. The API server rejects any manifest lacking metadata, so it fulfils the stem's requirement for a required NetworkPolicy field.

Why this answer

Option A (metadata) is correct because every Kubernetes object manifest, including a NetworkPolicy, must include a metadata block that supplies at least the resource name (and optionally namespace, labels, and annotations) so the object can be identified and referenced. Option C (kind set to NetworkPolicy) is correct because the kind field declares the resource type being created, and for a network policy it must be exactly NetworkPolicy so the API server routes the object to the networking.k8s.io API group. Option E (apiVersion) is correct because the manifest must specify the API group/version, e.g. networking.k8s.io/v1, so the API server knows which schema and endpoint to use when validating and persisting the object.

The unmarked options do not belong: securityContext (B) is a pod/container-level field for privileges and capabilities, not a NetworkPolicy field, and imagePullSecrets (D) is a Pod spec field for authenticating to private registries, unrelated to network policy definition.

Exam trap

KCSA often tests whether candidates confuse universal Kubernetes manifest fields (apiVersion, kind, metadata) with resource-specific fields like securityContext or imagePullSecrets — the trap is picking a field that sounds security-related but isn't part of NetworkPolicy.

Practice this question →

MCQeasy

A security engineer wants to ensure that a pod cannot escalate its privileges to gain root access on the node. Which securityContext setting should be configured to prevent privilege escalation?

A.runAsNonRoot: false

B.allowPrivilegeEscalation: false

C.hostNetwork: true

D.privileged: true

AnswerB

Setting allowPrivilegeEscalation to false prevents a process from gaining more privileges than its parent, blocking mechanisms such as setuid binaries or file capabilities that would otherwise yield root on the node. It directly satisfies the no-escalation constraint.

Why this answer

The allowPrivilegeEscalation: false setting in the securityContext prevents a process from gaining more privileges than its parent, specifically blocking setuid binaries and other mechanisms that could escalate to root. This directly addresses the requirement to prevent a pod from escalating privileges to gain root access on the node. It is a key pod security control.

Exam trap

The trap is confusing allowPrivilegeEscalation with runAsNonRoot or privileged; candidates may think runAsNonRoot: false prevents escalation, but it actually allows root, and privileged: true is the opposite of a security control.

How to eliminate wrong answers

Option A is wrong because runAsNonRoot: false explicitly allows the container to run as root, which is the opposite of preventing privilege escalation. Option C is wrong because hostNetwork: true gives the pod access to the host network namespace, which increases privilege and attack surface rather than preventing escalation. Option D is wrong because privileged: true grants the container almost all capabilities of the host, enabling full privilege escalation, which is the opposite of the desired control.

Practice this question →

MCQeasy

An administrator needs to store sensitive database credentials securely so that they can be mounted as environment variables inside a specific pod. Which Kubernetes object is designed for this purpose?

A.ResourceQuota

B.PersistentVolume

C.ConfigMap

D.Secret

AnswerD

A Secret stores sensitive data such as database credentials, base64-encoded within etcd, and can be injected into a pod as environment variables via `envFrom` or `valueFrom.secretKeyRef`. This directly satisfies the stem's requirement to mount credentials as environment variables inside a specific pod.

Why this answer

A Secret is the correct Kubernetes object for storing sensitive data like database credentials. Secrets are designed to hold confidential information and can be mounted as environment variables or volumes in pods. They are base64-encoded by default and can be encrypted at rest if configured.

ConfigMaps are for non-sensitive data, while ResourceQuota and PersistentVolume serve different purposes.

Exam trap

KCSA often tests the difference between ConfigMaps and Secrets, causing candidates to choose ConfigMap for sensitive data due to its similar usage pattern, but ConfigMaps are not designed for confidentiality.

How to eliminate wrong answers

Option A is wrong because ResourceQuota is used to limit resource consumption in a namespace, not to store sensitive data. Option B is wrong because PersistentVolume provides storage resources, not secret storage. Option C is wrong because ConfigMap is intended for non-confidential configuration data, and storing sensitive credentials in a ConfigMap would expose them in plaintext, violating security best practices.

Practice this question →

MCQeasy

What is the purpose of the Pod Security Standards 'baseline' profile?

A.To disable all security controls and permit unrestricted container execution.

B.To automatically encrypt all container environment variables.

C.To enforce the highest level of security, restricting pods to hardened sandbox environments.

D.To prevent known privilege escalations while maintaining broad compatibility for standard applications.

AnswerD

The baseline profile blocks known privilege escalations—host namespaces, privileged containers, hostPath volumes—while deliberately permitting standard workload configurations. It satisfies the stem's requirement for a middle tier between privileged and restricted, offering security hardening without the compatibility restrictions that break ordinary applications.

Why this answer

The baseline profile is designed to prevent known privilege escalations — such as privileged containers, hostNetwork, hostPID, and adding dangerous capabilities — while remaining broadly compatible with standard applications. It sits between the permissive 'privileged' profile and the highly restrictive 'restricted' profile. This makes it the default recommendation for general-purpose namespaces that need meaningful security without breaking typical workloads.

Exam trap

KCSA often tests confusion among the three Pod Security Standards profiles — candidates mix up baseline with restricted or privileged, so knowing the exact intent of each profile is essential.

How to eliminate wrong answers

Option A is wrong because disabling all security controls describes the 'privileged' profile, which is the most permissive and intended only for trusted system workloads. Option B is wrong because Pod Security Standards govern pod security contexts and admission, not environment variable encryption — secret encryption at rest is handled by the API server's encryption configuration. Option C is wrong because enforcing the highest security level with hardened sandboxes describes the 'restricted' profile, which requires runAsNonRoot, dropped capabilities, seccomp, and restricted volume types.

Practice this question →

MCQhard

You want to write a NetworkPolicy that allows backend pods to communicate with an external database located outside the cluster at IP address '203.0.113.50'. Which NetworkPolicy section must you configure?

A.ingress with a namespaceSelector matching the external network

B.ExternalName service mapped to an egress policy

C.egress with an ipBlock matching '203.0.113.50/32'

D.policyTypes set to ["Ingress"] with externalIPs

AnswerC

Traffic to an external database leaves the pod, so an egress rule is required. Because the destination is an IP outside the cluster, ipBlock with a /32 host prefix matches that single address; podSelector and namespaceSelector cannot reference external endpoints.

Why this answer

Traffic from backend pods to an external database at 203.0.113.50 is outbound traffic leaving the cluster, so it must be governed by the egress section of the NetworkPolicy. The ipBlock selector with CIDR 203.0.113.50/32 precisely matches that single external IP, since ipBlock is designed for destinations outside the cluster where podSelector and namespaceSelector do not apply. The policy must also list 'Egress' in policyTypes for the rule to be enforced.

Exam trap

The trap here is confusing ingress with egress: candidates see 'database' and think of inbound access, but the direction is from the pods outward, so the correct answer must be an egress rule with ipBlock.

How to eliminate wrong answers

Option A is wrong because ingress rules control inbound traffic to pods, not outbound connections to an external database, and namespaceSelector only matches cluster-internal namespaces, never external IPs. Option B is wrong because an ExternalName service is just a DNS CNAME abstraction and has no relationship to NetworkPolicy enforcement; egress policies are not 'mapped' to services. Option D is wrong because policyTypes set to ['Ingress'] would only enforce inbound rules, and externalIPs is a Service field, not a NetworkPolicy selector.

Practice this question →

Multi-Selecthard

Which TWO statements accurately describe how Kubernetes admission controllers function? (Choose TWO)

Select 2 answers

A.Admission controllers run on the kubelet before container creation on the worker node.

B.Validating admission controllers can reject incoming requests but cannot modify the object content.

C.Admission controllers replace the need for RBAC authentication.

D.If any validating webhook fails and its failurePolicy is 'Ignore', the API server stops processing further webhooks.

E.Mutating admission controllers execute before validating admission controllers and can modify object fields.

AnswersB, E

Validating webhooks run in the admission chain's validation phase, where they may only allow or deny a request; the API server rejects the object outright. They cannot mutate fields, which is the exclusive role of mutating controllers, so this statement correctly describes their non-modifying enforcement behaviour.

Why this answer

Option B is correct because validating admission controllers operate during the API server's admission phase and can only allow or deny a request; they cannot mutate the object, which is the exclusive role of mutating controllers. Option E is correct because in the Kubernetes admission chain, mutating admission controllers (including mutating admission webhooks) run first and may alter the object's fields, after which validating admission controllers run against the final mutated object. Option A is wrong because admission controllers run in the kube-apiserver, not on the kubelet, which only handles pod/container lifecycle after scheduling.

Option C is wrong because admission controllers are a separate policy layer and do not replace RBAC authentication/authorization, which still governs API access. Option D is wrong because a validating webhook with failurePolicy 'Ignore' causes the API server to ignore the webhook's failure and continue processing, not stop processing further webhooks.

Exam trap

The trap is mixing up mutating vs validating semantics and failurePolicy values — candidates assume validating webhooks can 'fix' objects or that 'Ignore' means 'deny,' when it actually means 'skip and continue.'

Practice this question →

MCQeasy

An administrator needs to grant read-only access to Pods specifically within the 'development' namespace to a new user. Which RBAC configuration correctly scopes this permission?

A.Create a ClusterRole for Pod read access and bind it to the user using a RoleBinding in the 'development' namespace.

B.Annotate the user's ServiceAccount with namespace read permissions.

C.Create a Role for Pod read access in the 'development' namespace and bind it to the user using a RoleBinding in the same namespace.

D.Create a Role for Pod read access and bind it globally using a ClusterRoleBinding.

AnswerC

A Role grants permissions within a single namespace, and a RoleBinding in that same namespace ties those permissions to the user. This confines Pod read access to 'development' only, satisfying the namespace-scoped constraint; a ClusterRole with ClusterRoleBinding would grant cluster-wide access instead.

Why this answer

To grant read-only access to Pods within a specific namespace, you create a Role in that namespace with the necessary permissions and bind it to the user using a RoleBinding in the same namespace. This scopes the permission to the 'development' namespace only, following the principle of least privilege.

Exam trap

The trap is confusing Role and ClusterRole, or RoleBinding and ClusterRoleBinding, and incorrectly thinking that a ClusterRoleBinding can be namespace-scoped or that a Role can be bound cluster-wide.

How to eliminate wrong answers

Option A is wrong because while a ClusterRole can be bound with a RoleBinding to limit scope to a namespace, the question asks for the correct RBAC configuration; creating a ClusterRole is unnecessary and less precise than creating a Role directly. However, it is technically valid, but the most correct answer is C because it uses a Role. Option B is wrong because annotating a ServiceAccount does not grant permissions; RBAC requires Role/ClusterRole and RoleBinding/ClusterRoleBinding.

Option D is wrong because binding a Role with a ClusterRoleBinding is not possible; ClusterRoleBinding requires a ClusterRole, and it would grant cluster-wide access, not namespace-scoped.

Practice this question →

MCQeasy

You need to restrict network traffic so that only pods with the label 'tier=frontend' can communicate with pods labeled 'tier=backend' in the same namespace. Which Kubernetes resource should you create?

A.NetworkPolicy

B.Ingress

C.FirewallRule

D.Service

AnswerA

A NetworkPolicy selects pods via label selectors and enforces ingress rules at the pod level, permitting traffic only from pods labelled tier=frontend to those labelled tier=backend within the namespace. This directly satisfies the stem's requirement for label-based, namespace-scoped traffic restriction, which Kubernetes NetworkPolicy is purpose-built to provide.

Why this answer

NetworkPolicy is the native Kubernetes resource designed to control pod-to-pod traffic at L3/L4 by selecting pods via label selectors. A NetworkPolicy with a podSelector matching 'tier=backend' and an ingress rule with a podSelector matching 'tier=frontend' restricts ingress to only those pods. This is enforced by the CNI plugin (e.g., Calico, Cilium) on each node.

Exam trap

The trap here is confusing Service (which routes traffic) with NetworkPolicy (which filters traffic) — candidates often pick Service thinking it 'restricts' access, when it actually just load-balances.

How to eliminate wrong answers

Option B is wrong because Ingress manages external HTTP/HTTPS traffic into the cluster (L7 routing to Services), not pod-to-pod communication. Option C is wrong because FirewallRule is not a Kubernetes resource — it is a cloud-provider construct (e.g., Azure/GCP) that operates at the VNet/VPC level, not on pod labels. Option D is wrong because a Service provides stable networking/load balancing to a set of pods but does not enforce any access control or traffic restriction.

Practice this question →

Multi-Selecthard

Which THREE components are involved when an external client authenticates to the Kubernetes API server using OpenID Connect (OIDC)? (Choose THREE)

Select 3 answers

A.The OIDC Identity Provider (IdP) issuing ID tokens.

B.The CoreDNS server resolving the OIDC provider domain.

C.The client (such as kubectl) presenting the OIDC token in the Authorization header.

D.The Kubelet running on worker nodes.

E.The kube-apiserver configured with OIDC issuer flags.

AnswersA, C, E

The external OIDC provider authenticates the user and issues signed ID tokens containing identity claims. This satisfies the stem's authentication flow because the Kubernetes API server trusts and validates those tokens; without an issuing IdP there is no token for the client to present.

Why this answer

Option A is correct because the OIDC Identity Provider (IdP) is the external authority that authenticates the user and issues the signed ID token (JWT) that the Kubernetes API server will later validate. Option C is correct because the client, such as kubectl, must obtain that ID token and present it to the API server in the HTTP Authorization header as a Bearer token, which is how the credentials reach the API server. Option E is correct because the kube-apiserver must be started with OIDC flags such as --oidc-issuer-url, --oidc-client-id, and --oidc-username-claim so it knows which issuer to trust and how to validate and map the token claims to a Kubernetes user.

Option B is not required for OIDC authentication itself; CoreDNS resolves cluster service names, and while DNS may be needed for general connectivity, it is not a component of the OIDC authentication flow. Option D is also not involved, since the kubelet runs on worker nodes to manage pods and does not participate in authenticating an external client to the API server.

Exam trap

The trap is including infrastructure components like CoreDNS or kubelet that seem plausibly involved in cluster communication but are not part of the OIDC authentication path — focus on IdP, client, and API server.

Practice this question →

Multi-Selectmedium

Which TWO of the following statements are true regarding Kubernetes Secrets and their security posture by default?

Select 2 answers

A.Mounting a Secret as an environment variable can expose the secret value in container logs or crash dumps.

B.Secrets are strongly encrypted at rest using AES-256 encryption by default in etcd.

C.RBAC can be used to restrict which users and ServiceAccounts can read Secrets within a namespace.

D.Secrets automatically expire and rotate every 30 days unless explicitly disabled.

E.Secrets encoded in base64 provide cryptographic security comparable to robust symmetric encryption.

AnswersA, C

Environment variables are captured in process memory and inherited by child processes, so a crash dump or an application logging its own environment can leak the value. This satisfies the stem's default-posture constraint: Kubernetes applies no masking or redaction to environment-sourced Secrets, unlike mounted volumes, which exist only as files.

Why this answer

Option A is correct because when a Secret is injected via envFrom or valueFrom into a container's environment, the value can leak into application logs, error output, or crash dumps (e.g., core dumps or stack traces), so environment-variable mounting is considered a weaker exposure path than a tmpfs-backed volume mount. Option C is correct because Kubernetes RBAC governs access to the secrets resource via rules on verbs like get, list, and watch, allowing you to limit which Users, Groups, or ServiceAccounts in a namespace can read Secret objects. Option B is wrong because Secrets are only base64-encoded in etcd by default; encryption at rest requires configuring an EncryptionConfiguration with a provider such as aescbc or kms, so AES-256 is not applied by default.

Option D is wrong because Kubernetes Secrets have no built-in expiration or automatic 30-day rotation mechanism; rotation must be implemented externally or via tooling. Option E is wrong because base64 is merely an encoding, not encryption, and provides no confidentiality or cryptographic protection.

Exam trap

The trap is assuming Kubernetes Secrets are encrypted by default — candidates often confuse base64 encoding with encryption and pick option B or E, but the exam tests that you know Secrets are plaintext in etcd unless EncryptionConfiguration is explicitly enabled.

Practice this question →

Multi-Selectmedium

Which THREE options represent valid ways to supply sensitive data to a container using Kubernetes native features? (Choose THREE)

Select 3 answers

A.Placing the Secret inside a persistent volume formatted with LUKS encryption.

B.Mounting the Secret as a volume in the Pod specification.

C.Querying the Kubernetes API server directly from the container using a ServiceAccount with proper RBAC.

D.Embedding the Secret plaintext string in the container image build args.

E.Injecting Secret keys as environment variables.

AnswersB, C, E

Projecting a Secret as a volume mounts its keys as files inside the container's filesystem, keeping values out of the image and environment. This is a native Kubernetes mechanism for delivering sensitive data without baking it into the Pod spec.

Why this answer

Option B is correct because Kubernetes natively supports mounting a Secret as a volume in a Pod spec (via volumes.secret and volumeMounts), which projects each key as a file inside the container's filesystem. Option C is correct because a container can use its mounted ServiceAccount token to authenticate to the Kubernetes API server and, with appropriate RBAC permissions, read Secret objects directly via the API. Option E is correct because Secret keys can be injected as environment variables using env.valueFrom.secretKeyRef, a standard native mechanism for passing sensitive data to containers.

Option A is not a Kubernetes-native way to supply Secrets; LUKS-encrypted persistent volumes are an external storage/encryption concern and Secrets are not stored in PVs. Option D is not valid because embedding plaintext secrets in image build args exposes them in image layers and build history, and it is not a Kubernetes Secret delivery mechanism.

Exam trap

The trap here is that candidates pick options that sound secure (LUKS encryption, build args) but are not Kubernetes-native Secret delivery mechanisms — the exam rewards knowing the three built-in paths: volume mount, env var, and API retrieval via ServiceAccount.

Practice this question →

Multi-Selecteasy

Which TWO of the following are valid Kubernetes RBAC rule subjects that can be bound to roles or cluster roles?

Select 2 answers

A.Secret

B.User

C.Namespace

D.ServiceAccount

E.PersistentVolume

AnswersB, D

User subjects bind RBAC roles to named human accounts, satisfying the stem's requirement for a valid subject type. Kubernetes authorises requests by matching the authenticated username against RoleBinding or ClusterRoleBinding subjects, and Microsoft Entra ID–backed clusters surface that identity as a User entry.

Why this answer

Option B (User) is correct because Kubernetes RBAC subjects include User, Group, and ServiceAccount, and a User subject is identified by a string name (often an email or certificate CN) in a RoleBinding or ClusterRoleBinding. Option D (ServiceAccount) is correct because ServiceAccount is a first-class RBAC subject, specified with its name and namespace (e.g., system:serviceaccount:<namespace>:<name>) when binding a Role or ClusterRole. Options A (Secret), C (Namespace), and E (PersistentVolume) are not RBAC subjects; they are Kubernetes API resource kinds that can appear in a Role/ClusterRole's rules as resources, but they cannot be bound as the subject of a RoleBinding or ClusterRoleBinding.

Exam trap

KCSA often tests the distinction between RBAC subjects and RBAC resources — candidates see 'Secret,' 'Namespace,' or 'PersistentVolume' and forget that subjects must be identities (User, Group, ServiceAccount), not API objects.

Practice this question →

MCQeasy

You are auditing a cluster and find a pod that mounts the host's root filesystem directly into the container. Which Pod Security Standard rule does this violate?

A.It is permitted under all standards provided the container runs as a non-root user.

B.It violates both baseline and restricted standards by using a hostPath volume.

C.It is fully compliant with the restricted standard as long as 'readOnly: true' is set.

D.It only violates the restricted standard; baseline permits hostPath mounts.

AnswerB

Mounting the host root filesystem uses a hostPath volume, which the baseline standard forbids and the restricted standard also prohibits. The pod therefore breaches both standards, satisfying the audit finding that hostPath is the violating mechanism.

Why this answer

Mounting the host's root filesystem via a hostPath volume violates both the baseline and restricted Pod Security Standards. The baseline standard prohibits hostPath volumes (except for a few specific, safe paths), and the restricted standard prohibits them entirely. Therefore, this pod violates both.

Exam trap

KCSA often tests the specific differences between baseline and restricted Pod Security Standards, and candidates may incorrectly assume that readOnly: true makes hostPath compliant or that baseline allows any hostPath.

How to eliminate wrong answers

Option A is wrong because hostPath volumes are not permitted under all standards even if the container runs as non-root; the baseline and restricted standards explicitly restrict hostPath. Option C is wrong because the restricted standard does not permit hostPath volumes even with readOnly: true; readOnly does not make it compliant. Option D is wrong because baseline does not permit hostPath mounts (except for a limited set of paths like /proc, /sys, etc., but not the host root filesystem); thus it violates baseline as well.

Practice this question →

MCQhard

You have configured a NetworkPolicy with an egress rule targeting a specific CIDR block. However, DNS resolution for external domain names fails from within the pods selected by this policy. What is the most likely cause?

A.NetworkPolicies automatically disable CoreDNS across the entire namespace.

B.DNS packets are rejected because they do not contain IP block headers.

C.The external domain name does not have a corresponding Service object.

D.Outgoing DNS traffic on UDP/TCP port 53 to the cluster DNS server was blocked by the default-deny egress behavior.

AnswerD

A default-deny egress policy blocks all outbound traffic, including UDP and TCP port 53 queries to the cluster DNS service. Without an explicit egress rule permitting DNS, pods cannot resolve external domain names even though the CIDR rule allows other destinations.

Why this answer

When a NetworkPolicy with egress rules is applied, it acts as a default-deny for all egress traffic except what is explicitly allowed. DNS resolution requires egress to the cluster DNS service (often CoreDNS) on UDP/TCP port 53. If that traffic is not allowed, DNS queries fail, causing resolution errors.

Exam trap

KCSA often tests NetworkPolicy egress rules, and candidates may overlook the need to explicitly allow DNS traffic, assuming DNS is always permitted.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies do not disable CoreDNS; they only control traffic to and from selected pods. Option B is wrong because DNS packets are UDP/TCP and do not have IP block headers; the issue is port/protocol blocking. Option C is wrong because external domain names do not require a Service object; DNS resolution is about querying the DNS server, not about Services.

Practice this question →

MCQmedium

A security auditor notices that a deployment running in the 'production' namespace is violating the Restricted Pod Security Standard because containers are running as root. How can you enforce compliance using Pod Security Admission?

A.Label the 'production' namespace with 'pod-security.kubernetes.io/enforce=restricted'.

B.Create a NetworkPolicy that blocks root user communication.

C.Enable the SecurityContextDeny legacy admission controller.

D.Update the kube-apiserver flags to globally block non-restricted pods without namespace labels.

AnswerA

Applying the enforce label with the restricted value makes Pod Security Admission actively reject pods that violate the Restricted standard, including root-running containers. This directly enforces compliance in the production namespace rather than merely warning or auditing.

Why this answer

Pod Security Admission is enforced per-namespace via labels, and the label 'pod-security.kubernetes.io/enforce=restricted' applies the Restricted Pod Security Standard to every pod created in that namespace, rejecting non-compliant pods such as those running as root. This is the native, supported mechanism in Kubernetes 1.25+ after PodSecurityPolicy was removed.

Exam trap

KCSA often tests the misconception that Pod Security Admission can be configured globally via apiserver flags or replaced by NetworkPolicy — candidates who don't know PSA is namespace-label driven pick B or D.

How to eliminate wrong answers

Option B is wrong because NetworkPolicy operates at L3/L4 and has no concept of user IDs or root — it cannot enforce runAsNonRoot or any security context setting. Option C is wrong because SecurityContextDeny is a deprecated legacy admission controller that was removed in Kubernetes 1.13 and never enforced the full Restricted PSS. Option D is wrong because Pod Security Admission is namespace-label driven by design; there is no kube-apiserver flag that globally enforces a PSS profile without namespace labels, and modifying apiserver flags is not how PSA is configured.

Practice this question →

MCQhard

An application pod requires access to the Kubernetes API to list other pods. To follow secure practices, you create a dedicated ServiceAccount and bind a custom Role to it. How should you configure the Pod specification to prevent the default service account token from being automatically mounted?

A.Delete the 'default' ServiceAccount in the namespace.

B.Set 'automountServiceAccountToken: false' in the Pod specification.

C.Configure the Pod securityContext with 'readOnlyRootFilesystem: true'.

D.Add a deny NetworkPolicy blocking egress to the Kubernetes API service IP.

AnswerB

Setting automountServiceAccountToken to false in the Pod specification stops Kubernetes injecting the default ServiceAccount token, so the pod uses only its dedicated ServiceAccount credentials. This removes an unnecessary, broadly permissioned token from the pod's filesystem.

Why this answer

Setting automountServiceAccountToken: false in the Pod spec prevents Kubernetes from automatically projecting the ServiceAccount token into the pod's filesystem. This is the correct way to stop the default token mount while still allowing the pod to use a dedicated ServiceAccount for API access when needed. The pod can still explicitly mount a token if required, but automatic mounting is disabled.

Exam trap

KCSA often tests whether candidates know that automountServiceAccountToken is the direct control for token mounting, while securityContext and NetworkPolicy address unrelated concerns — don't pick filesystem or network hardening for a token-mounting question.

How to eliminate wrong answers

Option A is wrong because deleting the default ServiceAccount is disruptive and unnecessary; Kubernetes recreates it, and it does not control per-pod token mounting. Option C is wrong because readOnlyRootFilesystem hardens the container filesystem but has no effect on whether the ServiceAccount token is mounted. Option D is wrong because a NetworkPolicy blocking egress to the API server IP prevents network access but does not stop the token from being mounted into the pod, and it would also break legitimate API calls the app needs.

Practice this question →

MCQeasy

A cluster administrator needs to grant read-only access to pods within the 'development' namespace using Kubernetes RBAC. Which resource kind should be used to define the permissions?

A.SecurityContextConstraints

B.Role

C.PodSecurityPolicy

D.ClusterRole

AnswerB

A Role defines permissions scoped to a single namespace, so it grants read-only pod access within 'development' only. ClusterRole would apply cluster-wide, breaching the namespace constraint. Binding the Role via RoleBinding to the intended subjects completes the RBAC grant.

Why this answer

A Role is a namespaced Kubernetes resource that defines permissions within a specific namespace. Since the requirement is to grant read-only access to pods in the 'development' namespace, a Role scoped to that namespace is the correct choice. It can be bound to a user, group, or service account via a RoleBinding to grant the necessary permissions.

Exam trap

KCSA often tests the difference between namespaced and cluster-scoped RBAC resources, and candidates may incorrectly choose ClusterRole thinking it is required for any permission, or confuse SecurityContextConstraints with RBAC.

How to eliminate wrong answers

Option A is wrong because SecurityContextConstraints (SCCs) are OpenShift-specific resources that control pod security policies, not RBAC permissions for accessing pods. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) was used to control pod security settings, not to grant read access to pods. Option D is wrong because a ClusterRole is cluster-scoped and grants permissions across all namespaces; while it could be used with a RoleBinding to grant access within a namespace, it is not the most precise resource for namespace-specific permissions and is typically used for cluster-wide access or for defining reusable permissions.

Practice this question →

MCQhard

A security team runs a multi-tenant cluster and wants a single, cluster-scoped policy that restricts which PersistentVolumeClaim StorageClasses each tenant namespace may use, rejecting any PVC that requests a non-approved StorageClass at admission time. They prefer a declarative, Kubernetes-native mechanism that requires no custom controller code. Which approach best meets this requirement?

A.A MutatingAdmissionWebhook that rewrites the PVC's storageClassName to an approved value before validation

B.A ResourceQuota in each tenant namespace that limits the number of PersistentVolumeClaims allowed

C.A ValidatingAdmissionPolicy with a CEL expression matching PersistentVolumeClaim objects, bound via a ValidatingAdmissionPolicyBinding with cluster scope

D.A ValidatingWebhookConfiguration pointing at a custom admission webhook service that inspects PVC StorageClass values

AnswerC

ValidatingAdmissionPolicy is a built-in, cluster-scoped admission mechanism that evaluates CEL expressions against incoming objects without requiring a webhook server. A cluster-scoped binding applies the rule to PVCs in all namespaces, and the CEL expression can inspect spec.storageClassName to reject non-approved values, satisfying the declarative, no-custom-controller requirement.

Why this answer

ValidatingAdmissionPolicy with a CEL expression lets administrators express admission rules directly in the cluster without deploying a webhook backend. Binding it at cluster scope applies the StorageClass restriction to PVCs across all tenant namespaces, and the expression can deny any claim whose spec.storageClassName falls outside the approved set, fully matching the declarative, native requirement.

Exam trap

The trap here is reaching for a ValidatingWebhookConfiguration out of habit, forgetting it requires an external webhook service while ValidatingAdmissionPolicy is built in.

Practice this question →

MCQhard

An external identity provider (OIDC) is integrated with your Kubernetes cluster. You want to restrict a group named 'contractors' so they can only view pods in the 'staging' namespace. Which configuration correctly maps this requirement?

A.A ClusterRole granting pod read access bound via a RoleBinding in the 'staging' namespace to the subject kind 'Group' with name 'contractors'.

B.A Namespace-scoped ServiceAccount configured with an OIDC JWT issuer URL.

C.A Role in the 'staging' namespace bound via a ClusterRoleBinding to the 'contractors' group.

D.An OIDC webhook configuration in the kube-apiserver specifying namespace boundaries.

AnswerA

A RoleBinding in the 'staging' namespace scopes the pod read permissions to that namespace only, satisfying the least-privilege constraint. Binding the ClusterRole to subject kind 'Group' named 'contractors' correctly maps the OIDC group claim, since Microsoft Entra ID supplies group membership as a group claim rather than individual user bindings.

Why this answer

A ClusterRole defines the permissions (read pods) at cluster scope, and a RoleBinding in the 'staging' namespace binds that ClusterRole to the 'contractors' Group, restricting the grant to only that namespace. This is the canonical pattern for granting cluster-defined permissions to a group within a single namespace.

Exam trap

KCSA often tests the RoleBinding-vs-ClusterRoleBinding distinction — candidates pick ClusterRoleBinding thinking 'ClusterRole needs ClusterRoleBinding', missing that a RoleBinding can reference a ClusterRole and scope it to one namespace.

How to eliminate wrong answers

Option B is wrong because a ServiceAccount is a workload identity, not a way to map an external OIDC group — OIDC groups are mapped via RBAC subjects of kind Group, not ServiceAccounts, and a ServiceAccount cannot carry an OIDC issuer URL. Option C is wrong because a ClusterRoleBinding grants permissions cluster-wide, so binding a staging Role via ClusterRoleBinding would not restrict the group to the staging namespace and is a privilege escalation risk. Option D is wrong because OIDC integration is configured via kube-apiserver flags (--oidc-issuer-url, --oidc-client-id, --oidc-groups-claim), not via a webhook configuration, and there is no 'namespace boundary' field in OIDC config.

Practice this question →

MCQeasy

An application running in a pod needs to securely consume a database password without storing it in plaintext within the container image or deployment manifest. Which native Kubernetes resource is best suited for storing this sensitive key-value data?

A.PersistentVolumeClaim

B.ResourceQuota

C.Secret

D.ConfigMap

AnswerC

Secrets store sensitive key-value data separately from pod specifications and container images, so the database password never appears in plaintext in the deployment manifest. Pods consume it via environment variables or mounted volumes, satisfying the requirement to avoid embedding credentials in the image.

Why this answer

A Kubernetes Secret is the native resource designed to hold sensitive key-value data such as passwords, tokens, and TLS keys, keeping them out of container images and manifests. Pods consume Secrets via environment variables or mounted volumes, and the API server stores them base64-encoded (with optional encryption at rest via EncryptionConfiguration). ConfigMaps are for non-sensitive configuration, so a database password belongs in a Secret.

Exam trap

KCSA often tests the misconception that base64 encoding in a Secret equals encryption, luring candidates toward ConfigMap or assuming Secrets are automatically encrypted at rest.

How to eliminate wrong answers

Option A is wrong because a PersistentVolumeClaim only requests storage from a PersistentVolume and has nothing to do with storing key-value secrets. Option B is wrong because a ResourceQuota enforces namespace-level limits on resource consumption (CPU, memory, object counts), not secret storage. Option D is wrong because a ConfigMap is intended for non-confidential configuration data and is stored in plaintext without the sensitivity handling that Secrets provide.

Practice this question →

Multi-Selectmedium

Which TWO of the following actions are considered best practices for securing Kubernetes Secrets? (Choose TWO)

Select 2 answers

A.Store database passwords in plaintext ConfigMaps for easier application ingestion.

B.Enable encryption at rest for Secret resources in etcd.

C.Rely on base64 encoding as the primary encryption mechanism for sensitive data.

D.Strictly limit RBAC permissions so that only necessary users and service accounts can read Secrets.

E.Mount Secrets as writable volumes so applications can update their own credentials.

AnswersB, D

Encrypting Secrets at rest protects the etcd datastore, where Kubernetes persists Secret objects unencrypted by default. Enabling an encryption provider configuration ensures that anyone reading etcd's underlying files or backups cannot recover plaintext credentials, directly satisfying the best-practise requirement to secure Secret data beyond RBAC and API-level controls.

Why this answer

Option B is correct because enabling encryption at rest for Secret resources protects the data stored in etcd, so even if an attacker gains access to the etcd data files or backups, the Secret contents are encrypted rather than exposed as plaintext. Option D is correct because Kubernetes Secrets are only as secure as the RBAC policy around them; strictly limiting who and which service accounts can read Secrets reduces the risk of credential theft and follows least-privilege best practice. Option A is not a best practice because ConfigMaps are not designed for sensitive data and store values in plaintext, making database passwords easily readable.

Option C is incorrect because base64 is merely an encoding, not encryption, and provides no confidentiality. Option E is not recommended because mounting Secrets as writable volumes can allow applications or attackers to modify credentials and increases the attack surface; Secrets should generally be mounted read-only unless there is a specific need.

Exam trap

KCSA often tests the misconception that base64 encoding equals encryption — candidates pick the base64 answer or the ConfigMap answer, missing that only encryption at rest plus RBAC least privilege constitute real Secret security.

Practice this question →

MCQhard

When configuring a MutatingWebhookConfiguration, you notice that mutating webhooks are executed before validating webhooks. Why is this execution order critical for security and consistency?

A.It ensures that validating webhooks evaluate the final, mutated state of the object rather than the original input.

B.It prevents mutating webhooks from timing out while waiting for validation checks.

C.Mutating webhooks require encryption keys generated during the validation phase.

D.It allows validating webhooks to override any changes made by mutating webhooks if security violations occur.

AnswerA

Mutating webhooks run first so they can alter the object before admission. Validating webhooks then assess that mutated result, ensuring policies are enforced against the exact configuration that will persist, rather than a pre-mutation version that could bypass security checks.

Why this answer

Mutating webhooks run before validating webhooks so that validating webhooks evaluate the final, mutated version of the object. This ensures that validation is performed against the actual state that will be persisted, preventing inconsistencies and security gaps where a mutation could bypass validation.

Exam trap

KCSA often tests the admission control order and its security implications, and candidates may incorrectly think validating webhooks can override mutations or that order is for performance.

How to eliminate wrong answers

Option B is wrong because the order is not about preventing timeouts; it is about ensuring validation sees the final object. Option C is wrong because mutating webhooks do not require encryption keys generated during validation; encryption is unrelated to webhook ordering. Option D is wrong because validating webhooks cannot override changes made by mutating webhooks; they can only allow or deny the final object.

Practice this question →

MCQhard

Your cluster uses the Pod Security admission controller with the 'restricted' profile enforced. A legacy application pod fails to start because it requires running as root (runAsNonRoot: false). How should you handle this securely without disabling the standard?

A.Disable the Pod Security admission controller entirely across the cluster.

B.Configure the Pod Security admission configuration file on the control plane to exempt the specific ServiceAccount or namespace from the restricted check.

C.Set the namespace enforce level to 'privileged' permanently.

D.Mount the host socket inside the pod to bypass user namespace restrictions.

AnswerB

Exempting the specific ServiceAccount or namespace via the admission configuration file lets the legacy root-requiring pod run while the restricted profile stays enforced cluster-wide. This is the documented, least-privilege exception mechanism, avoiding the insecure option of disabling the standard entirely.

Why this answer

The Pod Security admission configuration file (passed to kube-apiserver via --admission-control-config-file) supports per-namespace and per-ServiceAccount exemptions from a given Pod Security level. Exempting the specific ServiceAccount or namespace that runs the legacy root-requiring workload lets that pod start while the 'restricted' profile remains enforced everywhere else. This is the least-privilege, targeted approach that preserves cluster-wide security posture.

Exam trap

The trap here is assuming the only ways to handle a restricted-profile failure are to disable the controller or downgrade the whole namespace, when the exam expects knowledge of the granular exemptions stanza in the Pod Security admission configuration file.

How to eliminate wrong answers

Option A is wrong because disabling the Pod Security admission controller removes enforcement cluster-wide, eliminating a core defense-in-depth control and exposing all workloads to privilege escalation. Option C is wrong because setting the namespace enforce level to 'privileged' permanently disables all Pod Security restrictions for that namespace, not just for the one legacy pod, which is far broader than necessary. Option D is wrong because mounting the host socket (e.g., /var/run/docker.sock or containerd socket) is a severe container escape vector that grants effective host root — it bypasses security rather than handling the exception securely.

Practice this question →

MCQmedium

A platform team runs a shared Kubernetes cluster where each tenant namespace contains a ServiceAccount named 'builder'. CI pipelines in the 'ci' namespace authenticate as 'ci:builder' and need to create Deployments only in that same namespace. A security engineer must write a RoleBinding that grants the 'edit' ClusterRole to this identity without granting rights in any other namespace. Which subject entry should the RoleBinding contain?

A.kind: ServiceAccount, name: builder, namespace: default

B.kind: ServiceAccount, name: builder, namespace: ci

C.kind: User, name: ci:builder

D.kind: Group, name: system:serviceaccounts:ci

AnswerB

A RoleBinding lives in a namespace and can reference a ServiceAccount from that same namespace by setting kind to ServiceAccount along with its name and namespace. Binding the built-in edit ClusterRole here grants the CI identity rights only within the 'ci' namespace, which is exactly the least-privilege scope the security engineer needs.

Why this answer

A namespaced RoleBinding grants permissions only inside its own namespace, and a ServiceAccount subject is identified by its name plus its namespace. Referencing 'builder' in the 'ci' namespace ties the edit ClusterRole to precisely the CI identity that needs to create Deployments there, while leaving every other namespace untouched.

Exam trap

The trap here is assuming the colon-delimited authenticated username 'ci:builder' should be written as a User subject instead of referencing the ServiceAccount object itself.

Practice this question →

MCQhard

You are reviewing admission webhook configurations and notice that timeoutSeconds is set to 3 seconds for a critical validation webhook. If the webhook server takes 4 seconds to respond, what does the API server do when failurePolicy is 'Ignore'?

A.It quarantines the pod in a Pending state.

B.It rejects the API request immediately.

C.It retries the webhook request indefinitely until it responds.

D.It allows the API request to proceed as if the webhook succeeded.

AnswerD

With failurePolicy set to Ignore, a webhook call exceeding timeoutSeconds is treated as non-blocking, so the API server admits the request without the webhook's verdict. The 4-second response arrives too late to affect the outcome.

Why this answer

With failurePolicy set to Ignore, when the webhook exceeds timeoutSeconds (3s) and takes 4s to respond, the API server abandons the call and admits the request as if the webhook had allowed it. Ignore means failures — including timeouts — are non-blocking. The request proceeds without the webhook's validation result.

Exam trap

The trap is assuming a timeout always blocks the request — candidates forget that failurePolicy governs the outcome, and Ignore means timeouts and errors are swallowed, letting the request through.

How to eliminate wrong answers

Option A is wrong because Kubernetes has no quarantine mechanism that parks pods in Pending due to webhook timeouts; Pending reflects scheduling or image pull issues, not admission outcomes. Option B is wrong because immediate rejection describes failurePolicy: Fail, not Ignore. Option C is wrong because the API server does not retry webhook calls indefinitely; it makes a single call bounded by timeoutSeconds (default 10s, max 30s) and then applies the failurePolicy.

Practice this question →

MCQeasy

A security engineer wants to apply Pod Security Standards globally across an entire namespace using the modern built-in admission mechanism. Which approach should be used?

A.Create a MutatingWebhookConfiguration that injects security contexts into every pod spec.

B.Apply labels such as 'pod-security.kubernetes.io/enforce=restricted' to the namespace metadata.

C.Modify the kubelet configuration file on every worker node to enable restricted mode.

D.Deploy a custom PodSecurityPolicy object targeting the namespace selector.

AnswerB

Pod Security Admission is built into the API server and enforces Pod Security Standards per namespace via labels such as pod-security.kubernetes.io/enforce. Labelling namespace metadata applies the restricted profile globally across that namespace, satisfying the stem's modern built-in mechanism requirement.

Why this answer

The correct approach is to apply labels to the namespace metadata, such as 'pod-security.kubernetes.io/enforce=restricted'. This is the built-in Pod Security Admission (PSA) mechanism introduced in Kubernetes 1.23, which enforces Pod Security Standards (PSS) at the namespace level. By labeling the namespace, the PSA controller automatically validates pod creation against the specified policy (privileged, baseline, or restricted) without needing external webhooks or node-level changes.

This method is the modern, native way to apply PSS globally across a namespace.

Exam trap

KCSA often tests the confusion between deprecated PodSecurityPolicy and the modern Pod Security Admission, leading candidates to pick PSP-related answers even though PSP is removed in recent Kubernetes versions.

How to eliminate wrong answers

Option A is wrong because a MutatingWebhookConfiguration is used to mutate pod specs, not to enforce Pod Security Standards; it would require custom logic and is not the built-in admission mechanism. Option C is wrong because kubelet configuration does not control Pod Security Standards; kubelet settings affect node-level behavior, not namespace-wide pod admission policies. Option D is wrong because PodSecurityPolicy (PSP) is a deprecated and removed feature (as of Kubernetes 1.25) and is not the modern built-in mechanism; it also requires enabling the PSP admission controller and does not use namespace labels for enforcement.

Practice this question →

Multi-Selecthard

Which TWO components are involved in configuring and processing admission webhooks in a Kubernetes cluster?

Select 2 answers

A.kube-apiserver

B.ValidatingWebhookConfiguration

C.kube-proxy

D.kubelet

E.etcd daemon

AnswersA, B

The kube-apiserver hosts the admission chain, invoking mutating then validating webhooks during API request processing. It satisfies the stem's requirement for a component that processes webhooks, since it calls registered webhook endpoints and enforces their decisions before persisting objects to etcd.

Why this answer

The kube-apiserver (A) is the component that actually invokes admission webhooks: when a request reaches the admission chain, the API server sends an AdmissionReview request over HTTPS to each matching webhook and processes the returned AdmissionReview response to allow or deny the object. ValidatingWebhookConfiguration (B) is the cluster-scoped API resource that registers validating webhooks with the API server, specifying the webhook's clientConfig (URL or service reference), the rules that select which resources/operations trigger it, and failurePolicy, so it is essential to configuring admission webhooks. kube-proxy (C) only programs Service/Endpoint networking rules (iptables/IPVS) on nodes and plays no role in the admission chain. kubelet (D) runs pods on a node and does not evaluate admission webhooks. The etcd daemon (E) merely stores cluster state, including webhook configuration objects, but does not configure or process admission requests.

Exam trap

KCSA often tests the confusion between node-level components (kubelet, kube-proxy) and control-plane admission machinery, tempting candidates to pick kubelet as a webhook processor.

Practice this question →

MCQmedium

An application pod requires read access to secrets in the 'production' namespace. You need to bind a pre-existing ClusterRole named 'secret-reader' to a service account named 'app-sa' in that namespace. Which RBAC resource accomplishes this?

A.ClusterRoleBinding referencing the Role 'secret-reader'

B.NamespaceRoleBinding referencing the ClusterRole

C.RoleBinding referencing the ClusterRole 'secret-reader'

D.ServiceAccountBinding referencing the ClusterRole

AnswerC

A RoleBinding grants permissions within a single namespace, so binding the existing ClusterRole 'secret-reader' to 'app-sa' in 'production' satisfies the requirement for namespace-scoped secret read access. Unlike a ClusterRoleBinding, which would grant cluster-wide access, this confines the permissions correctly.

Why this answer

A RoleBinding grants the permissions defined in a referenced Role or ClusterRole to subjects within a specific namespace. Binding the pre-existing ClusterRole 'secret-reader' via a RoleBinding in the 'production' namespace grants those permissions only in that namespace to the 'app-sa' service account. This is the standard pattern for reusing a ClusterRole's permission set in a single namespace.

Exam trap

KCSA often tests the subtle rule that a RoleBinding can reference a ClusterRole but a ClusterRoleBinding cannot reference a Role, and candidates frequently confuse the two binding types or invent non-existent kinds.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding grants permissions cluster-wide and cannot reference a namespaced Role — it only references ClusterRoles, and it would violate the namespace-scoped requirement. Option B is wrong because 'NamespaceRoleBinding' is not a real Kubernetes resource kind; the correct kinds are RoleBinding and ClusterRoleBinding. Option D is wrong because 'ServiceAccountBinding' is not a Kubernetes resource kind — service accounts are bound via RoleBinding or ClusterRoleBinding.

Practice this question →

MCQmedium

A CI/CD pipeline service account needs permission to create Deployments and Services across multiple namespaces, but should not have cluster-admin privileges. What is the most secure way to grant these permissions?

A.Define a ClusterRole with the required verbs and resources, then create a RoleBinding for that ClusterRole in each target namespace.

B.Place the service account in the kube-system namespace.

C.Grant the service account permissions at the node level using kubeconfig overrides.

D.Create a ClusterRoleBinding linking the default cluster-admin ClusterRole to the service account.

AnswerA

A ClusterRole defines the required verbs and resources once, while RoleBindings scope that permission to each target namespace. This satisfies the least-privilege constraint: the service account gains Deployment and Service creation only where bound, never cluster-wide, unlike a ClusterRoleBinding which would grant access across all namespaces.

Why this answer

A ClusterRole defines permissions cluster-wide but does not grant them until bound. By creating a RoleBinding in each target namespace that references the ClusterRole, the service account receives only the specified verbs (create) on the specified resources (Deployments, Services) within those namespaces. This follows the principle of least privilege and avoids cluster-admin rights.

Exam trap

KCSA often tests the misconception that a ClusterRole always grants cluster-wide permissions; in fact, it only defines permissions, and a RoleBinding can restrict its scope to a single namespace.

How to eliminate wrong answers

Option B is wrong because placing the service account in kube-system does not grant any permissions; namespace placement alone has no RBAC effect. Option C is wrong because kubeconfig overrides are a client-side mechanism and do not grant server-side RBAC permissions; node-level access is unrelated to Kubernetes API authorization. Option D is wrong because binding cluster-admin grants full cluster-wide privileges, violating the requirement to avoid cluster-admin.

Practice this question →

MCQhard

You are troubleshooting a custom controller that fails to read ConfigMaps in the 'kube-system' namespace despite having a ClusterRole bound via a ClusterRoleBinding. What is the most likely reason for this failure?

A.The ClusterRole lacks the required verbs ('get', 'list', 'watch') or resources ('configmaps') for that API group.

B.ClusterRoleBindings cannot be used with ConfigMaps.

C.ClusterRoleBindings are automatically disabled in 'kube-system'.

D.ConfigMaps in 'kube-system' can only be accessed using ServiceAccounts named 'default'.

AnswerA

A ClusterRoleBinding grants whatever permissions the referenced ClusterRole defines; if that role omits get, list or watch on configmaps in the core API group, every request is denied by RBAC regardless of the binding's scope.

Why this answer

A ClusterRole defines permissions on cluster-scoped resources or across all namespaces. If the ClusterRole bound to the controller's ServiceAccount does not include 'get', 'list', 'watch' on 'configmaps' in the relevant API group, the controller cannot read ConfigMaps in any namespace, including kube-system.

Exam trap

KCSA often tests RBAC details, and candidates may assume that a ClusterRoleBinding automatically grants full access, forgetting that the ClusterRole must explicitly include the required verbs and resources.

How to eliminate wrong answers

Option B is wrong because ClusterRoleBindings can grant access to any resource, including ConfigMaps. Option C is wrong because ClusterRoleBindings are not disabled in kube-system; they work cluster-wide. Option D is wrong because ConfigMaps in kube-system are not restricted to the default ServiceAccount; any ServiceAccount with proper RBAC can access them.

Practice this question →

MCQmedium

You are deploying a ValidatingWebhookConfiguration to inspect incoming pod creations. What happens if the webhook fails and the 'failurePolicy' in the webhook configuration is set to 'Fail'?

A.The API request is allowed to proceed without validation.

B.The API request is rejected.

C.The pod is created in a suspended state until the webhook recovers.

D.The kube-apiserver restarts automatically.

AnswerB

With failurePolicy set to Fail, the API server treats an unreachable or erroring webhook as a denial, so the admission chain halts and the pod creation request is rejected rather than admitted. This enforces the stem's inspection guarantee even during webhook outages.

Why this answer

When failurePolicy is set to Fail, the API server treats any webhook call failure (network error, timeout, non-2xx response) as a denial, so the pod creation request is rejected. This is the safe default for security-critical validation because it prevents unvalidated resources from being admitted. The request fails closed rather than open.

Exam trap

The trap is mixing up failurePolicy: Fail with failurePolicy: Ignore — candidates often assume a webhook failure always blocks the request, but only Fail does; Ignore lets it through.

How to eliminate wrong answers

Option A is wrong because allowing the request to proceed describes failurePolicy: Ignore, not Fail. Option C is wrong because Kubernetes has no 'suspended pod' state tied to webhook recovery; pods are either admitted or rejected, and Pending only reflects scheduling/container startup, not admission. Option D is wrong because the kube-apiserver does not restart on webhook failures; it simply returns an error to the client, and the webhook is an external HTTP endpoint the API server calls.

Practice this question →

MCQmedium

An application pod needs to access the Kubernetes API server securely. How does Kubernetes authenticate the pod by default when it communicates with the API server?

A.Using static username and password credentials stored in environment variables.

B.Using a ServiceAccount bearer token mounted inside the pod's filesystem.

C.Using mutual TLS (mTLS) client certificates generated by the kubelet on startup.

D.Using SSH keys stored in the pod's root directory.

AnswerB

The kubelet projects a bound ServiceAccount token into the pod's filesystem, which the application presents as a bearer token to the API server. The API server validates it against the ServiceAccount, authenticating the pod's identity without embedding long-lived credentials in the image.

Why this answer

By default, Kubernetes authenticates pods to the API server using the ServiceAccount token that is automatically mounted into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. The kubelet projects this token into the pod, and the API server validates it as a bearer token tied to the pod's ServiceAccount identity. This is the standard in-cluster authentication mechanism.

Exam trap

KCSA often tests the misconception that pods use client certificates or static credentials, when the default is the auto-mounted ServiceAccount bearer token.

How to eliminate wrong answers

Option A is wrong because static username/password credentials are a legacy, deprecated mechanism and are not the default for pods. Option C is wrong because while the API server uses mutual TLS for client certificate authentication, the kubelet does not generate per-pod client certificates on startup for pod authentication; pods use ServiceAccount tokens instead. Option D is wrong because SSH keys are unrelated to Kubernetes API authentication and are never used for this purpose.

Practice this question →

MCQeasy

An administrator wishes to inspect which admission controllers are currently enabled in a running Kubernetes cluster. Where is this typically configured in a stacked control plane?

A.In the kube-apiserver static pod manifest file under '/etc/kubernetes/manifests/kube-apiserver.yaml'.

B.In the CoreDNS deployment spec.

C.In the kubelet configuration file on each worker node.

D.In the cluster-wide ConfigMap named 'kube-system/cluster-admission'.

AnswerA

Admission controllers are enabled via the `--enable-admission-plugins` flag, which is passed to the kube-apiserver process. In a stacked control plane, the kube-apiserver runs as a static pod, so its flags live in the manifest at `/etc/kubernetes/manifests/kube-apiserver.yaml`. Inspecting that file reveals exactly which plugins are active.

Why this answer

In a kubeadm-provisioned stacked control plane, the kube-apiserver runs as a static pod, and its command-line flags — including --enable-admission-plugins and --disable-admission-plugins — are defined in /etc/kubernetes/manifests/kube-apiserver.yaml. Editing that manifest causes the kubelet to restart the apiserver pod with the new admission controller set.

Exam trap

KCSA often tests whether candidates know that admission controllers are configured as apiserver flags in the static pod manifest, not via ConfigMaps or kubelet config — a common misconception because many other Kubernetes settings are ConfigMap-driven.

How to eliminate wrong answers

Option B is wrong because CoreDNS is a cluster add-on Deployment that only handles DNS resolution; it has no role in configuring apiserver admission behavior. Option C is wrong because the kubelet config (e.g., /var/lib/kubelet/config.yaml) governs node-level behavior like cgroup driver and eviction thresholds, not apiserver admission plugins. Option D is wrong because there is no built-in ConfigMap named 'kube-system/cluster-admission' — admission plugin configuration is a static apiserver flag, not a runtime ConfigMap.

Practice this question →

Multi-Selectmedium

Which TWO mechanisms are used by Kubernetes admission controllers to enforce security policies during the API request lifecycle?

Select 2 answers

A.Validating admission webhooks can reject object definitions that violate security standards.

B.kubelet automatically runs security audits on all container images prior to pull.

C.etcd executes consensus validation scripts to strip unauthorized RBAC rules.

D.Mutating admission webhooks can alter request payloads to enforce defaults like securityContext constraints.

E.kube-proxy inspects network payloads at Layer 7 to block unauthorized API requests.

AnswersA, D

Validating admission webhooks run after mutation and evaluate the final object against policy, returning a denial that blocks persistence. This satisfies enforcement by rejecting non-compliant definitions outright, ensuring only objects meeting security standards reach etcd.

Why this answer

Validating admission webhooks (A) are invoked during the admission phase of the API request lifecycle and can evaluate an object against security policies, returning a denial that causes the API server to reject the request, which is exactly how policies such as Pod Security Standards or custom constraints are enforced. Mutating admission webhooks (D) run before validating webhooks and can modify the incoming request payload, for example injecting a securityContext, defaulting runAsNonRoot, or applying seccomp/AppArmor profiles so that objects comply with security defaults before persistence. The remaining options are incorrect: kubelet (B) pulls and runs containers on nodes but does not perform image security audits as an admission mechanism, etcd (C) is only a key-value store and does not execute validation scripts or strip RBAC rules, and kube-proxy (E) implements Service load balancing at Layers 3/4 and never inspects Layer 7 API payloads.

Exam trap

KCSA often tests whether candidates confuse the admission phase (mutating vs validating webhooks) with unrelated components like kubelet, etcd, or kube-proxy — the trap is picking a plausible-sounding but architecturally wrong component for policy enforcement.

Practice this question →

MCQmedium

An application pod needs to mount a Secret as environment variables. Which section of the Pod manifest should be configured to achieve this securely?

A.Using 'env' with 'valueFrom.secretKeyRef' or 'envFrom' with 'secretRef' in the container specification.

B.Using 'volumeMounts' pointing to a PersistentVolumeClaim bound to the Secret.

C.Adding the Secret name directly to the container imagePullSecrets field.

D.Declaring the Secret in the container securityContext block.

AnswerA

Configuring `env` with `valueFrom.secretKeyRef`, or `envFrom` with `secretRef`, in the container specification injects Secret data as environment variables at pod start. This satisfies the stem's mount-as-environment-variables requirement without exposing the Secret through volumes, keeping credentials out of the manifest and node filesystem.

Why this answer

To expose a Secret as environment variables, you reference it in the container's env or envFrom block using valueFrom.secretKeyRef (for a single key) or envFrom.secretRef (for all keys). This is the standard, supported mechanism for injecting Secret data as environment variables in a Pod manifest.

Exam trap

The trap is confusing Secret consumption methods — candidates may pick volumeMounts or securityContext, but only env/envFrom with secretKeyRef or secretRef injects Secret data as environment variables.

How to eliminate wrong answers

Option B is wrong because PersistentVolumeClaims provide persistent storage volumes, not Secret data; Secrets are mounted via a secret volume source, not a PVC. Option C is wrong because imagePullSecrets is used only to authenticate to container registries when pulling images, not to inject application secrets as env vars. Option D is wrong because securityContext controls Linux security settings (runAsUser, capabilities, seccomp), not environment variable injection from Secrets.

Practice this question →

Multi-Selecteasy

Which TWO components are core parts of the Kubernetes authorization architecture? (Choose TWO)

Select 2 answers

A.Webhook Authorization

B.Role-Based Access Control (RBAC)

C.CoreDNS service discovery

D.Kubelet node daemon

E.etcd key-value datastore

AnswersA, B

Webhook authorization is a core Kubernetes authorization module, letting the API server delegate access decisions to an external HTTP service. It satisfies the requirement for pluggable, policy-driven decisions, integrating with external engines such as Open Policy Agent or Microsoft Entra ID-based tooling without rebuilding the API server.

Why this answer

Webhook Authorization (A) is a core Kubernetes authorization mode that lets the API server send SubjectAccessReview requests to an external HTTP service to decide whether a request is allowed, and it is one of the standard authorization modes configured via --authorization-mode. Role-Based Access Control (B) is also a core authorization component: it uses RBAC API objects such as Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings to grant permissions to users, groups, and ServiceAccounts, and is enabled as an authorization mode on the kube-apiserver. CoreDNS service discovery (C) is a cluster DNS add-on for name resolution, not an authorization mechanism.

Kubelet (D) is the node agent that manages pods and containers, and etcd (E) is the key-value datastore backing cluster state; neither performs authorization decisions for API requests.

Exam trap

The trap here is confusing cluster infrastructure components (like CoreDNS, kubelet, etcd) with authorization mechanisms; candidates might assume any core Kubernetes component plays a role in authorization, but only modules that directly evaluate access requests are part of the authorization architecture.

Practice this question →

MCQhard

A security engineer configures a ValidatingWebhookConfiguration to intercept pod creations. The webhook service goes down due to a network partition. What happens to incoming pod creation requests by default if the webhook 'failurePolicy' is set to 'Fail'?

A.The kubelet automatically bypasses the webhook and starts the container locally.

B.The API server allows the pod creation request and logs a warning.

C.The API server rejects the pod creation request with an error.

D.The API server queues the request until the webhook service recovers.

AnswerC

Under failurePolicy: Fail, a webhook call that cannot complete because of the network partition is treated as a failed admission decision, so the API server denies the request and returns an error to the client rather than admitting the pod.

Why this answer

When a ValidatingWebhookConfiguration has failurePolicy: Fail, the API server treats a webhook call failure (timeout, connection refused, network partition) as a denial and rejects the admission request with an error. This is the safe default for security-critical webhooks because it prevents unvalidated resources from being admitted during an outage.

Exam trap

KCSA often tests the inversion of failurePolicy semantics — candidates assume 'Fail' means 'fail open' or that the API server retries, when in fact Fail means the request is rejected immediately with no retry.

How to eliminate wrong answers

Option A is wrong because kubelet does not participate in admission control — admission webhooks are invoked by the kube-apiserver before the object is persisted to etcd, so kubelet never sees the pod if admission fails. Option B is wrong because that describes failurePolicy: Ignore, which allows the request through on webhook failure; with Fail, the request is rejected. Option D is wrong because the API server does not queue admission requests for retry — it applies the failurePolicy immediately (reject or allow) and returns the result to the client.

Practice this question →

Multi-Selectmedium

Which THREE conditions must be met for a RoleBinding to successfully grant permissions to a ServiceAccount?

Select 3 answers

A.The kubelet must restart to load the binding.

B.The RoleBinding and Role must reside in the same namespace (if using a Role).

C.The RoleBinding must reference an existing Role or ClusterRole.

D.The ServiceAccount must have cluster-admin privileges.

E.The ServiceAccount subject must be correctly specified with its name and namespace.

AnswersB, C, E

A Role is namespaced, and a RoleBinding can only grant permissions defined within its own namespace. If the binding and Role sit in different namespaces, the reference cannot resolve, so co-location is required when binding to a Role rather than a ClusterRole.

Why this answer

Option B is correct because a Role is a namespaced resource, so a RoleBinding can only bind to a Role that exists in the same namespace as the RoleBinding; cross-namespace Role references are not permitted. Option C is correct because the RoleBinding's roleRef must point to a Role or ClusterRole that actually exists, otherwise the binding grants nothing and the API server rejects or the reference is invalid. Option E is correct because the subject entry for a ServiceAccount must include both the ServiceAccount name and its namespace (kind: ServiceAccount, name, namespace), since ServiceAccounts are namespaced identities and an incomplete subject will not match the intended account.

Option A is wrong because RBAC bindings are evaluated dynamically by the API server at request time and require no kubelet restart. Option D is wrong because granting permissions via a RoleBinding does not require the ServiceAccount to hold cluster-admin; the binding itself supplies the permissions, and cluster-admin is unrelated to the binding mechanics.

Exam trap

The trap is the misconception that RBAC changes require a component restart or elevated privileges, when in fact RoleBindings take effect immediately and only need an existing Role/ClusterRole plus a correctly namespaced subject.

Practice this question →

MCQmedium

An enterprise cluster requires that all incoming NetworkPolicies must default to denying all traffic unless explicitly allowed. A developer creates a namespace but forgets to apply any policies. What is the default behavior of Kubernetes regarding inter-pod traffic within a namespace when no NetworkPolicies are present?

A.Only traffic originating from the kube-system namespace is allowed.

B.All traffic between pods is allowed by default.

C.Traffic is allowed only if the pods share the same node.

D.All traffic between pods is denied by default.

AnswerB

Kubernetes NetworkPolicies are additive allowlists; with none applied to a namespace, no isolation exists and every pod-to-pod flow is permitted. The cluster's default-deny requirement therefore needs explicit policies, since the platform itself imposes no implicit denial.

Why this answer

Kubernetes NetworkPolicies operate on an additive allow-list model: if no policy selects a pod, that pod is non-isolated and all ingress/egress traffic is permitted. The default-deny posture only takes effect once at least one NetworkPolicy selects the pod and does not explicitly allow the traffic. Therefore, a namespace with zero policies allows unrestricted inter-pod communication.

Exam trap

KCSA often tests the misconception that Kubernetes ships with an implicit default-deny NetworkPolicy, when in reality pods are non-isolated and fully open until a policy explicitly selects them.

How to eliminate wrong answers

Option A is wrong because kube-system has no special traffic privileges over user namespaces — NetworkPolicies are namespace-scoped and there is no implicit allow rule for kube-system. Option C is wrong because pod-to-pod reachability is determined by the CNI overlay network, not by whether pods share a node; same-node and cross-node traffic are both allowed when no policy exists. Option D is wrong because Kubernetes does not implement an implicit default-deny; default-deny must be explicitly created by applying a policy that selects the pods and specifies empty ingress/egress rules.

Practice this question →

MCQmedium

A cluster operator is enforcing the Pod Security Standards "restricted" profile across a namespace. A developer attempts to deploy a container running as root (runAsUser: 0). What will happen during the admission phase?

A.The pod will be created, but the kubelet will override the user ID to 65534 at runtime.

B.The pod will start successfully in audit mode, generating a warning event in the API server logs.

C.The PodSecurity admission controller will reject the pod creation request.

D.The container will drop all Linux capabilities and proceed with deployment.

AnswerC

Under the restricted profile, runAsNonRoot is mandatory, so a container specifying runAsUser: 0 violates the policy. The PodSecurity admission controller evaluates this during admission and denies the request, preventing the pod from being created in the namespace.

Why this answer

The restricted Pod Security Standard requires containers to run as non-root, among other hardening measures. When a pod attempts to run as root (runAsUser: 0) in a namespace enforcing the restricted profile, the PodSecurity admission controller will reject the pod creation request during the admission phase. This prevents the pod from being created at all.

Exam trap

The trap is confusing audit mode with enforce mode, or thinking that the kubelet or runtime will fix the violation, when in fact the admission controller rejects the pod outright.

How to eliminate wrong answers

Option A is wrong because the kubelet does not override the user ID; the admission controller blocks the pod before it reaches the kubelet. Option B is wrong because audit mode only logs violations and does not block; but the question states 'enforcing', so it's enforce mode, not audit. Option D is wrong because dropping capabilities does not automatically happen; the restricted profile requires capabilities to be dropped, but if the pod doesn't comply, it is rejected, not modified.

Practice this question →

MCQeasy

What is the primary function of the 'automountServiceAccountToken: false' setting in a Pod specification?

A.It deletes the ServiceAccount object from the cluster when the pod terminates.

B.It prevents the pod from communicating with the Kubernetes API server entirely.

C.It disables RBAC authorization checks for the pod.

D.It prevents the ServiceAccount API token from being automatically mounted inside the pod.

AnswerD

Setting `automountServiceAccountToken: false` stops the kubelet projecting the ServiceAccount token into the pod's filesystem at `/var/run/secrets/kubernetes.io/serviceaccount`. This satisfies the least-privilege constraint: workloads that never call the Kubernetes API avoid holding a credential that could be stolen and replayed against the API server.

Why this answer

The 'automountServiceAccountToken: false' setting in a Pod specification prevents the default ServiceAccount token from being automatically mounted into the pod's filesystem. This reduces the attack surface by ensuring the pod does not have credentials to access the Kubernetes API unless explicitly mounted. It does not delete the ServiceAccount, disable RBAC, or block all API communication.

Exam trap

KCSA often tests the misunderstanding that automountServiceAccountToken: false blocks all API access or deletes the ServiceAccount, when it only prevents automatic token mounting.

How to eliminate wrong answers

Option A is wrong because the setting does not delete the ServiceAccount object; it only affects token mounting. Option B is wrong because it does not prevent the pod from communicating with the API server entirely; the pod can still communicate if it obtains a token through other means or if the application doesn't need a token. Option C is wrong because it does not disable RBAC authorization checks; RBAC is enforced by the API server regardless of token mounting.

Practice this question →

MCQeasy

A developer accidentally committed plain-text database passwords into a public Git repository. The password was stored in a Kubernetes Secret manifest. What immediate remediation step should be taken regarding the Secret?

A.Apply a DenyAll NetworkPolicy to the namespace.

B.Delete the Secret object and restart all cluster nodes.

C.Rotate the credential in the underlying database, then update the Kubernetes Secret with the new value.

D.Change the Secret manifest encoding from base64 to hex format.

AnswerC

Once a credential is exposed in a public repository it must be treated as compromised, so rotating the password in the underlying database invalidates the leaked value. Updating the Kubernetes Secret afterwards keeps the cluster functional while ensuring the exposed credential can no longer authenticate.

Why this answer

Once a credential is exposed in a public repository, it must be treated as compromised — the only safe remediation is to rotate the password in the database and update the Kubernetes Secret with the new value. Deleting or re-encoding the Secret does nothing because the old password remains valid in the database and is already in Git history.

Exam trap

The trap is treating Secret deletion or re-encoding as remediation — candidates miss that the credential itself must be rotated at the source, since the leaked value remains valid regardless of what happens to the Kubernetes object.

How to eliminate wrong answers

Option A is wrong because a DenyAll NetworkPolicy only blocks network traffic to pods — it does not invalidate the leaked credential or prevent an attacker who already has it from using it directly against the database. Option B is wrong because deleting the Secret and restarting nodes does not change the database password; the credential is still valid and the Git history still contains it. Option D is wrong because changing base64 to hex is cosmetic — both are trivially reversible encodings, not encryption, and the plaintext password is still recoverable.

Practice this question →

MCQmedium

An administrator wants to ensure that no container in a specific namespace runs with a root User ID (UID 0). Which security context setting should be enforced?

A.privileged: false

B.readOnlyRootFilesystem: true

C.runAsNonRoot: true

D.allowPrivilegeEscalation: false

AnswerC

runAsNonRoot: true forces the kubelet to validate that the container's specified user is not UID 0 before starting it, rejecting the pod otherwise. This enforces the namespace requirement that no container runs as root, unlike runAsUser which merely sets a specific UID.

Why this answer

The runAsNonRoot: true security context setting instructs the kubelet to validate at container start that the image's USER is not UID 0, and to refuse to start the container if it would run as root. Setting it at the pod or container level enforces the no-root requirement across the namespace when combined with Pod Security Admission's restricted profile.

Exam trap

KCSA often tests whether candidates conflate privilege controls — the trap is choosing privileged: false or allowPrivilegeEscalation: false, which restrict capabilities but do not prevent a container from running as UID 0.

How to eliminate wrong answers

Option A is wrong because privileged: false only prevents the container from gaining elevated Linux capabilities and host access — a container can still run as UID 0 with privileged: false. Option B is wrong because readOnlyRootFilesystem: true makes the container's root filesystem immutable, which is a filesystem integrity control unrelated to the user ID the process runs as. Option D is wrong because allowPrivilegeEscalation: false blocks setuid/setgid binaries from gaining more privileges than the parent process, but it does not prevent the container from starting as UID 0 in the first place.

Practice this question →

Multi-Selecthard

Which TWO statements are true regarding Kubernetes NetworkPolicy default behaviors?

Select 2 answers

A.NetworkPolicies automatically block all traffic across all namespaces upon cluster installation.

B.By default, all pods in a cluster are non-isolated and accept traffic from any source.

C.When a NetworkPolicy selects a pod and specifies ingress rules, unallowed ingress traffic is blocked.

D.Egress traffic is blocked by default even if no NetworkPolicy is created.

E.NetworkPolicies apply to cluster nodes rather than individual pods.

AnswersB, C

NetworkPolicy is additive and namespace-scoped. Until a policy selects a pod, that pod is non-isolated and accepts all ingress and egress traffic from any source, so clusters without policies behave as fully open by default.

Why this answer

Option B is correct because Kubernetes starts with a flat, non-isolated network model: unless a NetworkPolicy selects a pod, that pod is non-isolated and accepts ingress from any source and sends egress to any destination. Option C is correct because once a NetworkPolicy selects a pod and defines ingress rules, the pod becomes isolated for ingress, so only traffic explicitly allowed by those rules (plus established return traffic) is permitted and all other ingress is denied. Option A is wrong because NetworkPolicies are namespaced, additive, and opt-in; installing a cluster does not create any policies or block cross-namespace traffic by default.

Option D is wrong because egress is also non-isolated by default—egress is only restricted when a policy selects the pod and includes egress rules (egress isolation). Option E is wrong because NetworkPolicies select pods (via podSelector) within a namespace, not cluster nodes; node-level filtering is handled by other mechanisms such as iptables, nftables, or cloud security groups.

Exam trap

The trap is assuming that NetworkPolicies are active by default or that they block all traffic upon creation, when in fact they only affect pods they select and only for the specified directions.

Practice this question →

MCQeasy

Which RBAC verb allows a user to delete an existing resource in a Kubernetes namespace?

A.delete

B.remove

C.purge

D.destroy

AnswerA

The `delete` verb in Kubernetes RBAC explicitly authorises removal of existing resources, satisfying the stem's requirement to delete a resource within a namespace. It maps directly to the HTTP DELETE method on resource endpoints, distinguishing it from `create`, `update`, or `patch`, which cannot remove objects.

Why this answer

In Kubernetes RBAC, the verb 'delete' is the canonical action that authorizes removal of an existing resource within a namespace (or cluster-scoped resource). It is one of the standard verbs alongside get, list, watch, create, update, patch, and deletecollection. A Role or ClusterRole rule such as 'verbs: ["delete"]' on a resource like pods grants the subject permission to issue DELETE requests against that resource's API endpoint.

Exam trap

The trap is that candidates may pick a synonym like 'remove', 'purge', or 'destroy' because they sound like deletion actions, but Kubernetes RBAC only recognizes the exact verb 'delete' (and 'deletecollection') — verb names are case-sensitive API tokens, not natural-language descriptions.

How to eliminate wrong answers

Option B is wrong because 'remove' is not a recognized Kubernetes RBAC verb — it is not part of the API verb set and would be rejected or simply never match an authorization check. Option C is wrong because 'purge' is not an RBAC verb; it is not defined in the Kubernetes authorization model and has no meaning in Role/ClusterRole rules. Option D is wrong because 'destroy' is not an RBAC verb either; while it sounds destructive, Kubernetes uses 'delete' and 'deletecollection' for removal operations, and 'destroy' would never authorize any API action.

Practice this question →

MCQmedium

Under the Pod Security Standards, a developer attempts to deploy a pod with 'privileged: true' in a namespace labeled with 'pod-security.kubernetes.io/enforce=baseline'. What will happen?

A.The admission controller will reject the pod creation request with an error.

B.The pod will run in a restricted sandbox environment automatically.

C.The pod will be created successfully, but a warning will be logged in the audit log.

D.The kubelet will automatically strip the 'privileged: true' setting and run the pod safely.

AnswerA

The Baseline policy explicitly prohibits privileged containers, so the Pod Security admission controller blocks the request at admission time and returns an error. Enforcement occurs before the pod is persisted, meaning no workload is scheduled — satisfying the stem's enforced baseline constraint rather than merely warning or auditing the violation.

Why this answer

The baseline Pod Security Standard explicitly prohibits privileged containers, so the Pod Security Admission controller will reject the pod creation request when the namespace enforces baseline. The 'enforce' label triggers rejection (not just warning) for any pod violating the baseline policy. Privileged mode is one of the restricted fields baseline forbids.

Exam trap

The trap here is confusing the three PSA label modes — candidates pick 'warning logged' (warn mode) or 'audit log entry' (audit mode) when the question specifies enforce, which always rejects non-compliant pods.

How to eliminate wrong answers

Option B is wrong because Pod Security Standards do not automatically sandbox or downgrade a pod's privileges; they either admit or reject the pod based on the enforce level. Option C is wrong because warnings are produced by the 'warn' label mode, not 'enforce'; with enforce=baseline the request is denied outright, not merely logged. Option D is wrong because the kubelet does not mutate or strip securityContext fields; admission control happens at the API server before scheduling, and no component silently rewrites privileged:true.

Practice this question →

Multi-Selecteasy

Which TWO entities can be assigned RBAC permissions in a Kubernetes cluster? (Choose TWO)

Select 2 answers

A.ConfigMap

B.Namespace

C.ServiceAccount

D.PersistentVolume

E.User

AnswersC, E

ServiceAccounts are namespaced identities used by pods to authenticate to the API server, and they can be bound to Roles or ClusterRoles via RoleBindings. This makes them a valid RBAC subject, satisfying the stem's requirement for entities assignable permissions.

Why this answer

In Kubernetes RBAC, permissions are granted to subjects (the "who") via RoleBindings or ClusterRoleBindings, and the two subject types listed here are ServiceAccount (C) and User (E). A ServiceAccount (C) is a namespaced identity used by Pods and controllers, and it can be bound to Roles or ClusterRoles so workloads receive specific API permissions. A User (E) represents a human or external identity authenticated by the cluster (for example via client certificates or an OIDC provider) and can likewise be referenced as a subject in RoleBinding/ClusterRoleBinding.

By contrast, ConfigMap (A), Namespace (B), and PersistentVolume (D) are API resources/objects that permissions are granted on (the "what"), not subjects that can be assigned permissions.

Exam trap

KCSA often tests the distinction between RBAC subjects and RBAC resources — candidates frequently pick Namespace or ConfigMap because they appear in RoleBinding YAML, but only User, Group, and ServiceAccount are valid subjects.

Practice this question →

MCQmedium

An administrator wants to prevent users from creating pods that mount the host network ('hostNetwork: true'). Which tool or feature is best suited to enforce this restriction natively across the cluster?

A.ResourceQuota limiting network interfaces

B.Pod Security admission controller with baseline or restricted profile

C.RBAC ClusterRole restricting pod creation

D.NetworkPolicy with a deny-all rule

AnswerB

Pod Security admission enforces the baseline and restricted profiles natively at the namespace level, and both explicitly forbid `hostNetwork: true` in their pod specifications. Labelling the target namespace with `pod-security.kubernetes.io/enforce` blocks such pods at admission time, satisfying the cluster-wide restriction without third-party tooling.

Why this answer

Pod Security admission (PSA) is the built-in Kubernetes admission controller that enforces Pod Security Standards at the namespace level using labels. The baseline and restricted profiles explicitly disallow hostNetwork: true, so labeling the namespace with pod-security.kubernetes.io/enforce: baseline (or restricted) blocks pods that request host networking. This is the native, cluster-wide enforcement mechanism.

Exam trap

KCSA often tests the confusion between RBAC (who can act) and admission control (what is allowed), tempting candidates to pick RBAC when the requirement is enforcing pod spec restrictions.

How to eliminate wrong answers

Option A is wrong because ResourceQuota limits resource consumption and object counts; it has no field to restrict network interfaces or hostNetwork. Option C is wrong because RBAC controls who can perform verbs on resources, not the contents of pod specs — a user with create pods permission can still submit a hostNetwork pod unless admission blocks it. Option D is wrong because NetworkPolicy governs pod-to-pod traffic flows, not whether a pod can join the host network namespace.

Practice this question →

MCQhard

You want to enable encryption at rest for Kubernetes Secrets in your cluster using an external KMS (Key Management Service) provider. Which component on the control plane reads the EncryptionConfiguration file and handles this encryption?

A.kube-controller-manager

B.kube-apiserver

C.kubelet

D.etcd daemon directly

AnswerB

The kube-apiserver reads the EncryptionConfiguration file and performs envelope encryption of Secrets before writing them to etcd, delegating data key wrapping to the external KMS provider. No other control plane component touches etcd writes, so this satisfies the requirement for KMS-backed encryption at rest.

Why this answer

The kube-apiserver is the only component that reads the EncryptionConfiguration file (passed via --encryption-provider-config) and performs envelope encryption of Secret data before writing to etcd. It encrypts on write and decrypts on read, so etcd only ever stores ciphertext for protected resources.

Exam trap

KCSA often tests which control-plane component owns a given function — candidates pick etcd or kube-controller-manager because they associate 'storage' or 'cluster management' with encryption, missing that only the API server handles it.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs controllers (Deployment, ReplicaSet, Node) and does not touch the encryption pipeline. Option C is wrong because kubelet runs on worker nodes and manages pod lifecycle — it never writes Secrets to etcd. Option D is wrong because etcd is a passive key-value store; it has no knowledge of Kubernetes encryption providers and simply persists whatever bytes the API server sends.

Practice this question →

MCQmedium

A cluster administrator needs to intercept and reject any resource creation requests that do not include a mandatory security-context label. Which admission controller type should be implemented?

A.MutatingAdmissionWebhook

B.ServiceAccount

C.ValidatingAdmissionWebhook

D.NamespaceLifecycle

AnswerC

ValidatingAdmissionWebhook satisfies the requirement to reject non-compliant requests, as it evaluates objects against custom rules and denies those failing validation. Unlike mutating webhooks, which may alter requests, this controller only permits or blocks them, making it ideal for enforcing the mandatory security-context label without modifying resource definitions.

Why this answer

A ValidatingAdmissionWebhook is the correct choice because it is invoked during the admission review phase and can evaluate an incoming object against custom policy logic, returning an 'allowed: false' response to reject requests that fail validation. Since the requirement is to intercept and reject resource creation requests missing a mandatory label, a validating webhook is purpose-built for this enforcement. Mutating webhooks can only modify objects, not reject them, and built-in controllers like ServiceAccount or NamespaceLifecycle do not perform arbitrary label validation.

Exam trap

KCSA often tests the distinction between mutating and validating admission webhooks, and candidates incorrectly assume a mutating webhook can reject requests or that built-in controllers like NamespaceLifecycle can enforce custom policies.

How to eliminate wrong answers

Option A is wrong because MutatingAdmissionWebhook is designed to mutate (patch) incoming objects before persistence, not to reject them based on policy violations. Option B is wrong because ServiceAccount is a built-in admission controller that automates service account token mounting, not a mechanism for enforcing custom label requirements. Option D is wrong because NamespaceLifecycle only enforces namespace existence and prevents operations in terminating namespaces; it has no capability to validate arbitrary labels on resources.

Practice this question →

MCQeasy

Which of the following describes a recommended security practice when managing Kubernetes Secrets?

A.Use ConfigMaps for passwords and Secrets for plain text configuration.

B.Store secret values in plain text inside public Git repositories for easy collaboration.

C.Limit RBAC access so that only necessary users and service accounts can read secrets.

D.Disable authentication on the Kubernetes API server to simplify secret retrieval.

AnswerC

RBAC restricts secret read verbs to specific users and service accounts, shrinking the blast radius if credentials leak. Least-privilege access directly reduces exposure of sensitive data stored in Secrets, satisfying the recommended practice of limiting who can retrieve them.

Why this answer

The recommended practice is to follow the principle of least privilege by restricting who can read Secrets. Kubernetes Secrets are not encrypted by default; they are only base64-encoded, so any user or service account with get/list/watch permissions on Secrets can easily decode and view sensitive data. Limiting RBAC access ensures that only authorized workloads and administrators can access specific Secrets, reducing the attack surface and potential for credential leakage.

Exam trap

KCSA often tests the misconception that Kubernetes Secrets are encrypted by default or that base64 encoding provides security, leading candidates to overlook the need for strict RBAC controls.

How to eliminate wrong answers

Option A is wrong because ConfigMaps are designed for non-sensitive configuration data and are stored in plain text; using them for passwords would expose credentials. Option B is wrong because storing secrets in plain text in public Git repositories is a severe security risk, as anyone can view and misuse them. Option D is wrong because disabling authentication on the Kubernetes API server would allow unauthenticated access to all resources, including Secrets, completely undermining cluster security.

Practice this question →

MCQmedium

Your team is storing sensitive database credentials in Kubernetes Secrets. A security review reveals that base64 encoding does not provide encryption at rest. What mechanism should you enable to ensure Secrets are encrypted when stored in etcd?

A.Apply a MutatingWebhookConfiguration to automatically hash passwords using bcrypt.

B.Enable TLS encryption for all intra-cluster communication using kubeadm configuration.

C.Configure an EncryptionConfiguration file and reference it via the '--encryption-provider-config' flag on the kube-apiserver.

D.Set the secret type to 'kubernetes.io/encrypted-secret'.

AnswerC

The EncryptionConfiguration resource defines providers (for example, aesgcm or kms) that encrypt Secret objects before they are written to etcd. Passing it via --encryption-provider-config makes the kube-apiserver perform that encryption, closing the base64 plaintext-at-rest gap.

Why this answer

To encrypt Secrets at rest in etcd, you must configure an EncryptionConfiguration file and pass it to the kube-apiserver via the --encryption-provider-config flag. This enables encryption of resources like Secrets before they are stored in etcd.

Exam trap

KCSA often tests the method to encrypt Secrets at rest, and candidates may confuse it with TLS or other encryption mechanisms.

How to eliminate wrong answers

Option A is wrong because MutatingWebhookConfiguration cannot hash passwords in Secrets; it mutates pod specs, not Secret data. Option B is wrong because TLS encryption secures data in transit, not at rest in etcd. Option D is wrong because there is no such Secret type as 'kubernetes.io/encrypted-secret'; Secret types are predefined and do not include encryption.

Practice this question →

Multi-Selectmedium

Which TWO types of selectors can be used within a Kubernetes NetworkPolicy ingress rule to specify allowed traffic sources?

Select 2 answers

A.serviceSelector

B.namespaceSelector

C.ingressSelector

D.nodeSelector

E.podSelector

AnswersB, E

A namespaceSelector matches source pods by their namespace's labels, satisfying the requirement to specify allowed traffic sources in an ingress rule. It operates at namespace granularity, unlike podSelector's per-pod matching, and combines with podSelector within a single from element to permit cross-namespace traffic precisely.

Why this answer

In a Kubernetes NetworkPolicy ingress rule, the from field accepts three selector-based peer types: ipBlock, namespaceSelector, and podSelector. Option B (namespaceSelector) is correct because it selects entire namespaces by their labels, allowing traffic from all pods in matching namespaces (or, when combined with a podSelector in the same from element, only matching pods in matching namespaces). Option E (podSelector) is correct because it selects pods by their labels within the policy's own namespace, defining which pods may send traffic to the selected pods.

Option A (serviceSelector) is incorrect because NetworkPolicy peers are never defined by Service; Services are not valid peer selectors in the API. Option C (ingressSelector) is incorrect because no such selector type exists in the NetworkPolicy spec. Option D (nodeSelector) is incorrect because NetworkPolicy operates at the pod/namespace/IP level and cannot select peers by node labels.

Exam trap

KCSA often tests whether candidates confuse scheduling selectors like nodeSelector with NetworkPolicy selectors; the trap is picking nodeSelector because it sounds like a network source selector.

Practice this question →

MCQmedium

An auditor notices that a secret is mounted as a volume in a pod. Where is this secret stored on the worker node filesystem by default?

A.In an encrypted SQLite database on the node's root partition.

B.In plaintext files inside /etc/kubernetes/secrets on the node's hard drive.

C.Inside the container image layer cache.

D.In tmpfs (memory), ensuring it is not written to non-volatile disk storage.

AnswerD

Kubernetes mounts secrets as tmpfs volumes, a memory-backed filesystem, so the data never touches the node's non-volatile disk. This satisfies the auditor's concern about persistent storage exposure: the secret exists only in RAM and is erased when the pod terminates.

Why this answer

When a secret is mounted as a volume in a pod, the kubelet writes the secret data to a tmpfs (memory-backed) filesystem on the worker node. This ensures the secret is not persisted to non-volatile disk storage by default, reducing the risk of forensic recovery from node disks. The files exist only in RAM and are removed when the pod is deleted.

Exam trap

KCSA often tests the misconception that mounted secrets are written to disk in plaintext; candidates forget that Kubernetes uses tmpfs for secret volumes by default.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not store mounted secrets in an encrypted SQLite database on the node; etcd stores secrets, but the node filesystem mount is tmpfs. Option B is wrong because secrets are not written to /etc/kubernetes/secrets in plaintext on the node's hard drive; that path is not the default mount location and would violate the memory-backed design. Option C is wrong because secrets are not baked into container image layers; image layers are immutable and shared, and secrets are injected at runtime.

Practice this question →

MCQmedium

You have deployed a NetworkPolicy in a namespace that selects backend pods, defining an 'ingress' rule with a 'from' block. No other NetworkPolicies exist in the namespace. What is the default behavior for traffic from pods not matched by the 'from' selector?

A.All ingress traffic remains allowed by default.

B.The policy fails to apply because an egress rule must also be defined.

C.Only traffic from other namespaces is denied; same-namespace traffic is still allowed.

D.All ingress traffic from unmatched pods is denied.

AnswerD

Once a NetworkPolicy selects a pod for ingress, that pod becomes isolated, so only traffic matching a 'from' selector is permitted. Connections from unmatched pods are therefore denied by default, even though no other policies exist.

Why this answer

When a NetworkPolicy selects a pod and defines an ingress rule with a 'from' block, it becomes an allow-list for that pod's ingress traffic. Any traffic not explicitly allowed by the 'from' selector is denied by default. This is the fundamental behavior of Kubernetes NetworkPolicy: once a pod is selected by a policy, all traffic not matching the allowed rules is blocked.

Exam trap

KCSA often tests the default-deny behavior of NetworkPolicy, and candidates may incorrectly assume that only traffic from other namespaces is blocked or that same-namespace traffic remains allowed.

How to eliminate wrong answers

Option A is wrong because once a pod is selected by a NetworkPolicy, the default becomes deny for traffic not explicitly allowed; it is not allowed by default. Option B is wrong because a NetworkPolicy does not require an egress rule to be defined; ingress and egress rules are independent, and a policy can specify only ingress. Option C is wrong because NetworkPolicy does not differentiate between same-namespace and other-namespace traffic by default; all traffic not matching the 'from' selector is denied, regardless of namespace.

Practice this question →

MCQhard

You are auditing a Kubernetes cluster and notice that a specific ServiceAccount has been granted the 'impersonate' verb on users. What security risk does this permission introduce?

A.It automatically generates valid X.509 client certificates for cluster nodes.

B.It allows the pod to intercept network traffic of other pods on the same node.

C.It permits the ServiceAccount to bypass the Kubernetes API server and write directly to etcd.

D.It allows the ServiceAccount to act as any user or service account, leading to privilege escalation.

AnswerD

The `impersonate` verb lets a ServiceAccount assume another identity's privileges via the Kubernetes API, bypassing its own RBAC restrictions. Granting it on users enables full privilege escalation, since the account can act as any user or service account — directly satisfying the risk described in the stem.

Why this answer

The 'impersonate' verb on users (or groups/serviceaccounts) allows the holder to send API requests with an Impersonate-User header, causing the API server to evaluate the request as that user. This effectively lets the ServiceAccount assume any identity in the cluster, including cluster-admin, enabling full privilege escalation.

Exam trap

The trap is assuming impersonate is a benign read-only permission — candidates underestimate that it grants full identity assumption and therefore privilege escalation to any role in the cluster.

How to eliminate wrong answers

Option A is wrong because X.509 client certificate generation is performed by the kube-controller-manager's CSR signing controller (or manually via openssl/cfssl), not by the impersonate verb. Option B is wrong because pod network traffic interception is a function of the CNI plugin or a privileged pod with CAP_NET_RAW/CAP_NET_ADMIN — impersonation is an API-server authorization concept. Option C is wrong because nothing bypasses the API server to write to etcd directly; etcd access requires client certificates and is a separate attack path entirely.

Practice this question →