Sample questions
Certified Kubernetes Application Developer CKAD practice questions
Match each Kubernetes concept to its definition.
Drag a concept onto its matching description — or click a concept then click the description.
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
Arrange the steps to create a multi-container Pod with a shared volume.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
A pod has been scheduled on a node but is stuck in 'ContainerCreating' state. The team suspects a missing storage class. Which command would best confirm this?
Trap 1: kubectl describe node
Shows node conditions, not pod storage errors.
Trap 2: kubectl get pvc
Shows PVC status, but not binding to pod.
Trap 3: kubectl get storageclass
Lists storage classes, but not pod issue.
- A
kubectl describe node
Why wrong: Shows node conditions, not pod storage errors.
- B
kubectl get pvc
Why wrong: Shows PVC status, but not binding to pod.
- C
kubectl get storageclass
Why wrong: Lists storage classes, but not pod issue.
- D
kubectl describe pod <pod>
Shows events like 'FailedMount' indicating missing storage class.
A developer is creating a Deployment with 4 replicas. The application requires a rolling update with zero downtime. Which TWO strategies ensure zero downtime during an update?
Trap 1: Set maxUnavailable=1
Allows one pod to be unavailable, possibly causing capacity drop.
Trap 2: Use Recreate strategy
Recreate terminates all pods before creating new ones.
Trap 3: Set maxSurge=0
No extra pods allowed; may cause downtime if maxUnavailable>0.
- A
Set maxSurge=1
Allows one extra pod to be created first.
- B
Set maxUnavailable=1
Why wrong: Allows one pod to be unavailable, possibly causing capacity drop.
- C
Use Recreate strategy
Why wrong: Recreate terminates all pods before creating new ones.
- D
Set maxUnavailable=0
Ensures no pods are unavailable during update.
- E
Set maxSurge=0
Why wrong: No extra pods allowed; may cause downtime if maxUnavailable>0.
A developer creates a Deployment with 3 replicas that uses a ConfigMap mounted as a volume. After updating the ConfigMap, the developer expects the pods to pick up the new configuration immediately, but the old configuration is still in use. What is the most likely reason?
Trap 1: ConfigMap updates are not propagated to mounted volumes.
Updates are propagated, but not instantly.
Trap 2: The pods must be recreated after a ConfigMap update to see the…
Mounted ConfigMaps are updated without pod restart, but with a delay.
Trap 3: ConfigMaps are immutable and cannot be updated.
ConfigMaps can be updated; immutability is optional.
- A
ConfigMap updates are not propagated to mounted volumes.
Why wrong: Updates are propagated, but not instantly.
- B
The kubelet sync interval delays the propagation of ConfigMap changes to pods.
The kubelet periodically syncs ConfigMap data; changes may take up to the sync period to appear.
- C
The pods must be recreated after a ConfigMap update to see the changes.
Why wrong: Mounted ConfigMaps are updated without pod restart, but with a delay.
- D
ConfigMaps are immutable and cannot be updated.
Why wrong: ConfigMaps can be updated; immutability is optional.
Which TWO statements about Kustomize are true?
Trap 1: Kustomize can be used to perform canary deployments.
Kustomize does not have native canary deployment support; it is for configuration management.
Trap 2: Kustomize requires Helm to manage dependencies.
Kustomize is standalone and does not require Helm.
Trap 3: Kustomize can only be used with kubectl apply -k.
It can also be used standalone with kustomize build.
- A
Kustomize can be used to perform canary deployments.
Why wrong: Kustomize does not have native canary deployment support; it is for configuration management.
- B
Kustomize supports overlays that allow different configurations for different environments.
Correct. Overlays modify base configurations for different contexts.
- C
Kustomize requires Helm to manage dependencies.
Why wrong: Kustomize is standalone and does not require Helm.
- D
Kustomize uses a file named kustomization.yaml to define resources and customizations.
Correct. kustomization.yaml is the central file.
- E
Kustomize can only be used with kubectl apply -k.
Why wrong: It can also be used standalone with kustomize build.
A developer creates a Secret using the command: 'kubectl create secret generic db-secret --from-literal=password=myPass'. Which way to consume this Secret in a pod is CORRECT?
Trap 1: volumes: - name: secret-vol secret: secretName:…
This mounts the Secret as files, not environment variables.
Trap 2: envFrom: - secretRef: name: db-secret
This would expose all keys as environment variables, but the key name would be 'password', not 'DB_PASSWORD'. It does not allow renaming.
Trap 3: env: - name: DB_PASSWORD valueFrom: configMapKeyRef:…
configMapKeyRef is for ConfigMaps, not Secrets. Use secretKeyRef.
- A
env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password
This correctly references the secret key 'password' from the Secret named 'db-secret'.
- B
volumes: - name: secret-vol secret: secretName: db-secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret
Why wrong: This mounts the Secret as files, not environment variables.
- C
envFrom: - secretRef: name: db-secret
Why wrong: This would expose all keys as environment variables, but the key name would be 'password', not 'DB_PASSWORD'. It does not allow renaming.
- D
env: - name: DB_PASSWORD valueFrom: configMapKeyRef: name: db-secret key: password
Why wrong: configMapKeyRef is for ConfigMaps, not Secrets. Use secretKeyRef.
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?
Trap 1: The pod is created because the request (2) is within the quota
The quota checks both requests and limits. The limit exceeds the allowed total limit.
Trap 2: The pod is created but its limit is automatically reduced to 8
Kubernetes does not automatically adjust resource limits; it rejects the creation.
Trap 3: The pod is created, but it will be evicted immediately
The API server rejects the pod during admission; it never runs.
- A
The pod is rejected because the limit (10) exceeds the quota's allowed limit
A ResourceQuota enforces that the sum of limits across all pods in the namespace does not exceed 8.
- B
The pod is created because the request (2) is within the quota
Why wrong: The quota checks both requests and limits. The limit exceeds the allowed total limit.
- C
The pod is created but its limit is automatically reduced to 8
Why wrong: Kubernetes does not automatically adjust resource limits; it rejects the creation.
- D
The pod is created, but it will be evicted immediately
Why wrong: The API server rejects the pod during admission; it never runs.
A pod uses a ServiceAccount with automountServiceAccountToken set to false. The pod still needs to access the Kubernetes API. How can you mount the service account token in this pod?
Trap 1: Create a secret with the token and mount it manually
While possible, it's not the standard way; the token is automatically mounted via the service account.
Trap 2: Use a ConfigMap to store the token
ConfigMaps should not store secrets; tokens are secrets.
Trap 3: Set serviceAccountName: default and automountServiceAccountToken:…
The default ServiceAccount also has automount disabled, but the pod spec can override it.
- A
Set automountServiceAccountToken: true in the pod spec
This overrides the ServiceAccount's setting and mounts the token.
- B
Create a secret with the token and mount it manually
Why wrong: While possible, it's not the standard way; the token is automatically mounted via the service account.
- C
Use a ConfigMap to store the token
Why wrong: ConfigMaps should not store secrets; tokens are secrets.
- D
Set serviceAccountName: default and automountServiceAccountToken: true in the pod spec
Why wrong: The default ServiceAccount also has automount disabled, but the pod spec can override it.
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?
Trap 1: env: - name: key1 valueFrom: configMapKeyRef:…
This only sets one environment variable from the ConfigMap, but the requirement is to mount all keys. Also, the task asks for mounting as environment variables, which 'envFrom' does.
Trap 2: volumes: - name: config-volume configMap: name:…
This mounts the ConfigMap as files in a volume, not as environment variables.
Trap 3: env: - name: key1 valueFrom: configMapRef:…
The configMapRef under 'valueFrom' is invalid; it should be configMapKeyRef and requires a specific key.
- A
env: - name: key1 valueFrom: configMapKeyRef: name: app-config key: key1
Why wrong: This only sets one environment variable from the ConfigMap, but the requirement is to mount all keys. Also, the task asks for mounting as environment variables, which 'envFrom' does.
- B
volumes: - name: config-volume configMap: name: app-config volumeMounts: - name: config-volume mountPath: /etc/config
Why wrong: This mounts the ConfigMap as files in a volume, not as environment variables.
- C
env: - name: key1 valueFrom: configMapRef: name: app-config
Why wrong: The configMapRef under 'valueFrom' is invalid; it should be configMapKeyRef and requires a specific key.
- D
envFrom: - configMapRef: name: app-config
envFrom with configMapRef injects all key-value pairs from the ConfigMap as environment variables.
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.)
Trap 1: Using envFrom to inject ConfigMap data as environment variables…
Environment variables are set at container startup and do not update.
Trap 2: ConfigMap updates are reflected immediately in the volume mount.
The sync is periodic (usually ~60 seconds), not instantaneous.
Trap 3: The Pod must be restarted for any ConfigMap change to take effect.
Volume mounts (without subPath) update automatically without restart.
- A
Using envFrom to inject ConfigMap data as environment variables will update automatically.
Why wrong: Environment variables are set at container startup and do not update.
- B
ConfigMap updates are reflected immediately in the volume mount.
Why wrong: The sync is periodic (usually ~60 seconds), not instantaneous.
- C
Using subPath in the volume mount prevents automatic updates.
subPath mounts a single file; updates require pod restart.
- D
The Pod must be restarted for any ConfigMap change to take effect.
Why wrong: Volume mounts (without subPath) update automatically without restart.
- E
Mounting the ConfigMap as a volume (without subPath) ensures that file updates are reflected automatically through symlinks.
The kubelet syncs the volume periodically, and the mount uses symlinks to update files.
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?
Trap 1: env: - name: SECRET_DATA valueFrom: configMapKeyRef:…
This uses configMapKeyRef, but the resource is a Secret, not a ConfigMap.
Trap 2: env: - name: SECRET_DATA valueFrom: secretKeyRef: name:…
The name field should reference the secret name, not the key. The key field specifies the key within the secret.
Trap 3: volumeMounts: - name: secret-volume mountPath:…
This mounts the secret as a file, not as an environment variable.
- A
env: - name: SECRET_DATA valueFrom: configMapKeyRef: name: mysecret key: password
Why wrong: This uses configMapKeyRef, but the resource is a Secret, not a ConfigMap.
- B
env: - name: SECRET_DATA valueFrom: secretKeyRef: name: mysecret key: password
Correct. secretKeyRef uses name for the secret and key for the key within the secret.
- C
env: - name: SECRET_DATA valueFrom: secretKeyRef: name: password key: mysecret
Why wrong: The name field should reference the secret name, not the key. The key field specifies the key within the secret.
- D
volumeMounts: - name: secret-volume mountPath: /etc/secret volumes: - name: secret-volume secret: secretName: mysecret items: - key: password path: secret.txt
Why wrong: This mounts the secret as a file, not as an environment variable.
Which THREE of the following are benefits of using a ResourceQuota in a namespace? (Select THREE)
Trap 1: It sets default resource requests and limits for Pods that don't…
LimitRange sets defaults, not ResourceQuota.
Trap 2: It restricts which users can create Pods in the namespace
Access control is done via RBAC, not ResourceQuota.
- A
It sets default resource requests and limits for Pods that don't specify them
Why wrong: LimitRange sets defaults, not ResourceQuota.
- B
It can enforce that every Pod has resource limits set
ResourceQuota can require that all Pods have limits set by specifying 'limits.cpu' and 'limits.memory' in the quota.
- C
It restricts which users can create Pods in the namespace
Why wrong: Access control is done via RBAC, not ResourceQuota.
- D
It prevents a single namespace from exhausting cluster resources
By limiting total resources, it ensures fair sharing among namespaces.
- E
It limits the total amount of CPU and memory that can be consumed by all Pods in the namespace
ResourceQuota sets hard limits on aggregate resource consumption.
Which of the following is the correct way to set a CPU request of 250 millicores and a memory limit of 512 Mi in a container?
Trap 1: resources: requests: cpu: 250 limits: memory: 512M
'250' without 'm' is interpreted as 250 cores, not 250 millicores. '512M' is not standard.
Trap 2: resources: requests: cpu: 250 limits: memory: 512MB
'250' without 'm' is 250 cores. '512MB' is not standard.
Trap 3: resources: requests: cpu: 0.25 limits: memory: 512MB
While '0.25' is valid, '512MB' is not a standard Kubernetes resource suffix; use 'Mi' for mebibytes.
- A
resources: requests: cpu: 250 limits: memory: 512M
Why wrong: '250' without 'm' is interpreted as 250 cores, not 250 millicores. '512M' is not standard.
- B
resources: requests: cpu: 250 limits: memory: 512MB
Why wrong: '250' without 'm' is 250 cores. '512MB' is not standard.
- C
resources: requests: cpu: 0.25 limits: memory: 512MB
Why wrong: While '0.25' is valid, '512MB' is not a standard Kubernetes resource suffix; use 'Mi' for mebibytes.
- D
resources: requests: cpu: 250m limits: memory: 512Mi
Correct. '250m' means 250 millicores, and '512Mi' means 512 mebibytes.
A security requirement states that a container must run with a read-only root filesystem. Which field must be set in the container's securityContext?
Trap 1: runAsUser: 1000
This sets the user ID but does not affect filesystem write permissions.
Trap 2: capabilities: drop: ["ALL"]
This drops all capabilities but does not make the filesystem read-only.
Trap 3: allowPrivilegeEscalation: false
This prevents privilege escalation but does not make the filesystem read-only.
- A
runAsUser: 1000
Why wrong: This sets the user ID but does not affect filesystem write permissions.
- B
capabilities: drop: ["ALL"]
Why wrong: This drops all capabilities but does not make the filesystem read-only.
- C
allowPrivilegeEscalation: false
Why wrong: This prevents privilege escalation but does not make the filesystem read-only.
- D
readOnlyRootFilesystem: true
This makes the container's root filesystem read-only.
A pod must run with a seccomp profile that only allows specific syscalls. Which SecurityContext field is used to specify the seccomp profile type?
Trap 1: appArmorProfile
AppArmor is a separate LSM; seccomp is not configured via appArmorProfile.
Trap 2: seLinuxOptions
SELinux options are for SELinux, not seccomp.
Trap 3: seccomp
There is no seccomp field; the correct field is seccompProfile.
- A
appArmorProfile
Why wrong: AppArmor is a separate LSM; seccomp is not configured via appArmorProfile.
- B
seLinuxOptions
Why wrong: SELinux options are for SELinux, not seccomp.
- C
seccomp
Why wrong: There is no seccomp field; the correct field is seccompProfile.
- D
seccompProfile
The seccompProfile field in securityContext specifies the seccomp profile to use.
A developer wants to ensure that a pod runs with a non-root user and cannot gain root privileges. Which SecurityContext settings should be used?
Trap 1: securityContext: allowPrivilegeEscalation: false
This does not prevent running as root; it only prevents privilege escalation.
Trap 2: securityContext: runAsNonRoot: true
This prevents root but does not explicitly prevent privilege escalation.
Trap 3: securityContext: runAsNonRoot: true allowPrivilegeEscalation:…
allowPrivilegeEscalation: true defeats the purpose; it should be false.
- A
securityContext: allowPrivilegeEscalation: false
Why wrong: This does not prevent running as root; it only prevents privilege escalation.
- B
securityContext: runAsNonRoot: true
Why wrong: This prevents root but does not explicitly prevent privilege escalation.
- C
securityContext: runAsNonRoot: true allowPrivilegeEscalation: false
Correct. runAsNonRoot ensures non-root; allowPrivilegeEscalation: false prevents privilege escalation.
- D
securityContext: runAsNonRoot: true allowPrivilegeEscalation: true
Why wrong: allowPrivilegeEscalation: true defeats the purpose; it should be false.
A ConfigMap named 'env-config' has keys 'DB_HOST' and 'DB_PORT'. A pod needs to set the environment variable 'DATABASE_HOST' to the value of 'DB_HOST' from the ConfigMap, and 'DB_PORT' directly as 'DB_PORT'. Which YAML snippet correctly achieves this?
Trap 1: env: - name: DB_PORT valueFrom: configMapKeyRef: name:…
This sets DB_PORT individually, but then envFrom loads all keys including DB_PORT, which would overwrite? Actually, envFrom does not override env if the key already exists? The documentation says envFrom keys are not added if the key already exists in env. So DB_PORT would keep its value. But this does not set DATABASE_HOST.
Trap 2: envFrom: - configMapRef: name: env-config env: - name:…
The value of DATABASE_HOST would be the literal string 'DB_HOST', not the value from the ConfigMap.
Trap 3: envFrom: - configMapRef: name: env-config prefix: DATABASE_
This would prefix all keys, resulting in DATABASE_DB_HOST and DATABASE_DB_PORT, not DATABASE_HOST.
- A
env: - name: DB_PORT valueFrom: configMapKeyRef: name: env-config key: DB_PORT envFrom: - configMapRef: name: env-config
Why wrong: This sets DB_PORT individually, but then envFrom loads all keys including DB_PORT, which would overwrite? Actually, envFrom does not override env if the key already exists? The documentation says envFrom keys are not added if the key already exists in env. So DB_PORT would keep its value. But this does not set DATABASE_HOST.
- B
env: - name: DATABASE_HOST valueFrom: configMapKeyRef: name: env-config key: DB_HOST envFrom: - configMapRef: name: env-config
This sets DATABASE_HOST from the ConfigMap key DB_HOST, and then loads all keys (DB_HOST and DB_PORT) as env vars, but note that envFrom might overwrite DATABASE_HOST if the key DB_HOST is also loaded. Actually, the order: env is processed first, then envFrom. So DATABASE_HOST will be set, then envFrom will set DB_HOST as an env var, but since DATABASE_HOST is already set, it remains. However, there would be both DATABASE_HOST and DB_HOST env vars. That's acceptable.
- C
envFrom: - configMapRef: name: env-config env: - name: DATABASE_HOST value: DB_HOST
Why wrong: The value of DATABASE_HOST would be the literal string 'DB_HOST', not the value from the ConfigMap.
- D
envFrom: - configMapRef: name: env-config prefix: DATABASE_
Why wrong: This would prefix all keys, resulting in DATABASE_DB_HOST and DATABASE_DB_PORT, not DATABASE_HOST.
A pod has 'automountServiceAccountToken: false' in its spec. What is the effect?
Trap 1: The pod cannot use any service account.
The pod can still use a service account; it just doesn't automatically mount the token. The token can be mounted manually if needed.
Trap 2: The pod will use a different service account.
The service account is still the one specified (or default), but the token is not mounted.
Trap 3: The pod will be unable to start.
The pod will start normally; it just won't have the token.
- A
The pod cannot use any service account.
Why wrong: The pod can still use a service account; it just doesn't automatically mount the token. The token can be mounted manually if needed.
- B
The pod will use a different service account.
Why wrong: The service account is still the one specified (or default), but the token is not mounted.
- C
The pod will be unable to start.
Why wrong: The pod will start normally; it just won't have the token.
- D
The pod will not have the service account token mounted.
Correct. The automatic mounting of the token is disabled.
A pod with the following security context is in CrashLoopBackOff. The container image runs as user 1000.
securityContext: runAsUser: 2000 runAsGroup: 3000 fsGroup: 4000
What is the most likely cause?
Trap 1: runAsGroup is set to 3000, but the container expects group 1000
The primary issue is usually the user, not the group.
Trap 2: The pod does not have enough CPU resources
That would cause a different state like OOMKilled or Pending.
Trap 3: fsGroup is set to 4000, causing volume mount permission issues
fsGroup alone typically does not cause a crash loop unless the container tries to write to volumes.
- A
runAsUser is set to 2000, but the container expects to run as user 1000
This mismatch causes permission errors because the container's file permissions or processes require user 1000.
- B
runAsGroup is set to 3000, but the container expects group 1000
Why wrong: The primary issue is usually the user, not the group.
- C
The pod does not have enough CPU resources
Why wrong: That would cause a different state like OOMKilled or Pending.
- D
fsGroup is set to 4000, causing volume mount permission issues
Why wrong: fsGroup alone typically does not cause a crash loop unless the container tries to write to volumes.
A cluster administrator wants to prevent all pods in a namespace from running with privileged escalation. Which Pod Security Admission standard enforces this?
Trap 1: baseline
Baseline prevents known privilege escalations but allows some less restrictive settings.
Trap 2: privileged
This standard allows all privileges, including privilege escalation.
Trap 3: high
There is no 'high' standard in Pod Security Admission.
- A
baseline
Why wrong: Baseline prevents known privilege escalations but allows some less restrictive settings.
- B
restricted
The restricted profile disallows privilege escalation and enforces many security constraints.
- C
privileged
Why wrong: This standard allows all privileges, including privilege escalation.
- D
high
Why wrong: There is no 'high' standard in Pod Security Admission.
A pod has a container with 'readOnlyRootFilesystem: true' in its securityContext. The container writes to /tmp. What is the expected outcome?
Trap 1: The pod runs normally; Kubernetes automatically makes /tmp writable.
Kubernetes does not automatically make any directory writable. Only explicitly mounted volumes can be written to.
Trap 2: The pod is rejected by the admission controller because…
The admission controller does not check runtime behavior; it only validates the manifest.
Trap 3: The container writes successfully because readOnlyRootFilesystem…
readOnlyRootFilesystem applies to the entire root filesystem, including overlay filesystem layers.
- A
The pod runs normally; Kubernetes automatically makes /tmp writable.
Why wrong: Kubernetes does not automatically make any directory writable. Only explicitly mounted volumes can be written to.
- B
The container crashes because it tries to write to /tmp but the filesystem is read-only.
The application will fail when trying to write to /tmp because the root filesystem is read-only.
- C
The pod is rejected by the admission controller because readOnlyRootFilesystem conflicts with writing to /tmp.
Why wrong: The admission controller does not check runtime behavior; it only validates the manifest.
- D
The container writes successfully because readOnlyRootFilesystem only applies to the container image layers.
Why wrong: readOnlyRootFilesystem applies to the entire root filesystem, including overlay filesystem layers.
A developer needs to create a Kubernetes Secret for Docker registry authentication. The registry URL is 'myregistry.io', username 'user', password 'pass', email 'user@example.com'. Which command creates this Secret?
Trap 1: kubectl create secret tls regcred --cert=cert --key=key
This creates a TLS secret, not Docker registry credentials.
Trap 2: kubectl create secret generic regcred --from-literal=username=user…
This creates an Opaque Secret, not a dockerconfigjson type.
Trap 3: kubectl create secret registry regcred --server=myregistry.io…
There is no 'registry' type; the correct subcommand is 'docker-registry', and flags are --docker-*.
- A
kubectl create secret tls regcred --cert=cert --key=key
Why wrong: This creates a TLS secret, not Docker registry credentials.
- B
kubectl create secret generic regcred --from-literal=username=user --from-literal=password=pass
Why wrong: This creates an Opaque Secret, not a dockerconfigjson type.
- C
kubectl create secret registry regcred --server=myregistry.io --username=user --password=pass
Why wrong: There is no 'registry' type; the correct subcommand is 'docker-registry', and flags are --docker-*.
- D
kubectl create secret docker-registry regcred --docker-server=myregistry.io --docker-username=user --docker-password=pass --docker-email=user@example.com
This creates a kubernetes.io/dockerconfigjson Secret with the correct credentials.
A pod runs as user ID 1000. The container image includes a binary that expects to run as root. Which SecurityContext setting can allow the binary to run with root-like privileges while still running the container as non-root?
Trap 1: Add the SYS_ADMIN capability under securityContext.capabilities.add
Capabilities grant specific administrative privileges but do not change the user ID.
Trap 2: Set securityContext.privileged: true
This makes the container run as privileged, which includes running as root, but it is a broader and less secure approach; setting runAsUser:0 is more specific.
Trap 3: Set securityContext.allowPrivilegeEscalation: true
This allows processes to gain more privileges than their parent, but the container still runs as user 1000 unless runAsUser is changed.
- A
Add the SYS_ADMIN capability under securityContext.capabilities.add
Why wrong: Capabilities grant specific administrative privileges but do not change the user ID.
- B
Set securityContext.privileged: true
Why wrong: This makes the container run as privileged, which includes running as root, but it is a broader and less secure approach; setting runAsUser:0 is more specific.
- C
Set securityContext.runAsUser: 0
Setting runAsUser to 0 makes the container run as root, fulfilling the binary's requirement.
- D
Set securityContext.allowPrivilegeEscalation: true
Why wrong: This allows processes to gain more privileges than their parent, but the container still runs as user 1000 unless runAsUser is changed.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.