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

Question 1

A developer creates a Secret named 'db-secret' with key 'password'. They want to expose the password as an environment variable DB_PASSWORD in a Pod. Which of the following is the correct way to achieve this?

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

Accepted Answer

Set env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password. It uses the `valueFrom.secretKeyRef` field to reference a specific key (`password`) from the Secret named `db-secret` and expose it as the environment variable `DB_PASSWORD`. This is the standard Kubernetes syntax for injecting a single Secret key into a Pod's environment variable.

Answer

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

Answer

Use envFrom: - secretRef: name: db-secret

Answer

Set env: - name: DB_PASSWORD secretRef: name: db-secret key: password

Question 2

Which TWO of the following are valid ways to inject configuration data into a Kubernetes Pod?

Accepted Answer

Using a ConfigMap to set environment variables in the Pod spec.. A ConfigMap is specifically designed to inject configuration data into Pods, and one of the primary methods is by setting environment variables in the Pod spec using `envFrom` or `valueFrom: configMapKeyRef`. This allows decoupling configuration from container images, enabling environment-specific settings without rebuilding images.

Answer

Mounting a ServiceAccount token as a volume.

Answer

Using a PersistentVolumeClaim to store configuration files.

Answer

Referencing a NetworkPolicy in the Pod spec.

Question 3

Refer to the exhibit. A Pod is defined with security contexts at both the container and Pod level. Which of the following statements accurately describes the effective security configuration?

Accepted Answer

The container runs as user 1000, group 2000, with NET_ADMIN capability added, and the Pod-level runAsNonRoot: true is also enforced.. Kubernetes merges Pod-level and container-level security contexts, with the container-level settings taking precedence for fields that overlap, but Pod-level settings that are not overridden (like runAsNonRoot) remain enforced. In this case, the container runs as user 1000, group 2000, with NET_ADMIN capability added, and the Pod-level runAsNonRoot: true is also enforced, ensuring the container does not run as root.

Answer

The Pod will fail to start because runAsNonRoot conflicts with the container's runAsUser.

Answer

The container runs as user 1000, but the Pod-level runAsNonRoot overrides the container's runAsUser to enforce non-root.

Answer

The container runs as root because the Pod-level runAsNonRoot is ignored when container-level capabilities are set.

Question 4

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: db
    image: postgres:latest
    securityContext:
      runAsNonRoot: true
```

The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

Accepted Answer

Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.. The PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Answer

Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

Answer

Increase the Pod's resource limits because the error is due to insufficient memory.

Answer

Create a PodSecurityPolicy that allows running as root.

Question 5

Arrange the steps to create a ConfigMap from a file and mount it as a volume in a Pod.

Accepted Answer

Step 1: Create ConfigMap from file, Step 2: Define Pod YAML with volume and volumeMount, Step 3: Apply the Pod manifest, Step 4: Verify the ConfigMap mount in the Pod. Create ConfigMap first, then define Pod with volume and volumeMount, apply, and verify.

Answer

Step 1: Define Pod YAML with volume and volumeMount, Step 2: Create ConfigMap from file, Step 3: Apply the Pod manifest, Step 4: Verify the ConfigMap mount in the Pod

Answer

Step 1: Create ConfigMap from file, Step 2: Apply the Pod manifest, Step 3: Define Pod YAML with volume and volumeMount, Step 4: Verify the ConfigMap mount in the Pod

Answer

Step 1: Verify the ConfigMap mount in the Pod, Step 2: Create ConfigMap from file, Step 3: Define Pod YAML with volume and volumeMount, Step 4: Apply the Pod manifest

Question 6

Sequence the steps to scale a Deployment to 5 replicas and verify.

Accepted Answer

Step 1: Check current state of the Deployment and existing Pods. Step 2: Scale the Deployment to 5 replicas using 'kubectl scale'. Step 3: Watch the Pods being created using 'kubectl get pods --watch'. Step 4: Confirm the number of replicas is 5 using 'kubectl get deployment'. Step 5: Inspect events for any errors using 'kubectl describe deployment' or 'kubectl get events'.. The correct sequence for scaling and verifying a Deployment involves first checking the current state to establish a baseline, then applying the scale command, watching the Pods to observe the rollout in real-time, confirming the final replica count, and finally inspecting events to catch any errors or anomalies. This order ensures a systematic and efficient verification process.

Answer

Step 1: Scale the Deployment to 5 replicas. Step 2: Watch the Pods being created. Step 3: Confirm the number of replicas is 5. Step 4: Inspect events for any errors. (Omit checking current state.)

Answer

Step 1: Check current state. Step 2: Immediately confirm the number of replicas (without scaling). Step 3: Scale the Deployment. Step 4: Watch Pods. Step 5: Inspect events.

Answer

Step 1: Watch Pods continuously. Step 2: Scale the Deployment. Step 3: Check current state. Step 4: Confirm the number of replicas. Step 5: Inspect events.

Question 7

Match each Kubernetes concept to its definition.

Accepted Answer

Pod: Smallest deployable unit in Kubernetes that can contain one or more containers.. Correct matches are Pod with smallest deployable unit, Service with logical set and access policy, Deployment with declarative updates, and Ingress with external HTTP access. Common confusions include swapping Pod and Service definitions.

Answer

Pod: An abstraction that defines a logical set of Pods and a policy to access them.

Answer

Service: Smallest deployable unit in Kubernetes that can contain one or more containers.

Question 8

Match each Kubernetes probe to its check behavior.

Accepted Answer

Liveness probe: Checks if container is running and healthy; restarts container on failure. Liveness probes check if a container is running (if they fail, the container is restarted). Readiness probes check if a container is ready to serve traffic (if they fail, traffic is not routed to it). Startup probes check if an application has started, used mainly for slow-starting containers.

Answer

Readiness probe: Checks if container is running and restarts it on failure

Answer

Startup probe: Checks if container is ready to serve traffic

Question 9

You need to create a ConfigMap named 'app-config' with key 'APP_COLOR' and value 'blue'. Which command creates this ConfigMap?

Accepted Answer

kubectl create configmap app-config --from-literal=APP_COLOR=blue. `kubectl create configmap app-config --from-literal=APP_COLOR=blue` uses the `--from-literal` flag, which directly creates a ConfigMap entry from a key-value pair specified in the command line. The syntax `key=value` is required for literal data, and this command correctly maps the key 'APP_COLOR' to the value 'blue'.

Answer

kubectl create configmap app-config --from-env-file=APP_COLOR=blue

Answer

kubectl create configmap app-config --from-literal=APP_COLOR:blue

Answer

kubectl create configmap app-config --from-file=APP_COLOR=blue

Question 10

A pod is running with the following SecurityContext:
securityContext:
  runAsUser: 1000
  runAsGroup: 2000
  fsGroup: 3000
What UID and GID does the process inside the container use?

Accepted Answer

UID 1000, GID 2000. The `runAsUser` and `runAsGroup` fields in the Pod's SecurityContext directly set the UID and GID for the container's main process. Here, `runAsUser: 1000` sets the process UID to 1000, and `runAsGroup: 2000` sets the process GID to 2000. The `fsGroup: 3000` field only applies to the group ownership of mounted volumes, not to the process's primary GID.

Answer

UID 1000, GID 3000

Answer

UID 0, GID 2000

Answer

UID 3000, GID 2000

Question 11

You need to create a Pod that mounts a Secret named 'mysecret' as an environment variable 'SECRET_DATA'. The secret has a key 'password'. Which YAML snippet correctly achieves this?

Accepted Answer

env:
- name: SECRET_DATA
  valueFrom:
    secretKeyRef:
      name: mysecret
      key: password. It uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Secret named 'mysecret' and inject its value into the environment variable `SECRET_DATA`. This is the standard Kubernetes syntax for exposing a Secret's key-value pair as an environment variable.

Answer

env:
- name: SECRET_DATA
  valueFrom:
    configMapKeyRef:
      name: mysecret
      key: password

Answer

env:
- name: SECRET_DATA
  valueFrom:
    secretKeyRef:
      name: password
      key: mysecret

Answer

volumeMounts:
- name: secret-volume
  mountPath: /etc/secret
volumes:
- name: secret-volume
  secret:
    secretName: mysecret
    items:
    - key: password
      path: secret.txt

Question 12

Which of the following is the correct way to set a CPU request of 250 millicores and a memory limit of 512 Mi in a container?

Accepted Answer

resources:
  requests:
    cpu: 250m
  limits:
    memory: 512Mi. In Kubernetes, CPU requests are specified in millicores (e.g., 250m) and memory limits use binary units like Mi (Mebibytes). The value '250m' equals 0.25 CPU cores, and '512Mi' is 512 Mebibytes (512 * 1024^2 bytes), which is the standard unit for memory limits.

Answer

resources:
  requests:
    cpu: 250
  limits:
    memory: 512M

Answer

resources:
  requests:
    cpu: 250
  limits:
    memory: 512MB

Answer

resources:
  requests:
    cpu: 0.25
  limits:
    memory: 512MB

Question 13

A developer wants to ensure that a pod runs with a non-root user and cannot gain root privileges. Which SecurityContext settings should be used?

Accepted Answer

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false. Setting `runAsNonRoot: true` enforces that the container's user ID is non-zero (non-root), and `allowPrivilegeEscalation: false` prevents the container from gaining additional privileges beyond its initial set, such as through setuid binaries or kernel capabilities. Together, they ensure the pod runs as a non-root user and cannot escalate to root, satisfying the developer's requirement.

Answer

securityContext:
  allowPrivilegeEscalation: false

Answer

securityContext:
  runAsNonRoot: true

Answer

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: true

Question 14

Which command creates a generic secret named 'db-secret' with key 'password' and value 'p@ss'?

Accepted Answer

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

Answer

kubectl create secret generic db-secret --from-file=password=p@ss

Answer

kubectl create secret tls db-secret --from-literal=password=p@ss

Answer

kubectl create secret docker-registry db-secret --from-literal=password=p@ss

Question 15

A pod named 'test-pod' in namespace 'test' has a service account 'my-sa' attached. The service account has a RoleBinding to a Role that allows get/list pods. However, the pod cannot list pods. What is the most likely issue?

Accepted Answer

The RoleBinding is in a different namespace than the pod. RoleBindings in Kubernetes are namespace-scoped and can only grant permissions within the namespace where they are created. If the RoleBinding is in a different namespace than the pod, the service account 'my-sa' will not have the get/list pods permissions in the pod's namespace, causing the pod to fail when trying to list pods.

Answer

The pod is using the default service account instead of 'my-sa'

Answer

RoleBindings cannot grant access to list pods

Answer

The pod has automountServiceAccountToken set to false