75 of 205 questions · Page 2/3 · Application Deployment · Answers revealed
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 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.
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 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.
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.
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.
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 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.
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`.
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 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 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 Deployment named 'api' has 6 replicas. You want to perform a rolling update with the following constraints: at most 2 pods can be unavailable during the update, and at most 1 extra pod can be created above the desired 6. Which strategy configurations achieve this? (Choose TWO)
Absolute numbers match constraints.
Why this answer
Option A: maxSurge=1 (extra pod), maxUnavailable=2 (unavailable pods) - satisfies constraints. Option E: maxSurge=1, maxUnavailable=2 - same. Option B has maxUnavailable=1 not 2.
Option C has maxSurge=2. Option D has maxUnavailable=3. So A and E are correct.
But note that A uses absolute numbers, E uses percentages. Both are valid.
Which TWO of the following are correct ways to pause a rollout of a Deployment named 'myapp'? (Select TWO)
Correct.
Why this answer
'kubectl rollout pause deployment/myapp' pauses the rollout. 'kubectl set image ... && kubectl rollout pause' pauses after setting the image but before the rollout completes. 'kubectl rollout resume' resumes, not pauses.
You want to perform a canary deployment where 10% of traffic goes to the new version. You have a Deployment 'app-v1' with 10 replicas. You create a second Deployment 'app-v2' with 1 replica and a new Service. What Kubernetes resource is typically used to split traffic between the two Services?
Ingress controllers support canary rules to split traffic.
Why this answer
An Ingress controller (like NGINX or other) with traffic splitting capabilities (e.g., via annotations or canary config) can distribute traffic between services. Alternatively, a Service Mesh like Istio can be used, but Ingress is the most common standard resource.
Which THREE of the following are valid fields in a HorizontalPodAutoscaler (HPA) v2 specification?
Yes, spec.metrics is an array of metric specifications.
Why this answer
In HPA v2 (autoscaling/v2), the spec includes 'metrics', 'behavior', and 'minReplicas'. 'metrics' defines the metrics to scale on, 'behavior' defines scaling policies, and 'minReplicas' sets the minimum number of pods. 'targetCPUUtilizationPercentage' is a deprecated field from v1. 'scaleTargetRef' is a required field but is not listed among the options as a field of spec; it's a separate field in the spec.
During a deployment update, the rollout is stuck and new pods are not becoming ready. The developer checks the events and sees 'Back-off restarting failed container'. What is the most likely cause?
If the command exits, the container crashes, leading to restart back-off.
Why this answer
The 'Back-off restarting failed container' event indicates that the container process exits immediately after starting, causing Kubernetes to repeatedly restart it with increasing back-off delays. This is most commonly caused by a container entrypoint or command that fails at runtime, such as a misconfigured binary, missing dependency, or incorrect startup script. Unlike probe failures, which cause restarts after the container is already running, this error occurs before the container can even become ready.
Exam trap
The trap here is that candidates confuse 'Back-off restarting failed container' with liveness probe failures, but the key distinction is timing: this event occurs immediately at container start, while probe failures happen after the container has been running for some time.
How to eliminate wrong answers
Option A is wrong because a failing liveness probe would cause the container to be restarted after it has started and been running for at least the initialDelaySeconds period, not immediately at startup; the event would typically be 'Liveness probe failed' rather than 'Back-off restarting failed container'. Option C is wrong because a missing image pull secret would result in an 'ImagePullBackOff' or 'ErrImagePull' event, not a back-off restart after the container has started. Option D is wrong because a pod exceeding its memory limit and being OOMKilled would show an 'OOMKilled' reason in the container status and an 'OutOfMemory' event, not a generic back-off restart due to immediate exit.
You want to perform a canary deployment. You have a Deployment 'app-v1' with 10 replicas. You create a new Deployment 'app-v2' with 1 replica. Both have the label 'app: myapp'. The Service 'myapp-svc' uses selector 'app: myapp'. How do you gradually increase traffic to v2?
This shifts traffic proportionally because both Deployments have the same label.
Why this answer
By increasing the number of replicas in the v2 Deployment, more pods will be available to receive traffic from the Service, as both versions share the same label.
A team is deploying a microservice that must be reachable within the cluster via a stable DNS name. They also need to distribute traffic among pods. Which Kubernetes resource provides both service discovery and load balancing?
Service assigns a stable IP and DNS name, and load balances across pods.
Why this answer
A Service in Kubernetes provides a stable DNS name (via cluster DNS, e.g., CoreDNS) that resolves to the Service's ClusterIP, and it load-balances traffic across the pods selected by its label selector using iptables or IPVS rules. This directly fulfills the requirement for both service discovery and load balancing within the cluster.
Exam trap
The trap here is that candidates often confuse Ingress with internal service discovery, but Ingress is designed for external traffic routing and does not provide a stable DNS name for pod-to-pod communication within the cluster.
How to eliminate wrong answers
Option B (ConfigMap) is wrong because it is used to store configuration data as key-value pairs and does not provide any network endpoint or load-balancing functionality. Option C (Secret) is wrong because it stores sensitive data like passwords or tokens and has no role in service discovery or traffic distribution. Option D (Ingress) is wrong because it operates at the HTTP/HTTPS layer to expose services externally (outside the cluster) and does not provide internal DNS-based service discovery or Layer 4 load balancing within the cluster.
Which TWO of the following are valid ways to scale a Deployment named 'my-app' to 5 replicas?
Applying updated YAML scales the deployment.
Why this answer
Option A uses kubectl scale with --replicas flag to set the count. Option C modifies the deployment YAML and applies it, which is also valid. Option B has typo 'scale' missing.
Option D sets a label selector but leaves replicas unchanged if not specified. Option E uses edit but doesn't specify the change.
You are deploying a microservice that reads from a ConfigMap and a Secret. The application logs show 'Failed to read configuration: missing key' on startup. Which TWO are likely causes?
If the ConfigMap is missing, the pod may fail to mount or the environment variable will be undefined.
Why this answer
Option B is correct because if the ConfigMap does not exist in the namespace, any pod referencing it will fail to start or the application will be unable to read the configuration data. Kubernetes validates ConfigMap existence at pod creation time, and missing ConfigMaps cause the pod to remain in a pending state or the application to log errors like 'missing key' when attempting to access the configuration.
Exam trap
CNCF often tests the misconception that RBAC permissions are required for reading Secrets mounted as volumes, when in fact any pod with a volume mount can read the Secret data directly from the filesystem without API-level authorization.
Which Helm command is used to install a chart from a repository?
Installs the chart stable/nginx as a release named myrelease.
Why this answer
Helm install with a chart reference installs a chart. Option B is correct.
Which TWO are valid reasons to use a HorizontalPodAutoscaler (HPA) with a custom metric? (Select two)
Queue length is a common custom metric for scaling.
Why this answer
HPA can scale based on custom metrics like requests per second or queue length, not just CPU/memory.
You need to perform a blue-green deployment using Deployments and Services. What is the most common approach to switch traffic from the old version (blue) to the new version (green)?
This is the standard way to switch traffic instantly in a blue-green deployment.
Why this answer
In a blue-green deployment, you have two Deployments (blue and green) and a Service that selects pods by a label. The Service's label selector initially matches the blue pods. To switch traffic to green, you update the Service's selector to match the green pods' labels.
This instantly routes traffic to the green version.
What is the purpose of the 'values.yaml' file in a Helm chart?
values.yaml is the default values file.
Why this answer
values.yaml contains default configuration values that can be overridden during installation or upgrade.
Which THREE of the following are valid ways to update a Deployment's container image in Kubernetes?
Correct. Applying a modified YAML file updates the deployment.
Why this answer
Option A is correct because `kubectl apply -f updated-deployment.yaml` applies a declarative configuration that includes the new container image. When the Deployment manifest is updated with the new image and reapplied, Kubernetes performs a rolling update to gradually replace pods with the new image, ensuring zero downtime if configured correctly.
Exam trap
The trap here is that candidates may confuse `kubectl rollout` with `kubectl set image` or invent commands like `kubectl update` or `kubectl rollout image`, which do not exist in kubectl's command set.
A company wants to deploy a stateless web application on Kubernetes. The application needs to be accessible externally via a stable IP address and should support SSL termination at the ingress level. Which resource should be used to route external traffic to the application?
Ingress provides external access, SSL termination, and routing rules.
Why this answer
Ingress is the correct resource because it provides external HTTP/HTTPS access to services within a cluster, supports SSL/TLS termination at the ingress controller level, and can expose multiple services under a single stable IP address or hostname. Unlike other service types, Ingress is specifically designed for layer 7 routing and SSL termination, making it ideal for stateless web applications that require a stable external endpoint.
Exam trap
The trap here is that candidates often confuse LoadBalancer with Ingress, thinking LoadBalancer can handle SSL termination natively, but in Kubernetes, LoadBalancer only provides a stable external IP at layer 4 (TCP/UDP) and does not terminate SSL; SSL termination is a layer 7 feature that requires an Ingress controller or a separate reverse proxy.
How to eliminate wrong answers
Option A is wrong because ClusterIP exposes the service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like a proxy or port-forward. Option B is wrong because NodePort exposes the service on a static port on each node's IP, but it does not support SSL termination natively, requires managing non-standard ports, and does not provide a stable external IP. Option D is wrong because LoadBalancer provisions an external load balancer with a stable IP, but it does not handle SSL termination at the ingress level; SSL termination would need to be configured separately on the load balancer or within the application, and it typically creates one load balancer per service, which is less efficient for multiple services.
A team is deploying a microservice that requires a ConfigMap mounted as a volume. The ConfigMap is expected to be updated frequently, and the application should read the latest values without restarting. Which volume type should be used?
Projected volume can mount ConfigMap and updates are reflected if the application monitors the file.
Why this answer
A Projected volume allows you to mount multiple existing volume sources, including ConfigMaps, Secrets, and others, into the same directory. When the ConfigMap is updated, the contents of the Projected volume are automatically updated via the kubelet's periodic sync (default every 60 seconds), enabling the application to read the latest values without restarting the pod.
Exam trap
The trap here is that candidates often confuse emptyDir with a mechanism that can automatically populate from a ConfigMap, but emptyDir only provides an empty scratch space and does not inject ConfigMap data, while Projected volume is the correct choice for combining multiple sources with live updates.
How to eliminate wrong answers
Option A is wrong because hostPath mounts a file or directory from the host node's filesystem, which does not reflect ConfigMap updates and ties the pod to a specific node, violating the requirement for dynamic updates without restart. Option B is wrong because persistentVolumeClaim is used for persistent storage (e.g., block or filesystem storage) and is not designed to mount ConfigMap data; it cannot reflect ConfigMap updates. Option C is wrong because emptyDir provides a temporary directory that is created when a pod is assigned to a node and is deleted when the pod is removed; it does not automatically populate or update with ConfigMap data, and any ConfigMap content would need to be manually written or copied, which defeats the purpose of live updates.
Which TWO are valid fields in a Deployment's rollingUpdate configuration? (Select 2)
Controls how many extra pods can be created.
Why this answer
maxSurge and maxUnavailable are the two fields in rollingUpdate.
Which THREE of the following are correct statements about Helm?
Template engine injects values from values.yaml.
Why this answer
Option A is correct: Helm charts can be shared via repositories. Option B is correct: 'helm rollback' restores a previous revision. Option C is correct: values are injected into templates.
Option D is false: Helm does not manage Kubernetes clusters; it deploys resources. Option E is false: Helm 3 uses three-way strategic merge patch, not two-way.
Which THREE of the following are valid ways to expose a set of pods as a network service?
Exposes externally via cloud load balancer.
Why this answer
A LoadBalancer Service is a valid way to expose a set of pods as a network service because it provisions an external load balancer (e.g., from a cloud provider) that distributes traffic to the pods via a NodePort and ClusterIP underneath. This allows external clients to access the service using a single IP address or hostname, making it suitable for production-grade external exposure.
Exam trap
The trap here is that candidates often confuse Ingress as a Service type or think ExternalName can expose pods, when in fact Ingress is a separate resource and ExternalName only maps to an external DNS name without any pod connectivity.
Which TWO of the following are correct about the difference between 'kubectl apply' and 'kubectl create'?
Apply updates; create fails on existing resources.
Why this answer
Option A is correct: apply uses declarative management; create is imperative. Option B is correct: apply can create and update resources; create only creates. Option C is false: create can also create resources from files.
Option D is false: both can create resources. Option E is false: apply does not delete resources by default.
Which command shows the rollout history of a Deployment named 'web'?
Correct. This command displays the revision history.
Why this answer
Option D is correct because `kubectl rollout history deployment web` is the dedicated command to display the revision history of a Deployment, including revision numbers and change-cause annotations. This command directly queries the Deployment's rollout state from the Kubernetes API server, showing each revision's metadata.
Exam trap
The trap here is that candidates confuse `rollout status` (which shows current progress) with `rollout history` (which shows past revisions), or assume `describe` or `get -o yaml` would include historical data when they only show the current state.
How to eliminate wrong answers
Option A is wrong because `kubectl rollout status deployment web` shows the current rollout progress (e.g., waiting for pods to become ready), not the historical list of revisions. Option B is wrong because `kubectl get deployment web -o yaml` outputs the full YAML manifest of the current Deployment spec, not the rollout history. Option C is wrong because `kubectl describe deployment web` provides a summary of the current Deployment state, including events and conditions, but does not list past revisions or rollout history.
During a rolling update, you want to ensure that a maximum of 2 extra pods are created above the desired replicas. Which field should you set in the Deployment spec?
maxSurge defines the maximum number of pods that can be created above the desired replicas during a rolling update.
Why this answer
The 'maxSurge' field controls how many extra pods can be created during a rolling update. Setting it to 2 allows up to 2 extra pods. Option D is correct.
Which kubectl command shows the rollout history of a Deployment named 'app'?
This is the correct syntax to view rollout history.
Why this answer
kubectl rollout history deployment/app shows the revision history of the Deployment.
Which THREE of the following are valid reasons to use a HorizontalPodAutoscaler (HPA) with a Deployment?
Can be implemented with custom metrics (e.g., Prometheus).
Why this answer
Option A is correct: HPA can scale based on CPU/memory metrics. Option B is correct: custom metrics can be used. Option C is correct: HPA can scale based on incoming request rate via custom metrics.
Option D is false: HPA does not enforce resource requests; it scales based on metrics. Option E is false: HPA does not use 'targetCPUUtilizationPercentage' for scaling; that's an older field replaced by metrics.
Which TWO statements about kubectl apply vs kubectl create are correct? (Select two)
apply is for create/update; create only creates and fails if exists.
Why this answer
kubectl apply manages resources declaratively using last-applied-configuration. kubectl create is imperative and will error if resource exists.
When performing a rolling update of a Deployment with 'maxSurge: 1' and 'maxUnavailable: 0', how many additional pods can be created above the desired replicas during the update?
maxSurge=1 allows one additional pod above the desired replicas.
Why this answer
maxSurge defines the maximum number of pods that can be created above the desired replicas. With maxSurge=1, exactly one extra pod can exist during the update.
You want to use Kustomize to apply a patch to a Deployment in the 'overlays/production' directory. Which command should you run from the kustomization directory?
Correct command to apply a kustomization.
Why this answer
kubectl apply -k applies the kustomization directory. Option C is correct.
You have a Helm chart for an application. You want to upgrade the release but only if the upgrade does not introduce breaking changes. Which command should you use?
--dry-run simulates the upgrade and shows the rendered templates without applying them.
Why this answer
Helm does not have a dry-run for upgrades that guarantees no breaking changes, but 'helm upgrade --dry-run' simulates the upgrade and shows changes without applying them.
You have a HorizontalPodAutoscaler (HPA) that targets CPU utilization at 50%. The current average CPU utilization is 80%. The HPA has a stabilization window of 300 seconds and a scale-down policy with a periodSeconds of 60. CPU utilization drops to 40%. How long will it take for the HPA to begin scaling down?
The HPA waits the stabilization window before scaling down.
Why this answer
The stabilization window is the time the HPA waits before considering a scale-down decision. It will wait 300 seconds after the utilization drops below the target.
During a rolling update of a Deployment, you notice that new pods are failing readiness probes. The rollout is stalled. Which command would you use to abort the rollout and revert to the previous revision?
Correct command to rollback.
Why this answer
'kubectl rollout undo deployment <name>' reverts the rollout to the previous revision. Option A is correct.
You have an HPA that scales a Deployment based on CPU utilization. You want to prevent the Deployment from scaling down for at least 5 minutes. Which HPA behavior field should you configure?
This sets a stabilization window for scale-down events, preventing rapid scale-down.
Why this answer
To prevent scaling down, you can set a stabilization window on the scaleDown policy. Option B correctly sets a stabilizationWindowSeconds in the scaleDown behavior.
What is the purpose of the 'maxUnavailable' field in a Deployment's rolling update configuration?
Correct. It ensures a certain number of Pods remain available.
Why this answer
The 'maxUnavailable' field in a Deployment's rolling update configuration specifies the maximum number of Pods that can be unavailable during the update process, relative to the desired replica count. This ensures that a controlled number of Pods are taken down at a time, maintaining application availability while the update progresses. It is defined as either an absolute number or a percentage of the desired replicas, and it works in conjunction with 'maxSurge' to control the update pace.
Exam trap
The trap here is that candidates often confuse 'maxUnavailable' with 'maxSurge' or assume it controls the termination rate, but the CKAD exam tests the precise definition that it limits the number of Pods that can be in an unavailable state during the update, not the number created above desired or the termination speed.
How to eliminate wrong answers
Option A is wrong because it describes the 'maxSurge' field, which controls the maximum number of Pods that can be created above the desired replicas, not 'maxUnavailable'. Option C is wrong because there is no 'maxUnavailable' field for time limits; Kubernetes uses 'progressDeadlineSeconds' for update timeout, not 'maxUnavailable'. Option D is wrong because while 'maxUnavailable' indirectly limits simultaneous terminations, it specifically caps the number of unavailable Pods (including those being terminated), not the number of Pods terminated simultaneously—Kubernetes handles termination in a rolling fashion based on availability constraints.
You have a Deployment 'web-app' with 4 replicas. You want to perform a rolling update such that during the update, at most 2 pods can be unavailable and at most 5 pods can be above the desired replica count. Which TWO of the following strategy configurations achieve this?
Absolute numbers: maxSurge=5 allows up to 5 extra pods (total 9), maxUnavailable=2 allows up to 2 unavailable pods – meets requirements.
Why this answer
maxUnavailable sets the maximum number of pods that can be unavailable during the update. maxSurge sets the maximum number of extra pods above the desired count. With 4 replicas, 2 maxUnavailable means at most 2 pods can be down, and 5 maxSurge means at most 5 extra pods, but due to absolute numbers, the total pods can go up to 9 (4+5). Option B uses absolute numbers: maxSurge=1 and maxUnavailable=2 – but maxSurge=1 allows only 1 extra pod (total 5), which is less than 5.
Option D uses percentages: maxSurge=125% (of 4 = 5) and maxUnavailable=50% (of 4 = 2). Option C has maxUnavailable=0 which contradicts the requirement. Option E has maxUnavailable=3 which exceeds 2.
Which kubectl command sets the number of replicas for a deployment named 'nginx' to 5?
Correct. The --replicas flag sets the number of replicas.
Why this answer
kubectl scale is the correct command to change the replica count of a deployment.
Which THREE of the following are true about using 'kubectl rollout undo'? (Select three)
Correct; without flags, it reverts to the previous revision.
Why this answer
Options A, C, and E are correct. 'kubectl rollout undo' can rollback to a previous revision (A), can specify a revision (C), and is available for DaemonSets (E). Option B is false because it doesn't delete the Deployment. Option D is false because 'undo' is used for rollback, not pause.
Which command is used to scale a Deployment named 'frontend' to 10 replicas?
This is the correct syntax.
Why this answer
kubectl scale can change the replica count of a Deployment.
You need to scale a Deployment named 'frontend' to 10 replicas. Which command correctly accomplishes this?
This is the correct syntax.
Why this answer
kubectl scale deployment frontend --replicas=10 is the correct command.
A Deployment named 'web' has replicas: 3 and update strategy type: Recreate. You run 'kubectl set image deployment/web web=nginx:1.22'. What immediate effect will this have on the existing pods?
Recreate terminates all pods first, then creates new ones.
Why this answer
The Recreate strategy terminates all existing pods before creating new ones. All 3 pods will be terminated simultaneously, then new pods are created.
A pod is running but not responding to requests. The developer suspects the liveness probe is misconfigured. Which command can they use to check the probe configuration of a running pod?
Describe shows full configuration including probes.
Why this answer
Option B is correct because `kubectl describe pod <pod-name>` displays the full pod specification, including the liveness probe configuration (e.g., `Liveness: http-get /healthz delay=0s timeout=1s period=10s #success=1 #failure=3`). This allows the developer to verify the probe type, endpoint, initial delay, timeout, and failure threshold directly from the running pod's definition.
Exam trap
The trap here is that candidates confuse `kubectl logs` (which shows runtime output) with `kubectl describe` (which shows configuration), assuming logs would reveal probe failures, but logs only show application output, not the probe definition itself.
How to eliminate wrong answers
Option A is wrong because `kubectl logs` shows the container's stdout/stderr output, not the pod's configuration or probe settings; it cannot reveal how the probe is defined. Option C is wrong because `kubectl exec -- env` prints environment variables inside the container, which are unrelated to the liveness probe configuration stored in the pod spec. Option D is wrong because `kubectl get pod` only shows a summary (name, status, restarts, age) and does not include detailed probe parameters like path, port, or thresholds.
You are using Helm to manage a chart. Which commands are valid to list installed releases? (Choose TWO)
Alias for helm list.
Why this answer
Option A is correct: 'helm list'. Option C is also correct: 'helm ls' (alias). Option B is for status.
Option D is for history. Option E is for upgrade.
A company wants to deploy a stateful database cluster where each pod has its own persistent storage. They need stable network identities and ordered pod creation. Which resource should they use?
StatefulSet is designed for stateful apps with stable identities and persistent storage.
Why this answer
StatefulSet is the correct resource because it provides stable, unique network identities (via headless Services and ordinal hostnames) and ordered, graceful deployment and scaling (pod creation/deletion in sequence). This matches the requirements for a stateful database cluster where each pod requires its own PersistentVolumeClaim (PVC) and stable identity for clustering.
Exam trap
CNCF often tests the misconception that Deployment can handle stateful workloads by using PersistentVolumeClaims, but they fail to recognize that Deployment lacks stable network identities and ordered pod management, which are critical for database clustering.
How to eliminate wrong answers
Option A is wrong because Deployment does not guarantee stable network identities or ordered pod creation; pods are treated as ephemeral and interchangeable, which is unsuitable for stateful applications requiring persistent storage per pod. Option C is wrong because CronJob is designed for scheduled, batch jobs (running to completion) and does not manage long-running stateful pods with persistent storage or stable identities. Option D is wrong because DaemonSet ensures one pod per node, not ordered creation or per-pod persistent storage; it is intended for node-level services like logging or monitoring, not stateful databases.
You are using Kustomize to manage Kubernetes configurations. You have a base configuration for 'nginx' and an overlay for 'production' that sets the replica count to 5. Which file structure is correct for Kustomize?
Correct: overlay/production/kustomization.yaml references ../base.
Why this answer
Kustomize expects a kustomization.yaml file in each layer. The base has its own kustomization.yaml that includes resources, and the overlay has a kustomization.yaml with a bases field pointing to the base path.
A developer needs to deploy a container that runs a batch job to process data once and then exit. The job should be restarted only if it fails. Which Kubernetes resource should be used?
Job runs a task to completion and restarts on failure.
Why this answer
A Kubernetes Job is the correct resource for a batch workload that runs to completion and exits. It ensures the pod is restarted only on failure (via the `RestartPolicy: OnFailure` or `Never`), which matches the requirement of restarting only if the job fails. Deployments and DaemonSets are designed for long-running processes, not termination.
Exam trap
The trap here is that candidates often confuse a Job with a Deployment because both can run containers, but a Deployment is designed for long-running services and will restart pods even on successful completion, which violates the 'run once' requirement.
How to eliminate wrong answers
Option A is wrong because a DaemonSet ensures one pod runs on every node and is intended for continuous daemon processes (e.g., log collectors), not for batch jobs that exit. Option B is wrong because a Deployment manages a set of pods that should run indefinitely, maintaining a desired replica count; it will restart pods regardless of exit reason, which does not match the 'restart only on failure' requirement. Option D is wrong because a StatefulSet is for stateful applications requiring stable network identities and persistent storage, not for ephemeral batch processing.
A Deployment has replicas: 3 and uses a ConfigMap. The ConfigMap is updated. The developer wants to update the pods to use the new ConfigMap without recreating the Deployment. What is the correct approach?
Restarts pods, which will mount the updated ConfigMap.
Why this answer
A `kubectl rollout restart deployment/<name>` triggers a rolling restart of the Pods managed by the Deployment. Since ConfigMaps are mounted as volumes or injected as environment variables at Pod creation time, the only way to pick up updated ConfigMap data without recreating the Deployment object itself is to force the existing Pods to be terminated and recreated. The Deployment controller handles this gracefully, ensuring zero downtime by following the configured rolling update strategy.
Exam trap
The trap here is that candidates assume ConfigMaps are dynamically updated in running Pods (Option C), but in reality, Pods must be recreated to consume updated ConfigMap data unless the application explicitly watches for file changes.
How to eliminate wrong answers
Option B is wrong because `kubectl set image` updates the container image, not the ConfigMap; it does not cause Pods to reload ConfigMap data. Option C is wrong because ConfigMaps are not automatically updated inside running Pods — they are snapshotted at Pod start; even if the volume is mounted as a subPath or as environment variables, the Pod must be restarted to reflect changes. Option D is wrong because manually deleting and recreating Pods is error-prone, does not leverage the Deployment’s rollout history or update strategy, and violates the principle of declarative management; the correct imperative command is `kubectl rollout restart`.
You have a Deployment named 'web-app' with 5 replicas. You run the command: kubectl set image deployment/web-app web-app=nginx:1.25. Which command can you use to monitor the progress of the rollout?
This command watches the rollout status until it completes.
Why this answer
The kubectl rollout status command tracks the progress of a deployment rollout.
Which TWO statements are true about Helm releases? (Select two)
Release secrets are stored in the namespace where the chart is installed.
Why this answer
Helm releases are tracked in the cluster, and each install creates a new release.
Which TWO commands can be used to update the image of a Deployment? (Select two)
Directly sets the image.
Why this answer
kubectl set image and kubectl edit are valid ways to update a Deployment's image. Option A and D are correct.
You have a Deployment that is currently paused. You want to resume the rollout and then check the status of the rollout. Which set of commands should you run?
Resume then check status.
Why this answer
First, resume the rollout with 'kubectl rollout resume deployment/<name>', then check status with 'kubectl rollout status deployment/<name>'. Option B is correct.
What is the difference between 'kubectl apply' and 'kubectl create'?
Correct, 'apply' is declarative and handles both create and update; 'create' only creates.
Why this answer
'kubectl apply' is declarative: it creates or updates a resource to match the provided configuration. 'kubectl create' is imperative: it creates a new resource and will fail if the resource already exists.
You have a Deployment 'db' that uses a ConfigMap for configuration. You want to update the ConfigMap and roll out the changes to pods without restarting them manually. Which approach should you use?
Pods will be recreated with the new ConfigMap.
Why this answer
Mounting ConfigMaps as volumes with subPath does not automatically update pods; however, using environment variables from ConfigMaps also does not update pods. The recommended approach is to use a Deployment update with a change that triggers a rollout (e.g., updating an annotation). Option B is correct.
Which TWO of the following are valid methods to achieve a blue-green deployment in Kubernetes? (Select two.)
This is the classic blue-green deployment pattern.
Why this answer
Options A and C are correct. A: Create two separate Deployments and switch a Service's selector. C: Use Kubernetes Services with label selectors to route traffic to one set of pods, then update the selector.
Option B is not standard; Option D describes a canary deployment; Option E describes a rolling update.
Which command lists all Helm releases in the current namespace?
This is the correct command.
Why this answer
helm list lists all releases in the current namespace (default namespace if not set).
During a canary deployment, you want to send 10% of traffic to the new version. You have two Deployments: 'app-stable' (version: stable) and 'app-canary' (version: canary). You use a Service with label selector 'app: myapp' and a second selector for version. How can you achieve the 10% traffic split?
Ingress controllers (e.g., NGINX Ingress) support canary annotations for traffic splitting.
Why this answer
Kubernetes Services do not support weighted load balancing natively. The common approach is to use an Ingress controller or service mesh. Option D is correct.
A Helm chart is installed with the command 'helm install myapp ./mychart'. You need to upgrade the release with new values from a file 'prod-values.yaml'. Which command is correct?
This is the correct syntax for upgrading with values file.
Why this answer
The correct command is 'helm upgrade myapp ./mychart -f prod-values.yaml'. The release name is 'myapp', chart path './mychart', and values file is specified with -f.
Which TWO of the following are valid methods to update a Deployment's image?
Editing the deployment allows you to change the image.
Why this answer
Both 'kubectl set image deployment/myapp mycontainer=nginx:1.21' and 'kubectl edit deployment/myapp' can be used to update the image. 'kubectl apply -f deployment.yaml' can also be used if the YAML has the new image. 'kubectl patch' can also be used. So there are multiple methods. The question asks for TWO valid methods.
The options include 'kubectl set image', 'kubectl edit', 'kubectl create -f' (which would fail if the resource exists), 'kubectl replace -f' (which can replace but requires the full manifest), and 'kubectl rollout image' (invalid).
You have created a HorizontalPodAutoscaler (HPA) named 'web-hpa' targeting a Deployment 'web'. The HPA uses targetCPUUtilizationPercentage: 80. The current CPU usage is 60%. How many replicas will the HPA set?
CPU usage is below target, so the HPA does not scale up.
Why this answer
The HPA scales based on the ratio: desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)]. With current replicas at 1, desired = ceil[1 * (60/80)] = ceil[0.75] = 1. So it remains at 1.
Option A is correct.
Which command is used to undo the most recent rollout of a Deployment named 'myapp'?
This command reverts the Deployment to the previous revision.
Why this answer
Option A is correct: 'kubectl rollout undo deployment myapp' rolls back to the previous revision. Option B rolls back to a specific revision. Option C shows the status, not undo.
Option D is not a valid command.
After upgrading a Helm release, you want to revert to the previous revision. Which command achieves this?
Correct. You need to specify the revision number to rollback to.
Why this answer
helm rollback release-name revision-number reverts to a specific revision. To revert to the previous one, you use the revision number of the previous version.
You are using Kustomize. Your kustomization.yaml file specifies a base and an overlay. You run: kubectl apply -k overlays/production. What happens?
Kustomize combines them and kubectl apply creates/updates the resources.
Why this answer
Option C is correct because when you run `kubectl apply -k overlays/production`, Kustomize reads the `kustomization.yaml` in the specified directory, which references a base and an overlay. It then performs a strategic merge patch of the overlay's customizations (e.g., patches, namePrefix, commonLabels) onto the base resources, producing a single set of manifests that are applied to the cluster. This is the core purpose of Kustomize: to compose and customize resources without templating.
Exam trap
The trap here is that candidates might think `-k` applies only the contents of the specified directory (like `-f` does), but Kustomize always resolves the full overlay chain, including the base, so the result is a merged output, not just the overlay's files.
How to eliminate wrong answers
Option A is wrong because `-k` does not require a directory with a file named exactly `kustomization.yaml`; it expects a directory containing a `kustomization.yaml` (or `kustomization.yml` or `Kustomization`) file, and `overlays/production` is a valid directory that contains such a file. Option B is wrong because Kustomize always merges the overlay onto the base; it does not apply only the base resources when an overlay is specified. Option D is wrong because Kustomize does not apply only the overlay resources; it merges the overlay's modifications onto the base, and the base resources are always included in the final output.
A developer is deploying a web application that requires 2 GiB of memory and 0.5 CPU cores. The cluster nodes have 4 GiB of memory and 2 CPU cores each. The developer wants to ensure the pod gets guaranteed QoS class. Which resource specification should be used?
Equal requests and limits give Guaranteed QoS.
Why this answer
Option B is correct because for a pod to receive the Guaranteed QoS class, every container in the pod must have both resource requests and limits set, and the requests must equal the limits for each resource (memory and CPU). This configuration ensures the pod is not overcommitted and gets the highest priority under resource pressure.
Exam trap
The trap here is that candidates often think setting only requests (Option A) or setting limits higher than requests (Option C) still gives Guaranteed QoS, but Kubernetes strictly requires requests == limits for all resources to achieve Guaranteed class.
How to eliminate wrong answers
Option A is wrong because it sets only requests without limits, which places the pod in the Burstable QoS class (since limits are not set, the pod can burst above requests). Option C is wrong because the limits exceed the requests (memory 4Gi > 2Gi, CPU 1 > 500m), which also results in Burstable QoS, not Guaranteed. Option D is wrong because the requests are lower than the limits (memory 1Gi < 2Gi, CPU 250m < 500m), again yielding Burstable QoS; additionally, the requests do not match the developer's requirement of 2Gi memory and 500m CPU.
You have just applied a new Deployment configuration using 'kubectl apply -f deployment.yaml'. You want to see the latest revision number of the rollout. Which command should you run?
Shows list of revisions with their numbers.
Why this answer
'kubectl rollout history deployment/<name>' shows revision history with revision numbers. The latest revision is shown as the most recent.
Ready to test yourself?
Try a timed practice session using only Application Deployment questions.