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

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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

Question 9

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 10

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 11

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 12

A developer needs to create a Kubernetes Secret for Docker registry authentication. The registry URL is 'myregistry.io', username 'user', password 'pass', email 'user@example.com'. Which command creates this Secret?

Accepted Answer

kubectl create secret docker-registry regcred --docker-server=myregistry.io --docker-username=user --docker-password=pass --docker-email=user@example.com. `kubectl create secret docker-registry` is the dedicated command for creating a Docker registry authentication secret, which automatically encodes the provided credentials into a `.dockerconfigjson` format. This secret type is specifically designed for pulling images from private registries, and the flags `--docker-server`, `--docker-username`, `--docker-password`, and `--docker-email` match the required fields for registry authentication.

Answer

kubectl create secret tls regcred --cert=cert --key=key

Answer

kubectl create secret generic regcred --from-literal=username=user --from-literal=password=pass

Answer

kubectl create secret registry regcred --server=myregistry.io --username=user --password=pass

Question 13

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 14

Which two statements about ConfigMaps and Secrets are correct? (Select TWO.)

Accepted Answer

Secrets store data in base64-encoded form, while ConfigMaps store plaintext. Secrets store data as base64-encoded strings, which is not encryption but a simple encoding that obscures the data. ConfigMaps store data in plaintext (UTF-8) without any encoding. This distinction is fundamental: base64 encoding is reversible and provides no security, while plaintext is human-readable.

Answer

ConfigMaps are immutable and cannot be updated after creation

Answer

ConfigMaps are suitable for storing sensitive data like passwords

Answer

Secrets are encrypted at rest by default in Kubernetes

Question 15

Which three security contexts can be set at the pod level (as opposed to container level)? (Select THREE.)

Accepted Answer

fsGroup. B is correct because `fsGroup` is a Pod-level security context field that applies a supplemental group ID to all containers in the Pod, ensuring that volumes mounted with that group ownership are accessible. It is set under `spec.securityContext.fsGroup`, not at the container level, making it a Pod-scoped setting.

Answer

readOnlyRootFilesystem

Answer

capabilities