CKAD Application Environment, Configuration and Security Practice Test 12 — 15 Questions

Question 1

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

Accepted Answer

ResourceQuota. 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.

Answer

HorizontalPodAutoscaler

Answer

NetworkPolicy

Answer

PodDisruptionBudget

Question 2

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

Accepted Answer

runAsNonRoot: true. 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.

Answer

allowPrivilegeEscalation: true

Answer

Privileged containers allowed

Question 3

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?

Accepted Answer

envFrom:
  - configMapRef:
      name: app-config. `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`.

Answer

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

Answer

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

Answer

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

Question 4

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. 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.

Answer

Set readOnlyRootFilesystem: true

Answer

Set runAsGroup: 2000

Answer

Add capability: CAP_DAC_READ_SEARCH

Question 5

Which command creates a Secret named 'db-secret' with two keys, 'username' and 'password', from literal values?

Accepted Answer

kubectl create secret generic db-secret --from-literal=username=admin --from-literal=password=secret123. `kubectl create secret generic` is the correct command syntax for creating a generic (opaque) Secret from literal key-value pairs. The `--from-literal` flag allows you to specify each key and its value directly on the command line, making it the appropriate choice for this task.

Answer

kubectl create secret db-secret --from-literal=username=admin --from-literal=password=secret123

Answer

kubectl create secret generic db-secret --from-file=username=admin --from-file=password=secret123

Answer

kubectl create secret generic db-secret --literal=username=admin --literal=password=secret123

Question 6

A developer creates a pod with the following YAML snippet:

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000

The pod mounts an emptyDir volume. What is the owner and group of the mounted directory inside the container?

Accepted Answer

Owner: 1000, Group: 2000. When a pod specifies `fsGroup: 2000`, Kubernetes recursively changes the group ownership of any volume mounted into the pod (including emptyDir) to that GID (2000). The `runAsUser: 1000` sets the container process's UID, but the volume's group ownership is overridden by `fsGroup`. Thus, the mounted emptyDir directory is owned by UID 1000 (the process user) and GID 2000 (the fsGroup).

Answer

Owner: 1000, Group: 3000

Answer

Owner: 1000, Group: 1000

Answer

Owner: 0, Group: 2000

Question 7

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

Accepted Answer

The service account token is not mounted into the pod. 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.

Answer

The pod uses the default service account token from the namespace

Answer

The service account token is mounted but not updated

Answer

The pod cannot communicate with the Kubernetes API

Question 8

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). 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 9

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?

Accepted Answer

BestEffort pods first, then this Burstable pod, then Guaranteed pods last. 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.

Answer

The node will not evict pods if limits are set

Answer

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

Answer

All pods are evicted simultaneously

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. 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

You need to create a Secret of type 'kubernetes.io/tls' for ingress. Which command is correct?

Accepted Answer

kubectl create secret tls my-tls --cert=cert.pem --key=key.pem. `kubectl create secret tls` is the dedicated command for creating a TLS secret, and it uses the `--cert` and `--key` flags to specify the certificate and private key files respectively. This creates a Secret of type `kubernetes.io/tls`, which is required for Ingress resources to terminate HTTPS traffic.

Answer

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

Answer

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

Answer

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

Question 12

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

Accepted Answer

PSA can be configured to warn or audit violations without blocking. 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.

Answer

PSA requires Open Policy Agent (OPA) Gatekeeper to function

Answer

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

Question 13

A developer wants to create a ConfigMap named 'app-config' with two key-value pairs: 'color=blue' and 'size=large'. Which kubectl command should they use?

Accepted Answer

kubectl create configmap app-config --from-literal=color=blue --from-literal=size=large. `kubectl create configmap` with `--from-literal` allows specifying key-value pairs directly in the command line. Each literal must be provided as a separate `--from-literal=key=value` flag, and this command correctly creates the ConfigMap with the two entries 'color=blue' and 'size=large'.

Answer

kubectl create configmap app-config --from-literal=color,size --value=blue,large

Answer

kubectl create configmap app-config --from-env-file=color=blue,size=large

Answer

kubectl create configmap app-config --from-file=color=blue --from-file=size=large

Question 14

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

Accepted Answer

The pod's memory request exceeds the available memory on any node. The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler attempted to place the pod on a node but found that the node's allocatable memory is less than the pod's memory request. The pod's memory request must be satisfied by at least one node for scheduling to succeed; if no node has enough unallocated memory, the pod remains Pending. This is a resource request, not a limit, that gates scheduling.

Answer

The pod is using too many CPU resources

Answer

The pod's memory limit is too low

Answer

The pod's container is crashing due to a bug

Question 15

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

Accepted Answer

The Pod will not start; the kubelet will reject it because the container tries to run as root. 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.

Answer

The Pod will start and immediately be OOMKilled

Answer

The Pod will run but with a warning

Answer

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