CKAD Practice Questions 2 — 50 Questions

Question 1

A developer wants to inject database credentials into a pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-creds' with keys 'username' and 'password'. Which pod spec snippet correctly injects both values as environment variables?

Accepted Answer

envFrom:
- secretRef:
    name: db-creds. Option C is correct because `envFrom` with `secretRef` injects all key-value pairs from a Secret as environment variables into the pod. This directly satisfies the requirement to inject both 'username' and 'password' from the 'db-creds' Secret without needing to specify each key individually.

Answer

env:
- name: username
  valueFrom:
    secretKeyRef:
      name: db-creds
      key: username

Answer

envFrom:
- configMapRef:
    name: db-creds

Answer

envFrom:
- secretKeyRef:
    name: db-creds

Question 2

Which TWO of the following are valid ways to consume a ConfigMap in a pod? (Select 2)

Accepted Answer

Mounting the ConfigMap as a volume. Option A is correct because a ConfigMap can be mounted as a volume in a Pod, allowing files or directories to be created from the ConfigMap's data. This is done by specifying a volume of type `configMap` in the Pod spec and mounting it into the container's filesystem, which makes the key-value pairs available as files.

Answer

Using configMapRef in env.valueFrom

Answer

Using secretKeyRef in env.valueFrom

Answer

Using envFrom with configMapRef

Question 3

You need to ensure that a pod in namespace 'dev' cannot consume more than 256Mi of memory. Which approach should you take?

Accepted Answer

Set 'resources.limits.memory: 256Mi' in the container spec. To limit a pod's memory usage, you set 'resources.limits.memory' in the container spec. Option A sets a limit on the container, which is the correct way. Option B uses a LimitRange, which sets default limits but does not enforce a hard limit on a specific pod if the pod does not specify limits. Option C uses a ResourceQuota which sets total limits for the namespace, not per-pod. Option D uses annotations which are not used for resource limits.

Answer

Add annotation 'memory-limit: 256Mi' to the pod

Answer

Create a ResourceQuota with 'limits.memory: 256Mi' in the namespace

Answer

Create a LimitRange with 'max: memory: 256Mi' in the namespace

Question 4

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

Accepted Answer

Mount the service account token manually by adding a volume and volumeMount. 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.

Answer

Create a new Secret of type kubernetes.io/dockerconfigjson

Answer

The application cannot access the API; the setting is final

Answer

Add a ConfigMap with the token

Question 5

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?

Accepted Answer

The namespace has already used all its CPU request quota.. 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.

Answer

The ResourceQuota applies to limits, not requests.

Answer

The pod does not specify a CPU limit.

Answer

The pod's CPU request exceeds the ResourceQuota limit.

Question 6

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?

Accepted Answer

The container is OOMKilled because it exceeds the memory limit. The correct answer is A because 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.

Answer

The container runs normally, but memory usage is throttled

Answer

The container runs normally because requests are the only constraints

Answer

The container is evicted from the node

Question 7

A pod is failing to start with error 'container has runAsNonRoot and image will run as root'. The container image runs as root. Which change allows the pod to run?

Accepted Answer

Set runAsUser to a non-zero UID, e.g., 1000. Option B is correct: set runAsUser to a non-zero ID to run as non-root, satisfying runAsNonRoot. Option A removes the check but may be insecure. Option C does not change user. Option D is not valid.

Answer

Remove runAsNonRoot: true from securityContext

Answer

Add fsGroup: 1000

Answer

Set allowPrivilegeEscalation: false

Question 8

A Pod is running in a namespace with a ResourceQuota that sets 'limits.memory: 2Gi'. The pod's container spec has 'resources.limits.memory: 1Gi' and 'resources.requests.memory: 512Mi'. The pod is in 'Running' state but consumes 1.5Gi of memory. What happens?

Accepted Answer

The container will be OOMKilled because it exceeds its own memory limit of 1Gi. The container has a hard memory limit of 1Gi set in its resources.limits.memory. When the container's memory usage exceeds this limit (1.5Gi > 1Gi), the Linux kernel's OOM killer terminates the container process. The namespace ResourceQuota of 2Gi is not violated because the pod's limit (1Gi) is within the quota, so the kubelet does not evict the pod.

Answer

The pod will be evicted by the kubelet due to namespace quota violation

Answer

The container will continue running because the namespace quota allows up to 2Gi

Answer

The pod will be throttled by the kernel to stay within 1Gi

Question 9

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?

Accepted Answer

Set fsGroup: 2000 in the pod-level securityContext. The 'fsGroup' field in the pod's SecurityContext changes the group ownership of any files in the mounted volumes to the specified GID, and all container processes are part of the supplementary group. This allows the container to read files with group 2000 if fsGroup is set to 2000. Option A (runAsGroup: 2000) would change the primary group of the process, but the file's group is 2000 and the container runs as user 1000, which might not own the file; fsGroup is the correct approach. Option C adds capabilities, which are not related to file access groups. Option D sets readOnlyRootFilesystem, which doesn't help with volume access.

Answer

Set readOnlyRootFilesystem: true

Answer

Set runAsGroup: 2000

Answer

Add capability: CAP_DAC_READ_SEARCH

Question 10

How can you set the environment variable 'DATABASE_URL' in a pod to the value stored in a Kubernetes Secret named 'db-secret' under the key 'url'?

Accepted Answer

env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: url. Option C is correct because the `env.valueFrom.secretKeyRef` field in a Pod spec is the proper mechanism to inject a specific key from a Kubernetes Secret as an environment variable. The `name` field identifies the Secret (`db-secret`), and the `key` field specifies which key within that Secret (`url`) to use. This is defined in the Kubernetes API for exposing Secret data as environment variables.

Answer

env:
  - name: DATABASE_URL
    valueFrom:
      configMapKeyRef:
        name: db-secret
        key: url

Answer

env:
  - name: DATABASE_URL
    valueFrom:
      secretRef:
        name: db-secret

Answer

env:
  - name: DATABASE_URL
    value:
      secretKeyRef:
        name: db-secret
        key: url

Question 11

Which of the following correctly describes the purpose of a PodSecurityPolicy (PSP) in Kubernetes? (Note: PSP is deprecated in v1.21+ and removed in v1.25; Pod Security Admission is the replacement.)

Accepted Answer

PSP is deprecated; its replacement is Pod Security Admission (PSA). Option A is correct because PodSecurityPolicy (PSP) was indeed deprecated in Kubernetes v1.21 and removed in v1.25, with Pod Security Admission (PSA) as its official replacement. PSA uses built-in Pod Security Standards (baseline, restricted, privileged) enforced via admission controllers and labels, eliminating the need for a separate admission webhook or CRD-based policy object.

Answer

PSP is applied automatically to all pods in a cluster without configuration

Answer

PSP is a namespace-scoped resource that defines default security for pods

Answer

PSP cannot be used to control container security contexts

Question 12

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?

Accepted Answer

roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1. Option A is correct because 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.

Answer

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

Answer

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

Answer

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

Question 13

Which field in a Pod spec specifies which ServiceAccount the pod should use?

Accepted Answer

spec.serviceAccountName. The correct field is `spec.serviceAccountName` in the Pod spec. This field explicitly specifies the name of the ServiceAccount that the Pod should use. If omitted, the Pod automatically uses the `default` ServiceAccount in its namespace. This is defined in the Kubernetes API for PodSpec.

Answer

spec.serviceAccount

Answer

spec.accountName

Answer

spec.automountServiceAccountToken

Question 14

A container image requires running as UID 0 but you need to comply with a 'restricted' Pod Security Admission policy. Which SecurityContext setting allows this while still passing the policy?

Accepted Answer

No SecurityContext setting allows running as UID 0 under the restricted policy.. The 'restricted' Pod Security Admission policy requires that containers run as non-root (runAsNonRoot: true) and prohibits setting runAsUser to 0. Since the image requires UID 0, no SecurityContext setting can override this policy constraint; the only way to comply is to modify the image to run as a non-root user. Therefore, option B is correct.

Answer

Set securityContext: { allowPrivilegeEscalation: true }

Answer

Set securityContext: { runAsNonRoot: true, capabilities: { add: ['SYS_ADMIN'] } }

Answer

Set runAsUser: 0 and runAsNonRoot: false

Question 15

A Pod is in 'CrashLoopBackOff' state. 'kubectl logs mypod' shows: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause?

Accepted Answer

The container's application is attempting to use a port that is already occupied. The error 'listen tcp :8080: bind: address already in use' indicates that the container's application is trying to bind to port 8080, but that port is already occupied by another process within the same network namespace (typically the same Pod or container). This is a classic port conflict, not a resource or permission issue, making option B correct.

Answer

The pod's resource limits are too low

Answer

The pod's ServiceAccount token is not mounted

Answer

The pod is using a readOnlyRootFilesystem

Question 16

A Pod has the following environment variable definition:
- name: DB_HOST
  valueFrom:
    configMapKeyRef:
      name: db-config
      key: host
The ConfigMap 'db-config' exists in the same namespace but does not have a key 'host'. What will happen when the Pod starts?

Accepted Answer

The Pod will fail to start because the key is not found. When a Pod references a ConfigMap key that does not exist, the Pod will fail to start. Kubernetes validates the ConfigMap key reference at Pod creation time; if the key is missing, the kubelet will not start the container, and the Pod will remain in a 'CreateContainerConfigError' or 'RunContainerError' state. This is because environment variables are resolved before the container starts, and a missing key is treated as a fatal configuration error.

Answer

The Pod will start and the environment variable will be set to the key name 'host'

Answer

The Pod will start and the environment variable will be empty

Answer

The Pod will start but the variable will be set to the ConfigMap's name

Question 17

Which annotation is used to enforce Pod Security Admission at the 'restricted' level on a namespace?

Accepted Answer

pod-security.kubernetes.io/enforce: restricted. Option A is correct because the `pod-security.kubernetes.io/enforce` annotation enforces Pod Security Standards (PSS) at the namespace level, and setting it to `restricted` blocks any pod that violates the most stringent set of security controls (e.g., running as root, privileged containers). This is the only annotation that actively prevents non-compliant pods from being created, rather than just warning or logging violations.

Answer

pod-security.kubernetes.io/warn: restricted

Answer

pod-security.kubernetes.io/enforce: baseline

Answer

pod-security.kubernetes.io/audit: restricted

Question 18

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?

Accepted Answer

The pod creation is denied because the spec does not specify resource limits or requests. 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.

Answer

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

Answer

The pod is created and the quota is ignored

Answer

The pod is created with default limits from the LimitRange

Question 19

You want to see a list of all events in the 'default' namespace, sorted by timestamp. Which command should you use?

Accepted Answer

kubectl get events. Option C is correct because `kubectl get events` retrieves all events in the current namespace (default) and, by default, sorts them by the `lastTimestamp` field in ascending order, which is the timestamp of the event. This command directly answers the requirement to list events sorted by timestamp without additional flags.

Answer

kubectl describe events

Answer

kubectl get pods

Answer

kubectl logs --all-containers

Question 20

A pod with a startup probe configured is taking longer than usual to start. The startup probe has 'failureThreshold: 10' and 'periodSeconds: 5'. What is the maximum time the pod has to start before it is restarted?

Accepted Answer

50 seconds. The maximum time a pod has to start before being restarted is calculated by multiplying the startup probe's `failureThreshold` (10) by its `periodSeconds` (5), which equals 50 seconds. This is because the startup probe runs every 5 seconds, and after 10 consecutive failures (i.e., the probe never succeeds within that window), the kubelet restarts the container. The startup probe is specifically designed to give slow-starting applications a grace period before the liveness probe takes over.

Answer

10 seconds

Answer

30 seconds

Answer

60 seconds