991 questions total · 14pages · All types, answers revealed
You have a Service named 'web' in namespace 'default'. Which DNS name resolves to the Service's ClusterIP?
This is the standard Service DNS name.
Why this answer
The DNS name for a Service follows the pattern <service>.<namespace>.svc.cluster.local. So 'web.default.svc.cluster.local' resolves to the Service's ClusterIP.
You need to temporarily access a pod's HTTP endpoint on port 8080 from your local machine. Which command should you use?
Correct command.
Why this answer
kubectl port-forward forwards a local port to a pod port.
You want to perform a canary deployment of a new version of your application. You create a Deployment named 'app-canary' with 1 replica and label 'version: canary'. The existing stable Deployment 'app-stable' has 3 replicas and label 'version: stable'. Both Deployments have the selector 'app: myapp'. You have a Service 'app-service' with selector 'app: myapp, track: stable'. How can you route traffic to the canary?
This routes traffic only to the canary pods via the Service.
Why this answer
To route traffic to the canary, the Service's selector must match the canary pod's labels. Option C adds a label 'track: canary' to the canary pods and updates the Service selector to 'app: myapp, track: canary'. However, this would remove the stable pods from the Service.
A better approach is to create a separate Service or use a more sophisticated selector. But among the options, C correctly updates both the pods and Service to match.
When using 'kubectl apply' vs 'kubectl create', which statement is correct?
This is accurate.
Why this answer
'kubectl apply' is declarative; it creates or updates resources based on the provided manifest. 'kubectl create' is imperative and will fail if the resource already exists.
Which kubectl command is used to view the rollout history of a Deployment?
Correct command to view rollout history.
Why this answer
The correct command is 'kubectl rollout history deployment <deployment-name>'. Option A is correct. Option B is for viewing rollout status.
Option C is not valid. Option D is for specific revision details.
Which field in the container spec controls the time Kubernetes waits after sending SIGTERM before sending SIGKILL during pod shutdown?
This field sets the grace period for the container to shut down gracefully after SIGTERM.
Why this answer
terminationGracePeriodSeconds specifies the duration after SIGTERM before SIGKILL is sent.
You have a Deployment named 'web-app' with 5 replicas. You want to perform a rolling update with a maximum of 2 extra pods during the update and allow at most 1 pod to be unavailable. Which YAML snippet correctly configures the rolling update strategy?
Correct values: maxSurge=2 allows up to 7 pods; maxUnavailable=1 allows 1 pod down.
Why this answer
Option A correctly sets maxSurge to 2 and maxUnavailable to 1. maxSurge specifies the maximum number of pods that can be created above the desired replicas (5+2=7). maxUnavailable specifies the maximum number of pods that can be unavailable during the update (1).
A StatefulSet is deployed with a headless service (clusterIP: None). The pods are named 'web-0', 'web-1', 'web-2'. What DNS name resolves to the specific IP of 'web-1'?
This is the correct DNS name for the pod.
Why this answer
For a headless service, pod DNS is of the form <pod-name>.<service-name>.<namespace>.svc.cluster.local.
You have a headless service 'db' in namespace 'data'. Pods in that namespace can resolve 'db.data.svc.cluster.local'. What is the effect of a headless service on DNS resolution?
DNS returns multiple A records with pod IPs.
Why this answer
A headless service (clusterIP: None) returns A records for the IPs of the pods matching the selector, rather than a single ClusterIP. This is used for StatefulSets where each pod needs a stable network identity.
Which TWO of the following are valid types of probes in Kubernetes?
A liveness probe checks if a container is still running.
Why this answer
The three standard probe types are liveness, readiness, and startup. Health is not a probe type, and survival is not a Kubernetes probe.
A pod has a readiness probe using tcpSocket on port 3306. The application listens on port 3306 but returns errors on database queries. What is the effect of the readiness probe?
tcpSocket probes only check if the port is accepting connections; they do not validate application-level health.
Why this answer
A readiness probe with tcpSocket only checks whether the TCP port is open and accepting connections. It does not verify application-level health, such as whether the application can process queries or return valid responses. Since port 3306 is open, the probe succeeds, and the pod is considered ready, even though the application returns errors on database queries.
Exam trap
The trap here is that candidates often assume readiness probes check application health or error responses, but a tcpSocket probe only verifies that the port is open, not that the application is working correctly.
How to eliminate wrong answers
Option A is wrong because readiness probe failures do not cause pod eviction; eviction is related to node resource pressure or taints, not probe results. Option C is wrong because a tcpSocket readiness probe does not evaluate application-level errors; it only checks if the TCP handshake succeeds on the specified port. Option D is wrong because readiness probe failures do not restart the container; only liveness probe failures trigger container restarts.
A developer deploys a set of Pods labeled app=frontend and wants to expose them internally within the cluster on a stable IP. Which resource should be used?
Correct: ClusterIP provides a stable internal IP.
Why this answer
A Service of type ClusterIP exposes the Pods on a stable internal IP address that is only reachable within the cluster. This is the default Service type and is ideal for internal communication between components, such as a frontend being accessed by a backend, without exposing the service outside the cluster.
Exam trap
The trap here is that candidates often confuse 'exposing internally' with 'exposing externally' and choose NodePort or LoadBalancer, forgetting that ClusterIP is the default and correct choice for internal-only stable IP access.
How to eliminate wrong answers
Option A is wrong because a NodePort Service exposes the Pods on a static port on each Node's IP address, making it accessible from outside the cluster, which is unnecessary and insecure for internal-only access. Option B is wrong because a LoadBalancer Service provisions an external load balancer (e.g., from a cloud provider) to expose the service to the internet, which is overkill and violates the requirement for internal-only exposure. Option D is wrong because an Ingress resource is not a Service; it provides HTTP/HTTPS routing rules to Services (typically ClusterIP) and is used for external traffic management, not for providing a stable internal IP directly.
You have a Dockerfile with a multi-stage build. The first stage is named 'builder' and uses 'golang:1.20' to compile a binary. The second stage uses 'alpine:3.18' and should copy the binary from the first stage. Which COPY instruction is correct?
This correctly copies from the 'builder' stage and is the recommended approach.
Why this answer
Option C is correct. In multi-stage builds, COPY --from=builder copies files from the stage named 'builder'. Option A incorrectly uses '--from 0' which would reference the first stage but by name is clearer.
Option B is valid but not the best practice. Option D is for adding remote URLs.
Which TWO of the following are valid reasons for using a startup probe?
By disabling liveness probes during startup, the startup probe prevents premature restarts.
Why this answer
Startup probes are used for containers that take a long time to start and need to delay liveness and readiness probes. They are not used for containers that start quickly.
A Service named `api` in namespace `default` has multiple endpoints. You run `kubectl get endpoints api` and see no IPs. What is the most likely cause?
If the selector does not match any pod labels, no endpoints are created.
Why this answer
Endpoints are created based on pod labels matching the Service's selector. If no pods match, endpoints will be empty.
A container image requires running as UID 0 but you need to comply with a 'restricted' Pod Security Admission policy. Which SecurityContext setting allows this while still passing the policy?
The restricted policy requires runAsNonRoot: true, which prohibits running as UID 0. The container must be modified to run as a non-root user.
Why this answer
The 'restricted' Pod Security Admission policy requires that containers run as non-root (runAsNonRoot: true) and prohibits setting runAsUser to 0. Since the image requires UID 0, no SecurityContext setting can override this policy constraint; the only way to comply is to modify the image to run as a non-root user. Therefore, option B is correct.
Exam trap
The trap here is that candidates assume they can override the restricted policy with a SecurityContext setting like runAsUser: 0, not realizing that the restricted policy explicitly forbids UID 0 and enforces runAsNonRoot: true, making any such override invalid.
How to eliminate wrong answers
Option A is wrong because allowPrivilegeEscalation: true is actually prohibited by the restricted policy (it must be false), and it does not address the UID 0 requirement. Option C is wrong because runAsNonRoot: true conflicts with running as UID 0, and adding SYS_ADMIN capability is forbidden by the restricted policy (only NET_BIND_SERVICE is allowed). Option D is wrong because runAsUser: 0 with runAsNonRoot: false explicitly violates the restricted policy's requirement that runAsNonRoot must be true and runAsUser must not be 0.
A developer wants to inject database credentials into a pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-creds' with keys 'username' and 'password'. Which pod spec snippet correctly injects both values as environment variables?
envFrom with secretRef loads all keys from the Secret as environment variables.
Why this answer
Option C is correct because `envFrom` with `secretRef` injects all key-value pairs from a Secret as environment variables into the pod. This directly satisfies the requirement to inject both 'username' and 'password' from the 'db-creds' Secret without needing to specify each key individually.
Exam trap
The trap here is that candidates often confuse `envFrom` with `env` and use `secretKeyRef` under `envFrom` (Option D) or mistakenly use `configMapRef` for secrets (Option B), failing to recognize that `envFrom` requires `secretRef` to inject all keys from a Secret.
How to eliminate wrong answers
Option A is wrong because it only injects a single key ('username') as an environment variable, missing the 'password' key; it uses `env` with `secretKeyRef` for one value, not `envFrom` for all values. Option B is wrong because `configMapRef` references a ConfigMap, not a Secret; ConfigMaps are for non-sensitive data, while database credentials require a Secret. Option D is wrong because `secretKeyRef` is not a valid field under `envFrom`; `envFrom` uses `secretRef` to reference the entire Secret, while `secretKeyRef` is used under `env` for individual key references.
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?
Correctly maps the secret key to the desired environment variable name.
Why this answer
Option A is correct because 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.
Exam trap
The trap here is that candidates often confuse `secretKeyRef` with `configMapKeyRef` or incorrectly use `secretRef` directly under `env`, forgetting that `secretKeyRef` must be nested under `valueFrom`.
How to eliminate wrong answers
Option B is wrong because `configMapKeyRef` is used to reference keys from a ConfigMap, not a Secret; using it with a Secret name would fail to resolve the value. Option C is wrong because `envFrom` with `secretRef` injects all keys from the Secret as environment variables, but the developer specifically wants only the `password` key exposed as `DB_PASSWORD`, not all keys. Option D is wrong because `secretRef` is not a valid field under `env`; the correct field is `valueFrom.secretKeyRef`, and the syntax shown is incomplete and invalid.
Which TWO of the following are valid sources for creating a ConfigMap?
Using --from-file.
Why this answer
A file is a valid source for creating a ConfigMap because the `kubectl create configmap` command supports the `--from-file` flag, which reads the entire contents of a file and creates a key-value pair where the key defaults to the filename. This is commonly used to inject configuration data like application properties or scripts into a Pod.
Exam trap
CNCF often tests the distinction between valid sources (`--from-file`, `--from-literal`) and invalid ones like a directory or Secret, tricking candidates into thinking a directory or Secret can be directly used as a source for `kubectl create configmap`.
A pod is in CrashLoopBackOff state. You need to view the last few lines of its logs to understand why it is crashing. Which command is most appropriate?
Shows only the last 20 lines, ideal for recent errors.
Why this answer
The `--tail=20` flag limits the output to the last 20 lines of the pod's logs, which is the most efficient way to see the recent crash-related errors without scrolling through the entire log history. In a CrashLoopBackOff state, the pod is repeatedly restarting, so viewing the tail of the logs directly shows the most recent failure messages, which is the standard diagnostic approach.
Exam trap
CNCF often tests the distinction between `kubectl logs` and `kubectl logs -f`, where candidates mistakenly choose the `-f` option thinking it shows 'the last few lines' because of the 'follow' concept, but `-f` actually streams new logs and does not limit output to a specific number of lines.
How to eliminate wrong answers
Option A is wrong because `kubectl logs -f` follows (tails) the log stream continuously, which is useful for real-time monitoring but not for viewing the last few lines of a crashed pod's logs; it will hang waiting for new output that may never come if the pod is not actively logging. Option B is wrong because `kubectl logs my-pod` without `--tail` will output the entire log history, which can be excessively long and inefficient for quickly identifying the crash cause, especially in pods with many restarts. Option D is wrong because `kubectl get events` shows cluster events (e.g., scheduling, pulling images) but does not display the application's stdout/stderr logs; it provides operational context but not the specific error messages from the crashing container.
A ClusterIP service named 'db-service' in namespace 'data' is not reachable from a pod in the same namespace. The pod's /etc/resolv.conf shows 'search data.svc.cluster.local svc.cluster.local cluster.local'. Using the pod, which command tests DNS resolution for the service?
Directly queries DNS for the service's full domain name.
Why this answer
Option C is correct. The full DNS name for a service is 'service.namespace.svc.cluster.local'. Using 'nslookup db-service.data.svc.cluster.local' will test resolution.
In-cluster DNS resolves short names within the same namespace, so 'db-service' should work, but the question asks for a command that tests DNS resolution. Option C explicitly uses the full name.
Which of the following is a valid NetworkPolicy that allows ingress traffic only from pods with label 'role: frontend' in any namespace?
Empty namespaceSelector selects all namespaces, and podSelector selects frontend pods.
Why this answer
NamespaceSelector selects namespaces, and podSelector selects pods within those namespaces.
You are responsible for deploying a critical application that must be highly available. The application consists of a single pod that should always be running on a node that has an SSD. You have two node pools: one with standard HDD and one with SSD. The application must be rescheduled immediately if the node fails. You create a Deployment with replicas: 1 and a nodeSelector for the SSD label. However, after a node failure, the pod is not rescheduled on another SSD node for several minutes. You check the Deployment and it shows the desired replica count is 1 but the current replica count is 0. What is the most likely reason for the delay?
Until the pod is confirmed deleted, ReplicaSet may not create a replacement immediately.
Why this answer
Option C is correct because when a node fails, the pod on that node enters the Terminating state (as the kubelet is unreachable to confirm deletion). The ReplicaSet controller waits for the pod to be fully deleted before creating a replacement, due to the default terminationGracePeriodSeconds (30s) plus the node failure detection time (up to node-monitor-grace-period, default 40s). This delay is compounded by the pod's status not being updated until the node controller marks the node as unreachable, causing the ReplicaSet to not immediately create a new pod.
Exam trap
The trap here is that candidates often assume a Deployment with replicas: 1 will immediately create a new pod upon node failure, but they overlook the pod's Terminating state and the ReplicaSet's dependency on pod deletion before creating a replacement, which is a common source of delay in real-world scenarios.
How to eliminate wrong answers
Option A is wrong because progressDeadlineSeconds controls the maximum time for a Deployment to make progress (e.g., rolling out new pods), not the speed of rescheduling after a node failure; it does not affect the ReplicaSet's behavior when a pod is stuck in Terminating. Option B is wrong because a readiness probe failing would cause the pod to be marked as not ready but would not prevent the ReplicaSet from creating a new pod; the issue is that no new pod is created at all, not that it fails readiness checks. Option D is wrong because the nodeSelector for SSD is correctly configured and would not prevent scheduling on available SSD nodes; the problem is that the ReplicaSet is not attempting to schedule a new pod due to the Terminating state, not that scheduling fails.
You have a Deployment named 'web-app' with 5 replicas. You run 'kubectl set image deployment/web-app app=nginx:1.21'. What is the effect of this command?
kubectl set image updates the image for a container in a Deployment, initiating a rolling update if the strategy is RollingUpdate.
Why this answer
The command updates the image of the container named 'app' to nginx:1.21, triggering a rolling update of the Deployment.
A developer wants to debug a running container in a Pod named 'web-app' in namespace 'dev'. Which command attaches an ephemeral container with the 'nicolaka/netshoot' image for network debugging?
kubectl debug creates an ephemeral container in the pod with the specified image.
Why this answer
Option C is correct. kubectl debug with --image and -c creates an ephemeral container. Option A uses attach which is for existing containers. Option B uses exec into a new container but ephemeral is the correct approach.
Option D uses run but does not target the pod.
You need to expose a Deployment named 'web' on port 80 internally within the cluster. Which command creates the appropriate Service?
This creates a ClusterIP Service with the same selectors as the deployment's pod template labels.
Why this answer
kubectl expose exposes a resource as a Kubernetes Service. The default type is ClusterIP.
What is the purpose of the 'kubectl rollout status' command?
It shows whether the rollout succeeded or is still in progress.
Why this answer
The command 'kubectl rollout status' tracks the progress of a rollout until it completes or fails.
Which THREE of the following are valid kubectl commands for managing rollouts? (Select 3)
Shows rollout status.
Why this answer
kubectl rollout commands: status, history, undo, pause, resume.
You have a multi-container pod with a main container and a sidecar container that collects logs. The sidecar container must start before the main container and must keep running. Which type of container is the sidecar?
Correct: sidecar containers are regular containers defined in the pod's containers list.
Why this answer
A sidecar container is a regular container that runs alongside the main container in the same pod. It is not an init container because init containers run to completion before the main containers start. The sidecar typically runs continuously, so it is a regular container.
You are a platform engineer managing a production Kubernetes cluster. A team deploys a stateful application called 'inventory-service' with 3 replicas using a StatefulSet. Each pod writes logs to a persistent volume via a PersistentVolumeClaim. Recently, the team reports that the application becomes unresponsive after running for a few hours. You notice that the pods are still running (READY 1/1) but the application does not respond to HTTP requests. You exec into one pod and find that the disk is 100% full. The PVC is backed by a cloud disk (e.g., AWS EBS). You check the pod's resource limits and see that memory and CPU are not exhausted. The container logs are not rotated. Which course of action should you take to resolve the immediate issue and prevent recurrence?
Immediate relief via resizing; prevention via log rotation.
Why this answer
Option A is correct because the immediate issue is a full disk caused by unrotated logs. Increasing the PVC size provides temporary relief, while configuring log rotation inside the container (e.g., using logrotate or the application's own rotation) prevents the disk from filling up again. This directly addresses the root cause without changing the application's logging behavior or introducing unnecessary sidecars.
Exam trap
CNCF often tests the distinction between logs written to stdout (handled by container runtime) versus logs written to a file inside the container (which require explicit rotation or external management).
How to eliminate wrong answers
Option B is wrong because compressing and archiving logs to remote storage does not free disk space on the local PVC; the logs remain on disk until deleted, so the disk will still fill up. Option C is wrong because changing the application to log to stdout and configuring Docker log rotation on the host does not affect logs written to a persistent volume; the application is writing logs to a file inside the container, not to stdout. Option D is wrong because using an emptyDir volume with a size limit would only cap the sidecar's own log storage, not the application's logs written to the PVC; the application's logs would still fill the PVC.
A pod named 'web-app' is running but has no environment variables. The developer wants to inject a variable 'DB_URL=postgres://db:5432' from a ConfigMap named 'db-config'. Which pod spec snippet correctly achieves this?
Correctly references ConfigMap key.
Why this answer
Option D is correct because it uses the `configMapKeyRef` field under `valueFrom` to inject a specific key from a ConfigMap as an environment variable. This allows the pod to consume the `DB_URL` value from the `db-config` ConfigMap without exposing it as a file or using `envFrom`.
Exam trap
CNCF often tests the distinction between `envFrom` (which imports all keys) and `valueFrom.configMapKeyRef` (which imports a single key), and candidates confuse the syntax by placing `key` directly under `configMapRef` instead of using the correct nested structure.
How to eliminate wrong answers
Option A is wrong because it hardcodes the value directly in the pod spec, ignoring the requirement to inject from a ConfigMap. Option B is wrong because `envFrom` with `configMapRef` imports all keys from the ConfigMap as environment variables, but the syntax is incorrect: `key` is not a valid field under `configMapRef` (it belongs under `configMapKeyRef` inside `valueFrom`). Option C is wrong because `secretKeyRef` is used to reference a Secret, not a ConfigMap, and the resource is named `db-config`, which implies a ConfigMap.
Which THREE statements correctly describe Kustomize? (Select THREE.)
Yes, kustomization.yaml is the core file.
Why this answer
Kustomize is a configuration management tool. It can patch resources, is built into kubectl via -k, and uses a kustomization.yaml file. It does not require a separate server.
Which THREE of the following are valid use cases for a Headless Service (clusterIP: None)?
DNS returns all Pod IPs for headless service.
Why this answer
Option A is correct because a Headless Service (clusterIP: None) does not provide a virtual IP or load balancing. Instead, DNS queries return A/AAAA records containing the IP addresses of all healthy Pods selected by the service. This allows clients to discover and connect directly to individual Pod IPs, which is essential for stateful applications or custom discovery patterns.
Exam trap
The trap here is that candidates often confuse the purpose of a Headless Service with a regular ClusterIP Service, mistakenly thinking it can provide external exposure or a stable virtual IP, when in fact it is designed for direct Pod-to-Pod discovery without load balancing.
A pod is running but the application inside is not serving traffic. The team runs 'kubectl exec -it <pod> -- curl localhost:8080' and gets 'Connection refused'. What is the most likely cause?
Connection refused indicates nothing listening on that port.
Why this answer
The 'Connection refused' error from curl indicates that the TCP connection to port 8080 was actively rejected by the kernel, meaning no process is listening on that port inside the container. This is most commonly caused by the application not starting, crashing before binding, or being configured to listen on a different port (e.g., 3000, 8443). The error is immediate and does not suggest a timeout or network-level block.
Exam trap
CNCF often tests the distinction between 'Connection refused' (no listener) and 'Connection timed out' (network block) — candidates mistakenly attribute the error to NetworkPolicy or resource issues, but the immediate RST is a definitive sign of a missing socket, not a network filter.
How to eliminate wrong answers
Option A is wrong because full container logs or slow disk writes would cause performance degradation or write errors, not a TCP 'Connection refused' — the kernel would still accept the connection if a socket is listening. Option B is wrong because NetworkPolicy operates at the network layer (iptables/eBPF) to allow or deny traffic between pods, but 'kubectl exec' runs inside the pod's network namespace, bypassing NetworkPolicy entirely; a NetworkPolicy cannot block localhost traffic. Option D is wrong because a failing liveness probe would cause the container to be restarted, but during the restart window the application might briefly be unavailable; however, 'Connection refused' is a persistent socket-level rejection, not a transient restart behavior, and a failing probe would also show events or crash loop status, not just a curl error.
A multi-stage build has two stages named 'builder' and 'final'. Which instruction copies artifacts from the builder stage to the final stage?
Correct syntax to copy from a previous stage.
Why this answer
Option B is correct. 'COPY --from=builder' copies from a previous stage. Option A uses 'ADD', which could work but COPY is preferred for clarity. Option C and D have incorrect syntax.
You run 'kubectl get pods -o wide' and see that a pod's NODE column shows 'node-1'. You want to see more details about that node's resource usage. Which command should you use?
This shows CPU and memory usage for the specified node.
Why this answer
Option D is correct because `kubectl top node node-1` directly displays real-time resource usage (CPU and memory) for the specified node, which is exactly what you need when you want to see more details about a node's resource consumption after identifying the node from `kubectl get pods -o wide`.
Exam trap
The trap here is that candidates confuse `kubectl top node` with `kubectl top pod` or `kubectl describe node`, mistakenly thinking that `describe` provides real-time resource usage or that `top pod` can target a node by name.
How to eliminate wrong answers
Option A is wrong because `kubectl top pods --all-namespaces` shows resource usage for pods across all namespaces, not for a specific node. Option B is wrong because `kubectl describe node node-1` shows detailed metadata, conditions, and capacity of the node, but not real-time resource usage metrics like CPU and memory consumption. Option C is wrong because `kubectl top pod node-1` attempts to get resource usage for a pod named 'node-1', not for a node; the command syntax is invalid for node-level metrics.
A developer creates a Role and RoleBinding in the namespace 'development' to grant list pods permission to a service account. Which manifest snippet correctly defines the Role?
Correct apiGroups for core resources is empty string.
Why this answer
Option C is correct because pods belong to the core API group, which is represented by an empty string `""` in the `apiGroups` field. The `list` verb is sufficient to list pods, and the `resources` field correctly specifies `pods`. This Role grants the service account permission to list pods in the `development` namespace.
Exam trap
The trap here is that candidates often confuse the core API group with a named group like `"apps"` or use a wildcard `"*"` instead of the correct empty string `""`, leading to rules that either don't apply or are overly permissive.
How to eliminate wrong answers
Option A is wrong because `apiGroups: ["pods"]` is invalid; `pods` is a resource, not an API group, and the correct API group for pods is the core group (`""`). Option B is wrong because `apiGroups: ["apps"]` is incorrect; pods are not part of the `apps` API group (which includes Deployments, StatefulSets, etc.), so the rule would not apply to pods. Option D is wrong because `apiGroups: ["*"]` is a wildcard that matches all API groups, which is overly broad and not the precise way to specify the core group; the correct value for the core group is an empty string.
A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/4 nodes are available: 4 Insufficient memory'. Which action will resolve the issue?
Correct: reducing memory usage on nodes may allow the pod to be scheduled.
Why this answer
The pod cannot be scheduled because no node has enough memory. Deleting other pods that are using memory would free up resources. Scaling the Deployment would increase the number of pods, worsening the problem.
Modifying the node selector would not help if the selected nodes still have insufficient memory.
Arrange the steps to create a Kubernetes Deployment with a rolling update strategy.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
First, define the Deployment in YAML. Then apply it. After an update, modify the YAML and re-apply; kubectl performs rolling update automatically.
Which THREE of the following are valid fields for configuring a probe in Kubernetes? (Select 3)
Number of seconds after the container starts before the probe begins.
Why this answer
Option A is correct because `initialDelaySeconds` is a valid field in a Kubernetes probe configuration (e.g., livenessProbe, readinessProbe, startupProbe). It defines the number of seconds after the container has started before the probe is initiated, allowing the application time to initialize before health checks begin.
Exam trap
The trap here is that candidates confuse `intervalSeconds` with `periodSeconds` and `retrySeconds` with `failureThreshold`, as the incorrect options sound plausible but do not exist in the Kubernetes API specification.
A pod with a startup probe configured is taking longer than usual to start. The startup probe has 'failureThreshold: 10' and 'periodSeconds: 5'. What is the maximum time the pod has to start before it is restarted?
failureThreshold * periodSeconds = 10 * 5 = 50 seconds.
Why this answer
The maximum time a pod has to start before being restarted is calculated by multiplying the startup probe's `failureThreshold` (10) by its `periodSeconds` (5), which equals 50 seconds. This is because the startup probe runs every 5 seconds, and after 10 consecutive failures (i.e., the probe never succeeds within that window), the kubelet restarts the container. The startup probe is specifically designed to give slow-starting applications a grace period before the liveness probe takes over.
Exam trap
The trap here is that candidates often forget to multiply `failureThreshold` by `periodSeconds` and instead pick a single value (like 10 or 5) or add them, missing the core formula for probe timeout calculation.
How to eliminate wrong answers
Option B (10 seconds) is wrong because it incorrectly assumes the `failureThreshold` alone (10) is the time limit, ignoring the `periodSeconds` multiplier. Option C (30 seconds) is wrong because it might result from multiplying `failureThreshold` (10) by a mistaken `periodSeconds` of 3, or from adding the two values (10+5=15) and doubling, but it does not match the correct product of 10*5=50. Option D (60 seconds) is wrong because it likely comes from misreading `periodSeconds` as 6 or adding an extra 10 seconds; the correct calculation is strictly `failureThreshold * periodSeconds`.
A pod's securityContext has 'allowPrivilegeEscalation: false' and 'capabilities: { drop: ["ALL"] }'. Which statement is true?
Correct interpretation.
Why this answer
Option B is correct because setting 'allowPrivilegeEscalation: false' prevents processes from gaining more privileges than their parent (e.g., via setuid binaries or kernel exploits), and dropping all capabilities with 'capabilities: { drop: ["ALL"] }' removes every Linux capability from the container's bounding set. Together, these ensure the container runs with no extra capabilities and cannot escalate privileges, even if running as root.
Exam trap
The trap here is that candidates assume dropping all capabilities still allows privilege escalation via setuid binaries, but 'allowPrivilegeEscalation: false' specifically blocks that path, making the combination a hard security boundary.
How to eliminate wrong answers
Option A is wrong because 'allowPrivilegeEscalation: false' explicitly blocks setuid binaries from granting elevated privileges, so the container cannot gain capabilities via that mechanism. Option C is wrong because dropping all capabilities means the container does not run with full privileges, even if the user is root; root without capabilities is restricted. Option D is wrong because 'drop: ["ALL"]' removes all Linux capabilities, so the container does not run with any capabilities, let alone all of them.
A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?
OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.
Why this answer
Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.
Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.
A developer needs to expose database credentials to a Pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-secret' with keys 'username' and 'password'. Which two methods correctly inject these values? (Choose two.)
Correct way to inject specific keys from a Secret.
Why this answer
Option C is correct because `valueFrom` with `secretKeyRef` allows you to reference a specific key from a Kubernetes Secret and inject its value as an environment variable. This is the standard method for exposing individual secret keys to a Pod. Option E is correct because `envFrom` with `secretRef` injects all keys from the referenced Secret as environment variables into the container, which is efficient when you need to expose multiple keys without defining each one individually.
Exam trap
CNCF often tests the distinction between `valueFrom` with `secretKeyRef` for individual keys versus `envFrom` with `secretRef` for bulk injection, and the trap here is that candidates confuse `configMapKeyRef` with `secretKeyRef` or think that mounting a Secret as a volume automatically creates environment variables from the file contents.
Which TWO commands can be used to create a Secret from a file? (Select 2)
--from-file with key=filename syntax.
Why this answer
Option A is correct because `kubectl create secret generic mysecret --from-file=key=file.txt` creates a generic Secret by reading the contents of `file.txt` and storing it under the key `key`. This is the standard method to import file data into a Secret, where the file content is base64-encoded automatically by Kubernetes.
Exam trap
The trap here is that candidates often confuse `--from-file` with `--from-env-file` or think `kubectl create configmap` can create Secrets, but the CKAD exam tests precise command syntax and the distinction between Secret types (generic vs. TLS) and resource types (ConfigMap vs. Secret).
Which command attaches an ephemeral container to a running pod for debugging?
This creates an ephemeral container attached to the pod.
Why this answer
Option A is correct. 'kubectl debug' with '-c' or '--container' specifies the ephemeral container name. Option B is for exec. Option C is for logs.
Option D is for attach but not for ephemeral containers.
An administrator wants to enforce that all Pods in a namespace run with a read-only root filesystem. Which admission controller should be configured?
PSA enforces predefined security profiles including restricted which mandates readOnlyRootFilesystem.
Why this answer
Pod Security Admission (PSA) is the correct choice because it enforces Pod Security Standards (PSS) at the namespace level, including the `Restricted` profile which mandates a read-only root filesystem (`readOnlyRootFilesystem: true`). PSA is a built-in admission controller that evaluates pod specifications against predefined security policies and rejects pods that violate them, making it the appropriate tool for this requirement.
Exam trap
The trap here is that candidates confuse admission controllers that manage resource quotas (LimitRange, ResourceQuota) with those that enforce security policies, or mistakenly think a webhook is required when a built-in controller like PSA already provides the needed enforcement.
How to eliminate wrong answers
Option A is wrong because LimitRange is used to set default resource requests/limits and enforce min/max constraints on CPU and memory per pod or container, not to enforce filesystem security policies like read-only root filesystem. Option B is wrong because ResourceQuota limits aggregate resource consumption (e.g., total CPU, memory, or count of objects) in a namespace, but does not inspect or enforce pod-level security attributes such as filesystem access. Option C is wrong because MutatingAdmissionWebhook can modify pod specs (e.g., inject a read-only root filesystem), but it is not a built-in admission controller for enforcing security policies; it requires custom development and does not natively enforce the read-only root filesystem constraint without additional logic.
Which command creates a Secret named 'db-secret' with two keys, 'username' and 'password', from literal values?
This command correctly creates a generic secret with literal key-value pairs.
Why this answer
Option A is correct because `kubectl create secret generic` is the correct command syntax for creating a generic (opaque) Secret from literal key-value pairs. The `--from-literal` flag allows you to specify each key and its value directly on the command line, making it the appropriate choice for this task.
Exam trap
The trap here is that candidates often forget the `generic` subcommand or confuse `--from-literal` with `--from-file` or a non-existent `--literal` flag, leading to syntax errors or unintended behavior.
How to eliminate wrong answers
Option B is wrong because it omits the required subcommand `generic`; the correct syntax is `kubectl create secret generic`. Option C is wrong because `--from-file` expects a file path, not a literal key=value pair; using `--from-file=username=admin` would attempt to read a file named 'admin' and assign its content to key 'username', which is not the intended behavior. Option D is wrong because the flag `--literal` does not exist; the correct flag is `--from-literal`.
Which THREE of the following are valid reasons to use a startup probe? (Select THREE.)
Startup probe accommodates varying startup durations.
Why this answer
Option A is correct because a startup probe is specifically designed for containers that have a variable or long initialization time. It allows the kubelet to delay the start of liveness and readiness probes until the application has finished starting up, preventing premature failures.
Exam trap
CNCF often tests the distinction between probe types, and the trap here is confusing the startup probe's role of delaying other probes with the readiness probe's role of controlling service traffic, or the liveness probe's role of restarting unhealthy containers.
Which command creates a Service named 'web' of type ClusterIP that selects pods with label 'tier: frontend' and exposes port 80?
This creates a ClusterIP service named 'web' that selects pods from the deployment 'frontend' which should have label 'tier: frontend'.
Why this answer
kubectl expose deployment or pod requires a resource with labels. Option C uses a deployment with label 'tier: frontend'. Option A uses NodePort.
Option B uses run. Option D is not a valid command (create service clusterip requires --tcp flag).
A developer creates a ServiceAccount 'my-sa' in namespace 'default'. They want to prevent pods from automatically mounting the ServiceAccount token. Which field should be set to false in the pod spec?
This disables automatic mounting of the service account token.
Why this answer
Option B is correct because setting `automountServiceAccountToken: false` in the pod spec explicitly prevents the automatic mounting of the ServiceAccount token into the pod. This is the standard Kubernetes field for controlling token mounting at the pod level, overriding the default behavior where the token is mounted automatically.
Exam trap
CNCF often tests the distinction between pod-level and container-level fields, and the trap here is that candidates may incorrectly assume `automountServiceAccountToken` can be set under `containers` (option D) or that specifying `serviceAccountName` alone (option A) is sufficient to control token mounting.
How to eliminate wrong answers
Option A is wrong because `serviceAccountName: my-sa` only specifies which ServiceAccount to use, but does not control token mounting; the token would still be mounted automatically unless explicitly disabled. Option C is wrong because it redundantly specifies both `serviceAccountName` and `automountServiceAccountToken`, but the correct field name is `automountServiceAccountToken` (not `automountServiceAccountToken` with a typo) and the placement is at the pod spec level, not as a separate line; however, the core issue is that the question asks for the field to set to false, and option C includes an unnecessary `serviceAccountName` specification, making it less precise than B. Option D is wrong because `automountServiceAccountToken` is a pod-level field, not a container-level field; placing it under `containers` is invalid and would be ignored by the Kubernetes API.
In a Kubernetes pod definition, which field specifies the container image to use?
The 'image' field specifies the container image to pull.
Why this answer
Option B is correct. The container image is specified under the 'image' field inside each container definition in the pod spec. 'containers.name' is for naming the container.
Which TWO options are valid annotations for a Pod?
Correct. Annotations can contain descriptive information.
Why this answer
Annotations are key-value pairs that can contain any non-identifying metadata. They are not used for selection.
An Ingress resource is created with the following YAML: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-svc port: number: 80 Which of the following requests will be routed to the api-svc Service?
Correct. Matches host example.com and path starts with /api.
Why this answer
The Ingress routes requests with host 'example.com' and path prefix '/api' to api-svc. Option A matches both conditions. Option B has wrong host.
Option C has wrong path (does not start with /api). Option D has wrong path type requirement (exact match would be needed for trailing slash behavior, but here it's Prefix).
Which API version is correct for a Deployment in Kubernetes v1.29?
This is the current stable version.
Why this answer
Option D (apps/v1) is correct because the Deployment API version apps/v1 has been the stable version since Kubernetes v1.9, and it is the only correct version for creating Deployments in Kubernetes v1.29. The apps/v1 API group is the current, stable, and recommended version for managing Deployments, ReplicaSets, and other workload resources.
Exam trap
The trap here is that candidates may confuse the core v1 API group (used for Pods) with the apps/v1 group (used for Deployments), or mistakenly think that beta versions like apps/v1beta2 are still valid in recent Kubernetes releases.
How to eliminate wrong answers
Option A is wrong because extensions/v1beta1 was deprecated in Kubernetes v1.9 and removed entirely in v1.16; it is no longer available in v1.29. Option B is wrong because v1 is the core API group used for resources like Pods, Services, and ConfigMaps, but Deployments belong to the apps API group, not the core group. Option C is wrong because apps/v1beta2 was deprecated in Kubernetes v1.9 and removed in v1.16; it is not a valid API version in v1.29.
A Job must run 10 times in total, with up to 3 pods running simultaneously. Which fields should be set?
completions=10 sets total runs, parallelism=3 sets max concurrent pods.
Why this answer
Option B is correct. completions=10 ensures the Job runs to completion 10 times, and parallelism=3 allows up to 3 pods running concurrently. Option A swaps the fields. Option C sets parallelism too high.
Option D uses 'successfulJobsHistoryLimit' which is not relevant.
A pod uses a Secret 'db-secret' with keys 'username' and 'password'. Which environment variable definition correctly exposes the 'password' as an env var named 'DB_PASSWORD'?
Correctly references the secret and key using secretKeyRef.
Why this answer
Option B is correct because it uses `valueFrom.secretKeyRef` to reference the specific key `password` from the Secret `db-secret`, mapping it to the environment variable `DB_PASSWORD`. This is the standard Kubernetes method to expose a single key from a Secret as an environment variable with a custom name.
Exam trap
The trap here is that candidates often confuse `envFrom` with `env` and `secretRef` with `configMapKeyRef`, or assume that `envFrom` allows renaming keys, when in fact it only imports keys as-is, making Option C a distractor for those who want to import all keys but forget the naming requirement.
How to eliminate wrong answers
Option A is wrong because it hardcodes the password as a literal string in the Pod spec, which defeats the purpose of using a Secret and exposes sensitive data in plaintext. Option C is wrong because `envFrom` with `secretRef` imports all keys from the Secret as environment variables, but it does not allow renaming the variable to `DB_PASSWORD`; the key name `password` would become the env var name, not `DB_PASSWORD`. Option D is wrong because `configMapKeyRef` is used to reference ConfigMaps, not Secrets; Secrets require `secretKeyRef`.
Which TWO kubectl commands can be used to view the rollout history of a Deployment named 'web-app'?
Displays rollout history with revision numbers.
Why this answer
Option A uses 'kubectl rollout history' which is correct. Option B uses 'kubectl describe deployment' which shows details but not revision history. Option C uses 'kubectl rollout status' which shows current status but not history.
Option D incorrectly uses 'rollout history' with a subcommand. Option E uses 'kubectl get rollout' which is not a valid resource.
Which of the following correctly describes the purpose of a PodSecurityPolicy (PSP) in Kubernetes? (Note: PSP is deprecated in v1.21+ and removed in v1.25; Pod Security Admission is the replacement.)
PSP is deprecated since Kubernetes v1.21 and removed in v1.25. Pod Security Admission is the successor.
Why this answer
Option A is correct because PodSecurityPolicy (PSP) was indeed deprecated in Kubernetes v1.21 and removed in v1.25, with Pod Security Admission (PSA) as its official replacement. PSA uses built-in Pod Security Standards (baseline, restricted, privileged) enforced via admission controllers and labels, eliminating the need for a separate admission webhook or CRD-based policy object.
Exam trap
The trap here is that candidates may remember PSP as a namespace-scoped resource (Option C) because it is often associated with namespaces in documentation, but it is actually cluster-scoped, and the deprecation timeline (Option A) is a frequent distractor for those who haven't kept up with Kubernetes version changes.
How to eliminate wrong answers
Option B is wrong because PSP is not applied automatically; it requires explicit RBAC authorization (use of the `use` verb on the PSP resource for the pod's service account) and an admission controller (`PodSecurityPolicy`) to be enabled in the API server. Option C is wrong because PSP is a cluster-scoped resource, not namespace-scoped; it applies across all namespaces unless restricted by RBAC. Option D is wrong because PSP can control container security contexts (e.g., `privileged`, `runAsUser`, `seLinuxOptions`, `capabilities`) via its spec fields, which is its primary function.
A pod is configured with 'securityContext.seccompProfile.type: RuntimeDefault' but the container still attempts to use a syscall that is blocked by the default seccomp profile. What happens?
The blocked syscall returns an error, and the application may or may not handle it gracefully.
Why this answer
Option D is correct because when a container uses a syscall blocked by the seccomp profile, the syscall itself fails (returns an error like EPERM or is killed by SIGSYS), but the container process can handle that error and continue running. The `RuntimeDefault` profile applies Docker's default seccomp profile, which blocks around 44 syscalls (e.g., `mount`, `ptrace`, `perf_event_open`), but does not terminate the container unless the process exits due to the failed syscall. The container is not killed by Kubernetes; only the specific syscall is denied by the kernel's seccomp mechanism.
Exam trap
The trap here is that candidates assume any security violation immediately kills the container or evicts the pod, but seccomp violations only fail the specific syscall, and the container may continue if the process handles the error.
How to eliminate wrong answers
Option A is wrong because the container is not killed by Kubernetes; the seccomp policy causes the syscall to fail, but the container process may continue if it handles the error gracefully. Option B is wrong because pod eviction by the kubelet occurs for resource constraints or node-level issues (e.g., memory pressure, disk pressure), not for seccomp violations. Option C is wrong because `RuntimeDefault` does not allow all syscalls; it applies a restrictive default profile that blocks dangerous syscalls, so a blocked syscall will fail.
You want to update a Deployment's image from nginx:1.20 to nginx:1.21. Which command will perform a rolling update?
This command directly sets the new image and triggers a rolling update.
Why this answer
The correct command to update a Deployment's image and trigger a rolling update is 'kubectl set image deployment/my-deployment nginx=nginx:1.21'.
You run 'kubectl get events' and see an event 'FailedScheduling' for a pod. What is the most common cause?
The scheduler cannot find a node that satisfies the pod's resource requirements.
Why this answer
The 'FailedScheduling' event indicates that the Kubernetes scheduler could not find a suitable node to place the pod. The most common cause is insufficient node resources (CPU, memory, or ephemeral storage) to meet the pod's resource requests defined in the pod spec. The scheduler uses the `kube-scheduler` component to evaluate node fit based on predicates like `PodFitsResources`, and if no node satisfies the requested resources, the pod remains in a Pending state with this event.
Exam trap
The trap here is that candidates confuse 'FailedScheduling' with pod runtime failures (like image pull or probe failures), but scheduling events occur before the pod is bound to a node, so only resource-related or node affinity issues apply.
How to eliminate wrong answers
Option B is wrong because a container image pull failure generates a 'Failed' or 'ErrImagePull' event, not 'FailedScheduling', and is handled by the kubelet on an already scheduled node. Option C is wrong because a liveness probe failure causes the kubelet to restart the container, not a scheduling failure; it would produce a 'Unhealthy' or 'BackOff' event. Option D is wrong because a Deployment update that deletes a pod triggers a 'Killing' event and the pod is terminated, not left unscheduled; 'FailedScheduling' occurs before the pod is placed on any node.
Which kubectl command creates a ConfigMap named 'app-config' from a file named 'config.properties'?
This creates a ConfigMap named app-config with a data entry where the key is 'config.properties' and value is the file content.
Why this answer
Option A is correct because `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.
Exam trap
The trap here is that candidates confuse `--from-file` (which imports a file as a single key-value pair) with `--from-env-file` (which imports a file of environment variables as multiple key-value pairs), or mistakenly think `--from-literal` can accept a file path.
How to eliminate wrong answers
Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to reference a file; using `--from-literal=config.properties` would treat 'config.properties' as a literal string key with no value, which is invalid. Option C is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option D is wrong because `--from-env-file` is used to create a ConfigMap from a file containing environment variable definitions in KEY=VALUE format (one per line), not from a generic properties file; it would parse the file differently and may not produce the expected single-key ConfigMap.
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?
This creates an ephemeral container in the same pod for debugging, even if the main container is failing.
Why this answer
kubectl debug with the -it flag creates an ephemeral container for interactive debugging.
Which THREE commands can be used to get detailed information about a pod named 'my-pod'? (Choose three.)
This outputs the full JSON definition of the pod.
Why this answer
Option B is correct because `kubectl get pod my-pod -o json` retrieves the full object representation of the pod in JSON format, which includes all fields such as metadata, spec, status, and annotations. This provides detailed, machine-readable information about the pod's current state and configuration.
Exam trap
CNCF often tests the distinction between commands that retrieve object metadata/status (get/describe) versus commands that interact with the pod's runtime (logs/exec), leading candidates to mistakenly select runtime commands for 'detailed information' about the pod itself.
Which TWO of the following are valid ways to consume a ConfigMap in a pod? (Select 2)
ConfigMaps can be mounted as volumes using volumes.configMap.
Why this answer
Option A is correct because a ConfigMap can be mounted as a volume in a Pod, allowing files or directories to be created from the ConfigMap's data. This is done by specifying a volume of type `configMap` in the Pod spec and mounting it into the container's filesystem, which makes the key-value pairs available as files.
Exam trap
The trap here is that candidates often confuse `configMapRef` (used in `envFrom`) with `configMapKeyRef` (used in `env.valueFrom`), and may incorrectly think `envFrom` is not a valid consumption method, or they may select `secretKeyRef` because they forget it is specific to Secrets, not ConfigMaps.
A developer wants to create a ConfigMap named 'app-config' with two key-value pairs: 'color=blue' and 'size=large'. Which kubectl command should they use?
Correct syntax for creating a ConfigMap from literals.
Why this answer
Option B is correct because `kubectl create configmap` with `--from-literal` allows specifying key-value pairs directly in the command line. Each literal must be provided as a separate `--from-literal=key=value` flag, and this command correctly creates the ConfigMap with the two entries 'color=blue' and 'size=large'.
Exam trap
The trap here is that candidates often confuse `--from-literal` with `--from-file` or try to use comma-separated syntax, not realizing that each literal must be specified with its own `--from-literal` flag in the exact `key=value` format.
How to eliminate wrong answers
Option A is wrong because `--from-literal` does not accept comma-separated keys and values; it requires the format `--from-literal=key=value` for each pair. Option C is wrong because `--from-env-file` expects a file path containing environment variables in `key=value` format, not inline comma-separated values. Option D is wrong because `--from-file` creates a ConfigMap entry from the content of a file, using the filename as the key, not from literal key-value pairs.
Order the steps to perform a rolling rollback of a Deployment to a previous revision.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
View history, choose revision, undo to that revision, wait for completion, then verify.
A company runs a Kubernetes cluster with multiple namespaces. The operations team wants to ensure that any application crash or container restart is automatically detected and the team is notified. Which built-in Kubernetes resource should they configure to achieve this?
Events are generated for pod crashes/restarts and can be used for monitoring.
Why this answer
Kubernetes Events are the built-in resource that records state changes, including pod crashes and container restarts. By configuring a monitoring tool or custom controller to watch Events (e.g., via the Kubernetes API or `kubectl get events`), the operations team can automatically detect application failures and trigger notifications. Events provide the necessary metadata (reason, message, timestamp) to identify crash loops or restart backoffs.
Exam trap
The trap here is that candidates may confuse CronJobs (which can run scripts to check health) with the built-in event detection mechanism, but Kubernetes Events are the native, declarative way to capture and react to state changes without custom scripting.
How to eliminate wrong answers
Option B is wrong because ConfigMaps are used to store non-sensitive configuration data (e.g., environment variables, config files) and do not generate or detect runtime events like crashes. Option C is wrong because Secrets store sensitive data (e.g., passwords, tokens) and have no mechanism for monitoring application health or container restarts. Option D is wrong because CronJobs schedule recurring tasks (e.g., batch jobs) but do not inherently detect or report on pod crashes or container restarts; they are for time-based job execution, not event-driven observability.
Which kubectl command correctly creates a ConfigMap from a file named 'app.properties'?
Correctly creates a ConfigMap with the file contents as a key-value pair.
Why this answer
Option D is correct because `kubectl create configmap app-config --from-file=app.properties` creates a ConfigMap by reading the entire contents of the file 'app.properties' and storing it under a key that defaults to the filename (app.properties). This is the standard way to import a file's data as a single key-value pair in a ConfigMap.
Exam trap
The trap here is that candidates confuse `--from-env-file` (which parses key=value lines) with `--from-file` (which imports the entire file as a single key), leading them to choose option C incorrectly.
How to eliminate wrong answers
Option A is wrong because it combines `--from-file` and `--from-env-file` for the same file, which is redundant and not the correct single command to create a ConfigMap from a file; `--from-env-file` is used for files with key=value format, not for importing a file as a single key. Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line, not to reference a file; it would attempt to treat 'app.properties' as a literal key without a value. Option C is wrong because `--from-env-file` is intended for files containing environment-variable-style key=value lines (e.g., a .env file), not for importing a file's entire content as a single key; it would parse 'app.properties' line by line and fail if the file does not follow that format.
Which TWO are true about LimitRange objects?
LimitRange is validated at pod creation.
Why this answer
Option A is correct because LimitRange objects enforce resource constraints at the time a container is created within a namespace. When a Pod is created, the LimitRange admission controller validates that the container's resource requests and limits fall within the defined minimum, maximum, and default values. If the container violates the LimitRange (e.g., requests less than the minimum memory), the Pod creation is rejected immediately.
Exam trap
The trap here is confusing LimitRange with ResourceQuota: candidates often think LimitRange can set namespace-wide limits like total Pod count or cluster-wide scope, but LimitRange is strictly per-container resource constraints within a single namespace.
An administrator wants to grant a ServiceAccount 'app-sa' in namespace 'dev' read-only access to pods in the same namespace. Which YAML snippet correctly defines the required RBAC resources?
Correctly defines a Role and RoleBinding in the same namespace.
Why this answer
Option A correctly defines a Role with read-only verbs (get, list, watch) on pods in the 'dev' namespace, and binds it to the ServiceAccount 'app-sa' using a RoleBinding. Since both the Role and RoleBinding are scoped to the same namespace, this grants the ServiceAccount the required read-only access to pods within that namespace.
Exam trap
The trap here is that candidates often confuse the subject kind (ServiceAccount vs. User vs. Group) or incorrectly use a ClusterRole when a namespace-scoped Role is sufficient, leading to overly permissive or misconfigured bindings.
How to eliminate wrong answers
Option B is wrong because it uses 'kind: Group' instead of 'kind: ServiceAccount'; a Group subject is used for LDAP or OIDC groups, not for a Kubernetes ServiceAccount. Option C is wrong because it uses 'kind: User' instead of 'kind: ServiceAccount'; a User subject is for human users or external identities, not for a ServiceAccount. Option D is wrong because it uses 'kind: ClusterRole' in the RoleBinding; while a ClusterRole can be bound to a namespace-scoped RoleBinding, the question specifically requires a Role (not a ClusterRole) to limit access to the 'dev' namespace only, and using a ClusterRole would introduce unnecessary cluster-wide scope.
Which kubectl command creates a pod named 'nginx' from the image 'nginx:latest'?
The run command creates a pod by default.
Why this answer
Option A is correct. 'kubectl run nginx --image=nginx:latest' creates a pod. Option B uses 'create pod' which is invalid. Option C uses 'apply' which requires a file.
Option D uses 'deployment' but the question asks for a pod.
You have created a ServiceAccount named 'my-sa' in namespace 'default'. You want a Pod to use this ServiceAccount. Which Pod spec field is correct?
Correct. This sets the ServiceAccount for the pod.
Why this answer
Option B is correct because the `serviceAccountName` field in a Pod spec is the standard way to assign a specific ServiceAccount to a Pod. When this field is set to `my-sa`, the Pod will use the token and permissions associated with that ServiceAccount for API authentication and authorization.
Exam trap
The trap here is that candidates confuse the deprecated `serviceAccount` field with the current `serviceAccountName` field, or incorrectly assume that `securityContext` can set the ServiceAccount.
How to eliminate wrong answers
Option A is wrong because `spec.securityContext.serviceAccount` is not a valid field; `securityContext` applies to Pod or container security settings (e.g., user ID, SELinux options), not ServiceAccount assignment. Option C is wrong because `serviceAccount` is a deprecated field in Pod spec; it has been replaced by `serviceAccountName` in Kubernetes v1.1+ and may be removed in future versions. Option D is wrong because `automountServiceAccountToken: false` controls whether the ServiceAccount token is automatically mounted into the Pod, but it does not specify which ServiceAccount to use; it is a boolean flag, not a name reference.
A Deployment has been updated with a new image. After running 'kubectl rollout status deployment/myapp', you see that the rollout has stalled. You want to undo the rollout to the previous revision. What command do you run?
This undoes the last rollout to the previous revision.
Why this answer
The 'kubectl rollout undo deployment/myapp' command reverts the deployment to the previous revision.
Practice CKAD by domain
Target a specific domain to shore up weak areas.