CKAD Practice Test 6 — 10 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