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

Question 1

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. 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 2

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

Accepted Answer

Mounting the ConfigMap as a volume. Although the question instructs to select two, all three options A, B, and E are actually valid ways to consume a ConfigMap in a pod. Option A is correct because a ConfigMap can be mounted as a volume, making each key a file in the container's filesystem. Option B is correct because `configMapKeyRef` in `env.valueFrom` allows loading a specific key from a ConfigMap as an environment variable. Option E is correct because `envFrom` with `configMapRef` loads all keys from a ConfigMap as environment variables. Options C and D are incorrect: `configMapRef` in `env.valueFrom` is not a valid construct (the correct syntax is `configMapKeyRef`), and `secretKeyRef` is used for Secrets, not ConfigMaps.

Answer

Using configMapRef in env.valueFrom

Answer

Using secretKeyRef in env.valueFrom

Question 3

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

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. The `kubectl create configmap` command with the `--from-file` flag directly creates a ConfigMap from the contents of a specified file, using the filename as the key and the file content as the value. This is the standard method for creating a ConfigMap from a single file like 'config.properties'.

Answer

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

Answer

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

Answer

kubectl apply -f config.properties

Question 4

A Secret named 'db-secret' of type Opaque contains a key 'password'. How do you reference this key as an environment variable named 'DB_PASSWORD' in a pod spec?

Accepted Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password. It uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Kubernetes Secret of type Opaque. The `secretKeyRef` is the proper mechanism to inject a single key from a Secret as an environment variable, mapping the key 'password' to the environment variable name 'DB_PASSWORD'.

Answer

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

Answer

envFrom:
  - secretRef:
      name: db-secret
      key: password

Answer

env:
  - name: DB_PASSWORD
    value: "db-secret.password"

Question 5

A Pod spec includes 'securityContext' with 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process inside the pod is expected to write to a mounted volume. Which securityContext field should be set to ensure the volume's group ownership is 3000?

Accepted Answer

fsGroup: 3000. The `fsGroup` field in the Pod's `securityContext` specifies the group ID (GID) that Kubernetes should assign to any volume mounted into the Pod. When `fsGroup: 3000` is set, Kubernetes recursively changes the ownership of the volume's files and directories to group ID 3000, and any new files created by the container process will inherit that group ownership. This ensures the container process, which runs with `runAsGroup: 3000`, can write to the volume without permission errors.

Answer

supplementalGroups: [3000]

Answer

fsGroup: 1000

Answer

runAsGroup: 3000

Question 6

A developer created a Role named 'pod-reader' in namespace 'ns1' that allows 'get', 'list', and 'watch' on pods. They created a RoleBinding binding this Role to a ServiceAccount 'sa1' in the same namespace. However, a pod using 'sa1' cannot list pods in namespace 'ns2'. What is the most likely cause?

Accepted Answer

Role and RoleBinding are namespace-scoped; they only grant permissions within their namespace. Role and RoleBinding are namespace-scoped resources in Kubernetes. A Role defined in 'ns1' grants permissions only within 'ns1', and a RoleBinding in 'ns1' binds that Role to a ServiceAccount only for operations inside 'ns1'. To list pods in 'ns2', the ServiceAccount needs a separate Role and RoleBinding (or a ClusterRole and ClusterRoleBinding) that explicitly grant permissions in 'ns2'. Therefore, the pod using 'sa1' cannot list pods in 'ns2' because the Role and RoleBinding are confined to 'ns1'.

Answer

The Role is missing the apiGroup field

Answer

The Role does not include the 'list' verb for pods

Answer

The RoleBinding is not bound to the correct ServiceAccount

Question 7

A Pod is running in a namespace with a ResourceQuota that sets 'limits.memory: 2Gi'. The pod's container spec has 'resources.limits.memory: 1Gi' and 'resources.requests.memory: 512Mi'. The pod is in 'Running' state but consumes 1.5Gi of memory. What happens?

Accepted Answer

The container will be OOMKilled because it exceeds its own memory limit of 1Gi. The container has a hard memory limit of 1Gi set in its resources.limits.memory. When the container's memory usage exceeds this limit (1.5Gi > 1Gi), the Linux kernel's OOM killer terminates the container process. The namespace ResourceQuota of 2Gi is not violated because the pod's limit (1Gi) is within the quota, so the kubelet does not evict the pod.

Answer

The pod will be evicted by the kubelet due to namespace quota violation

Answer

The container will continue running because the namespace quota allows up to 2Gi

Answer

The pod will be throttled by the kernel to stay within 1Gi

Question 8

You need to create a Secret of type kubernetes.io/tls for use with an Ingress. Which kubectl command should you use?

Accepted Answer

kubectl create secret tls my-tls --cert=cert.pem --key=key.pem. `kubectl create secret tls` is the dedicated command for creating a TLS secret, which automatically stores the certificate and key under the expected keys `tls.crt` and `tls.key` respectively. This secret type (`kubernetes.io/tls`) is required by Ingress controllers to serve HTTPS traffic, and the command directly accepts `--cert` and `--key` flags for the PEM-encoded files.

Answer

kubectl create secret docker-registry my-tls --docker-username=user --docker-password=pass

Answer

kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

Answer

kubectl create secret tls my-tls --from-file=tls.crt --from-file=tls.key

Question 9

A Pod is configured with securityContext: { runAsUser: 1000, runAsGroup: 2000, fsGroup: 3000 }. The container's image runs a process that must listen on a TCP port below 1024 (e.g., port 80). The process is currently failing to start. What should you modify to allow the process to bind to a privileged port?

Accepted Answer

Add 'capabilities.add: [NET_BIND_SERVICE]' to the container's securityContext. The container process runs as a non-root user (UID 1000) and needs to bind to a privileged port (below 1024). Linux requires either root privileges or the CAP_NET_BIND_SERVICE capability to bind to ports below 1024. Adding this capability to the container's securityContext grants the process the necessary privilege without running as root, which is the correct and secure approach.

Answer

Set 'allowPrivilegeEscalation: true'

Answer

Add 'capabilities.drop: [ALL]' to the container's securityContext

Answer

Set runAsUser: 0 to run as root

Question 10

Which of the following is the correct way to set an environment variable 'APP_COLOR' from a ConfigMap key 'color'?

Accepted Answer

env:
  - name: APP_COLOR
    valueFrom:
      configMapKeyRef:
        name: my-config
        key: color. It uses the `configMapKeyRef` field under `valueFrom` in the `env` array to inject a specific key from a ConfigMap as an environment variable. This is the standard Kubernetes syntax for referencing a single key from a ConfigMap, where `name` specifies the ConfigMap object and `key` specifies the key within that ConfigMap whose value will be assigned to the environment variable `APP_COLOR`.

Answer

env:
  - name: APP_COLOR
    valueFrom:
      configMapRef:
        name: my-config
        key: color

Answer

envFrom:
  - configMapKeyRef:
      name: my-config
      key: color

Answer

env:
  - name: APP_COLOR
    value: "configMap.color"

Question 11

Which THREE configurations are part of Pod Security Admission's 'restricted' profile? (Select THREE.)

Accepted Answer

runAsNonRoot: true. The 'restricted' profile in Pod Security Admission enforces the most stringent security standards. Option A is correct because `runAsNonRoot: true` is a required field in the restricted profile, ensuring containers cannot run as the root user, which mitigates privilege escalation risks.

Answer

allowPrivilegeEscalation: true

Answer

Privileged containers allowed

Question 12

You need to create a Secret of type 'kubernetes.io/tls' for ingress. Which command is correct?

Accepted Answer

kubectl create secret tls my-tls --cert=cert.pem --key=key.pem. `kubectl create secret tls` is the dedicated command for creating a TLS secret, and it uses the `--cert` and `--key` flags to specify the certificate and private key files respectively. This creates a Secret of type `kubernetes.io/tls`, which is required for Ingress resources to terminate HTTPS traffic.

Answer

kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

Answer

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

Answer

kubectl create secret tls my-tls --from-file=tls.crt=cert.pem --from-file=tls.key=key.pem

Question 13

Which TWO of the following are valid ways to create a ConfigMap from a file named 'app.properties'? (Select two.)

Accepted Answer

kubectl create configmap app-config --from-file=app.properties. `--from-file=app.properties` creates a ConfigMap with a single key-value pair, where the key defaults to the filename (app.properties) and the value is the entire file content. Option E is correct because `--from-env-file=app.properties` imports each line of the file as a separate key-value pair, treating the file as an environment variable definition file (key=value format).

Answer

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

Answer

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

Answer

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

Question 14

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

Accepted Answer

allowPrivilegeEscalation. A is correct because `allowPrivilegeEscalation` directly controls whether a process can gain more privileges than its parent, such as via setuid binaries or file capabilities. Setting it to `false` prevents privilege escalation, which is a core security requirement for restricting container breakout.

Answer

readOnlyRootFilesystem

Answer

runAsNonRoot

Answer

privileged

Question 15

Which TWO commands can be used to create a Secret from a file? (Select 2)

Accepted Answer

kubectl create secret generic mysecret --from-file=key=file.txt. Both options A and E are valid commands to create a Secret from a file. Option A uses `--from-file` to read file contents and store them under a specified key. Option E uses `--from-env-file` to parse a file with key=value pairs and create a Secret for environment variables. Option C is incorrect for this question because `kubectl apply -f secret.yaml` applies a YAML manifest that defines a Secret, but it does not create a Secret directly from a file's contents in the same way as the `kubectl create secret` commands. The question asks for two commands that create a Secret from a file, and both A and E meet that criterion.

Answer

kubectl create configmap mysecret --from-file=file.txt

Answer

kubectl apply -f secret.yaml where secret.yaml contains data fields

Answer

kubectl create secret tls mysecret --cert=file.txt