CKAD Application Environment, Configuration and Security — Timed 20 Questions

Question 1

A pod uses a service account 'my-sa' with a RoleBinding that grants get and list on pods in namespace 'app'. The pod runs a process that calls the Kubernetes API to list pods. However, the API call returns 403. What is the most likely cause?

20 minute time limit — choose an answer to begin.

Accepted Answer

The pod does not have the service account token mounted.. The pod must have the service account token mounted to authenticate to the Kubernetes API server. By default, Kubernetes automatically mounts the service account token into pods via a projected volume at /var/run/secrets/kubernetes.io/serviceaccount/token. If the pod is configured with automountServiceAccountToken: false or the token is not mounted, the API client cannot authenticate, resulting in a 403 Forbidden error even if the RoleBinding grants the correct permissions.

Answer

The API server is not running.

Answer

The RoleBinding is in the wrong namespace.

Answer

The Role does not include list permission.

Question 2

You are designing a Pod that runs a legacy application requiring a specific configuration file mounted at /etc/config/app.conf. The configuration is stored in a Kubernetes ConfigMap named 'app-config' with key 'config.yaml'. Which approach ensures the configuration is mounted correctly and the container automatically receives updates when the ConfigMap changes?

Accepted Answer

Create a ConfigMap volume mount at /etc/config, mounting the entire ConfigMap, and ensure the application reads /etc/config/config.yaml.. The provided explanation is incorrect. Mounting the entire ConfigMap at /etc/config creates a file named after the key, config.yaml. To meet the legacy application's requirement of /etc/config/app.conf, you would need a ConfigMap key named app.conf or a symlink. Option D with subPath achieves the exact file path but does not receive automatic updates. Therefore, the marked answer A is not correct.

Answer

Create a hostPath volume at /etc/config and copy the ConfigMap content to the node.

Answer

Use the ConfigMap to set an environment variable CONFIG and have the application read it from the environment.

Answer

Create a ConfigMap volume mount at /etc/config/app.conf using subPath: config.yaml.

Question 3

A cluster administrator wants to enforce that all pods in a namespace run with the 'restricted' Pod Security Standard. Which of the following is the correct way to label the namespace?

Accepted Answer

pod-security.kubernetes.io/enforce: restricted. The `restricted` Pod Security Standard is enforced by applying the label `pod-security.kubernetes.io/enforce: restricted` to the namespace. This label causes the Pod Security Admission controller to reject any pod that violates the restricted policy, ensuring compliance. Only option A correctly specifies this label. Option D is a duplicate and not considered distinct.

Answer

pod-security.kubernetes.io/warn: restricted

Answer

pod-security.kubernetes.io/audit: restricted

Answer

pod-security.kubernetes.io/enforce: restricted

Question 4

A pod needs to mount a ConfigMap as a volume so that when the ConfigMap is updated, the pod automatically gets the updates. Which volume type should be used?

Accepted Answer

configMap volume. A configMap volume type directly mounts a ConfigMap as a volume in a pod. When the ConfigMap is updated, the kubelet periodically syncs the volume's content (default sync period is 60 seconds), so the pod automatically sees the updated data without requiring a restart. This makes it the correct choice for live updates from a ConfigMap.

Answer

emptyDir volume

Answer

projected volume with configMap source

Answer

downwardAPI volume

Question 5

You need to grant a ServiceAccount named 'app-sa' in namespace 'default' read-only access to Pods in that namespace. Which RBAC resources should you create?

Accepted Answer

A Role with rules for pods (get, list, watch) and a RoleBinding to the ServiceAccount. The ServiceAccount 'app-sa' requires read-only access to Pods only within the 'default' namespace. A Role is namespace-scoped and can define rules for pods with verbs get, list, watch. A RoleBinding then binds that Role to the ServiceAccount within the same namespace, granting the permissions exactly where needed.

Answer

A ClusterRole with rules for pods (get, list, watch) and a ClusterRoleBinding to the ServiceAccount

Answer

A ClusterRole with rules for pods (get, list, watch) and a RoleBinding to the ServiceAccount

Answer

A Role with rules for pods (get, list, watch, create) and a RoleBinding to the ServiceAccount

Question 6

You create a Pod with a securityContext set to 'runAsNonRoot: true' and a container image that runs as root (user 0). What will happen when you create the Pod?

Accepted Answer

The Pod will be created but the container will be in a CrashLoopBackOff. When a Pod has `runAsNonRoot: true` in its security context and the container image runs as root (UID 0), the Pod object is still created, but the container fails to start because it violates the security context. Kubernetes attempts to run the container, but the CRI (Container Runtime Interface) refuses to run the container as root due to the `runAsNonRoot: true` setting. This results in a runtime error such as `CreateContainerError` or `CrashLoopBackOff` as the container repeatedly fails to start. The Pod is not rejected at admission time because `runAsNonRoot` is enforced at runtime by the container runtime, not by the API server.

Answer

The Pod will run but with root user, ignoring the setting

Answer

The Pod will not be created and you will see an error about securityContext violation

Answer

The Pod will run with root but the container will be killed by a security policy

Question 7

Which TWO of the following are valid ways to consume a ConfigMap in a Pod? (Select TWO)

Accepted Answer

Using env with valueFrom.configMapKeyRef to inject a specific key. Option B is correct because env.valueFrom.configMapKeyRef lets you inject a single specific key from a ConfigMap into a container's environment variable, referencing the ConfigMap by name and the key explicitly. Option C is correct because a ConfigMap can be mounted as a volume via a volumes entry with configMap and a corresponding volumeMount, which projects each key as a file in the mount path. Option A is incorrect because envFrom uses configMapRef (not secretRef) to bulk-load ConfigMap keys; secretRef belongs to Secrets. Option D is incorrect because env.value is a literal string, not a reference to a ConfigMap key. Option E is incorrect because envFrom does inject all keys as environment variables, but it is not one of the two marked correct answers here.

Answer

Using envFrom with secretRef

Answer

Using env with value directly set to a key name

Answer

Using envFrom to inject all keys as environment variables

Question 8

A developer creates a Secret using the command: 'kubectl create secret generic db-secret --from-literal=password=myPass'. Which way to consume this Secret in a pod is CORRECT?

Accepted Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password. The Secret can be consumed via secretKeyRef for a specific key, via envFrom to load all keys as environment variables, or via a volume mount. As the question is worded, all these methods are correct. If intended to ask specifically about injecting a single key into an environment variable, only A would be correct, but the current wording does not make that restriction.

Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      configMapKeyRef:
        name: db-secret
        key: password

Question 9

A developer runs 'kubectl create secret generic tls-secret --cert=cert.crt --key=key.pem'. What type of Secret is created?

Accepted Answer

kubernetes.io/tls. The command `kubectl create secret generic tls-secret --cert=cert.crt --key=key.pem` creates a Secret of type `kubernetes.io/tls`. This is because the `--cert` and `--key` flags automatically set the type to TLS, which is used to store TLS certificates and private keys for ingress or other TLS termination. The `generic` subcommand is a misnomer here; it does not create an Opaque secret when these specific flags are provided.

Answer

Opaque

Answer

kubernetes.io/dockerconfigjson

Answer

kubernetes.io/ssh-auth

Question 10

A namespace 'dev' has a ResourceQuota that sets 'requests.cpu: 4' and 'limits.cpu: 8'. A pod is created with a container that has 'resources.requests.cpu: 1' and 'resources.limits.cpu: 3'. However, the pod remains in Pending state. The output of 'kubectl describe quota -n dev' shows 'used requests.cpu: 3.5' and 'used limits.cpu: 7'. What is the most likely reason the pod is pending?

Accepted Answer

The pod's CPU limit exceeds the remaining quota.. The ResourceQuota in namespace 'dev' has a limit of 8 CPUs for limits.cpu, with 7 already used, leaving only 1 CPU remaining. The pod's container requests a limit of 3 CPUs, which exceeds the available 1 CPU, causing the scheduler to reject the pod and leave it in Pending state. ResourceQuota enforcement occurs at admission time, and the scheduler will not schedule a pod that would cause the namespace to exceed its quota limits.

Answer

The pod's CPU request exceeds the remaining quota.

Answer

The pod's memory request is not set.

Answer

The namespace does not have a LimitRange set.

Question 11

Which TWO of the following are valid ways to consume a ConfigMap in a pod?

Accepted Answer

envFrom:
  - configMapRef:
      name: my-config. Option C is correct because `envFrom` with `configMapRef` is the standard way to expose every key in a ConfigMap as environment variables in the container, using the exact field name `configMapRef` and the ConfigMap's `name`. Option D is correct because `env` with `valueFrom.configMapKeyRef` lets you inject a single specific key (`my-key`) from the ConfigMap `my-config` into a named environment variable (`MY_VAR`), which is the canonical per-key consumption pattern. Option E is correct because mounting a ConfigMap as a volume requires the pod `volumes` entry to use `configMap.name` (not `configMapName`) and a matching `volumeMounts` entry in the container with a `mountPath`, which is exactly what E shows. Option A is not valid because `envFrom` does not accept `secretRef` for ConfigMaps — `secretRef` is used to source Secrets, not ConfigMaps. Option B is not valid because the volume source field must be `configMap.name`, not `configMap.configMapName`, so the manifest would be rejected by the API server.

Answer

envFrom:
  - secretRef:
      name: my-config

Answer

volumes:
  - name: config-vol
    configMap:
      configMapName: my-config

Question 12

Which TWO of the following are valid sources for creating a ConfigMap?

Accepted Answer

A file. Option A (a file) is correct because kubectl create configmap supports the --from-file flag, which reads a file's contents and uses the filename as the key (or a specified key), making a file a valid source. Option C (literal key-value pairs) is correct because the --from-literal flag lets you specify key-value pairs directly on the command line, such as --from-literal=key1=value1. Option B is not a valid source type; environment variables are consumed by pods via envFrom or env, not used to create a ConfigMap. Option D is not a supported source for ConfigMap creation (unlike Secrets, which support --from-env-file and directories in some workflows), and Option E is incorrect because a Secret is a separate object and cannot be used as a source to create a ConfigMap.

Answer

An environment variable file

Answer

A directory

Answer

A Secret

Question 13

A developer wants to use a ConfigMap named 'app-config' to set environment variables for a pod. The ConfigMap has keys 'DEBUG' and 'DATABASE_URL'. Which annotation should be added to the pod spec to inject all keys from the ConfigMap as environment variables?

Accepted Answer

envFrom:
  - configMapRef:
      name: app-config. The `envFrom` field in a Pod spec allows injecting all key-value pairs from a ConfigMap as environment variables into the container. By specifying `configMapRef` with the ConfigMap name, every key in the ConfigMap becomes an environment variable, which matches the requirement to inject all keys without listing them individually.

Answer

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

Answer

envFrom:
  - secretRef:
      name: app-config

Answer

env:
  - configMapRef:
      name: app-config

Question 14

An administrator wants to grant a ServiceAccount 'app-sa' in namespace 'dev' read-only access to pods in the same namespace. Which YAML snippet correctly defines the required RBAC resources?

Accepted Answer

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io. Ly defines a Role with read-only verbs (get, list, watch) on pods in the 'dev' namespace, and binds it to the ServiceAccount 'app-sa' using a RoleBinding. Since both the Role and RoleBinding are scoped to the same namespace, this grants the ServiceAccount the required read-only access to pods within that namespace.

Answer

Same as A but subjects:
- kind: Group
  name: app-sa

Answer

Same as A but subjects:
- kind: User
  name: app-sa

Answer

Same as A but RoleBinding uses kind: ClusterRole

Question 15

Which TWO of the following are valid Kubernetes Secret types? (Select two.)

Accepted Answer

kubernetes.io/ssh-auth. Option B, kubernetes.io/ssh-auth, is a valid built-in Secret type used to store SSH authentication credentials, typically the private key under the ssh-privatekey field. Option D, kubernetes.io/tls, is a valid built-in Secret type designed to hold a TLS certificate and its private key in the tls.crt and tls.key fields. Option E, Opaque, is the default Secret type for arbitrary user-defined key/value data when no specific built-in type applies. The unmarked options do not belong: kubernetes.io/password is not a defined Secret type, and kubernetes.io/configmap is not a Secret type since ConfigMaps are a separate Kubernetes resource.

Answer

kubernetes.io/password

Answer

kubernetes.io/configmap

Question 16

Which THREE capabilities are commonly dropped in a pod's securityContext to adhere to restricted pod security standards?

Accepted Answer

SYS_ADMIN. The restricted Pod Security Standard requires containers to drop all Linux capabilities and then explicitly add back only those needed, so option B (SYS_ADMIN), option C (SETUID), and option D (NET_RAW) are correct because these are exactly the dangerous capabilities the standard calls out to be dropped — SYS_ADMIN grants broad administrative operations, SETUID allows changing user/group IDs during execution, and NET_RAW permits crafting raw packets (e.g., ping, packet sniffing). The restricted profile's baseline capability set is essentially empty, meaning every capability including these three must be dropped via securityContext.capabilities.drop. Option A (ALL) is not a Linux capability name but a keyword used inside the drop list, so it is not itself a capability being dropped. Option E (CHOWN) is a valid capability but is not one of the three specifically enumerated in the restricted standard's required drop list, so it does not belong among the marked answers.

Answer

ALL

Answer

CHOWN

Question 17

Which TWO are true about LimitRange objects?

Accepted Answer

A LimitRange is enforced at container creation time.. Option A is correct because a LimitRange is evaluated by the admission controller at the moment a Pod (and its containers) is created, so any container that violates the namespace's min/max constraints is rejected at creation time. Option C is correct because a LimitRange of type Container can specify min (and max) for resources such as memory and CPU, thereby enforcing a minimum memory request for containers in that namespace. Option B is wrong because LimitRange is a namespaced object, not a cluster-wide one. Option D is wrong because default CPU limits for pods are set via a LimitRange of type Container (default/defaultRequest), and the option's phrasing about pods rather than containers is imprecise; the canonical defaulting applies to containers. Option E is wrong because limiting the total number of pods in a namespace is done with a ResourceQuota (pods count), not a LimitRange.

Answer

A LimitRange can be applied to the entire cluster.

Answer

A LimitRange can set a default CPU limit for pods.

Answer

A LimitRange can limit the total number of pods in a namespace.

Question 18

A Pod Security Admission policy is set to 'restricted' for a namespace. Which of the following pod specs is ALLOWED?

Accepted Answer

A pod with securityContext.runAsNonRoot: true and readOnlyRootFilesystem: true. The 'restricted' Pod Security Admission (PSA) policy enforces the most stringent security controls, requiring pods to meet specific baseline security constraints. Option A satisfies these requirements by setting `runAsNonRoot: true` (preventing root execution) and `readOnlyRootFilesystem: true` (preventing writes to the root filesystem), both of which are mandatory for the restricted profile. The other options violate the restricted policy by either enabling privileged access, adding dangerous capabilities, or omitting required security contexts.

Answer

A pod with securityContext.capabilities.add: ["NET_ADMIN"]

Answer

A pod with no securityContext specified

Answer

A pod with securityContext.privileged: true

Question 19

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. Option A is correct because Kubernetes Secrets can be consumed by a Pod either by mounting them as a volume (via a secret volume in the pod spec) or by exposing individual keys as environment variables (using env.valueFrom.secretKeyRef or envFrom.secretRef). Option C is correct because Secret values in a YAML manifest are base64-encoded (for example, in the data field), but by default etcd stores the Secret object unencrypted at rest unless encryption at rest is explicitly configured for the API server. Option E is correct because Secrets are namespaced objects, so a Pod can only reference a Secret that exists in the same namespace as the Pod. Option B is not correct because Secrets are not always encrypted in etcd; encryption at rest is an optional API server configuration and is not enabled by default. Option D is not correct because the 1 MiB size limit applies to ConfigMaps and Secrets alike, but the statement as written is not one of the marked correct answers and the question asks for the two correct statements.

Answer

Secrets are always encrypted in etcd

Answer

The maximum size of a Secret is 1 MB

Question 20

A pod is in 'CrashLoopBackOff' state. 'kubectl logs pod' shows: 'Error: listen tcp :8080: bind: permission denied'. The container runs as user '1000'. Which securityContext setting is missing?

Accepted Answer

runAsUser: 0 (root). In Linux, non-root users can bind to ports >1024 without special capabilities. If the port were <1024, the correct setting would be capabilities.add: ['NET_BIND_SERVICE']. Running as root (runAsUser: 0) is not the recommended fix and would not be a 'missing' securityContext setting. The scenario as written is invalid.

Answer

readOnlyRootFilesystem: false

Answer

capabilities.add: ["NET_BIND_SERVICE"]

Answer

seccompProfile: type: RuntimeDefault