991 questions total · 14pages · All types, answers revealed
Which of the following is the correct way to scale a Deployment named 'api' to 5 replicas using kubectl?
Correct syntax.
Why this answer
'kubectl scale deployment api --replicas=5' is the correct command to scale a Deployment.
Which TWO of the following are true about headless services? (Select 2)
For headless services, DNS returns the IPs of all pods matching the selector.
Why this answer
Headless services set clusterIP: None, and they return DNS A records for each pod's IP. They are often used with StatefulSets. Option A and D are correct.
Option B is false because they don't provide a single VIP. Option C is false because they are used with StatefulSets. Option E is false because they can be used with any selector, not just StatefulSets, but the most common use is with StatefulSets.
A Deployment named 'web-app' has 4 replicas. You need to perform a rolling update with a maxSurge of 50% and maxUnavailable of 25%. Which YAML snippet configures this correctly?
Correctly sets maxSurge=50% and maxUnavailable=25%.
Why this answer
Option A sets maxSurge to 50% (2 pods) and maxUnavailable to 25% (1 pod), matching the requirement. Option B swaps the values. Option C uses incorrect field names (surge instead of maxSurge).
Option D uses absolute numbers.
You need to grant a ServiceAccount named 'app-sa' in namespace 'default' read-only access to Pods in that namespace. Which RBAC resources should you create?
Correct: Role scoped to namespace with read-only permissions, bound to the ServiceAccount.
Why this answer
Option C is correct because the ServiceAccount 'app-sa' requires read-only access to Pods only within the 'default' namespace. A Role is namespace-scoped and can define rules for pods with verbs get, list, watch. A RoleBinding then binds that Role to the ServiceAccount within the same namespace, granting the permissions exactly where needed.
Exam trap
The trap here is that candidates often confuse ClusterRole with Role, assuming ClusterRole is always needed for 'cluster' resources like nodes, but for namespace-scoped resources like Pods, a Role is the correct and more secure choice.
How to eliminate wrong answers
Option A is wrong because a ClusterRole is cluster-scoped and a ClusterRoleBinding would grant the permissions across all namespaces, which is excessive and violates the requirement of namespace-scoped access. Option B is wrong because while a RoleBinding is namespace-scoped, using a ClusterRole (even with a RoleBinding) is unnecessary and can lead to unintended broader access if the ClusterRole is later modified; a Role is the correct namespace-scoped resource. Option D is wrong because it includes the 'create' verb, which grants write access to Pods, violating the 'read-only' requirement.
Which kubectl command creates a Service of type ClusterIP named 'my-service' that exposes port 80 on a set of pods selected by label 'app: web'?
This correctly exposes a deployment as a ClusterIP service.
Why this answer
The correct command uses 'kubectl expose' with the '--type' flag to specify ClusterIP and '--target-port' for the container port. Option B is correct. Option A uses '--type=NodePort', which is incorrect.
Option C uses 'kubectl run' which is not the proper way to create a service. Option D uses 'kubectl create service clusterip' but without specifying the selector explicitly, it will not correctly select pods.
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
The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly resolving the OOM condition.
Exam trap
The trap here is that candidates may confuse OOMKilled with a general crash and choose to delete/recreate the pod, not realizing the OOMKilled status specifically indicates a memory limit violation that requires adjusting resource limits.
How to eliminate wrong answers
Option B is wrong because increasing CPU request does not affect memory allocation; OOMKilled is a memory issue, not a CPU issue. Option C is wrong because deleting and recreating the pod will not resolve the underlying memory limit; the pod will crash again with the same OOMKilled error. Option D is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that does not address the specific memory limit misconfiguration and would disrupt all workloads in the namespace.
Which THREE capabilities are commonly dropped in a pod's securityContext to adhere to restricted pod security standards?
SYS_ADMIN is a powerful capability often dropped.
Why this answer
Option B (SYS_ADMIN) is correct because the restricted pod security standard (PSS) requires dropping all capabilities via `ALL` and then adding back only those needed. However, `SYS_ADMIN` is a highly privileged capability that grants broad system administration access, such as mounting filesystems and performing privileged syscalls, and is explicitly forbidden in restricted profiles. Dropping it is mandatory to comply with restricted PSS.
Exam trap
The trap here is that candidates confuse the wildcard `ALL` (used to drop all capabilities) with a specific capability, or they assume `CHOWN` is dangerous because it relates to ownership, when in fact it is permitted under restricted PSS.
A ClusterRole named 'pod-reader' allows get, list, and watch on pods. A RoleBinding 'read-pods' in namespace 'default' binds this ClusterRole to user 'jane'. Which statement is true?
A RoleBinding grants permissions in its namespace only. The ClusterRole provides the rules, but the scope is limited by the RoleBinding.
Why this answer
A RoleBinding in a specific namespace binds a ClusterRole to a subject only within that namespace. Since the RoleBinding 'read-pods' is in the 'default' namespace, user 'jane' receives the permissions defined in the 'pod-reader' ClusterRole (get, list, watch on pods) only within the 'default' namespace, not across all namespaces.
Exam trap
The trap here is that candidates often assume a ClusterRole always grants cluster-wide permissions, forgetting that a RoleBinding scopes those permissions to a single namespace, while a ClusterRoleBinding is needed for true cluster-wide access.
How to eliminate wrong answers
Option A is wrong because a RoleBinding binds a ClusterRole to a subject only within the namespace where the RoleBinding exists, not across all namespaces; a ClusterRoleBinding would be required for cluster-wide access. Option B is wrong because a RoleBinding can bind a ClusterRole to a subject within a specific namespace, so it works correctly as is; no change to a ClusterRoleBinding is needed. Option C is wrong because the 'pod-reader' ClusterRole only grants get, list, and watch permissions on pods, not delete; a ClusterRole does not imply full access, only the permissions explicitly defined in its rules.
Which command shows resource usage (CPU and memory) for pods in a namespace?
Correct command to view pod resource usage.
Why this answer
The `kubectl top pod` command is the correct way to view real-time CPU and memory usage for pods in a specific namespace. The `-n <namespace>` flag targets the desired namespace, and the command relies on the metrics-server to collect resource usage data from the kubelet's cAdvisor endpoint.
Exam trap
The trap here is that candidates often confuse `kubectl top pod` (which requires the metrics-server) with `kubectl describe pod` (which shows resource requests/limits, not actual usage), or they omit the `-n` flag and assume it works across all namespaces.
How to eliminate wrong answers
Option A is wrong because `kubectl top node` shows resource usage for nodes (the entire worker machine), not for individual pods within a namespace. Option C is wrong because `kubectl top pods` without a namespace flag defaults to the current context's namespace (often `default`), not the specified namespace, and is incomplete without `-n`. Option D is wrong because `kubectl get pods --show-labels` only lists pod metadata and labels, not CPU or memory usage metrics.
You apply the following Ingress manifest: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: ingressClassName: nginx rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 The Ingress controller logs show a 404 error when accessing 'http://example.com/api'. The service 'api-service' exists and is reachable via ClusterIP. What is the most likely cause?
The Ingress controller must be configured to process the specified ingressClassName. If the IngressClass is missing, the Ingress will not be processed, resulting in 404.
Why this answer
The Ingress resource specifies an ingressClassName 'nginx', but if the corresponding IngressClass resource does not exist or the controller is not configured to watch that class, the Ingress will be ignored. Option C is correct. Option A is incorrect because the service port and container port don't need to match; the service targets the container port.
Option B is incorrect because the path and pathType are correct. Option D is incorrect because the service must be in the same namespace as the Ingress.
You need to view the logs of a container that previously crashed and has been restarted. Which flag do you use with 'kubectl logs'?
--previous shows logs from the previous container instance.
Why this answer
The `--previous` flag is used with `kubectl logs` to view logs from the previous instance of a container that has crashed and been restarted. This allows you to inspect the logs of the terminated container before the restart, which is essential for debugging crash loops.
Exam trap
CNCF often tests the distinction between flags that affect log output formatting (`--tail`, `-f`) versus flags that change which container instance's logs are accessed (`--previous`), leading candidates to confuse `--tail` or `-f` as solutions for viewing previous crash logs.
How to eliminate wrong answers
Option A is wrong because `--all-containers` is used to stream logs from all containers in a pod, not specifically from a previously crashed container. Option B is wrong because `--tail` limits the number of lines shown from the log output, but it does not retrieve logs from a previous container instance. Option D is wrong because `-f` (follow) streams logs in real-time, which is useful for live monitoring but does not access historical logs from a crashed container.
You are implementing a blue-green deployment using Kubernetes Deployments and Services. The 'blue' Deployment runs version 1.0, and the 'green' Deployment runs version 2.0. What is the key mechanism to switch traffic from blue to green?
This switches traffic to the green version.
Why this answer
By updating the Service's label selector to match the green Deployment's pod labels, the Service routes traffic to the new version.
Which annotation is used to specify the IngressClass for an Ingress resource in Kubernetes v1.18+?
Specifies the ingress class to use, though the newer way is spec.ingressClassName.
Why this answer
Option B is correct. The 'kubernetes.io/ingress.class' annotation was deprecated in v1.18 in favor of the 'spec.ingressClassName' field, but the annotation still works. Option A is for a different annotation.
Option C is for ingress controller. Option D is for custom annotation.
You have a Deployment running a web server that takes 30 seconds to initialize. You want to ensure that the load balancer does not send traffic to the pod until it is ready. Which probe should you configure?
Readiness probes indicate whether a pod is ready to serve traffic; if it fails, the pod is removed from Service endpoints.
Why this answer
A Readiness probe is the correct choice because it determines whether a Pod is ready to serve traffic. In this scenario, the web server takes 30 seconds to initialize, so a Readiness probe (e.g., an HTTP GET on the application's health endpoint) will prevent the Service (and thus the load balancer) from sending requests until the probe succeeds, ensuring zero traffic is routed to an uninitialized Pod.
Exam trap
The trap here is that candidates confuse Startup probes with Readiness probes, thinking a Startup probe alone will gate traffic, but only the Readiness probe controls whether the Service routes traffic to the Pod.
How to eliminate wrong answers
Option B is wrong because a Resource limit (CPU/memory) controls resource usage and scheduling, not traffic routing; it does not prevent the load balancer from sending traffic to an unready Pod. Option C is wrong because a Startup probe checks if the application has started successfully and is used for slow-starting containers, but it does not control traffic routing from the load balancer; once the Startup probe succeeds, the Liveness and Readiness probes take over, and the Readiness probe is the one that gates traffic. Option D is wrong because a Liveness probe restarts the container if it fails, but it does not prevent traffic from being sent to an unready Pod; a Pod can be alive but not ready, and the Liveness probe would not stop traffic.
You need to run a batch job that processes 10 items in parallel across 10 Pods, but the job should be considered complete only when all 10 Pods have succeeded. Which Job configuration is correct?
This runs 10 Pods in parallel and requires all 10 to complete successfully.
Why this answer
Option B is correct. completions: 10 and parallelism: 10 will run 10 Pods in parallel and require all 10 to succeed. Option A has completions: 10 but parallelism: 1, so Pods run sequentially. Option C has completions: 1, so only one Pod needs to succeed.
Option D has parallelism: 10 but completions: 1, so only one Pod needs to succeed.
You have a Deployment 'app' with the following strategy configuration: 'type: RollingUpdate', 'rollingUpdate: {maxSurge: 0, maxUnavailable: 1}'. You update the container image. What is the behavior during the update?
With maxSurge=0, no extra pods are created, so each old pod must be terminated before its replacement is created.
Why this answer
Option A is correct: maxSurge=0 means no extra pods above the desired count; maxUnavailable=1 means one pod can be unavailable at a time. So one old pod is terminated before a new one is created. Option B describes Recreate.
Option C is incorrect because maxSurge=0 prevents creating new pods first. Option D is incorrect because only one pod is unavailable.
A developer wants to create a Job that runs exactly 3 pods in parallel. Which field should be set in the Job spec?
parallelism sets the maximum number of pods running in parallel.
Why this answer
The 'parallelism' field controls how many pods can run concurrently.
Which TWO are correct about LimitRange?
Yes, via spec.default.
Why this answer
Option A is correct because a LimitRange can define default resource requests and limits for containers in a namespace. When a container is created without specifying resource requests or limits, the LimitRange admission controller automatically applies the default values defined in the LimitRange object. This ensures that containers have baseline resource guarantees even if the pod spec omits them.
Exam trap
The trap here is confusing LimitRange (per-container constraints and defaults) with ResourceQuota (aggregate namespace limits), leading candidates to incorrectly select option D.
You want to deny all incoming traffic to a set of pods except from pods with label 'role: frontend'. Which NetworkPolicy spec should you use?
This selects the target pods and allows traffic only from frontend pods.
Why this answer
A NetworkPolicy with podSelector matching the target pods and an ingress rule allowing only sources with label 'role: frontend' is needed.
You have a Job that should retry up to 3 times if it fails, and should be considered failed after 4 failures total (including retries). Which YAML fields should you set?
backoffLimit sets the number of retries. With 3 retries, total attempts = 1 (initial) + 3 (retries) = 4.
Why this answer
The .spec.backoffLimit field sets the number of retries, and .spec.activeDeadlineSeconds sets a timeout for the job. However, the question asks for failures total. By default, the backoff limit is 6, but setting it to 3 means 4 total attempts (initial + 3 retries).
The field that controls retries is backoffLimit, and activeDeadlineSeconds is optional. However, the most direct answer is to set backoffLimit: 4? Actually, the initial attempt is not a retry; backoffLimit defines the number of retries. So for 4 total attempts, set backoffLimit: 3.
But the options need to be evaluated. Let's create plausible distractors.
Which TWO of the following are valid uses of Kubernetes Annotations? (Select two.)
Many ingress controllers use annotations to customize behavior per ingress resource.
Why this answer
Options B and D are correct. Annotations are used to attach non-identifying metadata. Option B is correct because annotations can be used by tools like Helm to track release information.
Option D is correct because annotations can be used by ingress controllers for specific configurations. Option A is incorrect because selectors are used for identification. Option C is incorrect because the 'name' field is used for naming.
Option E is incorrect because annotations are not used for service discovery; labels and selectors are.
A Job has the following spec: apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never backoffLimit: 4 If the pod fails, how many times will Kubernetes retry the job before considering it failed?
backoffLimit sets the number of retries. After 4 retries, the job is marked as failed.
Why this answer
Option C is correct. backoffLimit specifies the number of retries before marking the job as failed. The default is 6. Here, backoffLimit: 4 means the job will be retried up to 4 times after the initial failure, so a total of 5 attempts (1 initial + 4 retries).
However, the question asks 'before considering it failed' — after the backoffLimit is exhausted, the job is marked as failed. So the number of retries is exactly the backoffLimit value.
You want to run a command inside a running container to check environment variables. Which command should you use?
This runs the 'env' command inside the container.
Why this answer
Option B is correct because `kubectl exec pod-name -- env` runs the `env` command inside the specified container, which prints all environment variables set in the container's runtime environment. This is the most direct and efficient way to inspect environment variables without entering an interactive shell.
Exam trap
The trap here is that candidates may choose Option D thinking they need an interactive shell to run `env`, but the question asks for the command to check environment variables directly, and `kubectl exec pod-name -- env` is the precise, non-interactive approach that works even in containers without a shell.
How to eliminate wrong answers
Option A is wrong because `kubectl logs pod-name` retrieves the container's stdout/stderr logs, not environment variables. Option C is wrong because `kubectl describe pod pod-name` shows the pod's specification and status, including environment variables defined in the pod spec, but it does not show runtime environment variables injected by the container runtime (e.g., from secrets, configmaps, or the platform). Option D is wrong because `kubectl exec -it pod-name -- /bin/bash` opens an interactive shell inside the container, which can then be used to run `env`, but it is not the direct command to check environment variables; it requires an extra step and assumes the container has a shell like bash.
A developer creates a Secret using the command: 'kubectl create secret generic db-secret --from-literal=password=myPass'. Which way to consume this Secret in a pod is CORRECT?
This correctly references the secret key 'password' from the Secret named 'db-secret'.
Why this answer
Option A is correct because `secretKeyRef` under `valueFrom` in an `env` entry is the proper way to inject a single key from a Kubernetes Secret into a container environment variable. The Secret was created with key `password` and value `myPass`, so `secretKeyRef` with `name: db-secret` and `key: password` correctly references that key.
Exam trap
The trap here is that candidates often confuse `configMapKeyRef` with `secretKeyRef` or assume that `envFrom` is the only way to consume Secrets, but the exam tests the precise syntax for referencing a single key from a Secret into a specific environment variable.
How to eliminate wrong answers
Option B is wrong because it shows a valid volume mount of the entire Secret, but the question asks for consuming the Secret in a pod, and while this is a valid method, it is not the only correct method; however, the question expects the specific correct way among the options, and B is technically correct but not the only correct answer, but the trap is that B is also a valid consumption method, but the question asks for 'which way is CORRECT' and both A and B are correct, but the exam expects A as the most direct answer for environment variable injection. Option C is wrong because `envFrom` with `secretRef` is valid for loading all keys from a Secret as environment variables, but it does not specify a single key; the question implies consuming the specific `password` key, and `envFrom` would expose all keys, which is not incorrect but less precise; however, the real issue is that `envFrom` is a valid method, but the question's answer set expects a single correct answer, and A is the most precise. Option D is wrong because `configMapKeyRef` is used to reference a ConfigMap, not a Secret; using it with a Secret name will fail because Secrets and ConfigMaps are separate resource types with different API objects.
A NetworkPolicy allows egress traffic to pods with label 'db: mysql' in the same namespace. Which egress rule is correct?
Correct.
Why this answer
Egress rules use 'to' with podSelector. Option A uses 'from' which is for ingress. Option D uses namespaceSelector incorrectly.
Which of the following commands creates a deployment named 'webapp' that runs the image 'nginx:1.25' with 3 replicas and exposes port 80?
This command creates a deployment named webapp with 3 replicas and exposes port 80.
Why this answer
Option B is correct. The kubectl create deployment command creates a deployment with a given name and image. The --replicas flag sets the number of replicas.
The --port flag is used to create a Service by default, but for this question, it is used to expose the container port. Option A uses --replicas incorrectly (it should be --replicas, not --replicas). Option C uses the wrong command (kubectl run is for pods, not deployments).
Option D has a typo (--replicas instead of --replicas).
A CronJob is configured with concurrencyPolicy: Replace and a job execution takes 10 minutes. The schedule is */5 * * * *. Which statement is true about job executions?
Replace policy terminates the running job and starts a new one at each scheduled time.
Why this answer
With concurrencyPolicy: Replace, if a new job should start while a previous one is still running, the running job is terminated and a new one is created. The schedule triggers every 5 minutes.
Which command lists all Helm releases in the current namespace?
Correct.
Why this answer
'helm list' lists all Helm releases. 'helm ls' is an alias.
You want to perform a rolling update of a Deployment. The Deployment has a maxSurge=1 and maxUnavailable=0. How many extra pods can be created above the desired count during the update?
Correct.
Why this answer
maxSurge=1 means at most one additional pod can be created above the desired replicas.
You want to configure a pod so that it receives a SIGTERM signal and has 60 seconds to shut down gracefully before being forcefully killed. Which field should you set?
This field defines the grace period for pod termination.
Why this answer
The 'terminationGracePeriodSeconds' field sets the time between SIGTERM and SIGKILL. Setting it to 60 gives 60 seconds for graceful shutdown. Option A is correct.
Option B is for preStop hook, not the grace period. Option C is for probes. Option D is for resource limits.
A developer wants to restrict a Pod's resource usage. Which two API resources can be used to enforce limits at the namespace level? (Choose two.)
Sets default resource limits and requests for containers in a namespace.
Why this answer
LimitRange (C) is correct because it allows administrators to set default resource requests and limits, as well as minimum and maximum constraints, for Pods and containers within a namespace. This enforces resource boundaries at the namespace level, ensuring that individual Pods cannot exceed defined limits.
Exam trap
CNCF often tests the distinction between namespace-level resource enforcement (LimitRange and ResourceQuota) and cluster-level or scaling mechanisms, leading candidates to confuse HorizontalPodAutoscaler (which scales Pods) with resource limits.
You have a multi-container pod with a main container and a sidecar container that collects logs. The sidecar container should start before the main container and must complete initialization tasks before the main container starts. Which type of container should you use for this purpose?
Init containers run to completion sequentially before any regular containers start, making them suitable for initialization tasks.
Why this answer
Option C is correct. Init containers run sequentially and complete before any regular containers in the pod start. They are ideal for initialization tasks.
Sidecar containers (regular containers) run concurrently with the main container. Ephemeral containers are for debugging and do not run at pod startup. Jobs are not containers within a pod.
Which of the following is a valid way to expose a Secret as an environment variable in a Pod?
secretKeyRef is the correct way to reference a Secret key as an environment variable.
Why this answer
Option D is correct because `secretKeyRef` is the Kubernetes API field used to reference a specific key from a Secret object and expose its value as an environment variable in a Pod. This is defined in the Pod spec under `env[].valueFrom.secretKeyRef`, which requires the `name` of the Secret and the `key` within that Secret.
Exam trap
CNCF often tests the distinction between `configMapKeyRef`, `secretKeyRef`, and `fieldRef`, and the trap here is that candidates confuse `configMapKeyRef` (for non-sensitive data) with `secretKeyRef` (for sensitive data), or think that variable substitution like `$(VAR_NAME)` can directly pull from a Secret.
How to eliminate wrong answers
Option A is wrong because `configMapKeyRef` references a ConfigMap, not a Secret; ConfigMaps are for non-sensitive data, while Secrets are for sensitive data like passwords. Option B is wrong because `$(DB_PASSWORD_SECRET)` is a variable substitution syntax used for referencing other environment variables or container arguments, not for directly exposing a Secret's value. Option C is wrong because `fieldRef` is used to expose Pod metadata (e.g., `metadata.name`, `status.podIP`) via the downward API, not Secret data.
Which of the following is NOT a valid restart policy for a Pod?
UnlessStopped is not a valid Kubernetes restart policy.
Why this answer
Option C is correct. Pod restartPolicy only supports Always, OnFailure, and Never. 'UnlessStopped' is not a valid Kubernetes restart policy.
You want to add an annotation to a pod without modifying the pod template. Which approach should you use?
Correct command to add annotation.
Why this answer
Option B is correct: 'kubectl annotate pod my-pod key=value'. Option A uses the wrong command. Option C goes into edit mode.
Option D adds to the Deployment, which would roll out a new pod with the annotation in the template.
Your team manages a microservices application on a Kubernetes cluster. A critical service 'order-service' is deployed with 3 replicas. Lately, customers have reported occasional timeouts when placing orders. You suspect that the service is overloaded during peak hours. You have configured a HorizontalPodAutoscaler (HPA) based on CPU utilization, but the autoscaler does not appear to be scaling up quickly enough. Upon inspection, you notice that the HPA is configured with a target CPU utilization of 80%, and the current CPU usage of the pods is around 70%. However, the pods' memory usage is high and growing. The application is also logging slow database queries. Which action is most likely to improve the responsiveness of the service during peak load?
Memory-based scaling can detect the actual resource pressure.
Why this answer
Option A is correct because the HPA is configured only for CPU, but the symptom (high memory usage, slow DB queries) indicates memory pressure is the bottleneck. Adding a memory-based metric to the HPA allows it to scale when memory exceeds the target, addressing the root cause of overload during peak hours. The current CPU at 70% is below the 80% threshold, so the HPA won't trigger on CPU alone, but memory scaling can react to the actual resource constraint.
Exam trap
The trap here is that candidates often assume CPU is the only metric for HPA scaling, but the CKAD exam tests the ability to identify when other metrics (like memory) are more relevant based on application behavior and symptoms.
How to eliminate wrong answers
Option B is wrong because reducing replicas to 2 would decrease capacity, worsening the overload and timeouts, not improving responsiveness. Option C is wrong because increasing the CPU target to 90% would make the HPA trigger later (at higher CPU), not earlier, and CPU is already below 80%, so this change would not help. Option D is wrong because while optimizing database queries is a valid long-term fix, it does not address the immediate scaling issue; the HPA should be configured to scale based on the actual bottleneck (memory) to handle peak load now.
Which three security contexts can be set at the pod level (as opposed to container level)? (Select THREE.)
fsGroup can be set at the pod level for volume ownership.
Why this answer
B is correct because `fsGroup` is a Pod-level security context field that applies a supplemental group ID to all containers in the Pod, ensuring that volumes mounted with that group ownership are accessible. It is set under `spec.securityContext.fsGroup`, not at the container level, making it a Pod-scoped setting.
Exam trap
The trap here is that candidates confuse Pod-level and container-level security contexts, often selecting `capabilities` or `readOnlyRootFilesystem` because they are commonly used, but they are only valid at the container level in the Kubernetes API.
Which THREE configurations are part of Pod Security Admission's 'restricted' profile? (Select THREE.)
Correct. Containers must run as non-root.
Why this answer
The 'restricted' profile in Pod Security Admission enforces the most stringent security standards. Option A is correct because `runAsNonRoot: true` is a required field in the restricted profile, ensuring containers cannot run as the root user, which mitigates privilege escalation risks.
Exam trap
The trap here is that candidates often confuse the 'restricted' profile with the 'baseline' profile, mistakenly thinking that options like `allowPrivilegeEscalation: true` or privileged containers are acceptable, when in fact the restricted profile explicitly prohibits them.
You have deployed an application using Helm. You want to see the history of revisions for the release 'frontend' in the 'web' namespace. Which command should you use?
Correct command to show revision history.
Why this answer
The command 'helm history frontend --namespace web' lists all revisions for the release 'frontend' in the 'web' namespace.
A Pod is configured with automountServiceAccountToken: false. The application inside the pod needs to access the Kubernetes API. What should be done?
You can manually mount the token by using a projected volume with serviceAccountToken.
Why this answer
Setting automountServiceAccountToken: false prevents automatic mounting of the service account token. To still access the Kubernetes API, you must manually mount the token by adding a volume of type projected (or secret) containing the service account token, and a corresponding volumeMount in the container. This allows the application to authenticate with the API server using the mounted token.
Exam trap
The trap here is that candidates assume automountServiceAccountToken: false permanently blocks API access, but the CKAD exam tests that you can override this by manually mounting the token, often using a projected volume or a secret reference.
How to eliminate wrong answers
Option A is wrong because a Secret of type kubernetes.io/dockerconfigjson is used for pulling images from private registries, not for API authentication. Option C is wrong because the application can still access the API if the token is manually mounted; the setting is not final. Option D is wrong because ConfigMaps store non-sensitive configuration data, not service account tokens, which are sensitive and must be stored in Secrets or projected volumes.
You want to view the logs of a pod named 'web-pod' that has two containers: 'nginx' and 'sidecar'. Which command correctly streams the logs from the 'nginx' container?
Correct. The -c flag specifies the container name.
Why this answer
When a pod has multiple containers, you must specify the container name with -c flag.
You have a pod that is in a 'Pending' state. You run 'kubectl describe pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?
The event indicates CPU insufficiency.
Why this answer
The event '0/3 nodes are available: 3 Insufficient cpu' indicates that the Kubernetes scheduler attempted to place the pod on each of the three nodes but found that none had enough allocatable CPU capacity to satisfy the pod's CPU request. This means the sum of CPU requests across all pods on each node, plus the new pod's request, exceeds the node's CPU capacity. The pod remains in 'Pending' because the scheduler cannot find a suitable node until CPU resources are freed or the request is reduced.
Exam trap
CNCF often tests the distinction between resource requests (used for scheduling) and resource limits (used for throttling), and candidates mistakenly think 'Insufficient cpu' refers to limits or actual usage rather than the guaranteed request that the scheduler evaluates.
How to eliminate wrong answers
Option B is wrong because the event explicitly mentions 'Insufficient cpu', not memory; a memory shortage would produce 'Insufficient memory'. Option C is wrong because liveness probe failures occur after the pod is running (in 'Running' state), not while it is still 'Pending' and before scheduling. Option D is wrong because taints and tolerations produce events like '0/3 nodes are available: 3 node(s) had taint {key:value} that the pod didn't tolerate', not 'Insufficient cpu'.
Which TWO of the following are valid methods to perform a blue-green deployment in Kubernetes?
This switches traffic to the new version by changing the selector.
Why this answer
A blue-green deployment involves two versions (blue and green) and switching traffic between them. Options A and D are valid: creating a new Deployment with the new version and updating the Service selector, or using two Services with different selectors and switching via DNS or ingress.
Which TWO commands can be used to view the logs of a pod that has crashed?
Shows logs from the previous container instance.
Why this answer
Option C is correct because `kubectl logs <pod> --previous` retrieves logs from the previous instance of a container in a pod that has crashed and been restarted. This is essential for debugging crash loops, as the current container may have no logs or only post-crash output. The `--previous` flag accesses the terminated container's logs stored by the kubelet.
Exam trap
CNCF often tests the distinction between `--previous` (or `-p`) and `-c` flags, where candidates mistakenly think `-c` retrieves logs from a crashed container instead of specifying a container name in a multi-container pod.
Which TWO statements about headless services are correct?
DNS returns A records for each pod.
Which THREE of the following are valid rules for a NetworkPolicy that allows egress traffic from pods with label 'app: worker' to the external IP range '192.168.0.0/16' on port 53 UDP? (Select 3)
This is also valid; order of fields does not matter.
Why this answer
To allow egress to an external IP range, you use egress rules with to containing ipBlock and ports. Multiple rules can be combined. Options B, D, and E are valid ways to express this.
Option A is incorrect because it also allows to all pods. Option C is incorrect because it uses from instead of to.
You are performing a blue-green deployment. You have two Deployments: 'app-blue' (current) and 'app-green' (new). Both have labels 'app: myapp' and 'version: blue' or 'version: green' respectively. The Service 'myapp-svc' selects pods with 'app: myapp, version: blue'. How do you switch traffic to the green deployment?
Directly changes the Service to route traffic to green pods.
Why this answer
Option B is correct: update the Service's selector to 'app: myapp, version: green'. Option A changes the Deployment, not the Service. Option C would break the Service selector syntax.
Option D changes the green Deployment's labels, which would not be picked up by the Service without selector change.
A cluster administrator wants to enforce that all pods in a namespace run with the 'restricted' Pod Security Standard. Which of the following is the correct way to label the namespace?
Correct. enforce level enforces the policy, rejecting pods that violate.
Why this answer
The 'restricted' Pod Security Standard is enforced by applying the label `pod-security.kubernetes.io/enforce: restricted` to the namespace. This label causes the Pod Security Admission controller to reject any pod that violates the restricted policy, ensuring compliance. The other labels (`warn` and `audit`) only generate warnings or audit annotations without blocking non-compliant pods.
Exam trap
CNCF often tests the distinction between `enforce`, `warn`, and `audit` labels, trapping candidates who assume any of these labels will block non-compliant pods, when only `enforce` actually rejects them.
How to eliminate wrong answers
Option B is wrong because `pod-security.kubernetes.io/warn: restricted` only generates a warning event when a pod violates the restricted policy, but does not enforce it or block the pod from running. Option C is wrong because `pod-security.kubernetes.io/audit: restricted` only adds an audit annotation to the pod's audit log entry for violations, without any enforcement or warning to the user.
You need to allow ingress traffic to pods in namespace 'api' only from pods in namespace 'frontend' that have label 'role: proxy'. Which NetworkPolicy ingress rule correctly implements this?
This selects pods with label 'role: proxy' in namespaces that have label 'name: frontend'.
Why this answer
To select pods from another namespace with a specific label, you must use both namespaceSelector and podSelector in the same from item. Option A is correct. Option B allows from any pod in namespace 'frontend' regardless of label.
Option C allows from any pod with label 'role: proxy' in any namespace. Option D uses ipBlock which is not needed.
In a Deployment, what is the purpose of the 'maxUnavailable' field in the rolling update strategy?
Correct definition.
Why this answer
In a Deployment's rolling update strategy, the 'maxUnavailable' field specifies the maximum number of Pods that can be unavailable during the update process. This ensures that the Deployment maintains a certain level of availability by controlling how many Pods can be taken down at any given time, relative to the desired replica count. It is defined as either an absolute number or a percentage of the desired Pods, and it works alongside 'maxSurge' to manage the update's pace and safety.
Exam trap
The trap here is that candidates often confuse 'maxUnavailable' with 'maxSurge', thinking it controls the number of Pods created above the desired count, when in fact 'maxUnavailable' governs the number of Pods that can be unavailable, while 'maxSurge' controls the number of extra Pods created above the desired replicas.
How to eliminate wrong answers
Option A is wrong because 'maxUnavailable' does not limit the number of Pods that can be terminated at once; that behavior is governed by the combination of 'maxUnavailable' and 'maxSurge', but 'maxUnavailable' specifically caps the number of Pods that can be in an unavailable state, not the termination rate. Option C is wrong because there is no 'maxUnavailable' field for rollout completion time; Kubernetes uses 'progressDeadlineSeconds' to set a timeout for the rollout to complete, not 'maxUnavailable'. Option D is wrong because the maximum number of Pods that can be created above the desired replicas is controlled by the 'maxSurge' field, not 'maxUnavailable'; 'maxUnavailable' deals with unavailability, not overshooting the replica count.
You need to debug a pod that has no running container because it crashed. The pod is in CrashLoopBackOff. Which command allows you to start a temporary container in the same pod for debugging?
This adds an ephemeral debug container.
Why this answer
kubectl debug can add an ephemeral container to a running or crashed pod.
Which Dockerfile instruction is used to specify the base image for a build?
FROM specifies the base image.
Why this answer
The FROM instruction initializes a new build stage and sets the base image.
What is the purpose of the 'kubectl describe pod' command?
kubectl describe provides a comprehensive overview of a pod's state and recent events.
Why this answer
The 'kubectl describe pod' command retrieves detailed metadata about a specific pod, including its current state, labels, annotations, container specifications, volumes, and a chronological list of recent events (e.g., image pull failures, container restarts, scheduling decisions). This aggregated information is essential for debugging pod lifecycle issues because it surfaces both static configuration and dynamic cluster-level events that are not shown in the pod's YAML manifest or logs.
Exam trap
CNCF often tests the distinction between 'describe' (detailed metadata + events) and 'get' (summary or YAML output), so the trap here is confusing 'kubectl describe' with 'kubectl logs' or 'kubectl exec', especially when a pod is failing and candidates instinctively reach for logs instead of first checking events for scheduling or image-related errors.
How to eliminate wrong answers
Option B is wrong because executing a command inside a pod is done with 'kubectl exec', not 'kubectl describe'. Option C is wrong because resource usage (CPU/memory) is displayed by 'kubectl top pod', which relies on the metrics-server, not by 'kubectl describe'. Option D is wrong because showing logs is the purpose of 'kubectl logs', which streams stdout/stderr from containers, whereas 'kubectl describe' provides configuration and event data, not log output.
Which of the following is true about the CMD instruction in a Dockerfile?
CMD is the default command, easily overridden by docker run arguments.
Why this answer
CMD sets the default command to run when the container starts, but it can be overridden by command-line arguments to docker run.
You have a Deployment named 'web' with label 'app: web'. You want to create a Service that exposes the Deployment on port 80 internally within the cluster. Which kubectl command achieves this?
Correctly creates a ClusterIP Service for the 'web' Deployment on port 80.
Why this answer
Option A is correct. 'kubectl expose deployment web --port=80' creates a ClusterIP Service targeting pods with label 'app: web' (inherited from the Deployment) and exposes port 80.
You want to collect logs from a pod that has multiple containers. Which TWO approaches allow you to view logs from a specific container?
Correct syntax to specify container.
Why this answer
Option A is correct because the `kubectl logs` command with the `-c` flag allows you to specify a container name within a multi-container pod. This is the standard shorthand for `--container` and is explicitly supported in the Kubernetes CLI for targeting logs from a specific container.
Exam trap
The trap here is that candidates may think `--all-containers` is a valid way to view logs from a specific container, but it actually streams logs from all containers, which is not what the question asks; also, the duplicate options A and D are both correct, but candidates might overlook that both are valid and pick only one.
Which THREE are valid reasons to use a StatefulSet instead of a Deployment?
StatefulSets assign stable hostnames based on ordinal index.
Why this answer
StatefulSet assigns each pod a stable, unique network identity (e.g., a hostname like `web-0`, `web-1`) via a headless Service, which is critical for stateful applications like databases that rely on consistent DNS names for clustering and discovery. Deployments create pods with random, ephemeral hostnames, making them unsuitable for workloads requiring predictable network identities.
Exam trap
CNCF often tests the misconception that only StatefulSets support rolling updates, but both controllers do; the trap is confusing a shared feature with a unique StatefulSet capability.
A Pod in a namespace with a ResourceQuota that sets 'limits.cpu: 4' and 'limits.memory: 8Gi' is being created with the following container resources: requests: cpu: 2, memory: 4Gi; limits: cpu: 4, memory: 8Gi. The namespace also has a LimitRange with default limits of cpu: 500m, memory: 512Mi. Which statement is true about this resource configuration?
The pod's limits do not exceed the quota, and since limits are specified, LimitRange defaults are not applied.
Why this answer
B is correct because the Pod explicitly sets its own limits (cpu: 4, memory: 8Gi) and requests (cpu: 2, memory: 4Gi), which are within the ResourceQuota's 'limits.cpu: 4' and 'limits.memory: 8Gi' constraints. The LimitRange default limits only apply to containers that do not specify limits; since this Pod specifies limits, the defaults are ignored. The Pod is admitted as it satisfies both admission controllers.
Exam trap
The trap here is that candidates assume LimitRange defaults always override Pod specifications, but in reality defaults only apply when the Pod does not set its own limits, and the Pod's explicit limits take precedence.
How to eliminate wrong answers
Option A is wrong because LimitRange defaults only apply to containers that do not have limits set; here limits are explicitly defined, so no override occurs. Option C is wrong because the Pod's limits exactly match the ResourceQuota's maximum (4 CPU, 8Gi memory), not exceed it, and the LimitRange default is irrelevant when limits are set. Option D is wrong because Kubernetes does not require requests to equal limits; they can differ, and the ResourceQuota only enforces the maximum limits, not equality.
Which THREE are valid fields in a NetworkPolicy spec? (Choose three.)
Required.
Why this answer
Valid fields include podSelector, policyTypes, and ingress. egress is also valid but not listed as correct in this set.
You have a CronJob that runs every 5 minutes. The job sometimes takes longer than 5 minutes to complete. You want to ensure that while a job is running, the next scheduled job is skipped (not started). Which concurrencyPolicy should you use?
Forbid skips the next run if the previous job is still active.
Why this answer
concurrencyPolicy: Forbid prevents new jobs from starting while the previous job is still running.
You run 'kubectl apply -f pod.yaml' but the pod remains in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient cpu'. What is the most likely cause?
The message 'Insufficient cpu' means no node can satisfy the CPU request. This is the correct interpretation.
Why this answer
Option D is correct. The error indicates that no node has enough CPU capacity to satisfy the pod's CPU request. Option A would cause a different error (ImagePullBackOff).
Option B is unrelated to CPU. Option C is not a typical cause of Insufficient CPU; node pressure is a symptom, not a cause.
A NetworkPolicy denies all ingress traffic to a namespace. Which rule would allow traffic only from pods in the same namespace?
Empty podSelector selects all pods in the same namespace.
Why this answer
To allow traffic from within the same namespace, use a podSelector that matches all pods (empty selector) in the ingress from rule. This allows traffic from any pod in the namespace.
To prevent a container from running as root, which field should be set in the securityContext?
Enforces that the container must not run as root; if the image runs as root, the container will fail.
Why this answer
The `runAsNonRoot: true` field in the securityContext explicitly prevents the container from running as the root user (UID 0). When set, Kubernetes will refuse to start the container if the image is configured to run as root, enforcing a non-root execution policy at the pod or container level. This is the direct and intended mechanism for ensuring the container does not run with root privileges.
Exam trap
The trap here is that candidates often confuse `runAsNonRoot: true` with `runAsUser: 1000`, mistakenly thinking that setting a non-zero user ID alone guarantees the container does not run as root, when in fact `runAsUser` only sets the UID and does not enforce a root check, leaving the container vulnerable if the image defaults to root.
How to eliminate wrong answers
Option A is wrong because `runAsUser: 1000` sets a specific user ID for the container process but does not prevent running as root; if the image runs as root, this field overrides it only if explicitly set, and it does not enforce a non-root check. Option C is wrong because `allowPrivilegeEscalation: false` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not prevent the container from initially running as root. Option D is wrong because `readOnlyRootFilesystem: true` makes the container's root filesystem read-only, which is a security hardening measure but does not affect the user identity under which the container runs.
A developer wants to expose a Secret named 'db-secret' as environment variables in a Pod. The Secret has keys 'username' and 'password'. Which Pod spec snippet correctly achieves this?
Correct: envFrom with secretRef injects all keys as env vars.
Why this answer
Option A is correct because `envFrom` with `secretRef` allows you to inject all key-value pairs from a Secret as environment variables into a Pod in a single declaration. This is the most concise and intended method when you want to expose every key from a Secret (here 'username' and 'password') as individual environment variables without manually listing each one.
Exam trap
CNCF often tests the distinction between `envFrom` (bulk injection) and `env` with `secretKeyRef` (individual key injection), and the trap here is that candidates may choose option C because it works, missing that option A is the more efficient and correct approach for exposing all keys from a Secret as environment variables.
How to eliminate wrong answers
Option B is wrong because it mounts the Secret as files in a volume at `/etc/secret`, not as environment variables; the question specifically asks for environment variables. Option C is wrong because while it correctly uses `secretKeyRef` to expose individual keys as environment variables, it requires explicit enumeration of each key ('username' and 'password'), which is not the most efficient approach when the goal is to expose all keys from the Secret; the question asks for the snippet that 'correctly achieves this', and A is more direct and concise. Option D is wrong because it uses `configMapKeyRef` instead of `secretKeyRef`, and references a ConfigMap named 'db-secret' rather than a Secret, which would fail to read the Secret's data and would not expose the correct values.
You have a Deployment that uses the Recreate strategy. You update the container image. What happens to the existing pods?
Recreate first terminates all pods, then creates new ones.
Why this answer
With the Recreate strategy, all existing pods are killed before new pods are created. This ensures no two versions run simultaneously but causes downtime.
You are deploying a microservice application on a Kubernetes cluster. The application consists of a frontend service (type: ClusterIP) and a backend service (type: ClusterIP). The frontend needs to communicate with the backend via DNS name 'backend-service'. The backend service runs three replicas, each listening on port 8080. You have created the backend service and deployment, and verified that pods are running. However, when you deploy the frontend pod and attempt to curl http://backend-service:8080 from within the frontend, you get 'connection refused'. The frontend pod is in the same namespace as the backend. You check the backend pods and they are all running and ready, and the endpoints object shows the correct pod IPs. You suspect a misconfiguration in the service definition. Which of the following is the most likely cause of the issue?
If containerPort does not match targetPort, the service sends traffic to a port on the pod that is not listening, resulting in connection refused.
Why this answer
Option D is correct because the backend service's `targetPort` defaults to the value of `port` (8080) when not explicitly set, but the backend deployment's `containerPort` is 8081. This mismatch means the service sends traffic to port 8080 on the pods, where no process is listening, resulting in a 'connection refused' error. The pods are running and ready, but the readiness probe (if any) might still pass if it checks a different path, while the actual application port is misaligned.
Exam trap
The trap here is that candidates assume the `port` and `targetPort` are always identical by default and overlook checking the actual container listening port, leading them to incorrectly suspect DNS or resource issues.
How to eliminate wrong answers
Option A is wrong because the pods are running and ready, and the endpoints object shows correct pod IPs, which would not be the case if the cluster had insufficient resources. Option B is wrong because the frontend pod is in the same namespace as the backend service, so the short DNS name 'backend-service' resolves correctly; the fully qualified name is only needed for cross-namespace access. Option C is wrong because the default behavior of `targetPort` matching `port` is correct when the container listens on the same port; the issue here is a mismatch between the container's actual listening port and the service's target port.
A pod is scheduled but stays in Pending state. 'kubectl describe pod' shows: '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?
Correct: the scheduler cannot find a node with enough unallocated memory.
Why this answer
The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler could not find a node with enough allocatable memory to satisfy the pod's memory request. The pod's memory request (spec.containers[].resources.requests.memory) must be less than or equal to a node's allocatable memory for the pod to be scheduled. Since no node meets this requirement, the pod remains in Pending state.
Exam trap
The trap here is that candidates confuse memory requests with memory limits, assuming a low limit causes scheduling failure, when in fact the scheduler only evaluates requests, and limits only affect runtime OOM behavior.
How to eliminate wrong answers
Option B is wrong because a misconfigured liveness probe would cause the pod to be restarted or marked as unhealthy after it starts, not prevent it from being scheduled; scheduling failures occur before the pod runs. Option C is wrong because a ResourceQuota would cause an error like 'exceeded quota' or 'forbidden' when creating the pod, not a node-level 'Insufficient memory' message from the scheduler. Option D is wrong because a memory limit that is set too low would affect the pod's runtime behavior (e.g., OOMKill) but does not impact scheduling; the scheduler only considers the memory request, not the limit, when determining node fit.
Which TWO of the following are valid reasons to use a readiness probe? (Select 2)
Readiness probe checks if the pod can serve traffic.
Why this answer
A readiness probe is used to determine whether a pod is ready to serve traffic. Option A is correct because it prevents traffic from being sent to a pod that is not ready due to a dependency, such as a database or cache that hasn't fully initialized. The kubelet uses the probe's success or failure to control whether the pod's IP address is added to the endpoints of a Service, ensuring only ready pods receive requests.
Exam trap
CNCF often tests the distinction between readiness, liveness, and startup probes; the trap here is confusing the purpose of a readiness probe (traffic routing) with that of a liveness probe (container restart) or a startup probe (delaying other probes).
A Helm chart has the following template snippet: '{{ .Values.replicaCount }}'. You want to set replicaCount to 5 during installation. Which command should you use?
This overrides the 'replicaCount' value with 5 in the chart.
Why this answer
Option D is correct: '--set' overrides values directly on the command line. Option A sets the release name, not values. Option B specifies a values file, but the question asks for direct setting.
Option C is not a valid flag.
Which TWO of the following are valid ways to consume a ConfigMap in a pod?
This exposes all keys from the ConfigMap as environment variables.
Why this answer
Option C is correct because `envFrom` with a `configMapRef` is a valid method to consume a ConfigMap as environment variables in a pod. This injects all key-value pairs from the ConfigMap named `my-config` as environment variables into the container. Option E is also correct as it demonstrates mounting a ConfigMap as a volume using the `configMap` volume source with the correct `name` field and then mounting that volume into the container at `/etc/config`.
Exam trap
CNCF often tests the distinction between `configMapRef` and `secretRef`, and the correct field name for a ConfigMap volume source is `name`, not `configMapName`, which is a common misremembered field from older documentation or other resource types.
Which TWO of the following are valid ways to mount a Secret into a pod as environment variables? (Select exactly 2)
Correct: references a specific key from a Secret.
Why this answer
Option D is correct because `secretKeyRef` is the standard Kubernetes API field for referencing a specific key from a Secret object and injecting its value as an environment variable. Option E is correct because `envFrom` with `secretRef` allows you to load all key-value pairs from a Secret as environment variables into the pod, which is a valid and common pattern.
Exam trap
The trap here is that candidates often confuse `configMapKeyRef`/`configMapRef` with `secretKeyRef`/`secretRef`, or invent non-existent fields like `secretEnvRef`, because the syntax for Secrets and ConfigMaps is nearly identical except for the resource-specific keyword.
What is the purpose of the 'spec.externalName' field in a Service of type ExternalName?
ExternalName service provides DNS alias to external name.
Why this answer
Option A is correct. ExternalName service maps a service name to an external DNS name, returning a CNAME record. Option B is for LoadBalancer.
Option C for ClusterIP. Option D for NodePort.
You have a Deployment with the following strategy: rollingUpdate: maxSurge: 25%, maxUnavailable: 25%. The Deployment has 4 replicas. During an update, what is the minimum number of pods guaranteed to be available?
25% of 4 is 1, so at most 1 unavailable, guaranteeing 3 available.
Why this answer
maxUnavailable: 25% means at most 1 pod (25% of 4) can be unavailable. Therefore, at least 3 pods are available.
Which THREE statements are true about init containers? (Select 3)
Main containers wait for all init containers to succeed.
Why this answer
Options A, C, and D are correct. Init containers run sequentially (A), their restart policy is always RestartPolicyAlways regardless of pod's restartPolicy (C), and they must complete successfully before main containers start (D). Option B is false because init containers don't have liveness probes.
Option E is false because init containers can have resource limits.
You have a HorizontalPodAutoscaler (HPA) targeting a Deployment. The HPA is configured with 'targetCPUUtilizationPercentage: 50'. The current CPU utilization is 60% across the pods. What action does the HPA take?
By adding more pods, the load is distributed, reducing the average CPU utilization towards the target.
Why this answer
Option B is correct: HPA scales up to bring actual utilization closer to the target. Option A is incorrect because scaling down when above target would increase utilization further. Option C is incorrect because HPA does not wait for sustained load; it reacts based on the metric.
Option D is incorrect because HPA does not stop itself; it continues to adjust.
Practice CKAD by domain
Target a specific domain to shore up weak areas.