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

Question 1

Which of the following is a valid way to expose a Secret as an environment variable in a Pod?

Accepted Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef: .... `secretKeyRef` is the Kubernetes API field used to reference a specific key from a Secret object and expose its value as an environment variable in a Pod. This is defined in the Pod spec under `env[].valueFrom.secretKeyRef`, which requires the `name` of the Secret and the `key` within that Secret.

Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      configMapKeyRef: ...

Answer

env:
  - name: DB_PASSWORD
    value: $(DB_PASSWORD_SECRET)

Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      fieldRef: ...

Question 2

You have a Secret of type 'kubernetes.io/tls' named 'tls-secret'. What keys are required in the Secret data?

Accepted Answer

tls.crt and tls.key. A is correct because a Kubernetes TLS secret of type 'kubernetes.io/tls' requires exactly two data keys: 'tls.crt' (the TLS certificate) and 'tls.key' (the private key). These are mandatory for the TLS handshake to function, as defined by the Kubernetes API for TLS secrets.

Answer

username and password

Answer

tls.crt, tls.key, and ca.crt

Answer

.dockerconfigjson

Question 3

Which kubectl command creates a Secret named 'db-secret' with key 'password' and value 'mypwd'?

Accepted Answer

kubectl create secret generic db-secret --from-literal=password=mypwd. `kubectl create secret generic` with `--from-literal` allows you to specify key-value pairs directly on the command line. The syntax `--from-literal=password=mypwd` creates a secret with key 'password' and value 'mypwd', which is the exact requirement.

Answer

kubectl create secret generic db-secret password=mypwd

Answer

kubectl create secret generic db-secret --from-file=password=mypwd

Answer

kubectl create secret generic db-secret --from-env-file=password=mypwd

Question 4

You need to grant a ServiceAccount named 'app-sa' in namespace 'default' read-only access to Pods in that namespace. Which RBAC resources should you create?

Accepted Answer

A Role with rules for pods (get, list, watch) and a RoleBinding to the ServiceAccount. The ServiceAccount 'app-sa' requires read-only access to Pods only within the 'default' namespace. A Role is namespace-scoped and can define rules for pods with verbs get, list, watch. A RoleBinding then binds that Role to the ServiceAccount within the same namespace, granting the permissions exactly where needed.

Answer

A ClusterRole with rules for pods (get, list, watch) and a ClusterRoleBinding to the ServiceAccount

Answer

A ClusterRole with rules for pods (get, list, watch) and a RoleBinding to the ServiceAccount

Answer

A Role with rules for pods (get, list, watch, create) and a RoleBinding to the ServiceAccount

Question 5

You create a Pod with a securityContext set to 'runAsNonRoot: true' and a container image that runs as root (user 0). What will happen when you create the Pod?

Accepted Answer

The Pod will be created but the container will be in a CrashLoopBackOff. When a Pod has `runAsNonRoot: true` in its security context and the container image runs as root (UID 0), the Pod object is still created, but the container fails to start because it violates the security context. Kubernetes attempts to run the container, but the CRI (Container Runtime Interface) refuses to run the container as root due to the `runAsNonRoot: true` setting. This results in a runtime error such as `CreateContainerError` or `CrashLoopBackOff` as the container repeatedly fails to start. The Pod is not rejected at admission time because `runAsNonRoot` is enforced at runtime by the container runtime, not by the API server.

Answer

The Pod will run but with root user, ignoring the setting

Answer

The Pod will not be created and you will see an error about securityContext violation

Answer

The Pod will run with root but the container will be killed by a security policy

Question 6

Which TWO of the following are valid ways to consume a ConfigMap in a Pod? (Select TWO)

Accepted Answer

Using env with valueFrom.configMapKeyRef to inject a specific key. `env.valueFrom.configMapKeyRef` allows you to inject a specific key from a ConfigMap as an environment variable into a container. Option C is correct because you can mount a ConfigMap as a volume using `volumes` and `volumeMounts`, which makes its keys available as files. Option E is incorrect because while `envFrom` with `configMapRef` is a valid method, the question asks for exactly two correct answers, and the intended pair is B and C. Options A and D are invalid: A uses `secretRef` which is for Secrets, not ConfigMaps; D attempts to set a value directly to a key name, which is not supported.

Answer

Using envFrom with secretRef

Answer

Using env with value directly set to a key name

Answer

Using envFrom to inject all keys as environment variables

Question 7

Which THREE of the following are benefits of using a ResourceQuota in a namespace? (Select THREE)

Accepted Answer

It can enforce that every Pod has resource limits set. A ResourceQuota can enforce that every Pod in the namespace has resource limits set by specifying the `limits.cpu` and `limits.memory` fields in the quota's `hard` spec. If a Pod is created without those limits, the API server will reject it, ensuring no Pod runs unbounded. This is distinct from setting default values, which is done by a LimitRange, not a ResourceQuota.

Answer

It sets default resource requests and limits for Pods that don't specify them

Answer

It restricts which users can create Pods in the namespace

Question 8

You want to apply a Pod Security Admission (PSA) policy that enforces the 'restricted' profile in the 'dev' namespace, but only for Pods that are not exempt. Which TWO steps are required? (Select TWO)

Accepted Answer

Set the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace. Setting the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace instructs the Pod Security Admission controller to reject any Pod that does not meet the restricted profile, unless the Pod is exempt (e.g., system-critical Pods or those with specific exemptions). This label directly enforces the policy at admission time, ensuring only compliant Pods are created in the 'dev' namespace.

Answer

Add a 'securityContext' field to the Pod template with 'runAsUser: 1000'

Answer

Set the label 'pod-security.kubernetes.io/enforce=baseline' on the namespace

Answer

Set the label 'pod-security.kubernetes.io/warn=restricted' on the namespace

Question 9

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

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' by reading the entire contents of the file 'config.properties' and storing it as a single key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content. This is the standard syntax for creating a ConfigMap from a file in Kubernetes.

Answer

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

Answer

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

Answer

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

Question 10

A developer creates a Secret using the command: 'kubectl create secret generic db-secret --from-literal=password=myPass'. Which way to consume this Secret in a pod is CORRECT?

Accepted Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password. The Secret can be consumed via secretKeyRef for a specific key, via envFrom to load all keys as environment variables, or via a volume mount. As the question is worded, all these methods are correct. If intended to ask specifically about injecting a single key into an environment variable, only A would be correct, but the current wording does not make that restriction.

Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      configMapKeyRef:
        name: db-secret
        key: password

Question 11

A cluster administrator wants to prevent all pods in a namespace from running with privileged escalation. Which Pod Security Admission standard enforces this?

Accepted Answer

restricted. The 'restricted' Pod Security Admission (PSA) standard enforces the most stringent security controls, including preventing privileged escalation by setting `securityContext.AllowPrivilegeEscalation` to `false` and requiring containers to run as non-root. This directly addresses the cluster administrator's goal of blocking privilege escalation in all pods within a namespace.

Answer

baseline

Answer

privileged

Answer

high

Question 12

A pod has a container with 'readOnlyRootFilesystem: true' in its securityContext. The container writes to /tmp. What is the expected outcome?

Accepted Answer

The container crashes because it tries to write to /tmp but the filesystem is read-only.. When `readOnlyRootFilesystem: true` is set in the container's securityContext, the root filesystem is mounted as read-only. The container writes to `/tmp`, which is part of the root filesystem by default, so the write fails and the container crashes (e.g., with an error like 'Read-only file system'). Kubernetes does not automatically make `/tmp` writable unless an explicit emptyDir volume is mounted at that path.

Answer

The pod runs normally; Kubernetes automatically makes /tmp writable.

Answer

The pod is rejected by the admission controller because readOnlyRootFilesystem conflicts with writing to /tmp.

Answer

The container writes successfully because readOnlyRootFilesystem only applies to the container image layers.

Question 13

You create a ServiceAccount 'my-sa' with automountServiceAccountToken: false. A pod that references this ServiceAccount also sets automountServiceAccountToken: true in its spec. Will the service account token be mounted?

Accepted Answer

Yes, because the pod spec setting takes precedence.. The pod spec's `automountServiceAccountToken: true` takes precedence over the ServiceAccount's `automountServiceAccountToken: false`. Kubernetes merges the ServiceAccount and pod-level settings, with the pod-level setting overriding the ServiceAccount's setting. Therefore, the token will be mounted into the pod.

Answer

No, because the ServiceAccount has automountServiceAccountToken: false, which is a hard block.

Answer

It depends on the namespace default settings.

Answer

No, because the ServiceAccount setting overrides the pod setting.

Question 14

A user wants to create a Kubernetes Secret for storing Docker registry credentials (username and password). Which type of Secret should they use?

Accepted Answer

kubernetes.io/dockerconfigjson. `kubernetes.io/dockerconfigjson` is the dedicated Secret type for storing Docker registry credentials in the format expected by `docker login`. It automatically encodes the username and password into a `.dockerconfigjson` field, which is used by Kubernetes to pull images from private registries. This type is required when referencing a `imagePullSecret` in a Pod spec.

Answer

kubernetes.io/tls

Answer

Opaque

Answer

kubernetes.io/basic-auth

Question 15

What is the purpose of a ResourceQuota in Kubernetes?

Accepted Answer

To limit the total amount of resources (CPU, memory, etc.) that can be consumed by all pods in a namespace.. A ResourceQuota is a Kubernetes object that enforces aggregate resource consumption limits on a per-namespace basis. It constrains the total CPU, memory, and other resource requests and limits across all pods in that namespace, preventing any single namespace from exhausting cluster resources. Option B correctly identifies this namespace-level resource cap.

Answer

To set default resource limits for containers that do not specify them.

Answer

To limit the number of nodes in a cluster.

Answer

To limit the number of replicas in a Deployment.