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

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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 2

A container image requires a seccomp profile that is not the default. The cluster supports the RuntimeDefault seccomp profile. Which Pod securityContext field should be configured to use the RuntimeDefault seccomp profile?

Accepted Answer

seccompProfile:
  type: RuntimeDefault. The `seccompProfile` field under the Pod's `securityContext` is the proper way to specify a seccomp profile in Kubernetes. Setting `type: RuntimeDefault` tells the container runtime (e.g., containerd or CRI-O) to use the default seccomp profile provided by the runtime, which is a secure baseline that blocks around 44 system calls while allowing common ones like `read`, `write`, and `exit`. This field was introduced in Kubernetes 1.19 (GA in 1.22) and is the standard approach for configuring seccomp at the Pod or container level.

Answer

seccomp:
  type: RuntimeDefault

Answer

capabilities:
  add: [SECCOMP]

Answer

securityContext:
  seccomp:
    type: Unconfined

Question 3

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 a Kubernetes object that sets hard limits on aggregate resource consumption (e.g., total CPU, memory, persistent volume claims) per namespace, preventing any single namespace from exhausting cluster resources. LimitRange (E) is correct because it enforces minimum and maximum resource requests/limits at the pod or container level within a namespace, complementing ResourceQuota by defining per-pod constraints.

Answer

HorizontalPodAutoscaler

Answer

NetworkPolicy

Answer

PodDisruptionBudget

Question 4

Which TWO commands can be used to create a Secret named 'db-creds' with keys 'username' and 'password'? (Select TWO.)

Accepted Answer

kubectl create secret generic db-creds --from-literal=username=admin --from-literal=password=secret123. `kubectl create secret generic` with `--from-literal` is the standard way to create a generic (Opaque) Secret from key-value pairs directly in the command line. Each `--from-literal` flag specifies a key=value pair, and the command creates a Secret named 'db-creds' with keys 'username' and 'password'.

Answer

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

Answer

kubectl create secret opaque db-creds --from-literal=username=admin

Answer

kubectl create secret tls db-creds --cert=cert.pem --key=key.pem

Question 5

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 6

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-level securityContext sets the group ID for all volumes mounted into the pod. When fsGroup is set to 2000, Kubernetes recursively changes the group ownership of the files in the volume to 2000 and ensures the container process is a member of the supplementary group 2000. This allows the process (running as user 1000) to read files owned by group 2000. Option B (readOnlyRootFilesystem: true) does not affect volume permissions. Option C (runAsGroup: 2000) would change the primary group of the process, but since the file is owned by user 1000 and group 2000, and the process is user 1000, the file's owner permissions may allow read; however, fsGroup is the standard Kubernetes mechanism for volume access because it modifies the volume's group ownership. Option D (CAP_DAC_READ_SEARCH) is a Linux capability that bypasses DAC permission checks, which is not recommended and not the standard approach in Kubernetes; fsGroup is the appropriate method.

Answer

Set readOnlyRootFilesystem: true

Answer

Set runAsGroup: 2000

Answer

Add capability: CAP_DAC_READ_SEARCH

Question 7

You need to create a Role and RoleBinding to allow a ServiceAccount 'monitor' in namespace 'app' to list pods in that namespace. Which YAML snippet correctly achieves this?

Accepted Answer

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: app
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: monitor-binding
  namespace: app
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- kind: ServiceAccount
  name: monitor
  namespace: app. Both A and D define a namespace-scoped Role with verbs 'get' and 'list' on pods, and bind it to the 'monitor' ServiceAccount in the 'app' namespace via a RoleBinding. Option B uses invalid verb 'read'. Option C uses ClusterRole/ClusterRoleBinding, granting cluster-wide permissions. Since A and D are exactly the same, both correctly achieve the requirement, so the question is flawed as a single-answer multiple-choice item.

Answer

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: app
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["read"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: monitor-binding
  namespace: app
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- kind: ServiceAccount
  name: monitor

Answer

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitor-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pod-reader
subjects:
- kind: ServiceAccount
  name: monitor
  namespace: app

Question 8

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 9

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 10

A pod is failing to start. The 'kubectl describe pod' output shows: 'container has runAsNonRoot and image will run as root'. The Dockerfile of the container image does not specify a USER directive. Which action will fix the issue?

Accepted Answer

Remove the 'runAsNonRoot: true' line from the pod spec. The error occurs because runAsNonRoot is true but the image runs as root. Adding runAsUser: 1000 (D) changes the effective UID to a non-root user, satisfying the constraint. However, removing runAsNonRoot (C) also eliminates the conflict and allows the pod to start, albeit without enforcing non-root. Both C and D are valid fixes.

Answer

Set 'runAsGroup: 1000' in the securityContext

Answer

Add capability 'CAP_SYS_ADMIN' to the container

Question 11

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. Setting `resources.limits.memory: 256Mi` in the container spec directly enforces a hard memory limit on that specific container. For a single-container pod, this ensures the pod cannot exceed 256Mi. For multi-container pods, set limits on each container so the sum is 256Mi. A LimitRange with `type: Pod` can also enforce a pod-level limit, so this is not the only approach.

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 12

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 13

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 14

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 15

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