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

Question 1

Which TWO of the following are valid fields in a container's SecurityContext to restrict privilege escalation? (Select two.)

Accepted Answer

allowPrivilegeEscalation. Option A, allowPrivilegeEscalation, is correct because it is a SecurityContext field that directly controls whether a process can gain more privileges than its parent (e.g., via setuid binaries or file capabilities); setting it to false blocks privilege escalation. Option E, capabilities, is correct because the capabilities field in SecurityContext lets you add or drop Linux capabilities (e.g., drop: ["ALL"]), which restricts the privileges a container process can acquire and is a core mechanism for limiting escalation. Option B, readOnlyRootFilesystem, is a valid SecurityContext field but it only makes the root filesystem read-only; it does not by itself restrict privilege escalation. Option C, runAsNonRoot, is a valid SecurityContext field that enforces running as a non-root UID, but it is an identity constraint rather than a privilege-escalation control. Option D, privileged, is a valid SecurityContext field, but setting it to true grants full privileges and thus enables escalation rather than restricting it.

Answer

readOnlyRootFilesystem

Answer

runAsNonRoot

Answer

privileged

Question 2

Which flag in a kubectl run command sets environment variables from a ConfigMap?

Accepted Answer

--env-from. `kubectl run` supports the `--env-from` flag to inject environment variables from a ConfigMap (or Secret) into a pod. This flag allows you to specify a ConfigMap name, and Kubernetes will populate the container's environment with all key-value pairs from that ConfigMap, which is the intended mechanism for bulk environment variable injection.

Answer

--env

Answer

--configmap

Answer

--from-env-config

Question 3

A pod has 'automountServiceAccountToken: false' in its spec. What is the effect?

Accepted Answer

The pod will not have the service account token mounted.. Setting `automountServiceAccountToken: false` in a Pod spec prevents the automatic injection and mounting of the service account token into the Pod's containers. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token` for API authentication; disabling this option means the token is not mounted, but the Pod can still use a service account if the token is explicitly mounted via a volume or if the Pod does not need API access.

Answer

The pod cannot use any service account.

Answer

The pod will use a different service account.

Answer

The pod will be unable to start.

Question 4

Which THREE of the following fields are part of a Pod's securityContext that can restrict container capabilities? (Choose three.)

Accepted Answer

capabilities.drop. Option A, capabilities.drop, is correct because it is a field within a container's securityContext that removes specific Linux capabilities (e.g., NET_RAW, SYS_ADMIN) from the container, thereby restricting what privileged operations it can perform. Option C, allowPrivilegeEscalation, is correct because setting it to false prevents a process from gaining more privileges than its parent (blocking setuid/setgid escalation), directly restricting capability-based privilege gains. Option D, capabilities.add, is correct because it is the counterpart field in the same capabilities block that explicitly adds Linux capabilities to a container, and thus is part of the securityContext mechanism that governs (and can restrict or grant) container capabilities. Option B, seccompProfile, is not among the marked answers because although it is a securityContext field, it restricts system calls rather than Linux capabilities. Option E, runAsUser, is not marked because it sets the UID for the container process and does not itself restrict capabilities.

Answer

seccompProfile

Answer

runAsUser

Question 5

Which THREE of the following are true about ServiceAccount token automounting? (Choose three.)

Accepted Answer

The token is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. Option A is correct because when a ServiceAccount token is automounted, the kubelet projects it into the container filesystem at the well-known path /var/run/secrets/kubernetes.io/serviceaccount/token (alongside ca.crt and namespace). Option B is correct because the ServiceAccount object itself supports the automountServiceAccountToken field, and setting it to false disables automounting for all Pods that use that ServiceAccount unless overridden at the Pod level. Option C is correct because automountServiceAccountToken can also be set in the Pod spec, where false disables automounting only for that specific Pod, taking precedence over the ServiceAccount setting. Option D is not correct because the legacy automounted token is not automatically refreshed by the kubelet; it is a static token valid until expiry or rotation of the underlying secret, whereas projected tokens (a different mechanism) are refreshed. Option E is not correct as stated because automounting depends on the ServiceAccount and Pod settings and is not unconditionally applied to every Pod; the default ServiceAccount is used only when no ServiceAccount is specified, and automounting can be disabled.

Answer

The token is automatically refreshed by the kubelet.

Answer

By default, Kubernetes automounts the default ServiceAccount token into every Pod.

Question 6

Which TWO of the following commands create a ConfigMap named 'my-config' from a file named 'app.properties'? (Choose two.)

Accepted Answer

kubectl create configmap my-config --from-file=app.properties=app.properties. Option B is correct because `kubectl create configmap my-config --from-file=app.properties=app.properties` explicitly maps the key `app.properties` to the file `app.properties`, creating the ConfigMap with that file's contents. Option C is correct because `--from-env-file=app.properties` reads the file as a set of `key=value` environment-style entries and creates the ConfigMap from those keys and values. Option E is correct because `--from-file=app.properties` uses the filename as the key and the file contents as the value, which creates the ConfigMap named `my-config` from that file. Option A is not among the marked correct answers because it adds an extra literal key, so it does not simply create the ConfigMap from the file as requested. Option D is incorrect because `--from-literal=app.properties` expects a literal `key=value` pair, not a filename, and would fail or create an invalid entry.

Answer

kubectl create configmap my-config --from-file=app.properties --from-literal=extra=value

Answer

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

Question 7

Which THREE of the following are valid fields in a LimitRange resource to enforce resource constraints at the container level? (Choose three.)

Accepted Answer

min. In a Kubernetes LimitRange, the container-level constraint fields are min, max, default, defaultRequest, and maxLimitRequestRatio, so options A, B, and D are valid. Option A (min) sets the minimum CPU/memory a container may request or limit, enforcing a floor at the container level. Option B (defaultRequest) specifies the default resource request applied to a container when none is declared, which is a container-level field. Option D (maxLimitRequestRatio) enforces the maximum allowed ratio between a container's limit and its request, capping overcommit at the container level. Option C (default) is not a valid LimitRange field name; the actual field for default limits is default, but as written it is not among the container-level fields being asked for, and the correct default-limit field is default (not defaultLimit), so it does not belong here.

Answer

default

Question 8

An administrator wants to implement Pod Security Admission (PSA) to enforce the 'restricted' policy for pods in the 'secure' namespace, but allow certain pods to use privileged containers by applying an exemption label. Which three steps are required? (Choose three.)

Accepted Answer

Use 'pod-security.kubernetes.io/audit=restricted' to log violations without enforcement.. Setting the audit label to 'restricted' logs violations, which is a common initial step to assess compliance before enforcing the policy. Option C is correct because creating a ServiceAccount and labeling it with 'pod-security.kubernetes.io/enforce=privileged' exempts pods using that ServiceAccount from the restricted policy, allowing them to run privileged containers. Option E is correct because setting the namespace label 'pod-security.kubernetes.io/enforce=restricted' enforces the restricted policy on all pods in that namespace that are not exempted. Option B is not required because the PodSecurity feature gate is enabled by default in Kubernetes v1.23+. Option D is incorrect because PSA uses security context validation, not a custom runtime.

Answer

Enable the PodSecurity feature gate on the API server and kubelet.

Answer

Install a custom container runtime that supports privilege escalation.

Question 9

Which two fields can be used in a SecurityContext to control a container's access to the host filesystem? (Choose two.)

Accepted Answer

capabilities. Option B (capabilities) is correct because the SecurityContext capabilities field lets you add or drop Linux capabilities (e.g., drop CAP_SYS_ADMIN or CAP_DAC_OVERRIDE), which directly governs what filesystem operations a container process may perform on host-mounted paths. Option C (readOnlyRootFilesystem) is correct because setting it to true mounts the container's root filesystem read-only, preventing writes to the host filesystem through that mount and enforcing filesystem access control. Option A (runAsUser) is not correct here because it only sets the UID for the process and does not by itself control host filesystem access. Option D (allowPrivilegeEscalation) is not correct because it only controls whether a process can gain more privileges (e.g., via setuid), not filesystem access directly. Option E (runAsGroup) is not correct because it only sets the primary GID and does not directly govern host filesystem access.

Answer

runAsUser

Answer

allowPrivilegeEscalation

Answer

runAsGroup

Question 10

A pod named 'web-app' is running but has no environment variables. The developer wants to inject a variable 'DB_URL=postgres://db:5432' from a ConfigMap named 'db-config'. Which pod spec snippet correctly achieves this?

Accepted Answer

env:
- name: DB_URL
  valueFrom:
    configMapKeyRef:
      name: db-config
      key: DB_URL. It uses the `configMapKeyRef` field under `valueFrom` to inject a specific key from a ConfigMap as an environment variable. This allows the pod to consume the `DB_URL` value from the `db-config` ConfigMap without exposing it as a file or using `envFrom`.

Answer

env:
- name: DB_URL
  value: "postgres://db:5432"

Answer

envFrom:
- configMapRef:
    name: db-config
    key: DB_URL

Answer

env:
- name: DB_URL
  valueFrom:
    secretKeyRef:
      name: db-config
      key: DB_URL

Question 11

A deployment runs a container that needs to read a file from a host path '/var/log/app' on the node. The file must be available to all pods on that node. Which volume type should be used?

Accepted Answer

hostPath. B is correct because hostPath mounts a file or directory from the host node's filesystem into the pod, making it available to all pods scheduled on that node. This is the only volume type that directly accesses a specific host path like '/var/log/app', ensuring the file is shared across all pods on the same node.

Answer

emptyDir

Answer

persistentVolumeClaim

Answer

configMap

Question 12

A developer wants to restrict network traffic so that only pods with label 'app: frontend' can communicate with pods labeled 'app: backend' on port 8080. Which Kubernetes resource should be used?

Accepted Answer

NetworkPolicy. A NetworkPolicy is the correct Kubernetes resource because it defines ingress and egress rules to control pod-to-pod communication based on labels, namespaces, and ports. By specifying a podSelector matching 'app: backend', an ingress rule allowing traffic from pods with label 'app: frontend' on port 8080, and a policyTypes field including 'Ingress', this resource enforces the desired restriction at the network layer using iptables or eBPF under the hood.

Answer

ResourceQuota

Answer

PodSecurityPolicy

Answer

RoleBinding

Question 13

A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?

Accepted Answer

runAsUser: 1000. `runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.

Answer

runAsNonRoot: true

Answer

fsGroup: 1000

Answer

privileged: false

Question 14

Which TWO of the following are valid ways to mount a Secret into a pod as environment variables? (Select exactly 2)

Accepted Answer

env:
- name: SECRET_KEY
  valueFrom:
    secretKeyRef:
      name: my-secret
      key: key. `secretKeyRef` is the standard Kubernetes API field for referencing a specific key from a Secret object and injecting its value as an environment variable. Option E is correct because `envFrom` with `secretRef` allows you to load all key-value pairs from a Secret as environment variables into the pod, which is a valid and common pattern.

Answer

env:
- name: SECRET_KEY
  valueFrom:
    configMapKeyRef:
      name: my-secret
      key: key

Answer

env:
- name: SECRET_KEY
  valueFrom:
    secretEnvRef:
      name: my-secret
      key: key

Answer

envFrom:
- configMapRef:
    name: my-secret

Question 15

Which THREE of the following are valid fields in a PodSecurityPolicy (PSP) that control Linux capabilities? (Select exactly 3)

Accepted Answer

defaultAddCapabilities. `defaultAddCapabilities` is a valid field in a PodSecurityPolicy (PSP) that specifies a list of Linux capabilities to be added to containers by default, even if not explicitly requested in the container's security context. This field is part of the PSP's capabilities control mechanism, as defined in the Kubernetes PodSecurityPolicy spec.

Answer

privileged

Answer

readOnlyRootFilesystem