991 questions total · 14pages · All types, answers revealed
What is the default type of a Kubernetes Service when no type is specified in the YAML manifest?
Default service type.
Why this answer
Option B is correct. The default service type is ClusterIP. If you omit 'spec.type', Kubernetes assumes ClusterIP.
Which command shows the CPU and memory usage of all pods in the current namespace?
This displays CPU and memory usage for pods in the current namespace.
Why this answer
Option D is correct because `kubectl top pod` without a specific pod name retrieves CPU and memory usage metrics for all pods in the current namespace, as the command defaults to listing all pods when no pod name is provided. This relies on the metrics-server collecting resource usage data from the kubelet's cAdvisor endpoint via the Resource Metrics API.
Exam trap
CNCF often tests the misconception that `kubectl top pod` requires a pod name to show metrics, but omitting the pod name lists all pods in the current namespace, which is the correct syntax for the question's requirement.
How to eliminate wrong answers
Option A is wrong because `kubectl top node` shows resource usage for nodes, not pods, and does not filter by namespace. Option B is wrong because `kubectl top --all` is not a valid kubectl command; the `--all` flag is used with `kubectl get` to select resources across all namespaces, but `kubectl top` does not support that flag. Option C is wrong because `kubectl top pod pod-name` shows metrics for a single specific pod, not all pods in the namespace.
A developer creates a headless Service with 'clusterIP: None' for a StatefulSet. What is the primary purpose of using a headless Service?
Headless services assign each pod a unique DNS name (pod-name.service-name.namespace.svc.cluster.local) and allow direct pod-to-pod communication.
Why this answer
Headless services are used with StatefulSets to enable direct pod-to-pod communication and stable network identities. Option A is correct. Option B is incorrect because ClusterIP services provide load balancing.
Option C is incorrect because headless services still use DNS. Option D is incorrect because headless services do not provide automatic TLS.
This order layers the npm install step after copying only the package files, allowing Docker to cache the npm install layer until package files change.
Why this answer
Option B is correct because it copies the package files first, runs npm install to leverage Docker layer caching, and then copies the rest of the source code. Option A copies everything first, which invalidates the cache for npm install on every source code change. Option C and D use ADD, which is unnecessary for local files and may have unintended behaviors like extracting archives.
You have a Deployment with a liveness probe using an exec command. The probe currently runs 'cat /tmp/healthy' and fails after 3 failures. You notice the pod is being restarted even though the application is healthy. What is the most likely cause?
The exec probe runs 'cat /tmp/healthy'. If the file is missing, the command fails, causing the probe to fail and restart the container.
Why this answer
Option C is correct because the liveness probe executes 'cat /tmp/healthy' and fails after 3 consecutive failures. If the file /tmp/healthy does not exist or is not being updated by the application, the command returns a non-zero exit code, causing the probe to fail and Kubernetes to restart the container even though the application process itself is running and healthy.
Exam trap
The trap here is that candidates confuse the liveness probe's exec command with an HTTP probe or assume the probe is failing due to timing, when the real issue is the command's exit code reflecting the absence or staleness of the file.
How to eliminate wrong answers
Option A is wrong because a readiness probe does not shut down pods; it only controls whether the pod receives traffic from Services. Option B is wrong because the liveness probe is explicitly configured as an exec command, not an HTTP endpoint, so the HTTP endpoint is irrelevant. Option D is wrong because if the command completes quickly (e.g., 'cat /tmp/healthy'), a low timeoutSeconds would not cause failure; the issue is the command's exit code, not its execution time.
A developer wants to restrict network traffic so that only pods with label 'app: frontend' can communicate with pods labeled 'app: backend' on port 8080. Which Kubernetes resource should be used?
NetworkPolicy defines ingress/egress rules based on pod labels.
Why this answer
A NetworkPolicy is the correct Kubernetes resource because it defines ingress and egress rules to control pod-to-pod communication based on labels, namespaces, and ports. By specifying a podSelector matching 'app: backend', an ingress rule allowing traffic from pods with label 'app: frontend' on port 8080, and a policyTypes field including 'Ingress', this resource enforces the desired restriction at the network layer using iptables or eBPF under the hood.
Exam trap
The trap here is that candidates confuse NetworkPolicy with RBAC or security context controls, mistakenly thinking RoleBinding or PodSecurityPolicy can restrict network traffic, when in fact only NetworkPolicy (with a compatible CNI) provides pod-level network access control.
How to eliminate wrong answers
Option B is wrong because ResourceQuota limits aggregate resource consumption (CPU, memory, storage) per namespace, not network traffic between pods. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21, removed in 1.25) controls security context constraints for pods, such as privileged mode or host namespaces, not network connectivity. Option D is wrong because RoleBinding grants RBAC permissions to users or service accounts within a namespace, but does not affect network traffic between pods.
You have a Deployment with 3 replicas. You run 'kubectl rollout pause deployment/app'. Which command would you use to resume the rollout?
Correct command to resume a paused rollout.
Why this answer
The 'kubectl rollout resume' command resumes a paused rollout, allowing the update to continue.
Which TWO of the following are valid ways to create a Service named 'web' that targets pods with label 'app: web' on port 80?
Valid command.
Why this answer
kubectl expose deployment web --port=80 creates a service from a deployment. A YAML manifest with spec.selector.app: web and spec.ports[0].port: 80 also works.
Which TWO of the following commands are used to inspect the rollout history of a Deployment?
This is the dedicated command for rollout history.
Why this answer
'kubectl rollout history deployment/<name>' shows the revision history. 'kubectl rollout status deployment/<name>' shows the current status, not the history. 'kubectl describe deployment/<name>' includes some history but is not the primary command. 'kubectl get replicasets' shows the ReplicaSets associated with revisions. Option D is the main command for history. Option E (kubectl get replicasets) can also be used to see revisions.
You have a Deployment with 3 replicas. You need to perform a rolling update with a 10-second delay between each Pod replacement to ensure stability. Which kubectl command is correct?
kubectl set image updates the container image; the rolling update strategy handles the delay via maxSurge and maxUnavailable, not a fixed delay. However, this is the standard command to trigger a rolling update.
Why this answer
Option A is correct. kubectl set image updates the image, and the --record flag is outdated but acceptable. Option B uses edit which is not needed. Option C uses rollout restart which does not change the image.
Option D applies a patch but is more complex.
A developer wants to expose a Deployment named 'web-app' (with label 'app: web') as a ClusterIP service on port 80. Which command achieves this?
Correctly exposes the deployment as a service.
Why this answer
The correct command is 'kubectl expose deployment web-app --port=80'. This creates a ClusterIP service named 'web-app' that selects pods with label 'app: web' and exposes port 80.
Which TWO statements are true about readiness probes? (Select two.)
These are the supported probe types for readiness probes as well.
Why this answer
Readiness probes determine if a container is ready to serve traffic. If failing, the pod is removed from Service endpoints. They are independent of liveness probes.
A developer is creating a ConfigMap from a file named 'app.properties'. The file contains key-value pairs. Which command correctly creates the ConfigMap with keys matching the file content?
--from-file creates a configmap with a key named 'app.properties' containing file content.
Why this answer
Option A is correct because `--from-file=app.properties` creates a ConfigMap where each key-value pair from the file becomes a separate data entry, with the key being the filename (app.properties) and the value being the entire file content. This matches the requirement that the ConfigMap keys match the file content, meaning the file itself is stored as a single key-value pair where the key is the filename.
Exam trap
The trap here is confusing `--from-file` (which stores the entire file as a single value under the filename key) with `--from-env-file` (which parses key-value pairs from the file), leading candidates to choose option D when they want to import key-value pairs from a properties file.
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; `--from-literal=app.properties` would create a ConfigMap with a single key named 'app.properties' and an empty value, not the file content. Option C is wrong because piping the file content via `cat` to `kubectl create configmap --from-file=-` would read the file content as a single blob and store it under the key `-`, not parse the key-value pairs from the file; `--from-file=-` expects the file content to be passed via stdin but still treats the entire input as a single value for the key `-`. Option D is wrong because `--from-env-file=app.properties` is used to create a ConfigMap from a file containing environment-variable-style lines (e.g., `KEY=VALUE`), which would parse the file and create separate keys for each line, not store the file content as a single key-value pair with the filename as the key.
Which THREE of the following are valid Kustomize features? (Select THREE)
List of resources to include.
Why this answer
Kustomize supports resources, patchesStrategicMerge, configMapGenerator, namePrefix, etc.
Which TWO resources are used to enforce resource quotas at the namespace level? (Select TWO.)
Correct. ResourceQuota sets aggregate resource limits for a namespace.
Why this answer
ResourceQuota (C) is correct because it is a Kubernetes object that sets hard limits on aggregate resource consumption (e.g., total CPU, memory, persistent volume claims) per namespace, preventing any single namespace from exhausting cluster resources. LimitRange (E) is correct because it enforces minimum and maximum resource requests/limits at the pod or container level within a namespace, complementing ResourceQuota by defining per-pod constraints.
Exam trap
CNCF often tests the distinction between cluster-level and namespace-level resource controls, and the trap here is that candidates confuse HorizontalPodAutoscaler (which scales pods) with ResourceQuota (which caps total usage), or think NetworkPolicy enforces resource limits due to its 'policy' name.
You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff' state. Which TWO conditions could cause this state?
Correct. Application crash causes restart loop.
Why this answer
CrashLoopBackOff means the container exits repeatedly and Kubernetes is delaying restarts. Common causes: application error causing exit, or liveness probe failure restarting the container.
You have a Service named 'api' with selectors that match pods. However, curl to the Service cluster IP times out. 'kubectl get endpoints api' shows no endpoints. What is the most likely cause?
Empty endpoints indicate selector mismatch.
Why this answer
Option B is correct. If endpoints are empty, the Service's selector does not match any pods, so no endpoints are created.
A pod is stuck in 'Pending' state. You run 'kubectl describe pod' and see '0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory.' What does this mean?
The scheduler found no node with enough CPU and memory to satisfy the pod's requests.
Why this answer
The 'Pending' state indicates the pod has been accepted by the Kubernetes API server but cannot be scheduled onto a node. The message '0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory' means the scheduler evaluated all nodes and found that none had enough allocatable CPU and memory to satisfy the pod's resource requests. This is a scheduling failure caused by the pod's requests exceeding the available resources on any node.
Exam trap
CNCF often tests the distinction between pod lifecycle phases (Pending, Running, CrashLoopBackOff) and the specific error messages in 'kubectl describe pod', leading candidates to confuse scheduling failures with runtime issues like image pull errors or probe failures.
How to eliminate wrong answers
Option A is wrong because an unavailable container image would cause the pod to stay in 'Pending' or 'ImagePullBackOff' state, but the error message would reference 'ImagePullBackOff' or 'ErrImagePull', not resource insufficiency. Option B is wrong because a failing liveness probe would cause the pod to be restarted (CrashLoopBackOff) or become 'Running' but unhealthy, not stuck in 'Pending' — liveness probes are only checked after the container starts. Option D is wrong because a container crashing due to an error would result in 'CrashLoopBackOff' or 'Error' state, not 'Pending', and the describe output would show crash loop backoff or exit code details, not resource insufficiency.
Which TWO of the following are valid strategies for updating a Deployment?
Default strategy that updates pods gradually.
Why this answer
RollingUpdate is the default update strategy in Kubernetes Deployments. It gradually replaces old Pods with new ones, ensuring zero downtime by incrementally scaling down old ReplicaSets and scaling up new ones based on configurable parameters like maxSurge and maxUnavailable.
Exam trap
CNCF often tests the distinction between built-in Kubernetes Deployment strategies (RollingUpdate, Recreate) and external deployment patterns (Canary, Blue/Green, Ramped) that require additional tooling or manual steps.
Which THREE of the following are valid fields in a PodSecurityContext?
Valid at pod level; sets group ownership of volumes.
Why this answer
Option A is correct because `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.
Exam trap
CNCF often tests the distinction between PodSecurityContext and container SecurityContext, trapping candidates who assume all security-related fields (like capabilities or allowPrivilegeEscalation) are valid at the pod level when they are actually container-specific.
A container in a pod is expected to shut down gracefully within 30 seconds when it receives SIGTERM. How should you configure the pod to ensure the container is given enough time to shut down before being forcefully killed?
This gives the container 35 seconds to shut down after SIGTERM before SIGKILL is sent.
Why this answer
terminationGracePeriodSeconds defines the time Kubernetes waits after sending SIGTERM before sending SIGKILL. Setting it to 35 seconds gives the container a 5-second buffer. Option B is correct.
Option A is not a valid field. Option C sets the grace period too short. Option D sets it to an excessively long time.
You need to add a debugging container to a running pod named 'app-pod' in the 'dev' namespace. Which command achieves this?
This adds an ephemeral container to the running pod for debugging.
Why this answer
Option D is correct. kubectl debug allows adding ephemeral containers to running pods. The syntax kubectl debug pod/app-pod -n dev --image=busybox --ephemeral creates an ephemeral container. Option A (kubectl exec) runs commands in existing containers, not add containers.
Option B (kubectl run) creates a new pod, not attach to existing. Option C (kubectl attach) attaches to a running container's stdin/stdout.
You are using a canary deployment strategy with Deployments and Services. You have a stable version (v1) and a canary version (v2). Both Deployments have the label 'app: myapp'. The Service selector is 'app: myapp'. How can you route a small percentage of traffic to the canary?
Both sets of pods match the selector, so traffic is split roughly 10% to canary and 90% to stable.
Why this answer
By setting different replica counts, you control the ratio of pods from each Deployment. If the Service selects by 'app: myapp', it will include both v1 and v2 pods, and traffic is distributed proportionally by the number of pods.
A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?
Directly sets the container's user ID to 1000.
Why this answer
Option B is correct because `runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.
Exam trap
The trap here is that candidates often confuse `runAsNonRoot: true` with setting a specific user ID, not realizing it only enforces non-root but does not guarantee UID 1000, which the question explicitly requires.
How to eliminate wrong answers
Option A is wrong because `runAsNonRoot: true` only prevents the container from running as root (UID 0) but does not specify which non-root UID to use; it relies on the container image's default user, which may not be UID 1000. Option C is wrong because `fsGroup: 1000` sets the group ID for volume ownership, not the user ID the container process runs as. Option D is wrong because `privileged: false` is the default setting and only disables privileged mode; it does not enforce a specific non-root user.
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?
Container-level securityContext merges with Pod-level, but Pod-level runAsNonRoot is an additional constraint.
Why this answer
Option C is correct because 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.
Exam trap
CNCF often tests the misconception that Pod-level runAsNonRoot overrides container-level runAsUser, when in fact they are complementary checks, and the container's runAsUser must be non-root for the Pod to start.
How to eliminate wrong answers
Option A is wrong because runAsNonRoot: true does not conflict with runAsUser: 1000; it only prevents the container from running as UID 0, and user 1000 is non-root, so the Pod starts successfully. Option B is wrong because runAsNonRoot does not override runAsUser; it is an additional check that the container's effective UID is not 0, and user 1000 satisfies that condition. Option D is wrong because Pod-level runAsNonRoot is not ignored when container-level capabilities are set; capabilities like NET_ADMIN do not affect the user ID, and runAsNonRoot remains enforced.
A user runs: kubectl apply -f job.yaml. The Job spec has backoffLimit: 0. The pod fails immediately. What happens?
No retries are allowed, so the Job fails.
Why this answer
With backoffLimit: 0, the Job is not retried after the first failure, so the Job enters Failed state.
A pod spec has terminationGracePeriodSeconds: 30. The main process ignores SIGTERM. After 30 seconds, what happens?
After the grace period, the container is forcefully killed with SIGKILL.
Why this answer
If SIGTERM is ignored, Kubernetes waits for terminationGracePeriodSeconds, then sends SIGKILL to force termination. Option B is correct.
You are using a canary deployment pattern with two Deployments: 'web-stable' (version 1) and 'web-canary' (version 2). Both have the label 'app: web'. The Service 'web-svc' selects pods with 'app: web' and 'version: stable'. How do you route traffic to the canary?
This includes both stable and canary pods in the Service, allowing traffic to be split. You can then gradually increase canary replicas.
Why this answer
By adding the label 'version: canary' to the canary pods and updating the Service's selector to include 'version: stable' or 'version: canary', traffic is routed to both. Alternatively, use a separate Service for the canary.
A developer deploys a web application as a Deployment named 'web-app' with 3 replicas. The application listens on port 8080 and should be accessible from within the cluster via the service name 'web-svc' on port 80. Which Service YAML correctly exposes the application?
Correctly selects pods with label app=web-app and maps port 80 to 8080.
Why this answer
Option A is correct because it defines a ClusterIP Service (default type) named 'web-svc' that maps port 80 (the service port) to targetPort 8080 (the container port), and uses the selector `app: web-app` to match the Pods created by the Deployment. This allows internal cluster traffic to reach the application on port 80 via the service name, while the application container listens on port 8080.
Exam trap
The trap here is that candidates often confuse `port` and `targetPort`, mistakenly swapping them (as in Option C), or they add unnecessary `type: NodePort` (Option B) when only internal cluster access is required, leading to over-exposure and incorrect configuration.
How to eliminate wrong answers
Option B is wrong because it specifies `type: NodePort`, which is unnecessary for internal cluster access and exposes the service on a high port on each node, violating the requirement of accessibility via the service name on port 80. Option C is wrong because it incorrectly maps port 8080 (service port) to targetPort 80 (container port), which would not match the application listening on port 8080, causing connection failures. Option D is a duplicate of Option A and is also correct, but the question expects a single correct answer; however, since both A and D are identical, the intended correct answer is A (the first listed), and D is considered a distractor.
A ClusterIP Service named 'db' in namespace 'data' is not reachable from a pod in namespace 'app'. Which DNS name should the pod use to resolve the service?
This is the correct DNS name for the service.
Why this answer
The correct DNS name for a service is <service>.<namespace>.svc.cluster.local.
You want to debug a running pod by starting a temporary container that has network access to the pod's containers. Which kubectl command should you use?
This creates a new ephemeral container in the pod for debugging.
Why this answer
The 'kubectl debug' command with the '-i' (interactive) and '--image' flags creates an ephemeral container for debugging.
Which TWO statements about Kubernetes Services are correct?
NodePort opens a specific port on all nodes.
Why this answer
Headless services (clusterIP: None) are used for StatefulSets and do not provide load balancing. NodePort services expose a port on every node's IP. ClusterIP is the default type.
LoadBalancer type requires external cloud provider support.
Which TWO of the following are valid ways to inject configuration data into a Kubernetes Pod?
ConfigMaps are designed to hold configuration data and can be exposed as environment variables.
Why this answer
Option B is correct because 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.
Exam trap
The trap here is that candidates often confuse 'injecting configuration data' with 'providing storage' or 'network policies', leading them to select PersistentVolumeClaim or NetworkPolicy as valid options, when in fact only ConfigMaps and Secrets (for sensitive data) are the native Kubernetes resources for injecting configuration into Pods.
Which command builds a Docker image from the current directory and tags it as 'myapp:v1'?
Correct syntax: -t for tag, . for build context.
Why this answer
The -t flag tags the image.
You want to run a command inside an existing container 'app-container' in pod 'my-pod'. The pod has only one container. Which command enters an interactive shell?
Correct. -it allocates a pseudo-TTY and keeps stdin open.
Why this answer
kubectl exec -it podname -- /bin/sh opens an interactive shell inside the container.
A pod needs to mount a Secret named 'db-secret' as a volume at /etc/secret. Which volume mount definition is correct?
This is the correct syntax: 'secret' with 'secretName' field.
Why this answer
Option A is correct because it uses the proper `secret` key under the `volumes` field to reference a Secret object by its `secretName`. When this volume is mounted at `/etc/secret`, Kubernetes automatically creates a file for each key in the Secret, with the file content being the decoded value of the key. This is the standard syntax for mounting a Secret as a volume.
Exam trap
The trap here is that candidates often confuse the `secret` volume source with the `configMap` volume source, or incorrectly use `secretVolumeSource` (which is not a valid field) instead of the correct `secret` key, leading them to choose option B.
How to eliminate wrong answers
Option B is wrong because `secretVolumeSource` is not a valid field in the volume definition; the correct field is `secret`. Option C is wrong because the volume name is `db-secret`, which is not technically invalid but is misleading — the volume name should be a descriptive identifier (e.g., `secret-volume`) and is not required to match the Secret name. Option D is wrong because it uses `name: db-secret` under the `secret` block, but the correct key is `secretName`, not `name`.
A developer creates a Deployment with 3 replicas and a Service with `clusterIP: None`. What is the primary use case for this headless Service?
Headless Services return the IPs of all pods, enabling direct communication.
Why this answer
A headless Service (clusterIP: None) is used for DNS-based service discovery, typically with StatefulSets to provide stable network identities for each pod.
Which flag in a kubectl run command sets environment variables from a ConfigMap?
Correct. --env-from takes a ConfigMap name to populate environment variables.
Why this answer
Option C is correct because `kubectl run` supports the `--env-from` flag to inject environment variables from a ConfigMap (or Secret) into a pod. This flag allows you to specify a ConfigMap name, and Kubernetes will populate the container's environment with all key-value pairs from that ConfigMap, which is the intended mechanism for bulk environment variable injection.
Exam trap
The trap here is that candidates often confuse `--env-from` with the non-existent `--from-env-config` or assume `--configmap` is a valid flag, because they recall the concept of using ConfigMaps but not the exact kubectl syntax.
How to eliminate wrong answers
Option A is wrong because `--env` is used to set individual environment variables directly in the command (e.g., `--env=KEY=VALUE`), not to source variables from a ConfigMap. Option B is wrong because `--configmap` is not a valid flag in `kubectl run`; ConfigMaps are referenced via `--env-from` or mounted as volumes, not by a dedicated `--configmap` flag. Option D is wrong because `--from-env-config` does not exist as a kubectl flag; the correct syntax uses `--env-from` with a ConfigMap name, and the `--from-env-config` option is a common misremembering of the actual flag.
A developer wants to test a service locally using kubectl. Which command forwards local port 8080 to the service's port 80?
Correct. Forwards local 8080 to service's 80.
Why this answer
The correct syntax is 'kubectl port-forward service/<service-name> 8080:80'. Option B uses 'svc' abbreviation, which is correct, but the order is local:remote. Option A is missing service/ prefix.
Option C is reversed ports. Option D uses pod instead of service.
Which THREE of the following fields are part of a Pod's securityContext that can restrict container capabilities? (Choose three.)
Correct.
Why this answer
Option A is correct because `capabilities.drop` in a Pod's `securityContext` explicitly removes Linux capabilities from all containers in the Pod, thereby restricting what privileged operations they can perform. This is a key mechanism for adhering to the principle of least privilege by dropping capabilities such as `NET_RAW` or `SYS_ADMIN` that are not needed.
Exam trap
CNCF often tests the distinction between capability management (`capabilities.drop`/`capabilities.add`) and other security context fields like `seccompProfile` or `runAsUser`, so candidates mistakenly think any security-related field can restrict capabilities.
Which kubectl command is used to view the rollout status of a Deployment?
This is the correct command to view the rollout status.
Why this answer
The 'kubectl rollout status' command is specifically designed to show the status of a rollout for a Deployment, DaemonSet, or StatefulSet.
You have a LimitRange in namespace 'ns' that sets default limits.cpu to 500m and default requests.cpu to 200m. You create a pod without specifying any CPU resources. What CPU values will be applied to the container?
Correct. LimitRange defaults apply to containers that don't specify resource requirements.
Why this answer
When a LimitRange is configured in a namespace with default CPU limits and requests, any pod created without specifying CPU resources will have those defaults injected by the admission controller. The LimitRange sets default limits.cpu to 500m and default requests.cpu to 200m, so the container will receive request: 200m and limit: 500m. This is enforced by the LimitRanger admission plugin during pod creation.
Exam trap
The trap here is that candidates often assume a pod without resource specs will be rejected or have no limits, but the LimitRange admission controller silently applies defaults, making option B correct.
How to eliminate wrong answers
Option A is wrong because the pod is not rejected; the LimitRange admission controller applies defaults rather than rejecting the pod. Option C is wrong because the LimitRange explicitly sets default values, so the container will not have zero CPU requests and limits; the defaults are applied automatically. Option D is wrong because it confuses default limits with default requests; the default request is 200m, not 500m, and the limit is 500m, not equal to the request.
You want to undo a rollout to the previous revision. Which command should you use?
This rolls back to the previous revision.
Why this answer
kubectl rollout undo deployment/myapp rolls back to the previous revision.
Which command lists all Helm releases in the current namespace?
Correct. helm list shows releases.
Why this answer
helm list lists all releases in the current namespace.
Which of the following best describes the purpose of an init container?
Init containers are ideal for initialization tasks like database schema migrations or waiting for services.
Why this answer
Init containers run before the main containers in a pod and must complete successfully before the main containers start.
You need to ensure that a Pod always runs on a node with an SSD. Which node selector mechanism should you use?
Correct: nodeSelector ensures the pod is scheduled on nodes with the specified label.
Why this answer
Node affinity with requiredDuringSchedulingIgnoredDuringExecution ensures the pod is scheduled only on nodes that match the label (e.g., disktype=ssd). nodeSelector is simpler but less expressive; nodeName is not flexible; pod affinity is for co-location with other pods.
Which TWO statements about init containers are true?
Init containers have their own resource specifications independent of app containers.
Why this answer
Options A and D are correct. Init containers must run to completion before app containers start (A). They can have different resource limits than app containers (D) and can use different container images.
Option B is false because init containers run sequentially, not in parallel. Option C is false because init containers can have their own images. Option E is false because init containers run before all app containers.
You need to debug a Pod that is in CrashLoopBackOff. Which command should you run first?
Logs often contain the error that caused the crash.
Why this answer
When a Pod is in CrashLoopBackOff, the immediate priority is to see why the container is failing. `kubectl logs <pod-name>` retrieves the container's stdout/stderr output, which typically contains the error message (e.g., missing config, runtime exception, or startup failure). This is the fastest way to get the root cause without modifying the Pod state.
Exam trap
CNCF often tests the misconception that `kubectl describe pod` provides enough debugging information, but it only shows the exit code and a brief termination message, not the full application logs that reveal the actual error.
How to eliminate wrong answers
Option A is wrong because `kubectl get events --sort-by=.lastTimestamp` shows cluster-level events (e.g., scheduling, pulling images) but does not show the container's application logs, which are essential for debugging a crash loop. Option C is wrong because `kubectl exec -it <pod-name> -- sh` attempts to start an interactive shell inside a running container, but if the Pod is in CrashLoopBackOff, the container is not running, so exec will fail with an error like 'error: unable to upgrade connection: container not found'. Option D is wrong because `kubectl describe pod <pod-name>` provides metadata, status, and events, but it does not include the container's stdout/stderr logs; it only shows the last termination state and exit code, which is less detailed than the actual logs.
Which command creates a generic secret named 'db-secret' with key 'password' and value 'p@ss'?
Correct. 'generic' creates an Opaque secret with literal values.
Why this answer
Option B is correct because `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.
Exam trap
The trap here is that candidates often confuse `--from-file` with `--from-literal`, mistakenly thinking `--from-file=key=value` will treat the value as a literal string, when in fact it treats it as a file path.
How to eliminate wrong answers
Option A is wrong because `--from-file=password=p@ss` treats 'p@ss' as a filename, not a literal value; it would attempt to read a file named 'p@ss' and store its contents under the key 'password', which is not the intended behavior. Option C is wrong because `kubectl create secret tls` is used specifically for TLS certificates and keys, not for arbitrary key-value pairs; it expects `--cert` and `--key` flags, not `--from-literal`. Option D is wrong because `kubectl create secret docker-registry` is used for Docker registry authentication credentials and requires flags like `--docker-username`, `--docker-password`, and `--docker-email`; `--from-literal` is not supported for this secret type.
DNS returns all pod IPs as A records for the headless Service.
Why this answer
A headless Service (clusterIP: None) does not have a cluster IP. Instead, DNS queries for the Service name return A records for all pods matching the selector. Since the Service selects pods with label 'app: db', the DNS lookup for 'db' returns the three pod IPs (10.0.0.1, 10.0.0.2, 10.0.0.3) as separate A records, allowing direct pod-to-pod communication.
Exam trap
The trap here is that candidates confuse headless Services with regular Services, assuming DNS returns a single cluster IP or a round-robin list, when in fact headless Services return all pod IPs as separate A records with no load balancing.
How to eliminate wrong answers
Option A is wrong because a headless Service does not return only the first pod's IP; it returns all matching pod IPs as separate A records. Option B is wrong because a headless Service has no cluster IP (clusterIP is set to None), so DNS does not return a cluster IP. Option D is wrong because DNS for a headless Service returns all pod IPs in an unordered list; the client's DNS resolver may rotate them, but the Service itself does not implement round-robin — that behavior depends on the client's DNS caching and resolution logic.
You need to view events for a specific pod named 'web-1' in the 'default' namespace. Which command shows events related to this pod?
Correctly filters events for the pod.
Why this answer
Option C is correct because `kubectl get events --field-selector involvedObject.name=web-1` filters events by the `involvedObject.name` field, which directly matches the pod name. This is the precise way to retrieve only events related to a specific pod in Kubernetes, as events are associated with objects via the `involvedObject` field, not labels.
Exam trap
The trap here is that candidates confuse label selectors (`--selector`) with field selectors (`--field-selector`), assuming pod names are labels, when in fact events use the `involvedObject` field for association, not metadata labels.
How to eliminate wrong answers
Option A is wrong because `kubectl get events` returns all events in the namespace without any filtering, which is too broad and not specific to the pod 'web-1'. Option B is wrong because `kubectl describe pod web-1 --events` is not a valid command; the `--events` flag does not exist for `kubectl describe`, and even if it did, `describe` shows pod details but not a filtered list of events. Option D is wrong because `--selector name=web-1` uses label selectors, but events are not labeled with the pod's name; the pod name is stored in the `involvedObject.name` field, not as a label, so this selector would return no events or incorrect ones.
Match each Kubernetes concept to its definition.
Drag a concept onto its matching description — or click a concept then click the description.
Virtual cluster for resource isolation
Runs one pod per node for system services
Runs a pod to completion; for batch processing
Automatically scales pods based on CPU/memory
Controls traffic flow between pods
Why these pairings
These concepts cover scheduling, scaling, and networking.
Which command builds a Docker image from the current directory and tags it as 'myapp:v1'?
Correct syntax: docker build -t <tag> <context>.
Why this answer
Option C is correct. The 'docker build -t' command is used to tag an image during build. Option A misses the tag.
Option B uses wrong syntax. Option D uses 'push' which is for pushing images.
A developer needs to run a one-time batch job to process data. After completion, the pod should be retained for logs inspection. Which Job configuration parameter should be set?
If not set, the job and pods are retained until manually deleted.
Why this answer
To retain a Job's Pod after completion for log inspection, the `ttlSecondsAfterFinished` field must be left unset (or set to nil). When this field is unset, the Job controller does not automatically delete the Pod, allowing logs to be inspected. Setting it to any non-negative integer would schedule automatic deletion after that many seconds, which contradicts the requirement.
Exam trap
CNCF often tests the misconception that `ttlSecondsAfterFinished` must be set to a positive value to retain Pods, when in fact leaving it unset (nil) achieves indefinite retention, while setting it to any non-negative integer triggers automatic deletion.
How to eliminate wrong answers
Option A is wrong because `backoffLimit: 0` prevents the Job from retrying on failure, but does not affect Pod retention after completion; the Pod would still be deleted if `ttlSecondsAfterFinished` is set. Option C is wrong because `ttlSecondsAfterFinished: -1` is an invalid value; the field expects a non-negative integer or nil, and setting it to -1 would cause the Job to be rejected or ignored. Option D is wrong because `activeDeadlineSeconds: 3600` sets a maximum duration for the Job to run, after which it is terminated, but does not control Pod retention after completion; the Pod would still be deleted according to `ttlSecondsAfterFinished`.
A container in your pod takes a long time to start (up to 5 minutes). You want to avoid the container being restarted by the liveness probe during this period. What should you configure?
A startup probe delays the liveness and readiness probes until the container has started successfully.
Why this answer
A startup probe is designed specifically for slow-starting containers. It runs at initialization and defers the liveness and readiness probes until it succeeds. By setting a high `failureThreshold` (e.g., 30) with a short `periodSeconds` (e.g., 10s), you allow up to 5 minutes for the container to start without the liveness probe killing it.
Exam trap
The trap here is that candidates confuse `initialDelaySeconds` (a static delay) with the startup probe (a dynamic, failure-tolerant mechanism), leading them to pick option A, which does not handle variable or long startup times reliably.
How to eliminate wrong answers
Option A is wrong because `initialDelaySeconds` only delays the start of the liveness probe by a fixed time, but if the container takes up to 5 minutes and the probe starts after that delay, it may still fail and restart the container before startup completes. Option B is wrong because a readiness probe controls traffic routing, not container restarts; it does not prevent the liveness probe from restarting the container during startup. Option C is wrong because increasing `failureThreshold` on the liveness probe only increases the number of consecutive failures allowed after the probe has started, but it does not prevent the probe from starting too early and potentially restarting the container before it is ready.
What is the purpose of a .dockerignore file in a Docker build context?
.dockerignore prevents certain files from being included in the build context, reducing build time and avoiding accidental inclusion of sensitive data.
Why this answer
Option C is correct. .dockerignore excludes files and directories from the build context, making builds faster and more secure. Option A is about ordering layers. Option B is about security scanning.
Option D is not a standard behavior.
Which TWO of the following are required for Ingress to route HTTP traffic to a backend Service?
Ingress controller is required to implement the rules.
Why this answer
An Ingress controller is required because the Ingress resource itself is just a set of routing rules; it does not process traffic. The Ingress controller, typically a pod running a reverse proxy like nginx or Envoy, watches the Ingress API and configures itself to route external HTTP/HTTPS traffic to the appropriate backend Services. Without a running Ingress controller, the Ingress resource has no effect.
Exam trap
CNCF often tests the misconception that an Ingress resource alone can route traffic without a controller, or that a LoadBalancer Service is mandatory for Ingress to work, when in fact the controller handles external exposure and any Service type suffices for the backend.
You create a Role named 'pod-reader' in the 'default' namespace with rules to get, list, and watch pods. A ServiceAccount 'app-sa' in the same namespace needs to be bound to this role. Which YAML snippet correctly creates the RoleBinding?
Correct structure: RoleBinding binds a ServiceAccount to a Role.
Why this answer
Option B is correct because it creates a RoleBinding in the 'default' namespace that binds the ServiceAccount 'app-sa' to the Role 'pod-reader' using the correct 'kind: Role' in the roleRef. The RoleBinding must reference a Role (not a ClusterRole) when the Role exists in the same namespace, and the apiGroup for the roleRef must be 'rbac.authorization.k8s.io'.
Exam trap
CNCF often tests the distinction between Role and ClusterRole in the roleRef of a RoleBinding, where candidates mistakenly use 'kind: ClusterRole' when the actual resource is a namespaced Role, or use 'kind: ClusterRoleBinding' for a namespaced binding.
How to eliminate wrong answers
Option A is wrong because the roleRef uses 'kind: ClusterRole' instead of 'kind: Role', but the Role 'pod-reader' is a namespaced Role, not a ClusterRole. Option C is wrong for the same reason as A: it incorrectly references a ClusterRole instead of a Role. Option D is wrong because it uses 'kind: ClusterRoleBinding' which is cluster-scoped and cannot bind a namespaced Role; also, a ClusterRoleBinding requires a ClusterRole, not a Role.
Match each volume type to its use case.
Drag a concept onto its matching description — or click a concept then click the description.
Temporary storage that shares a pod's lifecycle
Mounts a file or directory from the host node
Requests durable storage from a PersistentVolume
Inject configuration data as files or env vars
Inject sensitive data as files or env vars
Why these pairings
Volumes provide different storage options in Kubernetes.
You need to debug a running pod that does not have a shell installed. Which kubectl command allows you to start an ephemeral container with a shell?
kubectl debug adds an ephemeral container to the pod with the specified image and attaches to it.
Why this answer
Option C is correct. 'kubectl debug' is used to create ephemeral containers for debugging. Option A is wrong because kubectl exec requires a shell in the container. Option B is invalid.
Option D creates a new pod, not an ephemeral container.
An administrator wants to enforce that all pods in namespace 'secured' must run with a seccomp profile set to 'RuntimeDefault' at the container level. Which Pod Security Admission policy standard achieves this?
The restricted profile requires seccomp profile 'RuntimeDefault' or 'Localhost'.
Why this answer
The 'restricted' Pod Security Admission (PSA) policy standard enforces the most stringent security controls, including requiring that pods use a seccomp profile set to 'RuntimeDefault' at the container level. This is defined in the Kubernetes Pod Security Standards documentation, where the restricted profile mandates 'seccomp: RuntimeDefault' as a baseline requirement. Therefore, option C is correct because it directly matches the policy that enforces this specific seccomp constraint.
Exam trap
The trap here is that candidates often confuse the 'baseline' standard with 'restricted', assuming baseline covers seccomp requirements, but baseline only addresses basic privilege escalation and does not mandate a specific seccomp profile.
How to eliminate wrong answers
Option A is wrong because the 'privileged' PSA standard imposes no restrictions on seccomp profiles, allowing any profile or no profile at all. Option B is wrong because the 'baseline' PSA standard only prevents known privilege escalations but does not mandate a specific seccomp profile like 'RuntimeDefault'. Option D is wrong because 'pod-security.kubernetes.io/enforce=seccomp' is not a valid PSA standard; the valid standards are 'privileged', 'baseline', and 'restricted', and seccomp is a control within the restricted standard, not a standalone policy level.
You need to view the logs of the previous (terminated) instance of a container in a pod. Which command should you use?
The -p flag is short for --previous and shows logs from the previous instance of the container.
Why this answer
The '--previous' flag is used to retrieve logs from the previous instance of a container that has been terminated or restarted. This is useful for debugging crash loops.
You have a Service named 'myservice' in namespace 'default'. A pod in the same cluster but different namespace 'other' wants to resolve the service's IP. What DNS name should it use?
Correct for cross-namespace access.
Why this answer
Cross-namespace DNS uses the format <service>.<namespace>.svc.cluster.local.
You need to debug a pod that has no running containers because it is in a CrashLoopBackOff state. You want to start an ephemeral container with debugging tools in the same namespace. Which command accomplishes this?
This adds an ephemeral container to the running pod (or creates a copy if the pod is not running) with the specified image.
Why this answer
Option C is correct because `kubectl debug` allows you to start an ephemeral container in an existing pod that is in a CrashLoopBackOff state. The `--target` flag attaches the ephemeral container to the same Linux namespace as the specified container, enabling debugging without restarting the pod. This is the only command that works when the pod has no running containers and `kubectl exec` fails.
Exam trap
The trap here is that candidates assume `kubectl exec` is the standard debugging tool, but it fails when no container is running; `kubectl debug` with `--target` is the correct approach for CrashLoopBackOff scenarios.
How to eliminate wrong answers
Option A is wrong because `kubectl run` creates a new standalone pod, not an ephemeral container in the existing pod, so it cannot debug the specific pod's namespace or filesystem. Option B is wrong because `kubectl attach` only connects to a running container's stdin/stdout/stderr, and it fails when the pod is in CrashLoopBackOff with no running containers. Option D is wrong because `kubectl exec` requires at least one running container in the pod to execute a command, which is not available in CrashLoopBackOff.
You need to ensure that a pod in namespace 'dev' cannot consume more than 256Mi of memory. Which approach should you take?
Setting memory limits at the container level ensures that the container cannot exceed that amount.
Why this answer
To limit a pod's memory usage, you set 'resources.limits.memory' in the container spec. Option A sets a limit on the container, which is the correct way. Option B uses a LimitRange, which sets default limits but does not enforce a hard limit on a specific pod if the pod does not specify limits.
Option C uses a ResourceQuota which sets total limits for the namespace, not per-pod. Option D uses annotations which are not used for resource limits.
Which THREE are valid ways to expose a Service externally in Kubernetes?
Exposes on each node's IP.
Why this answer
NodePort, LoadBalancer, and Ingress are external exposure methods. ClusterIP is internal. Headless services are for internal stable identities.
A CronJob has concurrencyPolicy set to 'Forbid'. At the scheduled time, if the previous job is still running, what happens?
Forbid prevents concurrent runs; the new job is simply skipped.
Why this answer
Option A is correct. 'Forbid' means the new job is skipped if the previous job is still running. Option B (Replace) kills the previous and starts new. Option C (Allow) allows concurrent runs.
Option D (Delay) is not a valid concurrency policy.
A DevOps engineer is setting up network policies in a Kubernetes cluster. The goal is to allow traffic from pods with label 'role=frontend' to pods with label 'role=backend' on TCP port 8080, and deny all other ingress to backend pods. Which two components are necessary to implement this? (Choose two.)
The NetworkPolicy defines the allowed ingress to backend pods.
Why this answer
Option A is correct because a NetworkPolicy with an ingress rule selecting pods with label 'role=backend' defines the target pods for the policy. This is the foundational component that scopes the policy to backend pods, allowing you to then specify which sources (frontend pods) and ports (TCP 8080) are permitted.
Exam trap
The trap here is that candidates often think a CNI plugin (like Calico) is one of the two components needed to 'implement' the policy, but the question asks for the components you configure (the NetworkPolicy and its ingress rule), not the underlying infrastructure that makes it work.
A pod is using a Secret to authenticate to a private registry. The Secret type must be 'kubernetes.io/dockerconfigjson'. Which of the following is the correct way to create such a Secret using kubectl?
This correctly creates a dockerconfigjson Secret.
Why this answer
Option D is correct because `kubectl create secret docker-registry` is the dedicated command to create a Secret of type `kubernetes.io/dockerconfigjson`. It automatically generates the required `.dockerconfigjson` field with the base64-encoded Docker credentials in the correct JSON format, which the kubelet uses to authenticate to a private registry when pulling images.
Exam trap
The trap here is that candidates may think any Secret with a `.dockerconfigjson` key works, but without the correct `kubernetes.io/dockerconfigjson` type, the kubelet will not interpret the data properly, leading to image pull failures.
How to eliminate wrong answers
Option A is wrong because it uses `--type=kubernetes.io/dockercfg` (which corresponds to the legacy `.dockercfg` format) instead of `kubernetes.io/dockerconfigjson`, and `--from-literal=.dockercfg=...` does not produce the required `.dockerconfigjson` key. Option B is wrong because `--from-file=.dockerconfigjson` would create a generic Secret with that key, but the Secret type would remain `Opaque` unless explicitly set to `kubernetes.io/dockerconfigjson`; the command does not specify the required type. Option C is wrong because `kubectl create secret tls` creates a Secret of type `kubernetes.io/tls` for TLS certificates and keys, not for Docker registry authentication.
You need to rollback a Deployment to the previous revision. Which command achieves this?
Correct command for rollback to previous revision.
Why this answer
The 'kubectl rollout undo' command without flags rolls back to the previous revision.
You need to schedule a task that runs every day at 2:00 AM. The task should be allowed to run even if a previous instance is still running. Which concurrencyPolicy should you set in the CronJob spec?
Allow permits concurrent runs, so if a previous instance is still running, a new one can start.
Why this answer
Option B is correct. concurrencyPolicy: Allow permits multiple Job instances to run concurrently. Forbid prevents new runs if any is currently running. Replace kills the current run and starts a new one.
The default is Allow, but explicitly setting Allow is better for clarity.
Which TWO actions can you perform using 'kubectl describe'? (Select two.)
'kubectl describe node' shows conditions, capacity, and other details.
Why this answer
'kubectl describe' provides detailed information about Kubernetes resources, including events and conditions. It can show the current state and recent events. It does not modify resources or show logs.
You have a Deployment that is failing after a rollout. You want to revert to the previous revision. Which command accomplishes this?
This rolls back to the previous revision.
Why this answer
kubectl rollout undo reverts to the previous revision by default.
What is the effect of running 'kubectl rollout pause deployment web'?
Correct. The rollout is paused.
Why this answer
It pauses the current rollout, preventing further updates until resumed.
A Pod has two containers: one with a liveness probe that fails after 30 seconds. The restartPolicy is 'Never'. What state will the Pod be in after the liveness probe fails?
With restartPolicy: Never, the Pod enters Failed state when a container exits with non-zero or is killed.
Why this answer
With restartPolicy: Never, the container that fails is not restarted. The Pod status becomes Failed.
Practice CKAD by domain
Target a specific domain to shore up weak areas.