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

Question 1

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. Option A is correct because 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 2

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 3

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

Accepted Answer

runAsNonRoot: true. The 'restricted' profile in Pod Security Admission enforces the most stringent security standards. Option A is correct because `runAsNonRoot: true` is a required field in the restricted profile, ensuring containers cannot run as the root user, which mitigates privilege escalation risks.

Answer

allowPrivilegeEscalation: true

Answer

Privileged containers allowed

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. Option A is correct because `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. Option D is correct because `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'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 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. Option A is correct because it defines a Role in the 'app' namespace with rules allowing 'get' and 'list' verbs on 'pods', and binds that Role to the 'monitor' ServiceAccount using a RoleBinding in the same namespace. This grants the ServiceAccount the exact permissions needed to list pods within the namespace, following the principle of least privilege.

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. Option A is correct because `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. Option C is correct because 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

Add 'runAsUser: 1000' to the container's securityContext. Option D is correct because the error 'container has runAsNonRoot and image will run as root' indicates the pod's securityContext enforces runAsNonRoot: true, but the container image runs as root (default user). Adding runAsUser: 1000 explicitly sets the container's user to a non-root UID, satisfying the runAsNonRoot constraint and allowing the pod to start.

Answer

Set 'runAsGroup: 1000' in the securityContext

Answer

Add capability 'CAP_SYS_ADMIN' to the container

Answer

Remove the 'runAsNonRoot: true' line from the pod spec

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