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

Question 1

A security requirement states that a container must run with a read-only root filesystem. Which field must be set in the container's securityContext?

Accepted Answer

readOnlyRootFilesystem: true. Setting `readOnlyRootFilesystem: true` in the container's `securityContext` enforces that the container's root filesystem is mounted as read-only, preventing any writes to the filesystem at the root level. This satisfies the security requirement by ensuring that even if a process is compromised, it cannot modify system binaries, configuration files, or other critical files within the container's root filesystem.

Answer

runAsUser: 1000

Answer

capabilities:
  drop: ["ALL"]

Answer

allowPrivilegeEscalation: false

Question 2

A pod needs to run as a non-root user. Which securityContext field should be set to enforce this?

Accepted Answer

runAsNonRoot: true. Setting `runAsNonRoot: true` in the pod's securityContext explicitly enforces that the container must not run as the root user (UID 0). If the container image attempts to run as root, the Pod will fail to start, ensuring compliance with non-root security policies.

Answer

runAsGroup: 3000

Answer

runAsUser: 1000

Answer

readOnlyRootFilesystem: true

Question 3

A developer creates a ServiceAccount 'my-sa' in namespace 'default'. They want to prevent pods from automatically mounting the ServiceAccount token. Which field should be set to false in the pod spec?

Accepted Answer

automountServiceAccountToken: false. Setting `automountServiceAccountToken: false` in the pod spec explicitly prevents the automatic mounting of the ServiceAccount token into the pod. This is the standard Kubernetes field for controlling token mounting at the pod level, overriding the default behavior where the token is mounted automatically.

Answer

serviceAccountName: my-sa

Answer

serviceAccountName: my-sa
  automountServiceAccountToken: false

Answer

containers:
  - automountServiceAccountToken: false

Question 4

A pod is stuck in Pending state. You run 'kubectl describe pod mypod' and see the event: '0/3 nodes are available: 1 Insufficient memory, 2 Insufficient cpu'. The pod has resource requests defined. Which action would allow the pod to be scheduled?

Accepted Answer

Decrease the memory and CPU requests to fit within available node resources. The pod is unschedulable because the cluster's three nodes collectively lack sufficient CPU and memory to satisfy the pod's resource requests. Decreasing the memory and CPU requests to fit within the available node resources (option C) directly resolves the scheduling failure by making the pod's resource demands compatible with the remaining capacity on at least one node.

Answer

Increase the resource requests for the container

Answer

Delete the pod and recreate it with the same spec

Answer

Decrease the CPU request but keep the memory request the same

Question 5

Which of the following is a valid Pod Security Admission standard?

Accepted Answer

Restricted. The Pod Security Admission (PSA) standard defines three levels: Privileged, Baseline, and Restricted. Option C is correct because 'Restricted' is one of the three valid standards, designed to enforce the most restrictive pod security policies.

Answer

Privileged, Default

Answer

Default

Answer

Secure

Question 6

A namespace 'test' has a LimitRange that sets default memory request to 256Mi and default memory limit to 512Mi. A pod in that namespace does not specify any resources. What memory request and limit will the pod get?

Accepted Answer

request: 256Mi, limit: 512Mi. When a LimitRange exists in a namespace with default memory request and limit values, any pod that does not specify resource requests or limits will automatically have those defaults injected by the admission controller. This ensures the pod is subject to resource constraints even without explicit specification.

Answer

request: 0, limit: 0 (none)

Answer

request: 512Mi, limit: 256Mi

Answer

request: 256Mi, limit: 256Mi

Question 7

A cluster administrator wants to enforce that no pod in namespace 'prod' uses more than 4Gi of memory. Which Kubernetes resource should be created?

Accepted Answer

LimitRange. A LimitRange resource in the 'prod' namespace can set a default memory limit and a maximum memory limit per container or pod, enforcing that no pod exceeds 4Gi of memory. This is the appropriate Kubernetes primitive for per-pod resource constraints within a namespace, as it applies to all pods that do not specify their own limits.

Answer

PodDisruptionBudget

Answer

NetworkPolicy

Answer

ResourceQuota

Question 8

A container needs to run with the NET_ADMIN capability. Which securityContext field should be used?

Accepted Answer

capabilities:
  add: ["NET_ADMIN"]. The `capabilities.add` field in a container's `securityContext` is specifically designed to grant Linux capabilities like `NET_ADMIN` to a container. This allows the container to perform network administration operations (e.g., configuring iptables, changing interface settings) without running as root or giving full privileged access.

Answer

capabilities:
  drop: ["ALL"]

Answer

runAsUser: 0

Answer

readOnlyRootFilesystem: true

Question 9

Which TWO of the following are valid ways to expose a Secret as an environment variable in a pod? (Select two.)

Accepted Answer

envFrom:
  - secretRef:
      name: db-secret. `envFrom` with a `secretRef` allows all key-value pairs from a Secret to be injected as environment variables into a container. This is a concise method to expose multiple secret entries without specifying each one individually.

Answer

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

Answer

env:
  - secretRef:
      name: db-secret

Answer

envFrom:
  - configMapRef:
      name: db-secret

Question 10

Which THREE of the following are valid fields in a SecurityContext at the container level? (Select three.)

Accepted Answer

runAsUser. The correct three options are B, C, and D. Option B (runAsUser) sets the user ID for container processes and is valid at container level. Option C (readOnlyRootFilesystem) mounts the root filesystem as read-only. Option D (capabilities) manages Linux capabilities. Option A (fsGroup) is a Pod-level SecurityContext field, not container-level. Option E (sysctls) is also a Pod-level field and cannot be set at the container level. Therefore, B, C, and D are the valid container-level fields.

Answer

fsGroup

Answer

sysctls

Question 11

You have a ConfigMap named 'app-config' with key 'database.url'. Which environment variable definition correctly injects this value into a pod using a configMapKeyRef?

Accepted Answer

- name: DATABASE_URL
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: database.url. It properly defines an environment variable with a name and uses `valueFrom.configMapKeyRef` to reference the specific key 'database.url' from the ConfigMap 'app-config'. The `name` field is required in the env entry to specify the environment variable name. Option D is incorrect because it omits the `name` field, making the definition incomplete.

Answer

envFrom:
- configMapRef:
    name: app-config

Answer

- name: DATABASE_URL
  valueFrom:
    secretKeyRef:
      name: app-config
      key: database.url

Answer

- valueFrom:
    configMapKeyRef:
      name: app-config
      key: database.url

Question 12

Which kubectl command creates a Secret from literal username and password values?

Accepted Answer

kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret123. `kubectl create secret generic` with `--from-literal` is the proper syntax for specifying literal key-value pairs directly in the command. Each literal must be prefixed with `--from-literal=key=value`, and multiple literals can be provided to create a Secret containing both the username and password keys.

Answer

kubectl create secret generic my-secret --literal username=admin password=secret123

Answer

kubectl create secret generic my-secret --from-file=username --from-file=password

Answer

kubectl create secret generic my-secret --from-env-file=creds.txt

Question 13

A pod's container needs to run as non-root user with UID 1000 and ensure its filesystem is read-only. Which SecurityContext settings achieve this?

Accepted Answer

spec:
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
  containers:
  - name: app
    securityContext:
      readOnlyRootFilesystem: true. Ly sets runAsUser and runAsNonRoot at the pod level to enforce non-root execution with UID 1000, and readOnlyRootFilesystem at the container level, which is the correct placement for that field. The other options either use invalid fields (runAsRoot), omit runAsNonRoot, or incorrectly place readOnlyRootFilesystem at the pod level.

Answer

securityContext:
  runAsNonRoot: true
  runAsRoot: false
  readOnlyRootFilesystem: true

Answer

securityContext:
  runAsGroup: 1000
  readOnlyRootFilesystem: true

Answer

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true

Question 14

You have a service account 'my-sa' in the default namespace. You want a pod to use this service account and also prevent the pod from mounting the service account token. Which pod spec configuration is correct?

Accepted Answer

spec:
  serviceAccountName: my-sa
  automountServiceAccountToken: false. Setting `automountServiceAccountToken: false` in the pod spec prevents the automatic mounting of the service account token, while `serviceAccountName: my-sa` specifies the desired service account. This satisfies both requirements: using the custom service account and disabling token mounting.

Answer

spec:
  serviceAccountName: my-sa
  automountServiceAccountToken: true

Answer

spec:
  serviceAccount: my-sa
  automountServiceAccountToken: true

Answer

spec:
  serviceAccountName: default
  automountServiceAccountToken: false

Question 15

A developer creates a Role and RoleBinding in the namespace 'development' to grant list pods permission to a service account. Which manifest snippet correctly defines the Role?

Accepted Answer

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list"]. Pods belong to the core API group, which is represented by an empty string `""` in the `apiGroups` field. The `list` verb is sufficient to list pods, and the `resources` field correctly specifies `pods`. This Role grants the service account permission to list pods in the `development` namespace.

Answer

rules:
- apiGroups: ["pods"]
  resources: ["pods"]
  verbs: ["get", "list"]

Answer

rules:
- apiGroups: ["apps"]
  resources: ["pods"]
  verbs: ["list"]

Answer

rules:
- apiGroups: ["*"]
  resources: ["pods"]
  verbs: ["list"]