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

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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 2

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 3

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 4

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 5

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 6

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 7

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"]

Question 8

You apply a ResourceQuota to a namespace that limits memory requests to 2Gi. You then try to create a pod that requests 3Gi memory. What happens?

Accepted Answer

The pod creation fails with an error message indicating the quota would be exceeded.. When a ResourceQuota is applied to a namespace with a memory request limit of 2Gi, any pod creation that would cause the total memory requests in the namespace to exceed that quota is rejected by the Kubernetes API server. The pod creation fails immediately with an error message indicating the quota would be exceeded, because the admission controller validates the request against the quota before allowing the pod to be scheduled.

Answer

The pod is created with a warning, but the request is ignored.

Answer

The pod is created, but the memory request is capped at 2Gi.

Answer

The pod is created, but it will be OOMKilled if it exceeds 2Gi.

Question 9

A pod must run with a seccomp profile that only allows specific syscalls. Which SecurityContext field is used to specify the seccomp profile type?

Accepted Answer

seccompProfile. `seccompProfile` is the field within the Pod or container `SecurityContext` that specifies the seccomp profile type (e.g., `RuntimeDefault`, `Localhost`, or `Unconfined`). This field was introduced in Kubernetes v1.19 (beta) and replaces the older annotation-based seccomp configuration, allowing you to define the profile type directly in the pod spec.

Answer

appArmorProfile

Answer

seLinuxOptions

Answer

seccomp

Question 10

A pod in the 'staging' namespace is in a CrashLoopBackOff state. You run 'kubectl logs pod -n staging' and see: 'Error: container has been OOMKilled'. The pod YAML has resources: requests: memory: 256Mi, limits: memory: 256Mi. Which change should you make first?

Accepted Answer

Increase the memory limit to 512Mi.. The pod is in CrashLoopBackOff due to OOMKill, meaning the container exceeded its memory limit and was terminated. Since the current memory limit is 256Mi and the container needs more, increasing the limit to 512Mi directly addresses the out-of-memory condition. This is the correct first step because it provides the container with the additional memory it requires to run without being killed.

Answer

Increase the CPU limit to 1.

Answer

Reduce the memory request to 128Mi.

Answer

Set memory request to 512Mi and memory limit to 256Mi.

Question 11

You have a pod that needs to mount a Secret as a volume. The Secret has keys 'username' and 'password'. How should the volumes and volumeMounts be configured to mount the secret at /etc/secret with each key as a file?

Accepted Answer

volumes:
- name: secret-vol
  secret:
    secretName: my-secret
containers:
- volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret. It uses the `secret` volume type with `secretName: my-secret`, which mounts the specified Kubernetes Secret as a volume. When mounted at `/etc/secret`, each key in the Secret (e.g., 'username' and 'password') becomes a file in that directory, with the file name matching the key and the file content being the decoded value of the key. This is the standard method for exposing Secret data as files in a pod.

Answer

volumes:
- name: secret-vol
  hostPath:
    path: /etc/secret
containers:
- volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret

Answer

volumes:
- name: secret-vol
  configMap:
    name: my-secret
containers:
- volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret

Answer

volumes:
- name: secret-vol
  emptyDir: {}
containers:
- volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret

Question 12

A PodSecurityPolicy (PSP) has been replaced by Pod Security Admission. Which of the following commands applies a baseline pod security standard to the namespace 'dev'?

Accepted Answer

kubectl label ns dev pod-security.kubernetes.io/enforce=baseline. Pod Security Admission uses labels on namespaces to enforce pod security standards. The label `pod-security.kubernetes.io/enforce=baseline` applies the baseline standard, which prevents known privilege escalations while allowing the default minimal pod configuration. This replaces the deprecated PodSecurityPolicy (PSP) with a built-in admission controller.

Answer

kubectl label ns dev pod-security.kubernetes.io/warn=baseline

Answer

kubectl label ns dev pod-security.kubernetes.io/enforce=privileged

Answer

kubectl label ns dev pod-security.kubernetes.io/audit=baseline

Question 13

You have a ConfigMap created from an env file. Which command creates the ConfigMap from the file 'app.env' containing key=value pairs?

Accepted Answer

kubectl create configmap app-config --from-env-file=app.env. `--from-env-file` is the exact flag used to create a ConfigMap from a file containing key=value pairs in env-file format (e.g., `app.env`). This flag parses each line as a key-value pair and stores them as individual data entries in the ConfigMap, unlike `--from-file` which stores the entire file content under a single key.

Answer

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

Answer

kubectl create configmap app-config --env-file=app.env

Answer

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

Question 14

Which TWO are valid ways to expose a Secret's data as environment variables in a pod?

Accepted Answer

envFrom:
- secretRef:
    name: my-secret
    prefix: SECRET_. The `envFrom` field in a pod spec can reference a Secret using `secretRef`, and the optional `prefix` field prepends a string to each key from the Secret when exposing them as environment variables. This allows all key-value pairs from the Secret to be injected as environment variables with a common prefix, which is a concise and valid method.

Answer

envFrom:
- fieldRef:
    fieldPath: metadata.namespace

Answer

envFrom:
- literal:
    key: value

Answer

envFrom:
- configMapRef:
    name: my-secret

Question 15

Which THREE capabilities are commonly dropped in a pod's securityContext to adhere to restricted pod security standards?

Accepted Answer

SYS_ADMIN. (SYS_ADMIN) is correct because the restricted pod security standard (PSS) requires dropping all capabilities via `ALL` and then adding back only those needed. However, `SYS_ADMIN` is a highly privileged capability that grants broad system administration access, such as mounting filesystems and performing privileged syscalls, and is explicitly forbidden in restricted profiles. Dropping it is mandatory to comply with restricted PSS.

Answer

ALL

Answer

CHOWN