CKAD Practice Test 5 — 10 Questions

Question 1

To mount a ConfigMap as a volume, which field type must be used in the pod spec's volumes and volumeMounts?

Accepted Answer

configMap. To mount a ConfigMap as a volume in a Pod, the `configMap` field type must be specified in the `volumes` array of the Pod spec, and the corresponding `volumeMounts` entry references that volume by name. This tells Kubernetes to populate the volume with the key-value pairs from the ConfigMap, making them available as files in the container's filesystem.

Answer

emptyDir

Answer

secret

Answer

hostPath

Question 2

A container needs to run with the NET_ADMIN capability. Which securityContext field should be used?

Accepted Answer

capabilities:
  add: ["NET_ADMIN"]. Option B is correct because the `capabilities.add` field in a container's `securityContext` is specifically designed to grant Linux capabilities like `NET_ADMIN` to a container. This allows the container to perform network administration operations (e.g., configuring iptables, changing interface settings) without running as root or giving full privileged access.

Answer

capabilities:
  drop: ["ALL"]

Answer

runAsUser: 0

Answer

readOnlyRootFilesystem: true

Question 3

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?

Accepted Answer

User 'jane' can read pods only in the 'default' namespace. 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.

Answer

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

Answer

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

Answer

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

Question 4

Which of the following is a valid Pod Security Admission standard?

Accepted Answer

Restricted. The Pod Security Admission (PSA) standard defines three levels: Privileged, Baseline, and Restricted. Option C is correct because 'Restricted' is one of the three valid standards, designed to enforce the most restrictive pod security policies.

Answer

Privileged, Default

Answer

Default

Answer

Secure

Question 5

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

Accepted Answer

Reduce the CPU request in the container's resource spec. The pod cannot be scheduled because the requested CPU is not available on any node. Reducing the CPU request may allow scheduling.

Answer

Increase the CPU limit of the container

Answer

Delete and recreate the pod

Answer

Add more environment variables

Question 6

You want to enforce a Pod Security Standard of 'restricted' in a namespace. Which command applies the correct label?

Accepted Answer

kubectl label namespace my-ns pod-security.kubernetes.io/enforce=restricted. Option B is correct because Pod Security Standards are enforced by applying a label with the key `pod-security.kubernetes.io/enforce` to a namespace. The value `restricted` sets the most restrictive Pod Security Standard, which prevents pods from running with privileged access or insecure capabilities. This label is part of the built-in Pod Security Admission (PSA) controller, which replaced PodSecurityPolicy in Kubernetes v1.23+.

Answer

kubectl label namespace my-ns psp=restricted

Answer

kubectl annotate namespace my-ns pod-security.kubernetes.io/enforce=restricted

Answer

kubectl label namespace my-ns pod-security.kubernetes.io/audit=restricted

Question 7

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?

Accepted Answer

request: 200m, limit: 500m. 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.

Answer

The pod will be rejected by the admission controller

Answer

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

Answer

request: 500m, limit: 500m

Question 8

You need to create a Pod that runs with a specific non-root user (UID 1000), prevents privilege escalation, and mounts the container's filesystem as read-only. Which securityContext field is NOT required to achieve these requirements?

Accepted Answer

runAsGroup: 1000. Option B (runAsGroup: 1000) is not required because the requirement only specifies a non-root user (UID 1000) and does not mandate a specific group ID. The runAsGroup field sets the primary group for the container's processes, but it is optional; without it, the container will use the default group associated with the user or the container's default group. The other options are necessary: runAsUser: 1000 sets the user, readOnlyRootFilesystem: true makes the filesystem read-only, and allowPrivilegeEscalation: false prevents privilege escalation.

Answer

runAsUser: 1000

Answer

readOnlyRootFilesystem: true

Answer

allowPrivilegeEscalation: false

Question 9

A pod's securityContext has 'allowPrivilegeEscalation: false' and 'capabilities: { drop: ["ALL"] }'. Which statement is true?

Accepted Answer

The container runs with no extra capabilities and cannot gain privileges.. Option B is correct because setting 'allowPrivilegeEscalation: false' prevents processes from gaining more privileges than their parent (e.g., via setuid binaries or kernel exploits), and dropping all capabilities with 'capabilities: { drop: ["ALL"] }' removes every Linux capability from the container's bounding set. Together, these ensure the container runs with no extra capabilities and cannot escalate privileges, even if running as root.

Answer

The container can still gain capabilities via setuid binaries.

Answer

The container runs as root with full privileges.

Answer

The container runs with all Linux capabilities.

Question 10

Which TWO statements about Kubernetes Secrets are correct? (Select 2)

Accepted Answer

A Secret can be mounted as a volume or exposed as environment variables. A is correct because Kubernetes Secrets are designed to be consumed by Pods either as files mounted into a volume (via `volumes` and `volumeMounts`) or as environment variables (via `env` or `envFrom`). This flexibility allows applications to access sensitive data like passwords or tokens without hardcoding them into the container image or pod spec.

Answer

Secrets are always encrypted in etcd

Answer

The maximum size of a Secret is 1 MB

Answer

Secrets can only be used by pods in the same namespace as the Secret