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

Question 1

You have a Secret of type kubernetes.io/tls. The pod mounting it as a volume expects the files 'tls.crt' and 'tls.key'. What keys must the Secret data contain?

Accepted Answer

tls.crt and tls.key. For a Secret of type `kubernetes.io/tls`, the Kubernetes API server expects the data to contain exactly the keys `tls.crt` and `tls.key`. When such a Secret is mounted as a volume into a pod, the files created in the mount path are named `tls.crt` and `tls.key`, matching these keys. This is enforced by the Kubernetes TLS secret controller and is documented in the official Kubernetes reference for TLS secrets.

Answer

ca.crt and tls.key

Answer

cert and key

Answer

certificate and key

Question 2

A pod has a container with envFrom referencing a ConfigMap. The ConfigMap has keys 'APP_DEBUG=true' and 'APP_NAME=myapp'. The pod also has an env entry with name 'APP_DEBUG' set to 'false'. What is the value of APP_DEBUG in the container?

Accepted Answer

false. When a pod has both an `envFrom` referencing a ConfigMap and an explicit `env` entry with the same key, the explicit `env` entry takes precedence. This is because Kubernetes merges environment variables from multiple sources, and individual `env` entries override any values from `envFrom` for the same key. Therefore, `APP_DEBUG` will be set to 'false' as defined in the explicit `env` entry.

Answer

undefined

Answer

Both values are concatenated

Answer

true

Question 3

You apply a Pod Security Admission label 'pod-security.kubernetes.io/enforce: restricted' to a namespace. A pod with the following securityContext is created:
securityContext:
  runAsUser: 1000
  runAsNonRoot: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
Will the pod be admitted?

Accepted Answer

Yes, the pod satisfies all restricted profile requirements. The Pod Security Admission (PSA) restricted profile requires that pods drop all capabilities, set `runAsNonRoot: true`, set `seccompProfile.type` to `RuntimeDefault` or `Localhost`, set `allowPrivilegeEscalation: false`, and restrict `runAsUser` to a non-root user (which is satisfied by `runAsUser: 1000`). The provided pod meets all these requirements, so it will be admitted. The `runAsUser` field is allowed as long as the user ID is not 0 (root), and the `seccompProfile.type` is correctly set to `RuntimeDefault`, which is one of the permitted values.

Answer

No, because runAsUser must not be set

Answer

No, because seccompProfile type must be 'Localhost'

Answer

No, because the pod must not set capabilities at all

Question 4

Which field in a Pod spec specifies which ServiceAccount the pod should use?

Accepted Answer

spec.serviceAccountName. The correct field is `spec.serviceAccountName` in the Pod spec. This field explicitly specifies the name of the ServiceAccount that the Pod should use. If omitted, the Pod automatically uses the `default` ServiceAccount in its namespace. This is defined in the Kubernetes API for PodSpec.

Answer

spec.serviceAccount

Answer

spec.accountName

Answer

spec.automountServiceAccountToken

Question 5

Which TWO approaches can be used to expose a Secret's value as an environment variable in a pod?

Accepted Answer

env:
  - name: MY_SECRET
    valueFrom:
      secretKeyRef:
        name: my-secret
        key: my-key. The `valueFrom.secretKeyRef` field in a container's `env` definition directly references a specific key from a Kubernetes Secret and injects its value as an environment variable. This is the standard method for exposing a single secret key as an environment variable, as defined in the Kubernetes API.

Answer

volumeMounts:
  - name: secret-volume
    mountPath: /etc/secret

Answer

env:
  - name: MY_SECRET
    value: "$(MY_SECRET)"

Answer

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

Question 6

Which THREE are valid ways to create a ConfigMap?

Accepted Answer

kubectl create configmap my-config --from-literal=key=value. `kubectl create configmap` with `--from-literal` directly creates a ConfigMap with a key-value pair from the command line, which is a standard and valid method. This approach is ideal for simple, single-key configurations without needing external files.

Answer

kubectl create configmap my-config --from-file=key=file

Answer

kubectl apply configmap my-config --from-literal=key=value

Question 7

Which TWO are correct about LimitRange?

Accepted Answer

LimitRange can set default resource requests for containers that don't specify them. A LimitRange can define default resource requests and limits for containers in a namespace. When a container is created without specifying resource requests or limits, the LimitRange admission controller automatically applies the default values defined in the LimitRange object. This ensures that containers have baseline resource guarantees even if the pod spec omits them.

Answer

LimitRange can be applied only to pods in the default namespace

Answer

LimitRange is a cluster-scoped resource

Answer

LimitRange can enforce quotas on total resource usage across all pods

Question 8

Which command creates a ConfigMap named 'app-config' with two keys: 'key1=value1' and 'key2=value2'?

Accepted Answer

kubectl create configmap app-config --from-literal key1=value1 --from-literal key2=value2. `kubectl create configmap` with the `--from-literal` flag allows you to specify key-value pairs directly on the command line. Each `--from-literal` flag creates one entry in the ConfigMap, so using two separate flags correctly creates a ConfigMap named 'app-config' with keys 'key1' and 'key2' mapped to 'value1' and 'value2' respectively.

Answer

kubectl create configmap app-config --from-literal=key1=value1,key2=value2

Answer

kubectl create configmap app-config --from-file key1=value1 --from-file key2=value2

Answer

kubectl create configmap app-config --from-env-file=key1=value1 --from-env-file=key2=value2

Question 9

A pod is scheduled but stays in Pending state. 'kubectl describe pod' shows: '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?

Accepted Answer

The pod's memory request exceeds the available memory on any node.. The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler could not find a node with enough allocatable memory to satisfy the pod's memory request. The pod's memory request (spec.containers[].resources.requests.memory) must be less than or equal to a node's allocatable memory for the pod to be scheduled. Since no node meets this requirement, the pod remains in Pending state.

Answer

The pod has a liveness probe configured incorrectly.

Answer

The namespace has a ResourceQuota that blocks the pod.

Answer

The pod's memory limit is set too low.

Question 10

You need to create a Pod that runs with a specific non-root user (UID 1000), prevents privilege escalation, and mounts the container's filesystem as read-only. Which securityContext field is NOT required to achieve these requirements?

Accepted Answer

runAsGroup: 1000. (runAsGroup: 1000) is not required because the requirement only specifies a non-root user (UID 1000) and does not mandate a specific group ID. The runAsGroup field sets the primary group for the container's processes, but it is optional; without it, the container will use the default group associated with the user or the container's default group. The other options are necessary: runAsUser: 1000 sets the user, readOnlyRootFilesystem: true makes the filesystem read-only, and allowPrivilegeEscalation: false prevents privilege escalation.

Answer

runAsUser: 1000

Answer

readOnlyRootFilesystem: true

Answer

allowPrivilegeEscalation: false

Question 11

Which Pod spec snippets correctly achieve this?

Accepted Answer

envFrom:
  - secretRef:
      name: db-secret. This question has multiple correct answers. Both options A and C are correct ways to expose Secret keys as environment variables in a Pod. Option A uses `envFrom` with `secretRef` to inject all keys from the Secret as environment variables in a single declaration. Option C uses individual `env` entries with `secretKeyRef` to map each key explicitly. Both achieve the same result; option A is more concise for exposing all keys, while option C provides explicit control over each environment variable name. Options B and D are incorrect: B mounts the Secret as files, not environment variables, and D uses `configMapKeyRef`, which is for ConfigMaps, not Secrets.

Answer

volumes:
  - name: secret-volume
    secret:
      secretName: db-secret
  volumeMounts:
  - mountPath: /etc/secret
    name: secret-volume

Answer

env:
  - name: db-secret
    valueFrom:
      configMapKeyRef:
        name: db-secret
        key: username

Question 12

Which command creates a TLS secret from an existing certificate and key file?

Accepted Answer

kubectl create secret tls my-tls --cert=cert.pem --key=key.pem. The `kubectl create secret tls` command is specifically designed to create a TLS secret from an existing certificate and key file. The `--cert` and `--key` flags directly specify the paths to the PEM-encoded certificate and private key, which Kubernetes then stores as a `kubernetes.io/tls` secret type, automatically base64-encoding the data for secure storage in etcd.

Answer

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

Answer

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

Answer

kubectl create secret docker-registry my-tls --docker-server=... --docker-username=... --docker-password=...

Question 13

A Pod in a namespace with a ResourceQuota fails to create with the error: 'exceeded quota: compute-quota, requested: pods=1, used: pods=5, limited: pods=5'. What is the issue?

Accepted Answer

The namespace has reached its maximum number of Pods allowed by the ResourceQuota.. The error message explicitly states 'requested: pods=1, used: pods=5, limited: pods=5'. This means the ResourceQuota named 'compute-quota' has a hard limit of 5 pods in the namespace, and that limit has already been reached. The Pod creation fails because the quota's `count/pods` scope is exhausted, not because of resource requests or permissions.

Answer

The Pod's service account does not have permission to create Pods.

Answer

The Pod's resource requests exceed the quota.

Answer

The Pod is trying to mount a Secret that does not exist.

Question 14

You want to enforce a Pod Security Standard of 'restricted' in a namespace. Which command applies the correct label?

Accepted Answer

kubectl label namespace my-ns pod-security.kubernetes.io/enforce=restricted. Pod Security Standards are enforced by applying a label with the key `pod-security.kubernetes.io/enforce` to a namespace. The value `restricted` sets the most restrictive Pod Security Standard, which prevents pods from running with privileged access or insecure capabilities. This label is part of the built-in Pod Security Admission (PSA) controller, which replaced PodSecurityPolicy in Kubernetes v1.23+.

Answer

kubectl label namespace my-ns psp=restricted

Answer

kubectl annotate namespace my-ns pod-security.kubernetes.io/enforce=restricted

Answer

kubectl label namespace my-ns pod-security.kubernetes.io/audit=restricted

Question 15

Which TWO of the following are valid ways to consume a Secret named 'db-secret' in a Pod? (Choose two.)

Accepted Answer

As environment variables using envFrom with secretRef. `envFrom` with `secretRef` allows a Pod to consume all key-value pairs from a Secret named 'db-secret' as environment variables. This is a standard Kubernetes feature for injecting Secret data into containers without needing to specify each key individually.

Answer

As environment variables using env with valueFrom.configMapKeyRef

Answer

As a command-line argument using $(DB_PASSWORD)

Answer

As an imagePullSecrets entry