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

Question 1

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 2

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 3

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 4

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 5

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

Question 6

A ConfigMap named 'env-config' has keys 'DB_HOST' and 'DB_PORT'. A pod needs to set the environment variable 'DATABASE_HOST' to the value of 'DB_HOST' from the ConfigMap, and 'DB_PORT' directly as 'DB_PORT'. Which YAML snippet correctly achieves this?

Accepted Answer

env:
- name: DATABASE_HOST
  valueFrom:
    configMapKeyRef:
      name: env-config
      key: DB_HOST
envFrom:
- configMapRef:
    name: env-config. For 'DATABASE_HOST', it uses valueFrom with configMapKeyRef mapping key 'DB_HOST' to the env var. For 'DB_PORT', it uses envFrom with configMapRef to load all keys. Option A uses envFrom for both, but that would not rename 'DB_HOST'. Option C uses envFrom for DATABASE_HOST, which won't rename. Option D uses env with configMapKeyRef for DB_PORT, but then envFrom overrides it? Actually, order matters: envFrom is processed after env, so env would be overwritten. But the correct approach is to use env for the renamed variable and envFrom for the rest.

Answer

env:
- name: DB_PORT
  valueFrom:
    configMapKeyRef:
      name: env-config
      key: DB_PORT
envFrom:
- configMapRef:
    name: env-config

Answer

envFrom:
- configMapRef:
    name: env-config
env:
- name: DATABASE_HOST
  value: DB_HOST

Answer

envFrom:
- configMapRef:
    name: env-config
  prefix: DATABASE_

Question 7

A LimitRange in namespace 'limits' sets default memory request to 256Mi and default memory limit to 512Mi. A pod is created without specifying any resources. What are the pod's effective memory request and limit?

Accepted Answer

request: 256Mi, limit: 512Mi. When a LimitRange exists in a namespace, it automatically applies default resource requests and limits to any pod that does not specify them. In this case, the LimitRange sets the default memory request to 256Mi and the default memory limit to 512Mi, so the pod inherits those values. This ensures the pod has a guaranteed QoS class (Guaranteed) because request equals limit, but only if both are set; here they differ, so the pod will be Burstable.

Answer

request: 512Mi, limit: 256Mi

Answer

No request or limit; the pod will be scheduled with best-effort QoS

Answer

request: 0, limit: unlimited

Question 8

A pod is running with 'securityContext: { runAsUser: 1000, fsGroup: 2000, runAsNonRoot: true }'. The container image has USER root set in Dockerfile. What happens when the pod is created?

Accepted Answer

The pod runs successfully as user 1000 with group 2000. The pod's securityContext settings override the USER directive in the container image. The runAsUser: 1000 sets the container process to run as user 1000, and fsGroup: 2000 sets the group ownership of any mounted volumes to group 2000. The runAsNonRoot: true ensures the container does not run as root, but since the securityContext explicitly sets a non-root user, the check passes and the pod runs successfully.

Answer

The pod runs as user 1000 but group remains root

Answer

The pod runs as root because the image's USER directive takes precedence

Answer

The pod fails with 'container has runAsNonRoot and image will run as root'

Question 9

A pod runs as user ID 1000. The container image includes a binary that expects to run as root. Which SecurityContext setting can allow the binary to run with root-like privileges while still running the container as non-root?

Accepted Answer

Set securityContext.runAsUser: 0. Setting securityContext.runAsUser:0 overrides the container-level user ID (1000) to 0, running the container as root. This allows the binary to execute with root privileges. The pod-level security context remains unchanged, so other containers can still run as UID 1000. It does not use privileged mode or add capabilities.

Answer

Add the SYS_ADMIN capability under securityContext.capabilities.add

Answer

Set securityContext.privileged: true

Answer

Set securityContext.allowPrivilegeEscalation: true

Question 10

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

Accepted Answer

Mounting the ConfigMap as a volume. Option A is correct because a ConfigMap can be consumed by mounting it as a volume, which projects each key as a file in the mounted directory inside the container. Option B is correct because env.valueFrom.configMapKeyRef lets you inject a single specific key from a ConfigMap as an environment variable. Option E is correct because envFrom.configMapRef exposes all keys of a ConfigMap as environment variables in the container at once. Option C is not valid because configMapRef belongs under envFrom, not under env.valueFrom, which requires configMapKeyRef. Option D is not valid because secretKeyRef references a Secret, not a ConfigMap, so it does not consume a ConfigMap.

Answer

Using configMapRef in env.valueFrom

Answer

Using secretKeyRef in env.valueFrom

Question 11

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' is the proper subcommand for creating an Opaque secret, and the repeated '--from-literal=key=value' flags correctly define the 'username' and 'password' keys with their values. Option D is correct because piping a YAML manifest that declares 'kind: Secret' with 'stringData' (or base64-encoded 'data') containing the 'username' and 'password' keys into 'kubectl apply -f -' creates the same named Secret declaratively. Option B is wrong because '--from-file=username=admin' treats 'admin' as a filename to read from disk, not a literal value, so it would fail unless such a file exists. Option C is wrong because 'opaque' is not a valid 'kubectl create secret' subcommand (the valid types are generic, docker-registry, tls, and a few others), and it also omits the 'password' key. Option E is wrong because 'kubectl create secret tls' creates a kubernetes.io/tls secret from certificate and key files, not a generic secret with 'username' and 'password' keys.

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 12

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 13

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 14

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 15

Which TWO of the following are valid ways to create a ConfigMap from a file named 'app.properties'? (Select two.)

Accepted Answer

kubectl create configmap app-config --from-file=app.properties. Option A is correct because `kubectl create configmap app-config --from-file=app.properties` uses the `--from-file` flag with a single file path, which creates a ConfigMap where the key defaults to the file's basename (`app.properties`) and the value is the file's contents. Option E is correct because `--from-env-file=app.properties` reads a file in `KEY=value` format and creates one ConfigMap entry per line, which is a valid way to build a ConfigMap from a properties file. Option B is wrong because `--from-literal` expects an inline `key=value` pair, not a filename, so `--from-literal=app.properties` would fail or create a malformed entry. Option C is wrong because `--from-env` is not a valid kubectl flag for ConfigMap creation. Option D is technically redundant/incorrect here since `--from-file=app.properties=app.properties` maps a key to a file, but the question asks for valid ways to create a ConfigMap from the file, and the standard single-argument form in A is the intended correct usage.

Answer

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

Answer

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

Answer

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