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

Question 1

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

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 3

You need to set environment variables in a pod from a ConfigMap 'app-config' that has keys 'APP_ENV' and 'APP_DEBUG'. Which approach exposes all keys as environment variables?

Accepted Answer

envFrom:
  - configMapRef:
      name: app-config. `envFrom` with `configMapRef` is the Kubernetes-native way to expose all keys from a ConfigMap as environment variables in a pod. This injects each key-value pair from the ConfigMap 'app-config' as an environment variable, matching the requirement to expose all keys without manual enumeration.

Answer

envFrom:
  - secretRef:
      name: app-config

Answer

env:
  - name: APP_ENV
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: APP_ENV
  - name: APP_DEBUG
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: APP_DEBUG

Answer

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

Question 4

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 is in Pending state because no node has enough allocatable CPU to satisfy the container's CPU request. Reducing the CPU request in the container's resource spec lowers the amount of guaranteed CPU the scheduler requires, making it possible to schedule the pod on a node with insufficient CPU capacity. This directly resolves the 'Insufficient cpu' condition shown in 'kubectl describe pod'.

Answer

Increase the CPU limit of the container

Answer

Delete and recreate the pod

Answer

Add more environment variables

Question 5

Which THREE of the following are valid fields in a PodSecurityContext that affect container security? (Select 3)

Accepted Answer

runAsUser. (runAsUser) is correct because it is a valid field in a PodSecurityContext that specifies the user ID (UID) under which all containers in the pod run. This field directly affects container security by controlling privilege levels and access to host resources, overriding the container's default user.

Answer

capabilities

Answer

privileged

Question 6

Which TWO methods can be used to expose a Secret's data as environment variables inside a container? (Select 2)

Accepted Answer

Using 'env.valueFrom.secretKeyRef'. `env.valueFrom.secretKeyRef` allows you to inject a specific key from a Kubernetes Secret as an environment variable into a container. This is a standard method for exposing sensitive data like passwords or tokens directly into the container's environment without hardcoding them in the Pod spec.

Answer

Using 'args' in container spec

Answer

Using 'env.valueFrom.configMapKeyRef'

Answer

Using 'volumeMounts' with a secret volume

Question 7

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

An administrator needs to create a ConfigMap named 'app-config' from a file called 'config.properties'. Which kubectl command accomplishes this?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. `kubectl create configmap app-config --from-file=config.properties` reads the file `config.properties` and creates a ConfigMap where the key is the filename (config.properties) and the value is the file's content. This is the standard way to create a ConfigMap from a single file in Kubernetes.

Answer

kubectl create configmap app-config --from-literal=config.properties

Answer

kubectl create configmap app-config --from-env-file=config.properties

Answer

kubectl create configmap app-config --from-file=key1=config.properties

Question 9

A pod fails to start with a 'CreateContainerConfigError'. Running 'kubectl describe pod my-pod' reveals: 'Error: container has runAsNonRoot and image will run as root'. The pod definition includes 'securityContext.runAsNonRoot: true'. What is the most likely cause?

Accepted Answer

The container image's default user is root (UID 0), conflicting with runAsNonRoot. The error 'container has runAsNonRoot and image will run as root' occurs because the pod's securityContext sets `runAsNonRoot: true`, but the container image's default user is root (UID 0). Kubernetes checks the image's user at container startup; if the image runs as root and the pod enforces non-root, the container fails to start with a CreateContainerConfigError.

Answer

The container does not have the CAP_SYS_ADMIN capability

Answer

The container's filesystem is read-only

Answer

The runAsUser field is missing, so the pod uses a random UID

Question 10

A security requirement states: 'The container must drop all capabilities and add only NET_BIND_SERVICE'. Which YAML snippet correctly implements this in the securityContext?

Accepted Answer

securityContext:
  capabilities:
    drop: [ALL]
    add: ["NET_BIND_SERVICE"]. It first drops all capabilities with `drop: [ALL]` and then explicitly adds only `NET_BIND_SERVICE` via `add: ["NET_BIND_SERVICE"]`. This matches the security requirement exactly: the container starts with no capabilities and gains only the one needed to bind to privileged ports (<1024). In Kubernetes, the order of `drop` and `add` matters — dropping ALL first ensures a clean slate, then adding the specific capability.

Answer

securityContext:
  capabilities:
    drop: ["NET_BIND_SERVICE"]
    add: [ALL]

Answer

securityContext:
  capabilities:
    add: [ALL]
    drop: ["NET_BIND_SERVICE"]

Answer

securityContext:
  capabilities: "drop ALL; add NET_BIND_SERVICE"

Question 11

A pod is running with the default service account. An administrator wants to prevent the pod from automatically mounting the service account token. Which field in the pod spec accomplishes this?

Accepted Answer

automountServiceAccountToken: false. Setting `automountServiceAccountToken: false` in the pod spec explicitly prevents the automatic mounting of the service account token into the pod. By default, Kubernetes mounts a projected service account token into every pod at `/var/run/secrets/kubernetes.io/serviceaccount`; this field overrides that default behavior at the pod level.

Answer

serviceAccountName: ""

Answer

serviceAccountToken: none

Answer

securityContext.readOnlyRootFilesystem: true

Question 12

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 13

A namespace 'team-a' has a ResourceQuota that sets 'requests.cpu: 4' and 'limits.cpu: 8'. A developer tries to create a pod with 'resources.requests.cpu: 2' and 'resources.limits.cpu: 10'. What happens?

Accepted Answer

The pod is rejected because the limit (10) exceeds the quota's allowed limit. The pod is rejected because the ResourceQuota in namespace 'team-a' sets a hard limit of 8 CPUs for limits.cpu across all pods. The developer's pod specifies a limit of 10 CPUs, which exceeds this quota. Kubernetes enforces ResourceQuota at admission time, so any resource request or limit that violates the quota's constraints will cause the pod creation to be denied.

Answer

The pod is created because the request (2) is within the quota

Answer

The pod is created but its limit is automatically reduced to 8

Answer

The pod is created, but it will be evicted immediately

Question 14

An administrator wants to enforce that all pods in namespace 'secured' must run with a seccomp profile set to 'RuntimeDefault' at the container level. Which Pod Security Admission policy standard achieves this?

Accepted Answer

Set the namespace label 'pod-security.kubernetes.io/enforce=restricted'. The 'restricted' Pod Security Admission (PSA) policy standard enforces the most stringent security controls, including requiring that pods use a seccomp profile set to 'RuntimeDefault' at the container level. This is defined in the Kubernetes Pod Security Standards documentation, where the restricted profile mandates 'seccomp: RuntimeDefault' as a baseline requirement. Therefore, option C is correct because it directly matches the policy that enforces this specific seccomp constraint.

Answer

Set the namespace label 'pod-security.kubernetes.io/enforce=privileged'

Answer

Set the namespace label 'pod-security.kubernetes.io/enforce=baseline'

Answer

Set the namespace label 'pod-security.kubernetes.io/enforce=seccomp'

Question 15

Which kubectl command creates a Secret named 'tls-secret' from a TLS certificate file 'cert.pem' and private key file 'key.pem'?

Accepted Answer

kubectl create secret tls tls-secret --cert=cert.pem --key=key.pem. The `kubectl create secret tls` command is specifically designed to create a TLS secret from a certificate and private key pair. The correct flags are `--cert` for the certificate file and `--key` for the private key file, matching the usage shown in option B.

Answer

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

Answer

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

Answer

kubectl create secret docker-registry tls-secret --cert=cert.pem --key=key.pem