CKAD Practice Test 12 — 15 Questions

Question 1

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 2

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 3

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 4

Which TWO of the following are valid methods to create a Service in Kubernetes? (Select 2)

Accepted Answer

kubectl create service clusterip my-svc --tcp=80:80. Options A, B, and E are all valid methods to create a Service. Option A uses `kubectl create service clusterip` to directly create a ClusterIP Service. Option B uses the declarative approach with `kubectl apply -f service.yaml` to create a Service from a YAML definition. Option E (`kubectl expose deployment`) creates a Service that exposes an existing deployment. Although the question asks for two answers, in fact three of the options are valid methods.

Answer

kubectl create deployment my-svc --image=nginx

Answer

kubectl run my-svc --image=nginx --port=80

Question 5

A company wants to ensure zero-downtime deployments for a stateless web application running in Kubernetes. They have a single Deployment with 3 replicas and a Service of type LoadBalancer. Which strategy should they use to achieve this?

Accepted Answer

Use RollingUpdate with maxSurge=25% and maxUnavailable=0. A RollingUpdate strategy with maxSurge=25% and maxUnavailable=0 ensures that during a deployment, the desired number of replicas is always available (no downtime). maxUnavailable=0 means no old Pods are terminated until new ones are ready, and maxSurge=25% allows one extra Pod (25% of 3 replicas = 0.75, rounded up to 1) to be created before terminating old ones, maintaining capacity for zero-downtime updates.

Answer

Use Recreate strategy

Answer

Use RollingUpdate with maxSurge=100% and maxUnavailable=100%

Answer

Use RollingUpdate with maxSurge=0 and maxUnavailable=25%

Question 6

Which TWO are valid Service types? (Choose two.)

Accepted Answer

NodePort. A is correct because NodePort is a standard Kubernetes Service type that exposes a Service on a static port (30000-32767) on each Node's IP address, allowing external traffic to reach the Service. It works by opening that port on every node and routing traffic to the ClusterIP Service, which then forwards to the Pods.

Answer

Headless

Answer

Ingress

Answer

Pod

Question 7

You are debugging a pod that is crashing immediately on startup. You want to run an ephemeral container for debugging while the pod is running. Which command should you use?

Accepted Answer

kubectl debug -it pod --image=busybox --target=crashing-container. `kubectl debug` with the `--target` flag allows you to attach an ephemeral container to a running pod that is crashing on startup, targeting the specific container that is failing. Ephemeral containers are designed for troubleshooting when `kubectl exec` is not possible (e.g., the container has no shell or crashes immediately), and they run in the pod's namespaces without restarting the pod.

Answer

kubectl run debug --image=busybox -it --rm

Answer

kubectl attach pod

Answer

kubectl exec -it pod -- /bin/sh

Question 8

You are a platform engineer managing a Kubernetes cluster version 1.28. A development team has deployed a microservice application called 'order-processor' in the 'prod' namespace. The application consists of a frontend Pod 'frontend' and a backend Pod 'backend', each with a single container. The frontend needs to communicate with the backend using a headless Service named 'backend-svc' that selects Pods with label 'app:backend'. The backend Pods are expected to scale horizontally, and the frontend uses a DNS lookup to discover all backend Pod IPs for client-side load balancing. However, after deploying, the frontend is unable to resolve 'backend-svc' to any IP addresses. The backend Pod is running and has the correct label 'app:backend'. The Service 'backend-svc' is defined as a ClusterIP with clusterIP: None. The frontend container has the 'default' DNS policy. What is the most likely cause of the failure?

Accepted Answer

The headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.. A headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. If the backend Pod is running but not ready (e.g., due to a failing readiness probe or other conditions), the Service excludes it from DNS. Setting publishNotReadyAddresses: true on the Service would include all matching Pods regardless of readiness, allowing the frontend to discover the backend IPs. Since the frontend cannot resolve any IPs, the most likely cause is that the Service is not configured to serve not-ready Pods.

Answer

The Service and frontend are in different namespaces; the DNS name must be fully qualified.

Answer

The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.

Answer

The frontend Pod's DNS policy is set to 'None' which disables DNS resolution.

Question 9

A pod is running with a service account that has been granted a Role to get pods. The pod's code uses the Kubernetes API from within the container. However, the API call fails with a 403 Forbidden error. Which file should the pod read to obtain the authentication token?

Accepted Answer

/var/run/secrets/kubernetes.io/serviceaccount/token. The pod's service account token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the pod uses to authenticate to the Kubernetes API server. Without reading this file, the pod cannot present valid credentials, resulting in a 403 Forbidden error.

Answer

/etc/kubernetes/admin.conf

Answer

/var/run/secrets/kubernetes.io/serviceaccount/namespace

Answer

/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Question 10

To create a service that will be accessible from outside the cluster using a cloud provider's load balancer, what type should be used?

Accepted Answer

LoadBalancer. The LoadBalancer service type (D) provisions an external load balancer from the cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer) and assigns a public IP or DNS name, making the service accessible from outside the cluster. This is the correct choice when the requirement explicitly states using a cloud provider's load balancer for external access.

Answer

NodePort

Answer

ClusterIP

Answer

ExternalName

Question 11

Which THREE of the following are valid fields in a PodSecurityContext?

Accepted Answer

fsGroup. `fsGroup` is a valid field in a PodSecurityContext. It specifies the supplemental group ID applied to all containers in the pod when accessing volumes, ensuring proper file ownership and permissions for shared storage.

Answer

capabilities

Answer

allowPrivilegeEscalation

Question 12

Based on the exhibit, why is the container being killed and restarted?

Accepted Answer

The liveness probe is failing, causing the container to be restarted.. In Kubernetes, a failing liveness probe causes the kubelet to restart the container. The exhibit shows the container being killed and restarted, which is consistent with liveness probe failure. Option A is incorrect because a failing readiness probe does not restart the container; it only marks the pod as not ready and removes it from service endpoints. Option C is incorrect: OOM would result in a different error message (OOMKilled). Option D is incorrect: repeated image pulls would cause ImagePullBackOff, not a restart after running.

Answer

The readiness probe is failing, causing the pod to be considered not ready and restarted.

Answer

The container is running out of memory (OOM).

Answer

The container image is being pulled repeatedly.

Question 13

A user creates a Deployment with 3 replicas and a Service of type ClusterIP. The Service selects pods with label 'app: web'. The user wants external clients to access the application via a stable IP address. Which additional resource is required?

Accepted Answer

An Ingress resource. A ClusterIP Service is only reachable within the cluster. To expose a Deployment to external clients via a stable IP, an Ingress resource is required because it provides HTTP/HTTPS routing from outside the cluster to the Service, typically using a load balancer or a reverse proxy like NGINX. Ingress also offers a stable external IP (or hostname) and can manage TLS termination, making it the correct choice for external access with a stable endpoint.

Answer

A second Service of type NodePort

Answer

A NetworkPolicy

Answer

A ConfigMap

Question 14

You have a NetworkPolicy that allows ingress from pods with label 'app: frontend' in any namespace, and also allows ingress from the IP range '10.0.0.0/8'. The policy is not working as expected. Which YAML snippet correctly implements both requirements?

Accepted Answer

ingress:
- from:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        app: frontend
- from:
  - ipBlock:
      cidr: 10.0.0.0/8. It uses two separate `from` entries in the ingress rule. The first `from` combines a `namespaceSelector: {}` (selects all namespaces) with a `podSelector` for `app: frontend`, meaning pods with that label in any namespace are allowed. The second `from` uses an `ipBlock` to allow traffic from the 10.0.0.0/8 CIDR range. In Kubernetes NetworkPolicy, multiple `from` entries are ORed together, so traffic matching either rule is permitted.

Answer

ingress:
- from:
  - namespaceSelector: {}
  - podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Answer

ingress:
- from:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        app: frontend
  - ipBlock:
      cidr: 10.0.0.0/8

Question 15

You have a Deployment 'db' that uses a ConfigMap for configuration. You want to update the ConfigMap and roll out the changes to pods without restarting them manually. Which approach should you use?

Accepted Answer

Update the ConfigMap and then update the Deployment's pod template (e.g., change an annotation) to trigger a rolling update. Mounting ConfigMaps as volumes with subPath does not automatically update pods; however, using environment variables from ConfigMaps also does not update pods. The recommended approach is to use a Deployment update with a change that triggers a rollout (e.g., updating an annotation). Option B is correct.

Answer

Delete the ConfigMap and recreate it with the same name

Answer

Edit the ConfigMap and run kubectl rollout restart deployment/db

Answer

Use kubectl replace on the ConfigMap and the pods will automatically get the new values