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

Question 1

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

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

Accepted Answer

Secrets store data in base64-encoded form, while ConfigMaps store plaintext. Option A is correct because 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 3

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

Question 4

Which two commands can create a ConfigMap from an environment file? (Select TWO.)

Accepted Answer

kubectl create configmap my-config --from-env-file=app.env. Option B is correct because `--from-env-file=app.env` is the dedicated flag for creating a ConfigMap from an environment file, where each line in the file is parsed as a key=value pair. Option C is also correct because `--from-file=app.env` creates a ConfigMap with the file's entire contents stored under the filename as the key, which is a valid method even though it does not parse the file as environment variables.

Answer

kubectl create configmap my-config --from-literal=app.env

Answer

kubectl create configmap my-config --from-file=key1=app.env

Answer

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

Question 5

Which kubectl command creates a ConfigMap named 'app-config' from a file 'config.properties'?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. Option A is correct because `kubectl create configmap` with the `--from-file` flag creates a ConfigMap from a file, using the filename as the key and the file content as the value. This is the standard Kubernetes method to import configuration data from a local file into a ConfigMap resource.

Answer

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

Answer

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

Answer

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

Question 6

A pod needs to mount a Secret named 'db-secret' as a volume at /etc/secret. Which volume mount definition is correct?

Accepted Answer

volumes:
- name: secret-volume
  secret:
    secretName: db-secret. Option A is correct because it uses the proper `secret` key under the `volumes` field to reference a Secret object by its `secretName`. When this volume is mounted at `/etc/secret`, Kubernetes automatically creates a file for each key in the Secret, with the file content being the decoded value of the key. This is the standard syntax for mounting a Secret as a volume.

Answer

volumes:
- name: secret-volume
  secretVolumeSource:
    secretName: db-secret

Answer

volumes:
- name: db-secret
  secret:
    secretName: db-secret

Answer

volumes:
- name: secret-volume
  secret:
    name: db-secret

Question 7

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. Option C is correct because setting `securityContext.runAsUser: 0` overrides the pod's user ID (1000) for this specific container, making it run as root (UID 0). This allows the binary that expects root privileges to execute without changing the pod-level security context or granting unnecessary capabilities.

Answer

Add the SYS_ADMIN capability under securityContext.capabilities.add

Answer

Set securityContext.privileged: true

Answer

Set securityContext.allowPrivilegeEscalation: true

Question 8

You create a Role named 'pod-reader' in the 'default' namespace with rules to get, list, and watch pods. A ServiceAccount 'app-sa' in the same namespace needs to be bound to this role. Which YAML snippet correctly creates the RoleBinding?

Accepted Answer

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
  apiGroup: ''
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io. Option B is correct because it creates a RoleBinding in the 'default' namespace that binds the ServiceAccount 'app-sa' to the Role 'pod-reader' using the correct 'kind: Role' in the roleRef. The RoleBinding must reference a Role (not a ClusterRole) when the Role exists in the same namespace, and the apiGroup for the roleRef must be 'rbac.authorization.k8s.io'.

Answer

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Answer

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Answer

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Question 9

You want to restrict total memory usage in a namespace to 10 Gi. Which resource should you create?

Accepted Answer

ResourceQuota. A ResourceQuota is the correct Kubernetes object to enforce aggregate resource consumption limits at the namespace level. By defining a ResourceQuota with `spec.hard.memory: 10Gi`, you restrict the total memory requested and used by all pods in that namespace to 10 GiB. This directly meets the requirement to limit total memory usage.

Answer

PodDisruptionBudget

Answer

LimitRange

Answer

NetworkPolicy

Question 10

A pod uses a ServiceAccount with automountServiceAccountToken set to false. The pod still needs to access the Kubernetes API. How can you mount the service account token in this pod?

Accepted Answer

Set automountServiceAccountToken: true in the pod spec. Option A is correct because setting `automountServiceAccountToken: true` in the pod spec overrides the ServiceAccount-level setting of `false`. This allows the pod to mount the service account token automatically, enabling it to authenticate to the Kubernetes API without manual intervention.

Answer

Create a secret with the token and mount it manually

Answer

Use a ConfigMap to store the token

Answer

Set serviceAccountName: default and automountServiceAccountToken: true in the pod spec

Question 11

You want to enforce that all pods in a namespace run with the 'restricted' Pod Security Standard (Pod Security Admission). Which label should you set on the namespace?

Accepted Answer

pod-security.kubernetes.io/enforce=restricted. Option C is correct because the `pod-security.kubernetes.io/enforce=restricted` label enforces the 'restricted' Pod Security Standard on the namespace, preventing any pod that violates the restricted policy from being created. This label directly activates Pod Security Admission (PSA) enforcement mode, which blocks non-compliant pods at admission time.

Answer

pod-security.kubernetes.io/warn=restricted

Answer

pod-security.kubernetes.io/enforce=baseline

Answer

pod-security.kubernetes.io/audit=restricted

Question 12

A pod's container has securityContext with runAsNonRoot: true but no runAsUser set. The container image has a user 'appuser' with UID 1001. Will the pod run successfully?

Accepted Answer

Yes, because the container image user is non-root. Option D is correct because when `runAsNonRoot: true` is set in the pod's security context without an explicit `runAsUser`, Kubernetes checks the container image's user (as defined in the Dockerfile `USER` directive). If that user is non-root (UID 1001 in this case), the container runs as that user, satisfying the non-root requirement. The pod will start successfully because the image user is non-root, and no explicit `runAsUser` is required.

Answer

No, because runAsNonRoot requires an explicit runAsUser

Answer

No, because the container image user is unknown

Answer

Yes, because runAsNonRoot is ignored if runAsUser is not set

Question 13

Which command creates an Opaque Secret named 'my-secret' with key 'password' and value 'p@ssw0rd'?

Accepted Answer

kubectl create secret generic my-secret --from-literal=password=p@ssw0rd. Option D is correct because `kubectl create secret generic` creates an Opaque secret, and the `--from-literal=key=value` syntax correctly assigns the literal value 'p@ssw0rd' to the key 'password'. This produces a secret with the specified key-value pair.

Answer

kubectl create secret tls my-secret --cert=cert.pem --key=key.pem

Answer

kubectl create secret generic my-secret --from-literal=password

Answer

kubectl create secret generic my-secret --from-literal=p@ssw0rd=password

Question 14

You deploy a pod with resource requests: cpu: 500m, memory: 256Mi and limits: cpu: 1, memory: 512Mi. The container tries to allocate 600Mi of memory. What happens?

Accepted Answer

The container is OOMKilled because it exceeds the memory limit. The correct answer is A because the container's memory allocation of 600Mi exceeds its configured memory limit of 512Mi. Kubernetes enforces memory limits using the cgroup memory controller; when a container attempts to allocate more memory than its limit, the kernel's Out-Of-Memory (OOM) killer terminates the container process. This results in the container being OOMKilled, as recorded in the pod status.

Answer

The container runs normally, but memory usage is throttled

Answer

The container runs normally because requests are the only constraints

Answer

The container is evicted from the node

Question 15

A pod has securityContext with capabilities.add: ['NET_ADMIN'] and capabilities.drop: ['ALL']. What effective capabilities does the container have?

Accepted Answer

Only NET_ADMIN. Option C is correct because when a container's securityContext specifies both `capabilities.drop: ['ALL']` and `capabilities.add: ['NET_ADMIN']`, the `drop: ['ALL']` first removes all capabilities, and then `add: ['NET_ADMIN']` adds back only the NET_ADMIN capability. The final effective set is exactly `[NET_ADMIN]`. This is the intended Kubernetes behavior: `drop` is processed before `add` within the same container spec.

Answer

No capabilities

Answer

All capabilities

Answer

All capabilities except NET_ADMIN