CCNA Application Environment, Configuration and Security Questions — Page 2 of 3

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file 'config.properties'?

A.kubectl create configmap app-config --from-file=config.properties

B.kubectl create configmap app-config --file config.properties

C.kubectl create configmap app-config --from-env-file config.properties

D.kubectl create configmap app-config --from-literal config.properties

AnswerA

This command is correct because `--from-file=config.properties` instructs kubectl to create a ConfigMap whose data contains a single key `config.properties` (the file basename) with the file's full contents as its value. This is the standard, documented way to import a file verbatim into a ConfigMap, and it does not require any extra flags or formatting assumptions about the file's internal structure.

Why this answer

`kubectl create configmap` with the `--from-file` flag creates a ConfigMap from a file, using the filename as the key and the file content as the value. This is the standard Kubernetes method to import configuration data from a local file into a ConfigMap resource.

Exam trap

The trap here is confusing `--from-file` (which stores the entire file as a single entry) with `--from-env-file` (which parses key-value pairs), leading candidates to choose option C when they need to preserve the file's original format.

How to eliminate wrong answers

Option B is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option C is wrong because `--from-env-file` imports the file as environment variables (key=value pairs per line), not as a single key-value entry, which changes the data structure. Option D is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to reference a file.

Practice this question →

MCQeasy

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows: ```yaml apiVersion: v1 kind: Pod metadata: name: app-pod spec: containers: - name: db image: postgres:latest securityContext: runAsNonRoot: true ``` The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

A.Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.

B.Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

C.Increase the Pod's resource limits because the error is due to insufficient memory.

D.Create a PodSecurityPolicy that allows running as root.

AnswerA

Setting `runAsUser: 999` explicitly instructs the kubelet to start the container process with UID 999, which is non-zero. This satisfies the `runAsNonRoot: true` validation because the runtime verifies that the effective UID is not 0. Since the Postgres image commonly defines a `postgres` user with UID 999, this aligns with the image's intended user and avoids running as root. This is the standard, least-privilege fix for a `runAsNonRoot` enforcement failure.

Why this answer

The PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Exam trap

The trap here is that candidates may think removing `runAsNonRoot` is the simplest fix, but the question explicitly requires the container to run securely without root, so the correct action is to specify a non-root user ID rather than disabling the security constraint.

How to eliminate wrong answers

Option B is wrong because removing `runAsNonRoot: true` would allow the container to run as root, which violates the security requirement to run securely without running as root. Option C is wrong because the error message explicitly states a security context violation (runAsNonRoot vs. root image), not a resource constraint; increasing resource limits would not resolve a security context error. Option D is wrong because a PodSecurityPolicy (PSP) is a cluster-level admission controller that can enforce policies, but it does not change the container's user ID; the immediate fix is to set a non-root user in the Pod spec, and PSPs are deprecated in Kubernetes 1.21+ and removed in 1.25.

Practice this question →

MCQeasy

Which command creates a ConfigMap named 'app-config' with two keys: 'key1=value1' and 'key2=value2'?

A.kubectl create configmap app-config --from-literal key1=value1 --from-literal key2=value2

B.kubectl create configmap app-config --from-literal=key1=value1,key2=value2

C.kubectl create configmap app-config --from-file key1=value1 --from-file key2=value2

D.kubectl create configmap app-config --from-env-file=key1=value1 --from-env-file=key2=value2

AnswerA

Using `kubectl create configmap app-config --from-literal key1=value1 --from-literal key2=value2` is correct because the `--from-literal` flag is designed to accept exactly one `key=value` pair, and repeating the flag accumulates each pair into the ConfigMap's `data` field. This is the canonical CLI syntax for defining inline literals directly from the command line, with no dependency on files or external input.

Why this answer

`kubectl create configmap` with the `--from-literal` flag allows you to specify key-value pairs directly on the command line. Each `--from-literal` flag creates one entry in the ConfigMap, so using two separate flags correctly creates a ConfigMap named 'app-config' with keys 'key1' and 'key2' mapped to 'value1' and 'value2' respectively.

Exam trap

The trap here is that candidates confuse `--from-literal` with `--from-file` or `--from-env-file`, or incorrectly assume that `--from-literal` accepts comma-separated syntax, leading them to choose options that either attempt to read nonexistent files or create a single malformed key.

How to eliminate wrong answers

Option B is wrong because `--from-literal` does not accept comma-separated key-value pairs; it expects a single key=value argument per flag, and using a comma would create a single key named 'key1=value1,key2=value2' instead of two separate keys. Option C is wrong because `--from-file` is used to load data from files on disk, not to specify literal key-value pairs; using it with 'key1=value1' would attempt to read a file named 'key1=value1' which does not exist. Option D is wrong because `--from-env-file` is used to load multiple key-value pairs from a file formatted as environment variables (e.g., a .env file), not to specify individual literals on the command line.

Practice this question →

MCQmedium

A ClusterRole named 'pod-reader' allows get, list, and watch on pods. A RoleBinding 'read-pods' in namespace 'default' binds this ClusterRole to user 'jane'. Which statement is true?

A.User 'jane' can read pods in all namespaces because ClusterRole is cluster-scoped

B.The RoleBinding must be changed to a ClusterRoleBinding for it to work

C.User 'jane' can read pods and also delete them because ClusterRole gives full access

D.User 'jane' can read pods only in the 'default' namespace

AnswerD

A RoleBinding always grants permissions only in the namespace where the binding itself is defined, regardless of whether it references a Role or a ClusterRole. Here, the ClusterRole supplies the pod read rules (get, list, watch), but the RoleBinding limits those rules to the 'default' namespace. As a result, Jane can read pods only in that namespace, not in any other.

Why this answer

A RoleBinding in a specific namespace binds a ClusterRole to a subject only within that namespace. Since the RoleBinding 'read-pods' is in the 'default' namespace, user 'jane' receives the permissions defined in the 'pod-reader' ClusterRole (get, list, watch on pods) only within the 'default' namespace, not across all namespaces.

Exam trap

The trap here is that candidates often assume a ClusterRole always grants cluster-wide permissions, forgetting that a RoleBinding scopes those permissions to a single namespace, while a ClusterRoleBinding is needed for true cluster-wide access.

How to eliminate wrong answers

Option A is wrong because a RoleBinding binds a ClusterRole to a subject only within the namespace where the RoleBinding exists, not across all namespaces; a ClusterRoleBinding would be required for cluster-wide access. Option B is wrong because a RoleBinding can bind a ClusterRole to a subject within a specific namespace, so it works correctly as is; no change to a ClusterRoleBinding is needed. Option C is wrong because the 'pod-reader' ClusterRole only grants get, list, and watch permissions on pods, not delete; a ClusterRole does not imply full access, only the permissions explicitly defined in its rules.

Practice this question →

Multi-Selectmedium

Which TWO are correct about LimitRange?

Select 2 answers

A.LimitRange can set default resource requests for containers that don't specify them

B.LimitRange can be applied only to pods in the default namespace

C.LimitRange is a cluster-scoped resource

D.LimitRange can enforce quotas on total resource usage across all pods

E.LimitRange can set maximum resource limits for containers

AnswersA, E

LimitRange's spec.default section defines default resource requests and limits for containers that do not explicitly declare them. When a pod is created in a namespace with a LimitRange, any container lacking a request or limit for a resource specified in default is automatically assigned that value. This defaulting mechanism applies at admission time, so it does not retroactively modify existing pods, and it works alongside the min/max constraints to keep pods within acceptable boundaries.

Why this answer

A LimitRange can define default resource requests and limits for containers in a namespace. When a container is created without specifying resource requests or limits, the LimitRange admission controller automatically applies the default values defined in the LimitRange object. This ensures that containers have baseline resource guarantees even if the pod spec omits them.

Exam trap

The trap here is confusing LimitRange (per-container constraints and defaults) with ResourceQuota (aggregate namespace limits), leading candidates to incorrectly select option D.

Practice this question →

Multi-Selecteasy

A developer wants to restrict a Pod's resource usage. Which two API resources can be used to enforce limits at the namespace level? (Choose two.)

Select 2 answers

A.PodSecurityPolicy

B.HorizontalPodAutoscaler

C.LimitRange

D.ResourceQuota

E.NetworkPolicy

AnswersC, D

A LimitRange is a namespaced Kubernetes object that sets minimum, maximum, and default values for CPU and memory requests and limits for individual containers or pods. When a container is created without explicit resources, the LimitRange admission plugin automatically injects defaults, and if the container's declared limits fall outside the configured range, the pod is rejected. This gives operators precise, per-pod control over how many resources each workload can consume.

Why this answer

LimitRange (C) is correct because it allows administrators to set default resource requests and limits, as well as minimum and maximum constraints, for Pods and containers within a namespace. This enforces resource boundaries at the namespace level, ensuring that individual Pods cannot exceed defined limits.

Exam trap

CNCF often tests the distinction between namespace-level resource enforcement (LimitRange and ResourceQuota) and cluster-level or scaling mechanisms, leading candidates to confuse HorizontalPodAutoscaler (which scales Pods) with resource limits.

Practice this question →

MCQeasy

Which of the following is a valid way to expose a Secret as an environment variable in a Pod?

A.env: - name: DB_PASSWORD valueFrom: configMapKeyRef: ...

B.env: - name: DB_PASSWORD value: $(DB_PASSWORD_SECRET)

C.env: - name: DB_PASSWORD valueFrom: fieldRef: ...

D.env: - name: DB_PASSWORD valueFrom: secretKeyRef: ...

AnswerD

The `secretKeyRef` field is the correct and standard mechanism for referencing a key from a Kubernetes Secret object and injecting its value as an environment variable. It requires the Secret to exist in the same namespace and the referenced key to be present; otherwise, the container creation fails. This approach keeps sensitive data out of the Pod manifest and centralizes it in the Secret API, which is the intended and secure pattern.

Why this answer

`secretKeyRef` is the Kubernetes API field used to reference a specific key from a Secret object and expose its value as an environment variable in a Pod. This is defined in the Pod spec under `env[].valueFrom.secretKeyRef`, which requires the `name` of the Secret and the `key` within that Secret.

Exam trap

CNCF often tests the distinction between `configMapKeyRef`, `secretKeyRef`, and `fieldRef`, and the trap here is that candidates confuse `configMapKeyRef` (for non-sensitive data) with `secretKeyRef` (for sensitive data), or think that variable substitution like `$(VAR_NAME)` can directly pull from a Secret.

How to eliminate wrong answers

Option A is wrong because `configMapKeyRef` references a ConfigMap, not a Secret; ConfigMaps are for non-sensitive data, while Secrets are for sensitive data like passwords. Option B is wrong because `$(DB_PASSWORD_SECRET)` is a variable substitution syntax used for referencing other environment variables or container arguments, not for directly exposing a Secret's value. Option C is wrong because `fieldRef` is used to expose Pod metadata (e.g., `metadata.name`, `status.podIP`) via the downward API, not Secret data.

Practice this question →

Multi-Selecthard

Which three security contexts can be set at the pod level (as opposed to container level)? (Select THREE.)

Select 3 answers

A.readOnlyRootFilesystem

B.fsGroup

C.runAsGroup

D.capabilities

E.runAsUser

AnswersB, C, E

fsGroup is a pod-level securityContext field that specifies the group ID for volume ownership. When set, Kubernetes changes the group ownership of volumes mounted into the pod (except Secrets and ConfigMaps) to that GID, and files created in those volumes will also inherit this group. This ensures containers have consistent group-based access to shared volumes, even when runAsGroup differs, because fsGroup applies at the mount layer.

Why this answer

B is correct because `fsGroup` is a Pod-level security context field that applies a supplemental group ID to all containers in the Pod, ensuring that volumes mounted with that group ownership are accessible. It is set under `spec.securityContext.fsGroup`, not at the container level, making it a Pod-scoped setting.

Exam trap

The trap here is that candidates confuse Pod-level and container-level security contexts, often selecting `capabilities` or `readOnlyRootFilesystem` because they are commonly used, but they are only valid at the container level in the Kubernetes API.

Practice this question →

Multi-Selecthard

Which THREE configurations are part of Pod Security Admission's 'restricted' profile? (Select THREE.)

Select 3 answers

A.runAsNonRoot: true

B.seccompProfile.type: RuntimeDefault

C.capabilities must drop ALL

D.allowPrivilegeEscalation: true

E.Privileged containers allowed

AnswersA, B, C

Setting `runAsNonRoot: true` forces the kubelet to refuse container startup if the image resolves to UID 0, satisfying the restricted profile's mandate that containers never run as root. This directly enforces the non-root user constraint, one of the three baseline hardening controls the restricted profile requires.

Why this answer

Option A (runAsNonRoot: true) is correct because the restricted profile requires containers to run as a non-root user, enforcing runAsNonRoot=true in the security context. Option B (seccompProfile.type: RuntimeDefault) is correct because restricted mandates a seccomp profile, and RuntimeDefault is the minimum accepted value. Option C (capabilities must drop ALL) is correct because restricted requires dropping all Linux capabilities, allowing only NET_BIND_SERVICE to be added back.

Option D is incorrect because allowPrivilegeEscalation must be false under restricted, not true. Option E is incorrect because privileged containers are explicitly disallowed by the restricted profile.

Exam trap

The trap here is that candidates often confuse the 'restricted' profile with the 'baseline' profile, mistakenly thinking that options like `allowPrivilegeEscalation: true` or privileged containers are acceptable, when in fact the restricted profile explicitly prohibits them.

Practice this question →

MCQhard

A Pod is configured with automountServiceAccountToken: false. The application inside the pod needs to access the Kubernetes API. What should be done?

A.Create a new Secret of type kubernetes.io/dockerconfigjson

B.Mount the service account token manually by adding a volume and volumeMount

C.The application cannot access the API; the setting is final

D.Add a ConfigMap with the token

AnswerB

Setting automountServiceAccountToken: false only disables the automatic mounting of the service account token; it does not prevent you from mounting it explicitly. You can add a projected volume in the Pod spec with the serviceAccountToken source, specifying the service account name, path, audience, and expiration seconds. Then add a volumeMount at an application-accessible path (e.g., /var/run/secrets/token) so the container reads the token from that file. This is the correct way to restore API access while keeping the automatic mount disabled.

Why this answer

Setting automountServiceAccountToken: false prevents automatic mounting of the service account token. To still access the Kubernetes API, you must manually mount the token by adding a volume of type projected (or secret) containing the service account token, and a corresponding volumeMount in the container. This allows the application to authenticate with the API server using the mounted token.

Exam trap

The trap here is that candidates assume automountServiceAccountToken: false permanently blocks API access, but the CKAD exam tests that you can override this by manually mounting the token, often using a projected volume or a secret reference.

How to eliminate wrong answers

Option A is wrong because a Secret of type kubernetes.io/dockerconfigjson is used for pulling images from private registries, not for API authentication. Option C is wrong because the application can still access the API if the token is manually mounted; the setting is not final. Option D is wrong because ConfigMaps store non-sensitive configuration data, not service account tokens, which are sensitive and must be stored in Secrets or projected volumes.

Practice this question →

MCQhard

A Pod in a namespace with a ResourceQuota that sets 'limits.cpu: 4' and 'limits.memory: 8Gi' is being created with the following container resources: requests: cpu: 2, memory: 4Gi; limits: cpu: 4, memory: 8Gi. The namespace also has a LimitRange with default limits of cpu: 500m, memory: 512Mi. Which statement is true about this resource configuration?

A.The Pod will have its limits overridden by the LimitRange defaults because limits must be set

B.The Pod will be admitted because it respects both the ResourceQuota and the LimitRange

C.The Pod will be rejected because the limits exceed the LimitRange default

D.The Pod will be rejected because requests must equal limits

AnswerB

The Pod is admitted because its declared resource limits fall within the maximum allowed by the ResourceQuota and, if a LimitRange exists, the Pod's own limits satisfy any minimum or maximum constraints defined there. As the Pod explicitly sets its limits, the LimitRange's default section is irrelevant. Admission only fails when a resource request would violate quota or a mandatory range constraint.

Why this answer

B is correct because the Pod explicitly sets its own limits (cpu: 4, memory: 8Gi) and requests (cpu: 2, memory: 4Gi), which are within the ResourceQuota's 'limits.cpu: 4' and 'limits.memory: 8Gi' constraints. The LimitRange default limits only apply to containers that do not specify limits; since this Pod specifies limits, the defaults are ignored. The Pod is admitted as it satisfies both admission controllers.

Exam trap

The trap here is that candidates assume LimitRange defaults always override Pod specifications, but in reality defaults only apply when the Pod does not set its own limits, and the Pod's explicit limits take precedence.

How to eliminate wrong answers

Option A is wrong because LimitRange defaults only apply to containers that do not have limits set; here limits are explicitly defined, so no override occurs. Option C is wrong because the Pod's limits exactly match the ResourceQuota's maximum (4 CPU, 8Gi memory), not exceed it, and the LimitRange default is irrelevant when limits are set. Option D is wrong because Kubernetes does not require requests to equal limits; they can differ, and the ResourceQuota only enforces the maximum limits, not equality.

Practice this question →

MCQeasy

To prevent a container from running as root, which field should be set in the securityContext?

A.runAsUser: 1000

B.runAsNonRoot: true

C.allowPrivilegeEscalation: false

D.readOnlyRootFilesystem: true

AnswerB

runAsNonRoot: true is the correct field because it actively enforces a security requirement that the container must not run as root. When set, the kubelet checks the user the image would run as: if that user is root (UID 0) or the image does not define a non-root user, the container is not started and the Pod fails. This provides a strong guarantee that the container process never executes with root privileges, regardless of the image's default configuration.

Why this answer

The `runAsNonRoot: true` field in the securityContext explicitly prevents the container from running as the root user (UID 0). When set, Kubernetes will refuse to start the container if the image is configured to run as root, enforcing a non-root execution policy at the pod or container level. This is the direct and intended mechanism for ensuring the container does not run with root privileges.

Exam trap

The trap here is that candidates often confuse `runAsNonRoot: true` with `runAsUser: 1000`, mistakenly thinking that setting a non-zero user ID alone guarantees the container does not run as root, when in fact `runAsUser` only sets the UID and does not enforce a root check, leaving the container vulnerable if the image defaults to root.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets a specific user ID for the container process but does not prevent running as root; if the image runs as root, this field overrides it only if explicitly set, and it does not enforce a non-root check. Option C is wrong because `allowPrivilegeEscalation: false` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not prevent the container from initially running as root. Option D is wrong because `readOnlyRootFilesystem: true` makes the container's root filesystem read-only, which is a security hardening measure but does not affect the user identity under which the container runs.

Practice this question →

MCQmedium

Which Pod spec snippets correctly achieve this?

A.envFrom: - secretRef: name: db-secret

B.volumes: - name: secret-volume secret: secretName: db-secret volumeMounts: - mountPath: /etc/secret name: secret-volume

C.env: - name: USERNAME valueFrom: secretKeyRef: name: db-secret key: username - name: PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

D.env: - name: db-secret valueFrom: configMapKeyRef: name: db-secret key: username

AnswerA, C

The envFrom directive with secretRef is a clean, idiomatic way to inject every key-value pair from the Secret db-secret as individual environment variables. Each key in the Secret (e.g., username, password) becomes an environment variable name, and its value is populated automatically. This is correct when you want to expose the entire Secret without manually mapping each key, and it requires no additional per-key configuration.

Why this answer

This question has multiple correct answers. Both options A and C are correct ways to expose Secret keys as environment variables in a Pod. Option A uses `envFrom` with `secretRef` to inject all keys from the Secret as environment variables in a single declaration.

Option C uses individual `env` entries with `secretKeyRef` to map each key explicitly. Both achieve the same result; option A is more concise for exposing all keys, while option C provides explicit control over each environment variable name. Options B and D are incorrect: B mounts the Secret as files, not environment variables, and D uses `configMapKeyRef`, which is for ConfigMaps, not Secrets.

Exam trap

A common trap is that candidates might think only the bulk `envFrom` method (option A) is correct, but the individual `env` with `secretKeyRef` (option C) is also perfectly valid. The key distinction is that both are acceptable methods for exposing Secrets as environment variables.

How to eliminate wrong answers

Option B is wrong because it mounts the Secret as files in a volume at `/etc/secret`, not as environment variables; the question specifically asks for environment variables. Option C is wrong because while it correctly uses `secretKeyRef` to expose individual keys as environment variables, it requires explicit enumeration of each key ('username' and 'password'), which is not the most efficient approach when the goal is to expose all keys from the Secret; the question asks for the snippet that 'correctly achieves this', and A is more direct and concise. Option D is wrong because it uses `configMapKeyRef` instead of `secretKeyRef`, and references a ConfigMap named 'db-secret' rather than a Secret, which would fail to read the Secret's data and would not expose the correct values.

Practice this question →

MCQmedium

A pod is scheduled but stays in Pending state. 'kubectl describe pod' shows: '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?

A.The pod's memory request exceeds the available memory on any node.

B.The pod has a liveness probe configured incorrectly.

C.The namespace has a ResourceQuota that blocks the pod.

D.The pod's memory limit is set too low.

AnswerA

The Kubernetes scheduler selects a node for a pod based on the pod's resource requests, comparing them to each node's allocatable capacity minus the requests of existing workloads. If every node lacks the unallocated memory needed to satisfy this pod's memory request, the pod remains Pending with scheduler events such as 'Insufficient memory'. This is a scheduling failure, not a runtime issue, and it persists until the request is lowered, nodes are added, or other workloads are removed to free capacity.

Why this answer

The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler could not find a node with enough allocatable memory to satisfy the pod's memory request. The pod's memory request (spec.containers[].resources.requests.memory) must be less than or equal to a node's allocatable memory for the pod to be scheduled. Since no node meets this requirement, the pod remains in Pending state.

Exam trap

The trap here is that candidates confuse memory requests with memory limits, assuming a low limit causes scheduling failure, when in fact the scheduler only evaluates requests, and limits only affect runtime OOM behavior.

How to eliminate wrong answers

Option B is wrong because a misconfigured liveness probe would cause the pod to be restarted or marked as unhealthy after it starts, not prevent it from being scheduled; scheduling failures occur before the pod runs. Option C is wrong because a ResourceQuota would cause an error like 'exceeded quota' or 'forbidden' when creating the pod, not a node-level 'Insufficient memory' message from the scheduler. Option D is wrong because a memory limit that is set too low would affect the pod's runtime behavior (e.g., OOMKill) but does not impact scheduling; the scheduler only considers the memory request, not the limit, when determining node fit.

Practice this question →

Multi-Selecthard

Which TWO of the following are valid ways to mount a Secret into a pod as environment variables? (Select exactly 2)

Select 2 answers

A.env: - name: SECRET_KEY valueFrom: configMapKeyRef: name: my-secret key: key

B.env: - name: SECRET_KEY valueFrom: secretEnvRef: name: my-secret key: key

C.envFrom: - configMapRef: name: my-secret

D.env: - name: SECRET_KEY valueFrom: secretKeyRef: name: my-secret key: key

E.envFrom: - secretRef: name: my-secret

AnswersD, E

This correctly uses secretKeyRef to reference a specific key from a Secret. The name field identifies the Secret resource, and key specifies which entry to extract; the value is base64-decoded before being set as the environment variable. This is the standard, explicit method for injecting a single secret value into a container.

Why this answer

`secretKeyRef` is the standard Kubernetes API field for referencing a specific key from a Secret object and injecting its value as an environment variable. Option E is correct because `envFrom` with `secretRef` allows you to load all key-value pairs from a Secret as environment variables into the pod, which is a valid and common pattern.

Exam trap

The trap here is that candidates often confuse `configMapKeyRef`/`configMapRef` with `secretKeyRef`/`secretRef`, or invent non-existent fields like `secretEnvRef`, because the syntax for Secrets and ConfigMaps is nearly identical except for the resource-specific keyword.

Practice this question →

MCQmedium

A developer wants to restrict network traffic so that only pods with label 'app: frontend' can communicate with pods labeled 'app: backend' on port 8080. Which Kubernetes resource should be used?

A.NetworkPolicy

B.ResourceQuota

C.PodSecurityPolicy

D.RoleBinding

AnswerA

NetworkPolicy is the correct Kubernetes resource for restricting network traffic to and from pods. It uses label selectors to match pods and defines ingress/egress rules in the spec, allowing you to control traffic at the IP/port level. For example, you can default-deny all ingress and then allow only from specific pod labels.

Why this answer

A NetworkPolicy is the correct Kubernetes resource because it defines ingress and egress rules to control pod-to-pod communication based on labels, namespaces, and ports. By specifying a podSelector matching 'app: backend', an ingress rule allowing traffic from pods with label 'app: frontend' on port 8080, and a policyTypes field including 'Ingress', this resource enforces the desired restriction at the network layer using iptables or eBPF under the hood.

Exam trap

The trap here is that candidates confuse NetworkPolicy with RBAC or security context controls, mistakenly thinking RoleBinding or PodSecurityPolicy can restrict network traffic, when in fact only NetworkPolicy (with a compatible CNI) provides pod-level network access control.

How to eliminate wrong answers

Option B is wrong because ResourceQuota limits aggregate resource consumption (CPU, memory, storage) per namespace, not network traffic between pods. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21, removed in 1.25) controls security context constraints for pods, such as privileged mode or host namespaces, not network connectivity. Option D is wrong because RoleBinding grants RBAC permissions to users or service accounts within a namespace, but does not affect network traffic between pods.

Practice this question →

Multi-Selectmedium

Which TWO resources are used to enforce resource quotas at the namespace level? (Select TWO.)

Select 2 answers

A.HorizontalPodAutoscaler

B.NetworkPolicy

C.ResourceQuota

D.PodDisruptionBudget

E.LimitRange

AnswersC, E

ResourceQuota is a namespace-scoped admission control object that sets aggregate limits on compute resources (e.g., cpu, memory) and on the number of certain objects (e.g., pods, services, PVCs) that can be created within that namespace. When any creation or update would exceed the quota, the API server rejects it with a 403 Forbidden, preventing resource exhaustion. This makes ResourceQuota one of the two core tools for enforcing namespace-level resource quotas.

Why this answer

ResourceQuota (C) is correct because it is the Kubernetes object that enforces aggregate quotas on a namespace, capping total CPU/memory requests and limits, pod counts, and object counts such as services, secrets, and PVCs. LimitRange (E) is correct because it enforces per-container or per-pod defaults and min/max constraints within a namespace, ensuring individual workloads cannot exceed or bypass the namespace's quota boundaries. HorizontalPodAutoscaler (A) only scales replica counts based on metrics and does not enforce quotas.

NetworkPolicy (B) governs pod-level ingress/egress traffic rules, not resource consumption. PodDisruptionBudget (D) limits voluntary disruptions to maintain availability, not resource usage.

Exam trap

CNCF often tests the distinction between cluster-level and namespace-level resource controls, and the trap here is that candidates confuse HorizontalPodAutoscaler (which scales pods) with ResourceQuota (which caps total usage), or think NetworkPolicy enforces resource limits due to its 'policy' name.

Practice this question →

Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext?

Select 3 answers

A.fsGroup

B.capabilities

C.seccompProfile

D.runAsNonRoot

E.allowPrivilegeEscalation

AnswersA, C, D

fsGroup is a valid PodSecurityContext field. It sets the supplementary group ID applied to all containers in the pod, and Kubernetes recursively changes ownership of mounted volumes to that group, enabling shared volume access across containers.

Why this answer

fsGroup (A) is a valid PodSecurityContext field that sets a supplemental group ID applied to all containers in the pod, used for volume ownership and permissions. seccompProfile (C) is valid at the pod level and defines the seccomp profile applied to all containers in the pod. runAsNonRoot (D) is a valid PodSecurityContext field that ensures containers run as a non-root user by validating the image's USER directive. capabilities (B) and allowPrivilegeEscalation (E) are not PodSecurityContext fields; they belong to the container-level SecurityContext, not the pod-level one.

Exam trap

CNCF often tests the distinction between PodSecurityContext and container SecurityContext, trapping candidates who assume all security-related fields (like capabilities or allowPrivilegeEscalation) are valid at the pod level when they are actually container-specific.

Practice this question →

MCQeasy

A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?

A.runAsNonRoot: true

B.runAsUser: 1000

C.fsGroup: 1000

D.privileged: false

AnswerB

runAsUser: 1000 directly sets the container process's user ID to 1000, overriding any default user defined in the image's Dockerfile or container runtime configuration. This makes the process run as UID 1000 regardless of the image's original settings, and it is the only way to deterministically satisfy a policy that explicitly requires UID 1000. It is the exact, explicit control needed when the container starts as root by default.

Why this answer

`runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.

Exam trap

The trap here is that candidates often confuse `runAsNonRoot: true` with setting a specific user ID, not realizing it only enforces non-root but does not guarantee UID 1000, which the question explicitly requires.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` only prevents the container from running as root (UID 0) but does not specify which non-root UID to use; it relies on the container image's default user, which may not be UID 1000. Option C is wrong because `fsGroup: 1000` sets the group ID for volume ownership, not the user ID the container process runs as. Option D is wrong because `privileged: false` is the default setting and only disables privileged mode; it does not enforce a specific non-root user.

Practice this question →

MCQhard

Refer to the exhibit. A Pod is defined with security contexts at both the container and Pod level. Which of the following statements accurately describes the effective security configuration?

A.The Pod will fail to start because runAsNonRoot conflicts with the container's runAsUser.

B.The container runs as user 1000, but the Pod-level runAsNonRoot overrides the container's runAsUser to enforce non-root.

C.The container runs as user 1000, group 2000, with NET_ADMIN capability added, and the Pod-level runAsNonRoot: true is also enforced.

D.The container runs as root because the Pod-level runAsNonRoot is ignored when container-level capabilities are set.

AnswerC

The container's effective identity is user 1000 and group 2000 as defined by its securityContext, and the NET_ADMIN capability is added unambiguously. The Pod-level runAsNonRoot: true is a separate, compatible gate that the kubelet checks; because the container runs as UID 1000, the gate passes. Both levels of securityContext are enforced, with container-level fields supplying the specifics and pod-level fields adding global constraints.

Why this answer

Kubernetes merges Pod-level and container-level security contexts, with the container-level settings taking precedence for fields that overlap, but Pod-level settings that are not overridden (like runAsNonRoot) remain enforced. In this case, the container runs as user 1000, group 2000, with NET_ADMIN capability added, and the Pod-level runAsNonRoot: true is also enforced, ensuring the container does not run as root.

Exam trap

CNCF often tests the misconception that Pod-level runAsNonRoot overrides container-level runAsUser, when in fact they are complementary checks, and the container's runAsUser must be non-root for the Pod to start.

How to eliminate wrong answers

Option A is wrong because runAsNonRoot: true does not conflict with runAsUser: 1000; it only prevents the container from running as UID 0, and user 1000 is non-root, so the Pod starts successfully. Option B is wrong because runAsNonRoot does not override runAsUser; it is an additional check that the container's effective UID is not 0, and user 1000 satisfies that condition. Option D is wrong because Pod-level runAsNonRoot is not ignored when container-level capabilities are set; capabilities like NET_ADMIN do not affect the user ID, and runAsNonRoot remains enforced.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to inject configuration data into a Kubernetes Pod?

Select 2 answers

A.Mounting a ServiceAccount token as a volume.

B.Using a ConfigMap to set environment variables in the Pod spec.

C.Using a PersistentVolumeClaim to store configuration files.

D.Referencing a NetworkPolicy in the Pod spec.

E.Mounting a Secret as a volume in the Pod.

AnswersB, E

A ConfigMap is an API object purpose-built for non-confidential configuration data, and its key-value pairs can be referenced in a container's env block with configMapKeyRef. Kubernetes then translates each referenced key into an environment variable inside the container, which is a declarative and image-independent way to inject config. Because the Pod spec references the ConfigMap by name, you can change configuration without rebuilding the container image.

Why this answer

A ConfigMap is specifically designed to inject configuration data into Pods, and one of the primary methods is by setting environment variables in the Pod spec using `envFrom` or `valueFrom: configMapKeyRef`. This allows decoupling configuration from container images, enabling environment-specific settings without rebuilding images.

Exam trap

The trap here is that candidates often confuse 'injecting configuration data' with 'providing storage' or 'network policies', leading them to select PersistentVolumeClaim or NetworkPolicy as valid options, when in fact only ConfigMaps and Secrets (for sensitive data) are the native Kubernetes resources for injecting configuration into Pods.

Practice this question →

MCQeasy

A pod needs to mount a Secret named 'db-secret' as a volume at /etc/secret. Which volume mount definition is correct?

A.volumes: - name: secret-volume secret: secretName: db-secret

B.volumes: - name: secret-volume secretVolumeSource: secretName: db-secret

C.volumes: - name: db-secret secret: secretName: db-secret

D.volumes: - name: secret-volume secret: name: db-secret

AnswerA

The pod spec's volumes stanza declares a volume named secret-volume sourced from the Secret db-secret via the secret.secretName field. A matching volumeMount referencing that volume name then projects the Secret's keys as files into the container at /etc/secret.

Why this answer

It uses the proper `secret` key under the `volumes` field to reference a Secret object by its `secretName`. When this volume is mounted at `/etc/secret`, Kubernetes automatically creates a file for each key in the Secret, with the file content being the decoded value of the key. This is the standard syntax for mounting a Secret as a volume.

Exam trap

The trap here is that candidates often confuse the `secret` volume source with the `configMap` volume source, or incorrectly use `secretVolumeSource` (which is not a valid field) instead of the correct `secret` key, leading them to choose option B.

How to eliminate wrong answers

Option B is wrong because `secretVolumeSource` is not a valid field in the volume definition; the correct field is `secret`. Option C is wrong because the volume name is `db-secret`, which is not technically invalid but is misleading — the volume name should be a descriptive identifier (e.g., `secret-volume`) and is not required to match the Secret name. Option D is wrong because it uses `name: db-secret` under the `secret` block, but the correct key is `secretName`, not `name`.

Practice this question →

MCQmedium

You have a LimitRange in namespace 'ns' that sets default limits.cpu to 500m and default requests.cpu to 200m. You create a pod without specifying any CPU resources. What CPU values will be applied to the container?

A.The pod will be rejected by the admission controller

B.request: 200m, limit: 500m

C.request: 0, limit: 0 (no limits enforced)

D.request: 500m, limit: 500m

AnswerB

Correct. When a container in the pod has no resources field, the LimitRange defaults apply during admission: the defaultRequest value fills the request and the default value fills the limit. The effective pod spec therefore contains request: 200m and limit: 500m, and these values are used for scheduling, QoS classification, and kubelet enforcement.

Why this answer

When a LimitRange is configured in a namespace with default CPU limits and requests, any pod created without specifying CPU resources will have those defaults injected by the admission controller. The LimitRange sets default limits.cpu to 500m and default requests.cpu to 200m, so the container will receive request: 200m and limit: 500m. This is enforced by the LimitRanger admission plugin during pod creation.

Exam trap

The trap here is that candidates often assume a pod without resource specs will be rejected or have no limits, but the LimitRange admission controller silently applies defaults, making option B correct.

How to eliminate wrong answers

Option A is wrong because the pod is not rejected; the LimitRange admission controller applies defaults rather than rejecting the pod. Option C is wrong because the LimitRange explicitly sets default values, so the container will not have zero CPU requests and limits; the defaults are applied automatically. Option D is wrong because it confuses default limits with default requests; the default request is 200m, not 500m, and the limit is 500m, not equal to the request.

Practice this question →

MCQeasy

Which command creates a generic secret named 'db-secret' with key 'password' and value 'p@ss'?

A.kubectl create secret generic db-secret --from-file=password=p@ss

B.kubectl create secret generic db-secret --from-literal=password=p@ss

C.kubectl create secret tls db-secret --from-literal=password=p@ss

D.kubectl create secret docker-registry db-secret --from-literal=password=p@ss

AnswerB

This is the correct syntax for creating an Opaque secret named db-secret with a literal key-value pair. The --from-literal flag takes 'key=value' directly from the command line and stores it as the secret data. Since 'generic' is the default and only type that accepts arbitrary literals, this matches the requirement for storing a database password. The resulting secret will have type 'Opaque' and contain password: p@ss.

Why this answer

`kubectl create secret generic` with `--from-literal` allows you to specify key-value pairs directly on the command line. The syntax `--from-literal=password=p@ss` creates a generic secret with the key 'password' and the literal value 'p@ss', which matches the requirement exactly.

Exam trap

The trap here is that candidates often confuse `--from-file` with `--from-literal`, mistakenly thinking `--from-file=key=value` will treat the value as a literal string, when in fact it treats it as a file path.

How to eliminate wrong answers

Option A is wrong because `--from-file=password=p@ss` treats 'p@ss' as a filename, not a literal value; it would attempt to read a file named 'p@ss' and store its contents under the key 'password', which is not the intended behavior. Option C is wrong because `kubectl create secret tls` is used specifically for TLS certificates and keys, not for arbitrary key-value pairs; it expects `--cert` and `--key` flags, not `--from-literal`. Option D is wrong because `kubectl create secret docker-registry` is used for Docker registry authentication credentials and requires flags like `--docker-username`, `--docker-password`, and `--docker-email`; `--from-literal` is not supported for this secret type.

Practice this question →

100

Matchingmedium

Match each Kubernetes concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Virtual cluster for resource isolation

Runs one pod per node for system services

Runs a pod to completion; for batch processing

Automatically scales pods based on CPU/memory

Controls traffic flow between pods

Why these pairings

Correct matches are Pod with smallest deployable unit, Service with logical set and access policy, Deployment with declarative updates, and Ingress with external HTTP access. Common confusions include swapping Pod and Service definitions.

Practice this question →

101

MCQmedium

You create a Role named 'pod-reader' in the 'default' namespace with rules to get, list, and watch pods. A ServiceAccount 'app-sa' in the same namespace needs to be bound to this role. Which YAML snippet correctly creates the RoleBinding?

A.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io

B.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa apiGroup: '' roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

C.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io

D.kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

AnswerB

This manifest is correct because it binds the ServiceAccount 'app-sa' to the namespaced Role 'pod-reader' in the default namespace. The roleRef uses kind: Role with the matching apiGroup rbac.authorization.k8s.io, and the subject explicitly sets apiGroup: '' to indicate a core ServiceAccount. This grants the ServiceAccount the permissions of the Role only within its namespace, exactly as intended.

Why this answer

It creates a RoleBinding in the 'default' namespace that binds the ServiceAccount 'app-sa' to the Role 'pod-reader' using the correct 'kind: Role' in the roleRef. The RoleBinding must reference a Role (not a ClusterRole) when the Role exists in the same namespace, and the apiGroup for the roleRef must be 'rbac.authorization.k8s.io'.

Exam trap

CNCF often tests the distinction between Role and ClusterRole in the roleRef of a RoleBinding, where candidates mistakenly use 'kind: ClusterRole' when the actual resource is a namespaced Role, or use 'kind: ClusterRoleBinding' for a namespaced binding.

How to eliminate wrong answers

Option A is wrong because the roleRef uses 'kind: ClusterRole' instead of 'kind: Role', but the Role 'pod-reader' is a namespaced Role, not a ClusterRole. Option C is wrong for the same reason as A: it incorrectly references a ClusterRole instead of a Role. Option D is wrong because it uses 'kind: ClusterRoleBinding' which is cluster-scoped and cannot bind a namespaced Role; also, a ClusterRoleBinding requires a ClusterRole, not a Role.

Practice this question →

102

MCQhard

An administrator wants to enforce that all pods in namespace 'secured' must run with a seccomp profile set to 'RuntimeDefault' at the container level. Which Pod Security Admission policy standard achieves this?

A.Set the namespace label 'pod-security.kubernetes.io/enforce=privileged'

B.Set the namespace label 'pod-security.kubernetes.io/enforce=baseline'

C.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted'

D.Set the namespace label 'pod-security.kubernetes.io/enforce=seccomp'

AnswerC

The restricted Pod Security Standard is the most stringent preset, and its policy explicitly requires every container to define a seccompProfile of either RuntimeDefault or Localhost. Setting the namespace label to restricted forces the Pod Security admission controller to reject any pod or update that lacks a compliant seccomp profile. This is precisely what the administrator needs, as it enforces seccomp at the namespace level and aligns with the recommended default for production workloads.

Why this answer

The 'restricted' Pod Security Admission (PSA) policy standard enforces the most stringent security controls, including requiring that pods use a seccomp profile set to 'RuntimeDefault' at the container level. This is defined in the Kubernetes Pod Security Standards documentation, where the restricted profile mandates 'seccomp: RuntimeDefault' as a baseline requirement. Therefore, option C is correct because it directly matches the policy that enforces this specific seccomp constraint.

Exam trap

The trap here is that candidates often confuse the 'baseline' standard with 'restricted', assuming baseline covers seccomp requirements, but baseline only addresses basic privilege escalation and does not mandate a specific seccomp profile.

How to eliminate wrong answers

Option A is wrong because the 'privileged' PSA standard imposes no restrictions on seccomp profiles, allowing any profile or no profile at all. Option B is wrong because the 'baseline' PSA standard only prevents known privilege escalations but does not mandate a specific seccomp profile like 'RuntimeDefault'. Option D is wrong because 'pod-security.kubernetes.io/enforce=seccomp' is not a valid PSA standard; the valid standards are 'privileged', 'baseline', and 'restricted', and seccomp is a control within the restricted standard, not a standalone policy level.

Practice this question →

103

MCQmedium

A pod is using a Secret to authenticate to a private registry. The Secret type must be 'kubernetes.io/dockerconfigjson'. Which of the following is the correct way to create such a Secret using kubectl?

A.kubectl create secret generic regcred --type=kubernetes.io/dockercfg --from-literal=.dockercfg=...

B.kubectl create secret generic regcred --from-file=.dockerconfigjson=/root/.docker/config.json

C.kubectl create secret tls regcred --cert=cert.crt --key=key.key

D.kubectl create secret docker-registry regcred --docker-server=my-registry.example.com --docker-username=myuser --docker-password=mypassword --docker-email=myemail@example.com

AnswerD

The docker-registry subcommand builds a Secret of type kubernetes.io/dockerconfigjson from the supplied server, username, password and email flags, generating the required .dockerconfigjson key automatically. Manual base64 encoding or generic Secret creation would not satisfy the registry's expected type.

Why this answer

`kubectl create secret docker-registry` is the dedicated command to create a Secret of type `kubernetes.io/dockerconfigjson`. It automatically generates the required `.dockerconfigjson` field with the base64-encoded Docker credentials in the correct JSON format, which the kubelet uses to authenticate to a private registry when pulling images.

Exam trap

The trap here is that candidates may think any Secret with a `.dockerconfigjson` key works, but without the correct `kubernetes.io/dockerconfigjson` type, the kubelet will not interpret the data properly, leading to image pull failures.

How to eliminate wrong answers

Option A is wrong because it uses `--type=kubernetes.io/dockercfg` (which corresponds to the legacy `.dockercfg` format) instead of `kubernetes.io/dockerconfigjson`, and `--from-literal=.dockercfg=...` does not produce the required `.dockerconfigjson` key. Option B is wrong because `--from-file=.dockerconfigjson` would create a generic Secret with that key, but the Secret type would remain `Opaque` unless explicitly set to `kubernetes.io/dockerconfigjson`; the command does not specify the required type. Option C is wrong because `kubectl create secret tls` creates a Secret of type `kubernetes.io/tls` for TLS certificates and keys, not for Docker registry authentication.

Practice this question →

104

MCQmedium

A Pod in a namespace with a ResourceQuota fails to create with the error: 'exceeded quota: compute-quota, requested: pods=1, used: pods=5, limited: pods=5'. What is the issue?

A.The Pod's service account does not have permission to create Pods.

B.The Pod's resource requests exceed the quota.

C.The namespace has reached its maximum number of Pods allowed by the ResourceQuota.

D.The Pod is trying to mount a Secret that does not exist.

AnswerC

When a ResourceQuota includes `count/pods: 5`, the Kubernetes API server counts every Pod object in the namespace, regardless of its resource requests or limits. Once five Pods already exist, the admission controller denies another create with an error like `pods "nginx" is forbidden: exceeded quota: my-quota, requested: pods=1, used: pods=5, limited: pods=5`. The namespace is at its ceiling, so no further Pods can be admitted until an existing Pod is deleted or the quota is increased.

Why this answer

The error message explicitly states 'requested: pods=1, used: pods=5, limited: pods=5'. This means the ResourceQuota named 'compute-quota' has a hard limit of 5 pods in the namespace, and that limit has already been reached. The Pod creation fails because the quota's `count/pods` scope is exhausted, not because of resource requests or permissions.

Exam trap

CNCF often tests the distinction between count-based quotas (e.g., `count/pods`) and resource-based quotas (e.g., `requests.cpu`), leading candidates to incorrectly assume the error is about resource requests when the message clearly references pod count.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount permission issue would produce a 'Forbidden' or 'Unauthorized' error, not a quota-exceeded error. Option B is wrong because the error message mentions 'pods=1' (count of pods), not CPU or memory resource requests; a resource request exceed would show 'requested: cpu=...' or 'memory=...'. Option D is wrong because a missing Secret would cause a 'MountVolume.SetUp failed' or 'secret not found' error during Pod startup, not a quota-exceeded error at creation time.

Practice this question →

105

MCQmedium

A pod has a container with envFrom referencing a ConfigMap. The ConfigMap has keys 'APP_DEBUG=true' and 'APP_NAME=myapp'. The pod also has an env entry with name 'APP_DEBUG' set to 'false'. What is the value of APP_DEBUG in the container?

A.false

B.undefined

C.Both values are concatenated

D.true

AnswerA

The correct answer is false. In Kubernetes, when both envFrom and env are used in a container spec, explicit env entries take precedence over any keys imported from a ConfigMap or Secret via envFrom. Regardless of the order of the fields, the value specified directly in the env array overrides the matching key from the ConfigMap, so the statement that envFrom overrides env is incorrect.

Why this answer

When a pod has both an `envFrom` referencing a ConfigMap and an explicit `env` entry with the same key, the explicit `env` entry takes precedence. This is because Kubernetes merges environment variables from multiple sources, and individual `env` entries override any values from `envFrom` for the same key. Therefore, `APP_DEBUG` will be set to 'false' as defined in the explicit `env` entry.

Exam trap

The trap here is that candidates often assume `envFrom` merges all keys and that explicit `env` entries are additive, but they fail to remember that explicit `env` entries override `envFrom` for duplicate keys, leading them to pick the ConfigMap's value (true) or think both values are concatenated.

How to eliminate wrong answers

Option B is wrong because the environment variable `APP_DEBUG` is defined both via the ConfigMap and the explicit `env` entry, so it is not undefined. Option C is wrong because Kubernetes does not concatenate values for the same key; it applies a precedence rule where the explicit `env` entry overrides the value from `envFrom`. Option D is wrong because the explicit `env` entry with value 'false' overrides the ConfigMap's value of 'true', not the other way around.

Practice this question →

106

MCQmedium

You apply a ResourceQuota to a namespace that limits memory requests to 2Gi. You then try to create a pod that requests 3Gi memory. What happens?

A.The pod is created with a warning, but the request is ignored.

B.The pod is created, but the memory request is capped at 2Gi.

C.The pod creation fails with an error message indicating the quota would be exceeded.

D.The pod is created, but it will be OOMKilled if it exceeds 2Gi.

AnswerC

This is the correct behavior because ResourceQuota validation runs as an admission controller in the API server. When a pod's memory request would push the namespace's aggregated usage over the quota limit, the server rejects the Create request with a clear error message, typically starting with 'quota exceeded' and detailing requested, used, and limited amounts. The rejection occurs synchronously before the pod is persisted, so no pod object is ever created. This is exactly how admission control is designed to protect finite namespace-level resources.

Why this answer

When a ResourceQuota is applied to a namespace with a memory request limit of 2Gi, any pod creation that would cause the total memory requests in the namespace to exceed that quota is rejected by the Kubernetes API server. The pod creation fails immediately with an error message indicating the quota would be exceeded, because the admission controller validates the request against the quota before allowing the pod to be scheduled.

Exam trap

The trap here is that candidates may confuse ResourceQuota (which enforces at admission time and rejects the pod) with LimitRange (which sets default requests/limits but does not cap existing requests), or mistakenly think Kubernetes silently adjusts resource requests to fit within quotas.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not create pods with warnings and ignore requests; quota enforcement is strict and fails the creation. Option B is wrong because the memory request is not capped at 2Gi; the pod creation is rejected entirely, not modified. Option D is wrong because the pod is never created, so it cannot be OOMKilled; OOMKilling occurs at runtime if a container exceeds its memory limit, not due to quota enforcement.

Practice this question →

107

MCQhard

A Pod specification includes: securityContext: { seccompProfile: { type: RuntimeDefault } }. What does this configuration do?

A.It disables seccomp for the pod

B.It applies the container runtime's default seccomp profile

C.It allows all syscalls

D.It uses a custom seccomp profile from a file

AnswerB

A `seccompProfile` with `type: RuntimeDefault` instructs the container runtime (e.g., Docker, containerd) to apply its built-in default seccomp filter, which is typically a restricted profile that blocks dangerous syscalls like `kexec_load`, `reboot`, and `keyctl` while permitting common operations. This provides a security-hardened baseline automatically, without needing to author or manage a custom profile. It is the recommended option for most workloads unless specific syscalls must be allowed.

Why this answer

Setting `seccompProfile.type: RuntimeDefault` in the Pod's securityContext instructs the container runtime (e.g., containerd or CRI-O) to apply its own default seccomp profile to the container. This default profile restricts system calls to a safe subset, blocking dangerous or unnecessary syscalls while allowing common ones required for typical application execution. It is the recommended way to enable seccomp without managing a custom profile.

Exam trap

The trap here is that candidates confuse `RuntimeDefault` with disabling seccomp or allowing all syscalls, when in fact it applies a restrictive, runtime-specific default profile that is neither fully permissive nor custom.

How to eliminate wrong answers

Option A is wrong because `RuntimeDefault` does not disable seccomp; disabling seccomp would require setting the type to `Unconfined` or omitting the seccomp configuration entirely. Option C is wrong because `RuntimeDefault` does not allow all syscalls; it applies a restrictive profile that blocks many syscalls, and allowing all syscalls would be achieved by `Unconfined`. Option D is wrong because using a custom seccomp profile from a file requires setting the type to `Localhost` and specifying a `localhostProfile` path, not `RuntimeDefault`.

Practice this question →

108

MCQmedium

A pod is in Pending state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient cpu'. Which action would resolve this?

A.Reduce the CPU request in the container's resource spec

B.Increase the CPU limit of the container

C.Delete and recreate the pod

D.Add more environment variables

AnswerA

Scheduling decisions in Kubernetes are based on resource requests, not limits. Your pod remains Pending because no node in the cluster has enough unallocated CPU to satisfy the container's requested amount. Reducing the CPU request lowers the pod's scheduling footprint, allowing the scheduler to fit it onto a node whose remaining allocatable CPU is smaller, resolving the Pending state.

Why this answer

The pod is in Pending state because no node has enough allocatable CPU to satisfy the container's CPU request. Reducing the CPU request in the container's resource spec lowers the amount of guaranteed CPU the scheduler requires, making it possible to schedule the pod on a node with insufficient CPU capacity. This directly resolves the 'Insufficient cpu' condition shown in 'kubectl describe pod'.

Exam trap

The CKAD exam often tests the distinction between CPU requests and limits, where candidates mistakenly think increasing limits or deleting/recreating the pod will fix scheduling issues, but only adjusting the request (or adding more nodes) resolves 'Insufficient cpu' errors.

How to eliminate wrong answers

Option B is wrong because increasing the CPU limit does not affect scheduling; the scheduler only considers CPU requests (not limits) when determining node fit, so raising the limit would not resolve the insufficient CPU issue. Option C is wrong because deleting and recreating the pod without changing the resource request will result in the same scheduling failure, as the cluster still lacks a node with enough allocatable CPU. Option D is wrong because environment variables have no impact on CPU resource allocation or scheduling decisions; they are purely for application configuration and do not affect node capacity.

Practice this question →

109

MCQmedium

A namespace 'team-a' has a ResourceQuota that sets 'requests.cpu: 4' and 'limits.cpu: 8'. A developer tries to create a pod with 'resources.requests.cpu: 2' and 'resources.limits.cpu: 10'. What happens?

A.The pod is rejected because the limit (10) exceeds the quota's allowed limit

B.The pod is created because the request (2) is within the quota

C.The pod is created but its limit is automatically reduced to 8

D.The pod is created, but it will be evicted immediately

AnswerA

When a ResourceQuota is active in a namespace, the API server enforces it during admission control by summing the resource limits of all existing objects and comparing them to the quota. A new Pod with a limit of 10 exceeds the namespace's allowed limit total of 8, so the API server rejects the creation with a 403 Forbidden response. The Pod is never persisted to etcd and never reaches the scheduler.

Why this answer

The pod is rejected because the ResourceQuota in namespace 'team-a' sets a hard limit of 8 CPUs for limits.cpu across all pods. The developer's pod specifies a limit of 10 CPUs, which exceeds this quota. Kubernetes enforces ResourceQuota at admission time, so any resource request or limit that violates the quota's constraints will cause the pod creation to be denied.

Exam trap

The trap here is that candidates often assume only the request is checked against the quota, but Kubernetes enforces both requests and limits independently, and a pod with a limit exceeding the quota's limit will be rejected even if the request is within bounds.

How to eliminate wrong answers

Option B is wrong because even though the request (2) is within the quota, the limit (10) exceeds the quota's allowed limit of 8, and Kubernetes checks both requests and limits against the quota. Option C is wrong because Kubernetes does not automatically reduce resource limits to fit within a quota; it rejects the pod instead, as per the admission controller behavior. Option D is wrong because the pod is not created at all due to admission denial, so it cannot be evicted; eviction occurs only after a pod is running and violates a limit range or is under resource pressure.

Practice this question →

110

MCQeasy

You have a ConfigMap named 'app-config' with key 'database.url'. Which environment variable definition correctly injects this value into a pod using a configMapKeyRef?

A.- name: DATABASE_URL valueFrom: configMapKeyRef: name: app-config key: database.url

B.envFrom: - configMapRef: name: app-config

C.- name: DATABASE_URL valueFrom: secretKeyRef: name: app-config key: database.url

D.- valueFrom: configMapKeyRef: name: app-config key: database.url

AnswerA

This option is correct because it properly defines an environment variable named `DATABASE_URL` using the `name` field and combines it with a `valueFrom` block. The `configMapKeyRef` inside `valueFrom` specifies the ConfigMap `app-config` and the key `database.url`, which instructs Kubernetes to retrieve that specific value. This is the standard and complete syntax for referencing a single key from a ConfigMap as an environment variable.

Why this answer

It properly defines an environment variable with a name and uses `valueFrom.configMapKeyRef` to reference the specific key 'database.url' from the ConfigMap 'app-config'. The `name` field is required in the env entry to specify the environment variable name. Option D is incorrect because it omits the `name` field, making the definition incomplete.

Exam trap

The trap is that candidates might think the `name` field is optional or that `valueFrom` alone is sufficient. In reality, each environment variable injection via `valueFrom` must include the `name` field to define the variable name.

How to eliminate wrong answers

Option A is wrong because it uses `valueFrom` with a `configMapKeyRef` but the syntax is incomplete — it lacks the `- name: DATABASE_URL` line above the `valueFrom` block, which is required to define the environment variable name; however, the core structure is actually correct if the name were present, so this option is not the best answer because the question expects the exact correct snippet. Option B is wrong because `envFrom` with a `configMapRef` injects all keys from the ConfigMap as environment variables, not a single specific key, and it does not allow renaming the variable to `DATABASE_URL`; it would create an environment variable named `database.url`, which is invalid in most shells due to the dot. Option C is wrong because it uses `secretKeyRef` instead of `configMapKeyRef`, which is designed for Secrets, not ConfigMaps; referencing a ConfigMap with `secretKeyRef` will fail because the API expects a Secret resource.

Practice this question →

111

MCQhard

A pod in a namespace with a ResourceQuota that sets 'requests.cpu: 2' is failing to schedule. The pod manifest specifies 'resources: { requests: { cpu: "500m" } }'. What is the likely cause?

A.The ResourceQuota applies to limits, not requests.

B.The namespace has already used all its CPU request quota.

C.The pod does not specify a CPU limit.

D.The pod's CPU request exceeds the ResourceQuota limit.

AnswerB

Even though the pod's individual request is small (500m), the ResourceQuota enforces an aggregate limit on the sum of all CPU requests in the namespace. At admission time, Kubernetes compares the current usage (sum of requests from all running/creating objects) plus the new pod's request against the quota's hard limit of 2000m. If the existing usage is already at or near 2000m, adding this pod's 500m pushes the total over the limit, causing the 'quota exceeded' error. This is a namespace-level accounting issue, not a per-pod scheduling problem.

Why this answer

The ResourceQuota sets a hard limit of 2 CPU cores for total requests across all pods in the namespace. If the sum of CPU requests from all pods already reaches or exceeds 2, a new pod with a 500m CPU request cannot be scheduled because it would exceed the quota. The pod's request (500m) is well within the quota limit, so the issue is that the namespace has exhausted its CPU request budget.

Exam trap

The trap here is that candidates assume the pod's individual request must be less than the quota, but they overlook that the quota is a cumulative limit across all pods in the namespace, so even a small request can fail if the namespace is already at capacity.

How to eliminate wrong answers

Option A is wrong because ResourceQuota can apply to both requests and limits; by default, it applies to requests unless specified otherwise, and the question states 'requests.cpu: 2' which explicitly targets requests. Option C is wrong because a CPU limit is not required for scheduling; the ResourceQuota only enforces the requests.cpu limit, and the pod can run without a limit. Option D is wrong because the pod's CPU request (500m) is less than the ResourceQuota limit (2), so it does not exceed the quota; the failure is due to cumulative usage, not an individual overage.

Practice this question →

112

MCQhard

You have a Secret of type kubernetes.io/tls. The pod mounting it as a volume expects the files 'tls.crt' and 'tls.key'. What keys must the Secret data contain?

A.ca.crt and tls.key

B.tls.crt and tls.key

C.cert and key

D.certificate and key

AnswerB

This is correct because the kubernetes.io/tls secret type is defined with these exact data keys. Kubernetes API validation and tools like kubectl rely on the literal names tls.crt and tls.key to read the certificate chain and private key. Any other key names cause the secret to be treated as a generic Opaque secret unless the type is manually set, but even then external tooling expects the standard names.

Why this answer

For a Secret of type `kubernetes.io/tls`, the Kubernetes API server expects the data to contain exactly the keys `tls.crt` and `tls.key`. When such a Secret is mounted as a volume into a pod, the files created in the mount path are named `tls.crt` and `tls.key`, matching these keys. This is enforced by the Kubernetes TLS secret controller and is documented in the official Kubernetes reference for TLS secrets.

Exam trap

The trap here is that candidates confuse the generic concept of a certificate and key with the exact key names required by the `kubernetes.io/tls` secret type, leading them to choose options like `cert` and `key` or `certificate` and `key` instead of the mandatory `tls.crt` and `tls.key`.

How to eliminate wrong answers

Option A is wrong because `ca.crt` is an optional key for a TLS secret (used to provide a CA bundle), but the required keys for the secret type `kubernetes.io/tls` are `tls.crt` and `tls.key`; the pod expects `tls.crt` and `tls.key` files, not `ca.crt`. Option C is wrong because `cert` and `key` are not the standard key names for a TLS secret; Kubernetes specifically requires the keys to be named `tls.crt` and `tls.key` to match the expected file names on mount. Option D is wrong because `certificate` and `key` are generic terms, not the exact key names mandated by the `kubernetes.io/tls` secret type; the API server will reject a secret that does not contain the exact keys `tls.crt` and `tls.key`.

Practice this question →

113

Multi-Selectmedium

Which TWO approaches can be used to expose a Secret's value as an environment variable in a pod?

Select 2 answers

A.env: - name: MY_SECRET valueFrom: secretKeyRef: name: my-secret key: my-key

B.volumeMounts: - name: secret-volume mountPath: /etc/secret

C.envFrom: - secretRef: name: my-secret

D.env: - name: MY_SECRET value: "$(MY_SECRET)"

E.env: - name: MY_SECRET valueFrom: configMapKeyRef: name: my-secret key: my-key

AnswersA, C

This is the canonical way to inject a single secret value as an environment variable. The `valueFrom.secretKeyRef` field directly references the named Secret (`my-secret`) and the specific key (`my-key`), and Kubernetes populates `MY_SECRET` with that key's value at container startup. Unlike `envFrom`, this gives you fine-grained control over the exact environment variable name and source, and unlike a volume mount, it does not create a filesystem object. It is the recommended approach when you need just one or a few values from a Secret exposed as env vars.

Why this answer

The `valueFrom.secretKeyRef` field in a container's `env` definition directly references a specific key from a Kubernetes Secret and injects its value as an environment variable. This is the standard method for exposing a single secret key as an environment variable, as defined in the Kubernetes API.

Exam trap

CNCF often tests the distinction between `secretKeyRef` (for individual keys) and `secretRef` (for all keys via `envFrom`), and the trap here is that candidates may confuse `configMapKeyRef` with `secretKeyRef` or think that `volumeMounts` can expose secrets as environment variables.

Practice this question →

114

Multi-Selectmedium

A developer wants to mount a ConfigMap as a volume in a Pod so that updates to the ConfigMap are reflected in the Pod without restarting. Which two statements are correct? (Choose two.)

Select 2 answers

A.Using envFrom to inject ConfigMap data as environment variables will update automatically.

B.ConfigMap updates are reflected immediately in the volume mount.

C.Using subPath in the volume mount prevents automatic updates.

D.The Pod must be restarted for any ConfigMap change to take effect.

E.Mounting the ConfigMap as a volume (without subPath) ensures that file updates are reflected automatically through symlinks.

AnswersC, E

Mounting a ConfigMap file with subPath creates a direct bind mount of the single file into the container, bypassing the symlink update mechanism. Because the inode is bound at mount creation, subsequent ConfigMap edits that replace the original file do not change the inode the container sees, so the mounted content stays stale. Only by restarting the pod (or re-creating it) is the subPath mount refreshed.

Why this answer

When a ConfigMap is mounted using `subPath`, Kubernetes treats the mount as a single file rather than a directory of symlinks. This means the atomic update mechanism (which uses symlinks to swap the directory contents) is bypassed, and updates to the ConfigMap are not reflected in the Pod without a restart or remount.

Exam trap

The trap here is that candidates often assume all ConfigMap mounts update automatically, but `subPath` mounts are a critical exception that breaks the automatic update mechanism.

Practice this question →

115

MCQmedium

A pod fails to start with a 'CreateContainerConfigError'. Running 'kubectl describe pod my-pod' reveals: 'Error: container has runAsNonRoot and image will run as root'. The pod definition includes 'securityContext.runAsNonRoot: true'. What is the most likely cause?

A.The container does not have the CAP_SYS_ADMIN capability

B.The container image's default user is root (UID 0), conflicting with runAsNonRoot

C.The container's filesystem is read-only

D.The runAsUser field is missing, so the pod uses a random UID

AnswerB

When runAsNonRoot: true is set, the kubelet inspects the container image's configured user (typically the USER instruction or default UID). If the image's default user is root (UID 0), the kubelet refuses to start the container and emits an error such as 'container has runAsNonRoot and image will run as root'. Since the error is CreateContainerConfigError, it exactly matches this contradiction between the securityContext and the image's default user, making this the correct cause.

Why this answer

The error 'container has runAsNonRoot and image will run as root' occurs because the pod's securityContext sets `runAsNonRoot: true`, but the container image's default user is root (UID 0). Kubernetes checks the image's user at container startup; if the image runs as root and the pod enforces non-root, the container fails to start with a CreateContainerConfigError.

Exam trap

The trap here is that candidates often assume the error is about missing runAsUser or capabilities, but the error message directly points to the image's default user being root, which is a mismatch with the runAsNonRoot constraint.

How to eliminate wrong answers

Option A is wrong because CAP_SYS_ADMIN is a Linux capability unrelated to the runAsNonRoot check; the error is about the container's user identity, not capabilities. Option C is wrong because a read-only filesystem does not cause a runAsNonRoot conflict; it would produce a different error (e.g., 'read-only filesystem'). Option D is wrong because runAsUser is not required when runAsNonRoot is true; Kubernetes will still enforce non-root even without an explicit UID, and the error explicitly states the image runs as root, not that a random UID is used.

Practice this question →

116

Drag & Dropmedium

Sequence the steps to scale a Deployment to 5 replicas and verify.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for scaling and verifying a Deployment involves first checking the current state to establish a baseline, then applying the scale command, watching the Pods to observe the rollout in real-time, confirming the final replica count, and finally inspecting events to catch any errors or anomalies. This order ensures a systematic and efficient verification process.

Practice this question →

117

MCQhard

A container image requires a seccomp profile that is not the default. The cluster supports the RuntimeDefault seccomp profile. Which Pod securityContext field should be configured to use the RuntimeDefault seccomp profile?

A.seccompProfile: type: RuntimeDefault

B.seccomp: type: RuntimeDefault

C.capabilities: add: [SECCOMP]

D.securityContext: seccomp: type: Unconfined

AnswerA

The correct configuration under a container's securityContext is seccompProfile, and setting its type to RuntimeDefault tells the container runtime to apply its built-in default seccomp profile. This profile restrictively filters syscalls, blocking dangerous ones while allowing normal operation, without requiring you to ship a custom profile. It is the preferred way to enable seccomp in modern Kubernetes because it delegates the policy to the runtime, which is already tuned for safe defaults.

Why this answer

The `seccompProfile` field under the Pod's `securityContext` is the proper way to specify a seccomp profile in Kubernetes. Setting `type: RuntimeDefault` tells the container runtime (e.g., containerd or CRI-O) to use the default seccomp profile provided by the runtime, which is a secure baseline that blocks around 44 system calls while allowing common ones like `read`, `write`, and `exit`. This field was introduced in Kubernetes 1.19 (GA in 1.22) and is the standard approach for configuring seccomp at the Pod or container level.

Exam trap

The trap here is that candidates confuse the old alpha annotation `seccomp.security.alpha.kubernetes.io/pod` (deprecated in 1.19) with the current `seccompProfile` field, or they mistakenly think `capabilities` can set the seccomp profile, when in fact capabilities only grant permission to use seccomp syscalls, not apply a profile.

How to eliminate wrong answers

Option B is wrong because `seccomp` is not a valid field in the Pod `securityContext`; the correct field is `seccompProfile`, and the `type` subfield specifies the profile type (e.g., RuntimeDefault, Localhost, Unconfined). Option C is wrong because `capabilities` with `SECCOMP` is a Linux capability that allows a process to install seccomp filters, but it does not configure the Pod to use the RuntimeDefault profile; it grants the ability to manipulate seccomp, which is a different concept. Option D is wrong because `securityContext` does not have a `seccomp` field; the correct structure is `seccompProfile.type`, and `Unconfined` disables seccomp entirely, which is the opposite of using the RuntimeDefault profile.

Practice this question →

118

MCQeasy

Which kubectl command creates a Secret named 'tls-secret' from a TLS certificate file 'cert.pem' and private key file 'key.pem'?

A.kubectl create secret tls tls-secret --certificate=cert.pem --private-key=key.pem

B.kubectl create secret tls tls-secret --cert=cert.pem --key=key.pem

C.kubectl create secret generic tls-secret --from-file=cert.pem --from-file=key.pem

D.kubectl create secret docker-registry tls-secret --cert=cert.pem --key=key.pem

AnswerB

This is the correct command to create a TLS secret: it generates a Secret with the type `kubernetes.io/tls` and stores the contents of `cert.pem` under the `tls.crt` data key and `key.pem` under the `tls.key` data key. The `--cert` and `--key` flags are required and must point to PEM-encoded files. After creation, the secret can be referenced by an Ingress's `tls` section or mounted into a pod for TLS termination.

Why this answer

The `kubectl create secret tls` command is specifically designed to create a TLS secret from a certificate and private key pair. The correct flags are `--cert` for the certificate file and `--key` for the private key file, matching the usage shown in option B.

Exam trap

The trap here is that candidates confuse the `--cert` and `--key` flags with similar flags from other tools (like OpenSSL) or assume `--certificate` is the correct flag, leading them to choose option A, or they mistakenly use `generic` instead of `tls` for TLS secrets, as in option C.

How to eliminate wrong answers

Option A is wrong because it uses `--certificate` and `--private-key` flags, which are not valid for `kubectl create secret tls`; the correct flags are `--cert` and `--key`. Option C is wrong because it uses `kubectl create secret generic`, which creates a generic Opaque secret, not a TLS secret; TLS secrets require the `tls` type to properly encode the certificate and key with the correct keys (`tls.crt` and `tls.key`). Option D is wrong because it uses `kubectl create secret docker-registry`, which is for creating a Docker registry authentication secret, not a TLS secret; it expects `--docker-username`, `--docker-password`, etc., not certificate files.

Practice this question →

119

MCQmedium

You deploy a pod with resource requests: cpu: 500m, memory: 256Mi and limits: cpu: 1, memory: 512Mi. The container tries to allocate 600Mi of memory. What happens?

A.The container is OOMKilled because it exceeds the memory limit

B.The container runs normally, but memory usage is throttled

C.The container runs normally because requests are the only constraints

D.The container is evicted from the node

AnswerA

The container is OOMKilled because it exceeds the memory limit. Memory limits are enforced via a cgroup; when the container's memory usage surpasses that limit, the kernel's OOM killer terminates the offending process. This results in the pod's container being marked as OOMKilled with exit code 137, and Kubernetes restarts it according to the restart policy.

Why this answer

The container's memory allocation of 600Mi exceeds its configured memory limit of 512Mi. Kubernetes enforces memory limits using the cgroup memory controller; when a container attempts to allocate more memory than its limit, the kernel's Out-Of-Memory (OOM) killer terminates the container process. This results in the container being OOMKilled, as recorded in the pod status.

Exam trap

CNCF often tests the misconception that memory, like CPU, can be throttled when limits are exceeded, but memory is a non-compressible resource and exceeding its limit always results in an OOM kill, not throttling.

How to eliminate wrong answers

Option B is wrong because memory is not a compressible resource like CPU; exceeding the memory limit triggers an OOM kill, not throttling. Option C is wrong because memory limits are hard constraints enforced by Kubernetes, not just requests; requests are used for scheduling, while limits are enforced at runtime. Option D is wrong because eviction occurs when a node is under memory pressure and the kubelet reclaims resources by terminating pods, not when a single container exceeds its own limit.

Practice this question →

120

MCQmedium

A pod is running with a SecurityContext that sets 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process is running as user 1000. However, the container needs to access a file on a mounted volume that is owned by user 1000 and group 2000. Which SecurityContext setting should be added to ensure the container can read the file?

A.Set fsGroup: 2000 in the pod-level securityContext

B.Set readOnlyRootFilesystem: true

C.Set runAsGroup: 2000

D.Add capability: CAP_DAC_READ_SEARCH

AnswerA

Set fsGroup: 2000 in the pod-level securityContext - This ensures the volume files' group ownership is changed to 2000 and the container process is part of that supplementary group, allowing read access. This is the correct approach.

Why this answer

fsGroup is a pod-level SecurityContext setting that causes Kubernetes to recursively change the group ownership of the volume's files to the specified GID and adds the container's supplemental group list. Setting fsGroup: 2000 makes the mounted volume files group-owned by GID 2000, and the container process running as user 1000 inherits 2000 as a supplemental group, granting read access. This is the canonical fix when a volume's group ownership does not match the container's primary runAsGroup.

Exam trap

CKAD often tests the confusion between runAsGroup (the process's primary GID) and fsGroup (the volume's group ownership), leading candidates to pick runAsGroup when the real issue is on-disk file group ownership.

How to eliminate wrong answers

Option B is wrong because readOnlyRootFilesystem only controls whether the container's root filesystem is writable — it has no effect on volume file ownership or group permissions. Option C is wrong because changing runAsGroup to 2000 alters the process's primary GID but does not change the on-disk group ownership of the volume files, which are owned by group 2000 only if fsGroup applied; without fsGroup the files remain owned by whatever GID the volume plugin assigned. Option D is wrong because CAP_DAC_READ_SEARCH is a Linux capability that bypasses file read permission checks entirely — it is an over-privileged workaround, not the intended Kubernetes mechanism, and it does not address group ownership semantics.

Practice this question →

121

MCQeasy

Which command creates a generic Secret with username=admin and password=secret123?

A.kubectl create secret tls mysecret --from-literal=username=admin --from-literal=password=secret123

B.kubectl create secret generic mysecret --from-env-file=username=admin,password=secret123

C.kubectl create secret generic mysecret --from-file=username=admin --from-file=password=secret123

D.kubectl create secret generic mysecret --from-literal=username=admin --from-literal=password=secret123

AnswerD

This is the correct syntax because `kubectl create secret generic` creates an Opaque Secret, and each `--from-literal` flag adds one key-value pair directly from the command line. kubectl automatically Base64-encodes the specified values when storing them in the Secret's `data` field, so `username=admin` and `password=secret123` become the secret's data entries. This approach is ideal for simple credential pairs without needing any local files.

Why this answer

`kubectl create secret generic` with `--from-literal` allows you to specify key-value pairs directly on the command line, creating a generic (opaque) Secret with the literal values `username=admin` and `password=secret123`. This is the standard way to create a generic Secret from literal data.

Exam trap

CNCF often tests the distinction between `--from-literal`, `--from-file`, and `--from-env-file`, and candidates commonly confuse `--from-file` (which expects a file path) with `--from-literal` (which expects a key=value pair).

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS Secret, which expects a `--cert` and `--key` file, not literal key-value pairs, and is used for TLS certificates, not generic credentials. Option B is wrong because `--from-env-file` expects a file path (e.g., a `.env` file), not inline key-value pairs; the syntax `--from-env-file=username=admin,password=secret123` is invalid and would cause an error. Option C is wrong because `--from-file` expects a file path (e.g., `--from-file=username=./username.txt`), not literal key-value pairs; using `--from-file=username=admin` would try to read a file named `admin` in the current directory, not set the value to `admin`.

Practice this question →

122

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file 'app.properties'?

A.kubectl create configmap app-config --from-file=app.properties

B.kubectl create configmap app-config --from-literal=app.properties

C.kubectl create configmap app-config --from-env-file=app.properties

D.kubectl create configmap app-config --file=app.properties

AnswerA

The --from-file flag tells kubectl to read the contents of the specified file and create a single data key in the ConfigMap, using the filename (app.properties) as the key and the file's content as the value. This is the correct imperative way to generate a ConfigMap from a file without manually writing a YAML manifest. Because the content becomes the value, any valid file format (properties, JSON, YAML, or plain text) can be stored as an opaque data entry.

Why this answer

`kubectl create configmap app-config --from-file=app.properties` reads the file `app.properties` and creates a ConfigMap with a single key-value pair where the key is the filename (without extension) and the value is the entire file content. This is the standard way to create a ConfigMap from a file in Kubernetes.

Exam trap

The trap here is confusing `--from-file` (which stores the entire file content as a single value) with `--from-env-file` (which parses the file as key-value pairs for environment variables), leading candidates to pick option C when they need to import a properties file as a single blob.

How to eliminate wrong answers

Option B is wrong because `--from-literal` expects a key=value pair directly on the command line, not a filename; using `--from-literal=app.properties` would create a ConfigMap with the literal string 'app.properties' as both the key and value, not the file's content. Option C is wrong because `--from-env-file` is used to import a file containing multiple key=value lines (one per line) as environment variables, not to store the entire file content as a single value. Option D is wrong because `--file` is not a valid flag for the `kubectl create configmap` command; the correct flag is `--from-file`.

Practice this question →

123

Multi-Selectmedium

Which THREE of the following are valid types of Secrets in Kubernetes?

Select 3 answers

A.Opaque

B.kubernetes.io/ssh-auth

C.configmap

D.dockerconfigjson

E.kubernetes.io/tls

AnswersA, B, E

Opaque is the default Kubernetes Secret type when no `type` field is specified, designed for arbitrary key-value pairs such as passwords, API tokens, or configuration fragments. Its data is base64-encoded but not encrypted at rest by default, and no additional validation or controller behavior is attached to it. This makes it the general-purpose fallback for most application secrets, and it is the most commonly used type in practice.

Why this answer

Options A, B, and E are valid Kubernetes Secret types. Opaque is the default type for arbitrary data. kubernetes.io/ssh-auth is used for SSH authentication credentials. kubernetes.io/tls is used for TLS certificates. Options C and D are invalid: configmap is a separate resource, and dockerconfigjson lacks the kubernetes.io/ prefix (the valid type is kubernetes.io/dockerconfigjson).

Exam trap

CNCF often tests the exact naming of built-in Secret types, and the trap here is that candidates may confuse `dockerconfigjson` (missing the `kubernetes.io/` prefix) with the valid `kubernetes.io/dockerconfigjson`, or assume `configmap` is a Secret type when it is a separate resource.

Practice this question →

124

MCQmedium

A Pod specification includes: securityContext: { runAsNonRoot: true }. The container image runs as root by default. What will happen when the Pod is created?

A.The Pod will start and immediately be OOMKilled

B.The Pod will run but with a warning

C.The Pod will not start; the kubelet will reject it because the container tries to run as root

D.The Pod will run successfully because K8s overrides the user to non-root

AnswerC

runAsNonRoot instructs the kubelet to verify that the container's effective user is not UID 0 before starting it. When the container image specifies root as its user, the kubelet returns an error and refuses to start the container, leaving the Pod in a failed or Pending state with a container creation failure event. This prevents a root process from ever executing.

Why this answer

When a Pod specifies `runAsNonRoot: true` in its `securityContext`, the kubelet verifies that the container's user ID is non-zero (non-root) before starting the container. If the container image runs as root by default (UID 0), the kubelet will reject the Pod, and it will remain in a `ContainerCreating` or `CrashLoopBackOff` state with an error like 'container has runAsNonRoot and image will run as root'. This is a security enforcement mechanism that prevents privileged execution.

Exam trap

The trap here is that candidates assume Kubernetes will automatically adjust the container user to non-root when `runAsNonRoot` is set, but in reality, Kubernetes only validates the existing user and rejects the Pod if it's root—you must explicitly set `runAsUser` to a non-zero value if the image runs as root.

How to eliminate wrong answers

Option A is wrong because OOMKilled (Out Of Memory Killed) occurs when a container exceeds its memory limit, not due to security context violations; the Pod is rejected before any execution. Option B is wrong because Kubernetes does not issue warnings for security context violations—it enforces them strictly by failing the Pod creation, and the event logs will show an error, not a warning. Option D is wrong because Kubernetes does not automatically override the container's user to non-root; the `runAsNonRoot` flag only validates the user, and if the image runs as root, the Pod is rejected unless you explicitly set `runAsUser` to a non-zero value.

Practice this question →

125

Multi-Selecthard

Which THREE are valid ways to create a ConfigMap?

Select 3 answers

A.kubectl create configmap my-config --from-literal=key=value

B.kubectl create configmap my-config --from-file=app.properties

C.kubectl create configmap my-config --from-env-file=app.env

D.kubectl create configmap my-config --from-file=key=file

E.kubectl apply configmap my-config --from-literal=key=value

AnswersA, B, C

The --from-literal flag creates a single key-value entry directly from the command line, using the exact syntax key=value. It is the simplest way to inject a scalar value, and you can repeat the flag multiple times to add more entries. Each flag must be a valid key-value pair, and the key must follow Kubernetes naming conventions (alphanumeric, '-', '_', '.').

Why this answer

`kubectl create configmap` with `--from-literal` directly creates a ConfigMap with a key-value pair from the command line, which is a standard and valid method. This approach is ideal for simple, single-key configurations without needing external files.

Exam trap

The trap here is that candidates may confuse `kubectl create configmap` with `kubectl apply` or misremember the syntax for `--from-file` with a custom key, leading them to select invalid options like D or E.

Practice this question →

126

MCQeasy

Which command creates a TLS secret from an existing certificate and key file?

A.kubectl create secret tls my-tls --cert=cert.pem --key=key.pem

B.kubectl create secret tls my-tls --from-file=cert.pem --from-file=key.pem

C.kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

D.kubectl create secret docker-registry my-tls --docker-server=... --docker-username=... --docker-password=...

AnswerA

This is the correct command because `kubectl create secret tls` is the dedicated subcommand for generating a Kubernetes secret of type `kubernetes.io/tls`. It requires the `--cert` flag to point to the PEM-encoded certificate (usually the full chain) and the `--key` flag to point to the PEM-encoded private key. The resulting secret automatically stores these under the standard data keys `tls.crt` and `tls.key`, which ingress controllers and other TLS consumers expect. Using this exact syntax ensures the secret is properly typed and immediately usable for TLS termination.

Why this answer

The `kubectl create secret tls` command is specifically designed to create a TLS secret from an existing certificate and key file. The `--cert` and `--key` flags directly specify the paths to the PEM-encoded certificate and private key, which Kubernetes then stores as a `kubernetes.io/tls` secret type, automatically base64-encoding the data for secure storage in etcd.

Exam trap

The trap here is that candidates confuse the `--from-file` flag (used for generic secrets) with the `--cert` and `--key` flags (required for TLS secrets), leading them to choose option B or C, which would create a secret of the wrong type or with incorrect key mappings.

How to eliminate wrong answers

Option B is wrong because `kubectl create secret tls` does not support `--from-file` flags; those flags are used with `kubectl create secret generic` or `kubectl create secret docker-registry`, and using them with `tls` would result in a syntax error or create a generic secret instead of a TLS secret. Option C is wrong because `kubectl create secret generic` creates a generic secret (type `Opaque`), not a TLS secret (type `kubernetes.io/tls`), and the `--from-file` flags would store the files as arbitrary keys rather than the required `tls.crt` and `tls.key` entries. Option D is wrong because `kubectl create secret docker-registry` creates a Docker registry authentication secret (type `kubernetes.io/dockercfg`), which is used for pulling images from private registries, not for storing TLS certificates and keys.

Practice this question →

127

Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext (pod-level securityContext)? (Select 3)

Select 3 answers

A.runAsUser

B.fsGroup

C.readOnlyRootFilesystem

D.capabilities

E.seccompProfile

AnswersA, B, E

In the PodSecurityContext, runAsUser specifies the UID that all containers in the pod run with, overriding any image-level USER directive. It is a pod-level field because it belongs to the pod's security context and applies uniformly to every container's primary process. Setting it ensures consistent privilege separation at the pod level.

Why this answer

`runAsUser` is a valid field in a PodSecurityContext that sets the user ID (UID) for all containers in the pod, overriding any container-level `securityContext.runAsUser`. This is defined in the Kubernetes API under `PodSecurityContext` and is commonly used to enforce non-root execution.

Exam trap

CNCF often tests the distinction between pod-level and container-level securityContext fields, and the trap here is that candidates confuse `readOnlyRootFilesystem` and `capabilities` as pod-level fields when they are actually only valid at the container level.

Practice this question →

128

Multi-Selecthard

Which THREE of the following are valid fields in a SecurityContext at the container level? (Select three.)

Select 3 answers

A.fsGroup

B.runAsUser

C.readOnlyRootFilesystem

D.capabilities

E.sysctls

AnswersB, C, D

runAsUser is a valid container-level SecurityContext field that specifies the user ID for the container's primary process. When set at the container level, it overrides any runAsUser value defined at the Pod level. This is essential for ensuring containers run as a non-root user, reducing the risk of privilege escalation.

Why this answer

The correct three options are B, C, and D. Option B (runAsUser) sets the user ID for container processes and is valid at container level. Option C (readOnlyRootFilesystem) mounts the root filesystem as read-only.

Option D (capabilities) manages Linux capabilities. Option A (fsGroup) is a Pod-level SecurityContext field, not container-level. Option E (sysctls) is also a Pod-level field and cannot be set at the container level.

Therefore, B, C, and D are the valid container-level fields.

Exam trap

The exam often tests the distinction between Pod-level and container-level SecurityContext fields. A common trap is confusing fsGroup and sysctls, which are only valid at the Pod level, with runAsUser, which is valid at both levels. Candidates may mistakenly select sysctls as container-level.

Practice this question →

129

MCQhard

You create a Secret with 'kubectl create secret generic db-secret --from-literal=password=myPass'. Later, you mount it as a volume in a pod. When you exec into the container and cat the file, what will you see?

A.password=myPass

B.bXlQYXNz

C.myPass

D.An error because secrets cannot be mounted as volumes

AnswerC

When a Secret volume is mounted, each Secret key becomes a file in the mount path, and its contents are the decoded value exactly as you supplied it. Kubernetes performs this decode from the stored base64 form before writing to the volume, so the raw `myPass` is what an application sees when reading the file. This functionality is a core feature for injecting configuration data into Pods.

Why this answer

When you mount a Secret as a volume, Kubernetes automatically decodes the base64-encoded data and presents the file contents as the original plaintext value. In this case, the Secret stores the literal key-value pair `password=myPass`, and when mounted, the file named `password` contains the decoded value `myPass`.

Exam trap

The trap here is that candidates often confuse the base64-encoded representation stored in the Secret manifest with the decoded content presented when mounted as a volume, leading them to pick Option B.

How to eliminate wrong answers

Option A is wrong because the file content is not the raw `--from-literal` string `password=myPass`; Kubernetes separates the key from the value, so the file name is the key (`password`) and the file content is the value (`myPass`). Option B is wrong because `bXlQYXNz` is the base64 encoding of `myPass`, but when mounted as a volume, Kubernetes automatically decodes the data, so the file contains the plaintext `myPass`, not the encoded string. Option D is wrong because Secrets can absolutely be mounted as volumes; this is a standard and common method for exposing secret data to pods.

Practice this question →

130

MCQhard

Given the following partial pod spec: ```yaml securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 ``` Which combination correctly describes the resulting permissions on a mounted volume?

A.Volume owned by user 2000, group 1000; container runs with user 2000 and group 1000

B.Volume owned by user 3000, group 2000; container runs with user 1000 and group 3000

C.Volume owned by user 1000, group 2000; container runs with user 1000 and group 3000

D.Volume owned by user 1000, group 3000; container runs with user 1000 and group 2000

AnswerC

fsGroup 2000 sets the mounted volume's group ownership and permissions, so the volume is owned by group 2000, while runAsGroup 3000 governs the container process's primary group. The volume's user ownership comes from runAsUser 1000. These are distinct axes, which is why the volume group and process group differ.

Why this answer

With `runAsUser: 1000`, the container's primary user ID is set to 1000, and this also makes the volume owned by user 1000. `runAsGroup: 3000` sets the container's primary group ID to 3000. `fsGroup: 2000` changes the group ownership of the mounted volume to group 2000 and adds it as a supplemental group. Thus, the volume is owned by user 1000 and group 2000, and the container runs with UID 1000 and GID 3000.

Exam trap

The trap here is confusing `runAsGroup` (which sets the container's primary GID) with `fsGroup` (which sets the volume's group ownership and adds a supplemental group), leading candidates to incorrectly assign the volume's group to the container's primary group or vice versa.

How to eliminate wrong answers

Option A is wrong because it incorrectly states the volume is owned by user 2000 and group 1000, but `fsGroup` only affects group ownership, not user ownership, and `runAsUser` sets the container's UID to 1000, not 2000. Option B is wrong because it claims the volume is owned by user 3000 and group 2000, but `runAsUser: 1000` sets the container's UID to 1000, not 3000, and `fsGroup: 2000` sets the volume's group to 2000, not the user. Option D is wrong because it states the volume is owned by user 1000 and group 3000, but `fsGroup: 2000` sets the volume's group to 2000, not 3000, and the container's primary group is 3000, not 2000.

Practice this question →

131

MCQeasy

You have a ConfigMap created from an env file. Which command creates the ConfigMap from the file 'app.env' containing key=value pairs?

A.kubectl create configmap app-config --from-file=app.env

B.kubectl create configmap app-config --env-file=app.env

C.kubectl create configmap app-config --from-literal=app.env

D.kubectl create configmap app-config --from-env-file=app.env

AnswerD

--from-env-file=app.env specifically parses a file containing lines in KEY=VALUE format and creates a separate data entry for each line. This is the intended way to import an environment file into a ConfigMap, preserving each variable as its own key-value pair.

Why this answer

`--from-env-file` is the exact flag used to create a ConfigMap from a file containing key=value pairs in env-file format (e.g., `app.env`). This flag parses each line as a key-value pair and stores them as individual data entries in the ConfigMap, unlike `--from-file` which stores the entire file content under a single key.

Exam trap

CNCF often tests the subtle difference between `--from-file` and `--from-env-file`, where candidates mistakenly choose `--from-file` because they think it handles env files generically, but it does not parse key-value pairs.

How to eliminate wrong answers

Option A is wrong because `--from-file=app.env` creates a ConfigMap where the entire file content is stored as a single entry under the key `app.env`, not as separate key-value pairs. Option B is wrong because `--env-file` is not a valid flag for `kubectl create configmap`; it is used with `kubectl run` to inject environment variables from a file into a pod. Option C is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `key=value`), not to reference a file, and passing `app.env` as a literal would treat it as a literal string, not a file path.

Practice this question →

132

Multi-Selecthard

Which THREE of the following are capabilities that can be added to a container's securityContext?

Select 3 answers

A.RuntimeDefault

B.CAP_SYS_ADMIN

C.NET_ADMIN

D.CHOWN

E.SYS_TIME

AnswersC, D, E

NET_ADMIN is the Kubernetes name for the Linux capability CAP_NET_ADMIN, which permits operations such as configuring network interfaces, modifying routing tables, and managing firewall rules. It is a legitimate capability that can be added to a container's security context, making it one of the three correct answers.

Why this answer

(NET_ADMIN) is correct because it is a Linux capability that can be added to a container's securityContext under the `capabilities.add` field. This capability allows the container to perform network administration tasks such as interface configuration, firewall management, and routing table manipulation, which are common in network-focused pods.

Exam trap

The trap here is that candidates often confuse seccomp profiles (like RuntimeDefault) with Linux capabilities, or they assume that all capability names must be prefixed with 'CAP_' in the YAML (e.g., writing 'CAP_NET_ADMIN' instead of 'NET_ADMIN'), leading them to select incorrect options.

Practice this question →

133

MCQhard

You want to restrict a Pod to only run with a seccomp profile of 'RuntimeDefault'. Which SecurityContext field should you set?

A.appArmorProfile

B.capabilities

C.seLinuxOptions

D.seccompProfile

AnswerD

This is the correct field in the `securityContext` (either at pod or container level) to specify a seccomp profile that restricts system calls. By setting `type: RuntimeDefault`, you tell the container runtime (e.g., containerd, CRI-O) to use its default seccomp profile, which blocks a set of dangerous or unused syscalls. For custom filters, you can point to a `Localhost` profile using the `localhostProfile` field and a node's profile directory. This directly satisfies the requirement of running with a seccomp profile.

Why this answer

The `seccompProfile` field in a Pod's SecurityContext allows you to specify a seccomp profile to restrict system calls. Setting it to `RuntimeDefault` applies the container runtime's default seccomp profile, which blocks a set of dangerous syscalls while allowing normal operation. This is the correct field to enforce a seccomp profile of 'RuntimeDefault'.

Exam trap

The trap here is that candidates confuse seccomp with other security mechanisms like AppArmor or SELinux, or think that `capabilities` can restrict syscalls, when in fact seccomp is the only field that directly controls syscall filtering.

How to eliminate wrong answers

Option A is wrong because `appArmorProfile` is used to set AppArmor profiles, not seccomp profiles; AppArmor is a separate Linux Security Module (LSM) that controls file access and capabilities. Option B is wrong because `capabilities` adds or drops Linux capabilities (e.g., CAP_NET_ADMIN), which are privileges, not syscall filters. Option C is wrong because `seLinuxOptions` configures SELinux labels for process and file security contexts, which is another LSM unrelated to seccomp.

Practice this question →

134

MCQhard

You need to create a Pod that mounts a Secret named 'mysecret' as an environment variable 'SECRET_DATA'. The secret has a key 'password'. Which YAML snippet correctly achieves this?

A.env: - name: SECRET_DATA valueFrom: configMapKeyRef: name: mysecret key: password

B.env: - name: SECRET_DATA valueFrom: secretKeyRef: name: mysecret key: password

C.env: - name: SECRET_DATA valueFrom: secretKeyRef: name: password key: mysecret

D.volumeMounts: - name: secret-volume mountPath: /etc/secret volumes: - name: secret-volume secret: secretName: mysecret items: - key: password path: secret.txt

AnswerB

This is the correct approach. secretKeyRef directly references the Secret object by name ('mysecret') and extracts the specific key ('password') from that Secret's data. When this env var is defined, Kubernetes fetches the decoded value of the 'password' key and injects it into the container's SECRET_DATA environment variable, fulfilling the requirement to mount the secret as an environment variable.

Why this answer

It uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Secret named 'mysecret' and inject its value into the environment variable `SECRET_DATA`. This is the standard Kubernetes syntax for exposing a Secret's key-value pair as an environment variable.

Exam trap

The trap here is that candidates often confuse `configMapKeyRef` with `secretKeyRef` or swap the `name` and `key` fields, leading them to pick options that either reference the wrong resource type or misorder the required fields.

How to eliminate wrong answers

Option A is wrong because it uses `configMapKeyRef` instead of `secretKeyRef`; ConfigMaps are for non-sensitive data, while Secrets require `secretKeyRef`. Option C is wrong because it swaps the `name` and `key` fields: `name` should be the Secret's name ('mysecret'), and `key` should be the key within that Secret ('password'). Option D is wrong because it mounts the Secret as a file via a volume, not as an environment variable, which does not meet the requirement to expose the value as `SECRET_DATA`.

Practice this question →

135

Multi-Selecteasy

Which TWO of the following are valid types for a Kubernetes Secret? (Choose two.)

Select 2 answers

A.kubernetes.io/tls

B.kubernetes.io/basic-auth

C.kubernetes.io/configmap

D.kubernetes.io/tls-key

E.kubernetes.io/ssh-key

AnswersA, B

The `kubernetes.io/tls` Secret type is a built-in type designed specifically to store a TLS certificate and its associated private key. The data keys must be named exactly `tls.crt` for the certificate and `tls.key` for the private key; when mounted or referenced by an Ingress, the API server uses these keys to configure HTTPS termination. It is the standard type for any TLS secret, and its structure is enforced by Kubernetes controllers for Ingress and other TLS consumers.

Why this answer

Option A, kubernetes.io/tls, is a valid built-in Secret type used to store a TLS certificate and its associated private key, typically consumed by Ingress controllers for HTTPS termination. Option B, kubernetes.io/basic-auth, is also a valid built-in Secret type designed to hold a username and password for basic authentication, with the required keys being 'username' and 'password'. Option C, kubernetes.io/configmap, is not a valid Secret type because ConfigMaps are a separate Kubernetes API object with their own kind and are not represented as a Secret type.

Option D, kubernetes.io/tls-key, is not a recognized built-in Secret type; the TLS private key is instead stored as the 'tls.key' data key within a kubernetes.io/tls Secret. Option E, kubernetes.io/ssh-key, is not a built-in Secret type in Kubernetes, as SSH keys would typically be stored using the generic Opaque type or a custom type.

Exam trap

The trick is that candidates may confuse similar-sounding types. For example, kubernetes.io/tls-key is not a valid type; the correct one is kubernetes.io/tls. Similarly, kubernetes.io/ssh-auth is valid but kubernetes.io/ssh-key is not.

Knowing the exact built-in types is essential.

Practice this question →

136

Multi-Selectmedium

Which TWO actions can help prevent a container from being compromised if an attacker gains access? (Select 2)

Select 2 answers

A.Setting securityContext.readOnlyRootFilesystem: true

B.Setting automountServiceAccountToken: true

C.Setting securityContext.capabilities.drop: ["ALL"]

D.Setting securityContext.allowPrivilegeEscalation: true

E.Setting securityContext.runAsUser: 0

AnswersA, C

Setting readOnlyRootFilesystem to true mounts the container's root filesystem as read-only, so even a compromised process cannot modify binaries, libraries, or write new files to the container layer. Any legitimate writes must go to explicitly mounted writable volumes, which sharply limits the blast radius of an attack. This is a strong defense-in-depth control that complements other securityContext settings.

Why this answer

Setting `securityContext.readOnlyRootFilesystem: true` makes the container's root filesystem read-only, preventing an attacker who gains access from modifying system binaries, libraries, or configuration files. This is a key defense-in-depth measure that limits the impact of a compromise by restricting write access to only explicitly mounted volumes.

Exam trap

CNCF often tests the misconception that running as a non-root user (e.g., `runAsUser: 1000`) is sufficient, but the trap here is that `runAsUser: 0` explicitly sets root, which is a common mistake when candidates confuse 'default' with 'secure'—always drop all capabilities and make the filesystem read-only for defense in depth.

Practice this question →

137

Multi-Selecthard

Which THREE of the following are characteristics of Pod Security Admission (PSA) standards? (Select three.)

Select 3 answers

A.PSA can be configured to warn or audit violations without blocking

B.There are three predefined security levels: privileged, baseline, restricted

C.PSA requires Open Policy Agent (OPA) Gatekeeper to function

D.A namespace can be labeled to enforce a security level for all pods in that namespace

E.PSA is a CustomResourceDefinition (CRD) that must be installed separately

AnswersA, B, D

The Pod Security Admission controller supports three operational modes: enforce, warn, and audit. Enforce rejects violating pods at creation time, while warn and audit only record warnings or log audit events without blocking the pod. This allows cluster operators to test policies incrementally before enabling strict enforcement.

Why this answer

Pod Security Admission (PSA) supports three modes: enforce (blocks violations), audit (logs violations in audit logs), and warn (returns a warning to the user). This allows administrators to test or monitor PSA policies without immediately blocking pod creation, which is critical for gradual adoption.

Exam trap

The trap here is that candidates confuse PSA with third-party tools like OPA Gatekeeper or think it requires a CRD, when in fact PSA is a built-in, label-driven admission controller that works out of the box in Kubernetes v1.23+.

Practice this question →

138

MCQmedium

A Role named 'pod-reader' in namespace 'ns1' grants get, list, and watch on pods. Which RoleBinding correctly binds this role to a ServiceAccount 'sa1' in the same namespace?

A.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

B.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: User name: sa1

C.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

D.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: default

AnswerA

This is correct because a RoleBinding in ns1 uses roleRef to bind the namespaced Role 'pod-reader' to ServiceAccount 'sa1' also in ns1. RoleBindings are namespaced, and both the Role and the ServiceAccount must reside in the same namespace as the binding for the permissions to apply. Here the subject kind is ServiceAccount, which matches the intended identity, so sa1 will receive the Role's permissions.

Why this answer

A RoleBinding in the same namespace as the Role and ServiceAccount must specify the Role's kind as 'Role' (not ClusterRole) and include the ServiceAccount's namespace in the subjects list. The roleRef references the 'pod-reader' Role with the correct apiGroup and kind, and the subject specifies the ServiceAccount 'sa1' in namespace 'ns1', which matches the Role's namespace, allowing the binding to grant the permissions.

Exam trap

The trap here is that candidates often forget to include the ServiceAccount's namespace in the subjects list or mistakenly use 'kind: User' for a ServiceAccount, leading to a binding that either fails or applies to the wrong entity.

How to eliminate wrong answers

Option B is wrong because it uses 'kind: User' instead of 'kind: ServiceAccount', and a ServiceAccount cannot be bound via a User subject; the subject must match the actual entity type. Option C is wrong because it uses 'kind: ClusterRole' in the roleRef, but the question specifies a Role (namespaced), not a ClusterRole; a RoleBinding can only reference a Role in the same namespace or a ClusterRole (which would then be scoped to the namespace), but here the role is a Role, so the kind must be 'Role'. Option D is wrong because it specifies 'namespace: default' in the subject, but the ServiceAccount 'sa1' is in namespace 'ns1', so the subject's namespace must match the ServiceAccount's actual namespace for the binding to work.

Practice this question →

139

MCQmedium

A cluster administrator wants to prevent all pods in a namespace from running with privileged escalation. Which Pod Security Admission standard enforces this?

A.baseline

B.restricted

C.privileged

D.high

AnswerB

The restricted Pod Security Standard is the only built-in profile that explicitly mandates `allowPrivilegeEscalation: false` for all containers, effectively closing the door on any capability-based privilege escalation. It also requires a seccomp profile of RuntimeDefault, dropping all capabilities, and running as a non-root user, which collectively harden the container against breakout. By labeling the namespace with `pod-security.kubernetes.io/enforce=restricted`, the Pod Security Admission controller rejects any pod that violates these constraints, ensuring every pod in the namespace meets this strict baseline.

Why this answer

The 'restricted' Pod Security Admission (PSA) standard enforces the most stringent security controls, including preventing privileged escalation by setting `securityContext.AllowPrivilegeEscalation` to `false` and requiring containers to run as non-root. This directly addresses the cluster administrator's goal of blocking privilege escalation in all pods within a namespace.

Exam trap

CNCF often tests the distinction between 'baseline' and 'restricted' standards, where candidates mistakenly choose 'baseline' because it blocks some privilege escalation but fails to recognize that 'restricted' is the only standard that explicitly and comprehensively prohibits `AllowPrivilegeEscalation`.

How to eliminate wrong answers

Option A is wrong because the 'baseline' standard only prevents known privilege escalation attacks (e.g., via `CAP_SYS_ADMIN`) but does not explicitly require `AllowPrivilegeEscalation` to be `false`; it allows some flexibility for legacy workloads. Option C is wrong because the 'privileged' standard is the most permissive, allowing unrestricted access including privilege escalation, which is the opposite of what the question asks. Option D is wrong because 'high' is not a valid Pod Security Admission standard; the three defined standards are 'privileged', 'baseline', and 'restricted'.

Practice this question →

140

MCQmedium

You create a ResourceQuota in a namespace that sets requests.cpu: '1' and limits.cpu: '2'. A pod spec has no resource limits or requests. What happens when you try to create this pod?

A.The pod is created without limits, but the quota is enforced at runtime

B.The pod creation is denied because the spec does not specify resource limits or requests

C.The pod is created and the quota is ignored

D.The pod is created with default limits from the LimitRange

AnswerB

When a ResourceQuota is active in a namespace, it imposes an admission-time validation that every pod in that namespace must specify resource requests (and limits if the quota includes limits). Because the pod spec in this scenario omits both resource limits and requests, the admission controller denies creation—there is nothing to count against the quota, so the request fails.

Why this answer

When a ResourceQuota is defined with requests.cpu and limits.cpu, Kubernetes requires that every pod in that namespace have explicit resource requests and limits that match the quota constraints. If a pod spec omits these fields, the API server denies the pod creation because it cannot determine whether the pod complies with the quota. This is enforced at admission time, not at runtime.

Exam trap

The trap here is that candidates assume a LimitRange will automatically apply default resource values, but without a LimitRange, the pod creation is denied outright due to the missing fields required by the ResourceQuota.

How to eliminate wrong answers

Option A is wrong because the quota is enforced at admission time, not at runtime; the pod is never created if it lacks required resource specifications. Option C is wrong because the quota is never ignored; it is a hard constraint that the API server enforces during admission. Option D is wrong because a LimitRange can provide default values, but the question does not mention a LimitRange existing in the namespace; without one, the pod creation is denied due to missing resource fields.

Practice this question →

141

MCQmedium

A pod in the 'staging' namespace is in a CrashLoopBackOff state. You run 'kubectl logs pod -n staging' and see: 'Error: container has been OOMKilled'. The pod YAML has resources: requests: memory: 256Mi, limits: memory: 256Mi. Which change should you make first?

A.Increase the memory limit to 512Mi.

B.Increase the CPU limit to 1.

C.Reduce the memory request to 128Mi.

D.Set memory request to 512Mi and memory limit to 256Mi.

AnswerA

Raising the memory limit from 256Mi to 512Mi directly addresses the container's memory usage ceiling. OOMKilled occurs when the container's memory footprint exceeds its cgroup memory limit, causing the kernel's OOM killer to terminate the process. Since the container is already crashing at the current 256Mi limit, increasing it to 512Mi provides the necessary headroom for the workload to operate without being killed.

Why this answer

The pod is in CrashLoopBackOff due to OOMKill, meaning the container exceeded its memory limit and was terminated. Since the current memory limit is 256Mi and the container needs more, increasing the limit to 512Mi directly addresses the out-of-memory condition. This is the correct first step because it provides the container with the additional memory it requires to run without being killed.

Exam trap

CNCF often tests the distinction between requests and limits, and the trap here is that candidates might confuse reducing the request (option C) as a solution, when in fact the OOMKill is caused by hitting the limit, not the request.

How to eliminate wrong answers

Option B is wrong because the issue is memory exhaustion (OOMKill), not CPU; increasing the CPU limit does not resolve the out-of-memory condition. Option C is wrong because reducing the memory request to 128Mi would lower the guaranteed memory, potentially worsening the OOM situation and increasing the risk of the container being killed. Option D is wrong because setting the memory request higher than the limit (512Mi request vs 256Mi limit) is invalid in Kubernetes; the request must be less than or equal to the limit, and this configuration would be rejected by the API server.

Practice this question →

142

MCQmedium

Which command creates a TLS secret named 'tls-secret' using certificate file 'tls.crt' and key file 'tls.key'?

A.kubectl create secret docker-registry tls-secret --docker-server=...

B.kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key

C.kubectl create secret generic tls-secret --from-file=tls.crt --from-file=tls.key

D.kubectl create secret generic tls-secret --from-literal=tls.crt=...

AnswerB

This is the correct command because `kubectl create secret tls` creates a secret with the type `kubernetes.io/tls`. The `--cert` and `--key` flags read the PEM-encoded `tls.crt` and `tls.key` files respectively, and the resulting secret stores them under the exact data keys `tls.crt` and `tls.key` that Kubernetes components like the Ingress controller and kubelet expect when loading TLS certificates. This type also validates that the provided key and certificate are present and correctly named at creation time, ensuring the secret is immediately usable.

Why this answer

The `kubectl create secret tls` command is specifically designed to create a TLS secret from a certificate and key pair. The `--cert` and `--key` flags directly reference the PEM-encoded certificate file (`tls.crt`) and private key file (`tls.key`), which Kubernetes stores as `tls.crt` and `tls.key` data entries in the Secret object.

Exam trap

The trap here is that candidates often choose Option C because they think `--from-file` can create a TLS secret, but they overlook that the secret type must be `kubernetes.io/tls` and the data keys must be exactly `tls.crt` and `tls.key` — a generic secret with arbitrary keys will not work for TLS termination.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret docker-registry` creates a Docker registry authentication secret, not a TLS secret; it uses `--docker-server`, `--docker-username`, etc. Option C is wrong because `kubectl create secret generic` with `--from-file` stores the entire file contents under arbitrary keys (e.g., the filename), not under the standard `tls.crt` and `tls.key` keys required for TLS secrets; the resulting secret would not be recognized as a TLS secret by ingress controllers or other components. Option D is wrong because `--from-literal` expects a literal key=value pair, not a file path; it would store the string 'tls.crt=...' as a literal, not the certificate content.

Practice this question →

143

MCQeasy

You create a ConfigMap named 'app-config' with the command 'kubectl create configmap app-config --from-literal=key1=value1'. Which of the following correctly mounts this ConfigMap as environment variables in a pod?

A.env: - name: key1 valueFrom: configMapKeyRef: name: app-config key: key1

B.volumes: - name: config-volume configMap: name: app-config volumeMounts: - name: config-volume mountPath: /etc/config

C.env: - name: key1 valueFrom: configMapRef: name: app-config

D.envFrom: - configMapRef: name: app-config

AnswerD

This is the correct approach: the envFrom field accepts a list of configMapRefs, and when a ConfigMap is referenced this way, all of its key-value pairs are automatically exposed as environment variables in the container. The key becomes the environment variable name and the value becomes its value, so no per-key declarations are needed. This exactly fulfills the requirement to mount the entire ConfigMap as environment variables, and it is the canonical pattern in Kubernetes for such bulk injection.

Why this answer

`envFrom` with `configMapRef` is the Kubernetes mechanism to expose all key-value pairs from a ConfigMap as environment variables in a pod. This directly mounts the ConfigMap created with `--from-literal=key1=value1` so that `key1` becomes an environment variable with value `value1`.

Exam trap

The trap here is that candidates confuse `envFrom` with `env` and `configMapRef` with `configMapKeyRef`, or they incorrectly think volume mounts are equivalent to environment variable injection.

How to eliminate wrong answers

Option A is wrong because while the syntax is valid for a single key reference, it requires explicitly listing each key, which is not the 'correctly mounts this ConfigMap' approach when the question implies using the entire ConfigMap; it is a valid but incomplete method for the scenario. Option B is wrong because it describes mounting the ConfigMap as files in a volume at `/etc/config`, not as environment variables. Option C is wrong because `configMapRef` is not a valid field under `env`; the correct field is `configMapKeyRef`.

Practice this question →

144

MCQmedium

A Deployment is configured with 'resources.requests.memory: 256Mi' and 'resources.limits.memory: 512Mi'. The node runs out of memory. Which pods will be the first to be evicted?

A.The node will not evict pods if limits are set

B.This pod will be evicted first because it has a memory limit

C.BestEffort pods first, then this Burstable pod, then Guaranteed pods last

D.All pods are evicted simultaneously

AnswerC

Under node memory pressure, the kubelet selects eviction victims by QoS class: it first targets BestEffort pods (no requests/limits), then Burstable pods (requests set, limits may differ), and finally Guaranteed pods (requests equal limits). Because this deployment sets only a memory request, it is Burstable, so it will be evicted after every BestEffort pod on the node has been reclaimed and before any Guaranteed pod is touched. This ordering is a core part of the Kubernetes eviction mechanism and helps protect the most critical workloads during resource shortages.

Why this answer

C is correct because Kubernetes evicts pods based on their Quality of Service (QoS) class when a node runs out of memory. BestEffort pods (no requests/limits) are evicted first, followed by Burstable pods (requests < limits, as in this case), and Guaranteed pods (requests == limits) are evicted last. This ensures that pods with stricter resource guarantees are more protected during memory pressure.

Exam trap

CNCF often tests the misconception that setting a memory limit alone protects a pod from eviction, but the key factor is the QoS class derived from the relationship between requests and limits, not just the presence of limits.

How to eliminate wrong answers

Option A is wrong because the node will evict pods when memory is exhausted, regardless of whether limits are set; the kubelet uses the QoS class to determine eviction order. Option B is wrong because this Burstable pod will not be evicted first; BestEffort pods (with no resource specifications) are evicted before any Burstable pod. Option D is wrong because eviction is not simultaneous; pods are evicted in a specific order based on their QoS class, starting with BestEffort, then Burstable, and finally Guaranteed.

Practice this question →

145

MCQhard

Which of the following is a valid YAML snippet for a container that sets the seccomp profile to 'RuntimeDefault' in a PodSecurityContext?

A.securityContext: seccompProfile: type: RuntimeDefault

B.securityContext: seccompProfile: profile: RuntimeDefault

C.securityContext: seccomp: RuntimeDefault

D.securityContext: seccomp: type: RuntimeDefault

AnswerA

Correct. In the Pod/container securityContext, seccompProfile is a structured object that selects the seccomp profile applied to the container. Its only required and valid field for this purpose is 'type', and setting type: RuntimeDefault instructs the container runtime (e.g., containerd/Docker) to use the runtime's default seccomp profile, which blocks a defined set of dangerous syscalls while allowing normal operation. This is the correct syntax and is fully supported in Kubernetes v1.19+ when the seccompProfile field is used in the API.

Why this answer

In a PodSecurityContext, the seccomp profile is configured under the `seccompProfile` field with a `type` key set to `RuntimeDefault`. This tells the container runtime (e.g., containerd) to use the default seccomp profile provided by the runtime, which blocks a set of syscalls that are not typically needed by containers.

Exam trap

The trap here is that candidates confuse the `type` key (which specifies the profile type, e.g., RuntimeDefault, Localhost, Unconfined) with a `profile` key, or they flatten the YAML structure by omitting the `seccompProfile` nesting, leading to invalid configuration.

How to eliminate wrong answers

Option B is wrong because it uses `profile: RuntimeDefault` instead of `type: RuntimeDefault`; the correct key under `seccompProfile` is `type`, not `profile`. Option C is wrong because it uses `seccomp: RuntimeDefault` as a flat key-value pair, but the seccomp configuration must be nested under `seccompProfile` with a `type` field. Option D is wrong because it uses `seccomp: type: RuntimeDefault` as a flat key-value pair, which is invalid YAML structure; the correct nesting requires `seccompProfile` as an intermediate key.

Practice this question →

146

MCQmedium

A pod has 'automountServiceAccountToken: false' in its spec. What is the effect?

A.The pod uses the default service account token from the namespace

B.The service account token is mounted but not updated

C.The pod cannot communicate with the Kubernetes API

D.The service account token is not mounted into the pod

AnswerD

Setting automountServiceAccountToken to false in the pod spec tells the kubelet not to project the namespace's default service account token into the pod. As a result, no token appears under /var/run/secrets/kubernetes.io/serviceaccount, and the pod has no automatic bearer credentials for API requests. This is a deliberate security hardening measure for workloads that do not require Kubernetes API access, limiting the blast radius if the pod is compromised.

Why this answer

Setting `automountServiceAccountToken: false` in a Pod spec explicitly prevents the automatic mounting of the service account token into the Pod's containers. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token` for API authentication; disabling it means the token is not present in the container filesystem, so the Pod cannot authenticate to the Kubernetes API using that default mechanism.

Exam trap

The trap here is that candidates often confuse `automountServiceAccountToken: false` with disabling API access entirely, but it only disables the automatic token mount—the pod can still use other authentication methods to reach the API.

How to eliminate wrong answers

Option A is wrong because `automountServiceAccountToken: false` does not cause the pod to use the default service account token; it prevents any token from being mounted. Option B is wrong because the token is not mounted at all, so there is no token to be updated or not updated. Option C is wrong because while the pod cannot use the default mounted token for API communication, it can still communicate with the Kubernetes API if it uses an alternative authentication method (e.g., a custom token injected via a volume or a client certificate).

Practice this question →

147

MCQeasy

A developer needs to expose a database password to a Pod as an environment variable, securely. What should they do?

A.Hardcode the password in the Pod YAML

B.Store the password in a ConfigMap and use configMapKeyRef

C.Create a Secret and use secretKeyRef in the env definition

D.Use a ConfigMap with binaryData field

AnswerC

Creating a Secret and injecting it with secretKeyRef is the correct pattern for exposing a database password to a pod. Secrets are a dedicated API object for sensitive data; while they are only base64-encoded by default, you can enable encryption at rest for Secret objects in etcd, and they have granular RBAC controls to limit access. The secretKeyRef field in the env definition tells Kubernetes to read a specific key from a specified Secret and expose it as an environment variable, keeping the plaintext value out of the Pod YAML. This also makes rotation and secret lifecycle management much easier than hardcoding.

Why this answer

Kubernetes Secrets are the recommended mechanism for storing sensitive data like passwords. By referencing the Secret's key via `secretKeyRef` in the `env` definition of a Pod, the password is injected as an environment variable without being exposed in the Pod manifest or stored in plaintext. This approach ensures the data is base64-encoded at rest (and can be encrypted at rest with etcd encryption) and avoids the security risks of hardcoding or using ConfigMaps for secrets.

Exam trap

The trap here is that candidates confuse ConfigMaps with Secrets, thinking that `binaryData` or `configMapKeyRef` can securely store sensitive data, when in fact ConfigMaps lack encryption and access control mechanisms that Secrets provide.

How to eliminate wrong answers

Option A is wrong because hardcoding the password in the Pod YAML exposes the credential in plaintext in version control and manifests, violating security best practices. Option B is wrong because ConfigMaps are designed for non-sensitive configuration data; storing a password in a ConfigMap leaves it unencrypted and accessible to anyone with cluster access, and `configMapKeyRef` does not provide the security guarantees needed for secrets. Option D is wrong because while `binaryData` in a ConfigMap can store binary data, it still does not provide encryption or access control; ConfigMaps are not intended for secrets, and using `binaryData` does not make the data secure.

Practice this question →

148

Drag & Dropmedium

Arrange the steps to create a ConfigMap from a file and mount it as a volume in a Pod.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Create ConfigMap first, then define Pod with volume and volumeMount, apply, and verify.

Practice this question →

149

Multi-Selecthard

Which THREE statements about ResourceQuota are correct? (Select 3)

Select 3 answers

A.ResourceQuota can specify both requests and limits for compute resources

B.ResourceQuota can limit the maximum CPU limit for a single pod

C.ResourceQuota can limit the total number of ConfigMaps in a namespace

D.ResourceQuota applies to all pods in a namespace

E.ResourceQuota applies across all namespaces

AnswersA, C, D

ResourceQuota definitions support separate hard limits for compute requests and limits, such as requests.cpu, requests.memory, limits.cpu, and limits.memory. These aggregate values are enforced across all pods in the namespace, so the total requested or limited resources cannot exceed the configured caps. This granularity lets administrators distinguish between guaranteed reservation and maximum usage.

Why this answer

A ResourceQuota can specify both `requests` and `limits` for compute resources such as CPU and memory. This allows the quota to enforce constraints on the minimum requested resources and the maximum allowed usage across all pods in a namespace, ensuring fair resource distribution and preventing resource exhaustion.

Exam trap

The trap here is that candidates often confuse ResourceQuota's aggregate namespace-level enforcement with per-pod limits, which are actually handled by LimitRange, not ResourceQuota.

Practice this question →

150

MCQmedium

A user wants to create a Kubernetes Secret for storing Docker registry credentials (username and password). Which type of Secret should they use?

A.kubernetes.io/tls

B.Opaque

C.kubernetes.io/dockerconfigjson

D.kubernetes.io/basic-auth

AnswerC

kubernetes.io/dockerconfigjson is the canonical secret type for Docker registry authentication, storing the entire Docker config file (typically generated by `docker login`) in a data field named `.dockerconfigjson`. This file contains `auths` entries with base64-encoded `username:password` tokens for each registry. When this secret is attached to a Pod via `imagePullSecrets`, the kubelet decodes it and uses the embedded credentials to pull private images exactly as Docker does.

Why this answer

`kubernetes.io/dockerconfigjson` is the dedicated Secret type for storing Docker registry credentials in the format expected by `docker login`. It automatically encodes the username and password into a `.dockerconfigjson` field, which is used by Kubernetes to pull images from private registries. This type is required when referencing a `imagePullSecret` in a Pod spec.

Exam trap

The trap here is that candidates often choose `Opaque` (Option B) because they think any secret can be used for Docker credentials, but the CKAD exam expects you to know that only `kubernetes.io/dockerconfigjson` provides the correct format and automatic integration with image pull secrets.

How to eliminate wrong answers

Option A is wrong because `kubernetes.io/tls` is used for TLS certificates and private keys, not for Docker registry credentials. Option B is wrong because `Opaque` is a generic secret type for arbitrary key-value pairs, but it does not provide the correct structure or automatic handling required by the container runtime for registry authentication. Option D is wrong because `kubernetes.io/basic-auth` is intended for HTTP basic authentication credentials (username/password for web services), not for Docker registry login data.

Practice this question →