CKAD Application Deployment Practice Test 6 — 15 Questions

Question 1

Which command scales a Deployment named 'web' to 5 replicas?

Accepted Answer

kubectl scale deployment web --replicas=5. The correct command to scale a Deployment to a specific number of replicas is `kubectl scale deployment web --replicas=5`. This command directly modifies the `spec.replicas` field of the Deployment object, instructing the Kubernetes controller manager to adjust the number of running Pods to match the desired count.

Answer

kubectl set replicas deployment web 5

Answer

kubectl resize deployment web --replicas=5

Answer

kubectl autoscale deployment web --replicas=5

Question 2

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?

Accepted Answer

behavior.scaleDown.stabilizationWindowSeconds. To prevent scaling down, you can set a stabilization window on the scaleDown policy. Option B correctly sets a stabilizationWindowSeconds in the scaleDown behavior.

Answer

behavior.scaleUp.policies[0].periodSeconds

Answer

behavior.scaleUp.stabilizationWindowSeconds

Answer

behavior.scaleDown.policies[0].periodSeconds

Question 3

Which TWO of the following are valid methods to perform a blue-green deployment in Kubernetes?

Accepted Answer

Create a new Deployment for the new version, then update the Service's selector to point to the new pods.. A blue-green deployment requires two separate environments (blue = current, green = new) and a mechanism to switch traffic between them. Option B is valid because it uses a new Deployment for the green version and updates the Service selector to point to the new pods, effectively switching traffic. Option C is also valid: it deploys the new version in a separate namespace and uses a Service to route traffic to the new namespace, achieving the same isolation and switch. Option A is incorrect because it modifies the existing Deployment's image and uses Recreate strategy, which is a single-version update with downtime, not a blue-green switch. Option D is incorrect because `kubectl rollout undo` reverts to a previous revision of the same Deployment, not a parallel green environment. Option E uses the RollingUpdate strategy with extreme surge, which is a rolling update, not a blue-green deployment.

Answer

Use kubectl patch to modify the Deployment's image and rely on the Recreate strategy.

Answer

Use kubectl rollout undo to revert to the previous version.

Answer

Use the RollingUpdate strategy with maxSurge=100% and maxUnavailable=0%.

Question 4

Which THREE of the following are valid fields in a Helm chart's values.yaml file that can be used in templates?

Accepted Answer

replicaCount: 3. `replicaCount: 3` is a standard top-level key in a Helm chart's `values.yaml` file. This file contains plain YAML key-value pairs that are injected into templates via the `.Values` object (e.g., `{{ .Values.replicaCount }}`). It is not a template directive itself, but a data source for templates.

Answer

Answer

Question 5

Which TWO of the following commands are used to inspect the rollout history of a Deployment?

Accepted Answer

kubectl rollout history deployment/my-deployment. The correct commands to inspect rollout history are 'kubectl rollout history deployment/' (option B) and 'kubectl get replicasets -l app=' (option C). 'kubectl rollout history' directly shows the revision history of a deployment, while 'kubectl get replicasets' indirectly shows the ReplicaSets created for each revision, which correspond to the rollout history. 'kubectl rollout status' (option A) shows current rollout progress, not history. 'kubectl get events' (option D) shows events, not history. 'kubectl describe deployment' (option E) shows some details but not the complete history of revisions.

Answer

kubectl rollout status deployment/my-deployment

Answer

kubectl get events --field-selector involvedObject.name=my-deployment

Answer

kubectl describe deployment my-deployment

Question 6

You want to update a Deployment's image to a new version, ensuring that at most 2 pods are unavailable during the rollout. Which field in the Deployment spec should you set?

Accepted Answer

spec.strategy.rollingUpdate.maxUnavailable. The `maxUnavailable` field in the `spec.strategy.rollingUpdate` section controls the maximum number of Pods that can be unavailable during a rolling update. Setting `maxUnavailable: 2` ensures that at most 2 Pods are taken down at any time, maintaining the required availability threshold. This field is part of the Deployment's update strategy and directly governs the disruption budget during the rollout.

Answer

spec.replicas

Answer

spec.strategy.rollingUpdate.maxSurge

Answer

spec.minReadySeconds

Question 7

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?

Accepted Answer

helm upgrade myapp ./mychart --values prod-values.yaml. `helm upgrade myapp ./mychart --values prod-values.yaml` explicitly specifies the release name (`myapp`), the chart path (`./mychart`), and the values file (`--values prod-values.yaml`). This is the standard syntax for upgrading a Helm release with custom values, where `--values` (or `-f`) merges the provided YAML file over the default chart values.

Answer

helm upgrade ./mychart prod-values.yaml --release myapp

Answer

helm upgrade --install myapp ./mychart -f prod-values.yaml

Answer

helm upgrade myapp -f prod-values.yaml

Question 8

Which kubectl command can be used to see the rollout status of a Deployment named 'web-app'?

Accepted Answer

kubectl rollout status deployment web-app. `kubectl rollout status deployment web-app` is the dedicated command to monitor the rollout progress of a Deployment, showing whether the new ReplicaSet has been fully rolled out or if the rollout is still in progress. It provides real-time updates on the status of the rollout, such as waiting for pods to become ready or successfully completing the update.

Answer

kubectl rollout history deployment web-app

Answer

kubectl describe deployment web-app

Answer

kubectl status deployment web-app

Question 9

You have a Deployment with 'replicas: 3' and the HPA is configured with 'targetCPUUtilizationPercentage: 80'. The current CPU usage is at 60% across all pods, but the HPA has scaled up to 5 replicas. What is the most likely reason?

Accepted Answer

The CPU request in the Deployment's resource spec might be set lower than expected, causing the HPA to perceive higher utilization.. The HPA calculates CPU utilization as the average CPU usage across all pods divided by the CPU request of each pod. If the Deployment's container resource requests are set to a value that is lower than expected (e.g., 0.5 CPU instead of 1.0 CPU), then the same absolute CPU usage results in a higher utilization percentage. With 3 pods at 60% actual usage but a low CPU request, the utilization relative to the request could exceed the 80% target, triggering scale-up to 5 replicas. Therefore, option A is the most likely reason: a mismatch in the CPU request on the Deployment's resource spec causes the HPA to perceive higher utilization.

Answer

The HPA has a behavior policy that scales up aggressively

Answer

The HPA is using the 'averageUtilization' target type on a custom metric, not CPU

Answer

The HPA is reading the total CPU usage instead of average

Question 10

You are asked to implement a blue-green deployment using Kubernetes Deployments and Services. You have a blue Deployment with label 'version: blue' and a green Deployment with label 'version: green'. Both have selector 'app: myapp'. You need a Service that initially points to blue. How should you configure the Service to switch to green without downtime?

Accepted Answer

Update the Service's label selector to 'app: myapp, version: green'. Updating the Service's label selector to 'app: myapp, version: green' causes the Service to immediately route traffic to green pods without any downtime. The Service uses the selector to dynamically discover pods with matching labels, so changing the selector seamlessly shifts traffic to the green Deployment while the blue Deployment remains untouched.

Answer

Change the blue Deployment's pod label to 'version: green' and delete green Deployment

Answer

Delete the Service and recreate it with the new selector

Answer

Update the Service's cluster IP to point to green pods

Question 11

Which of the following is the correct way to scale a Deployment named 'api' to 5 replicas using kubectl?

Accepted Answer

kubectl scale deployment api --replicas=5. `kubectl scale deployment api --replicas=5` is the standard kubectl command to change the replica count of a Deployment. The `scale` subcommand directly modifies the `.spec.replicas` field in the Deployment's manifest, instructing the ReplicaSet controller to adjust the number of Pods to match the desired count.

Answer

kubectl scale deploy api 5

Answer

kubectl update deployment api --replicas=5

Answer

kubectl set replicas deployment api 5

Question 12

You have a Kustomize overlay that sets 'replicas: 5' in a patch, but the base Deployment has 'replicas: 3'. What is the final number of replicas after applying 'kubectl apply -k overlay/'?

Accepted Answer

5. In Kustomize, overlays are applied on top of the base, and patches override the base values. Since the overlay explicitly sets 'replicas: 5' via a patch, it replaces the base value of 3. The final Deployment will have 5 replicas, making D correct.

Answer

3

Answer

8

Answer

It depends on the strategy

Question 13

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?

Accepted Answer

kubectl rollout undo deployment . 'kubectl rollout undo deployment ' reverts the rollout to the previous revision. Option A is correct.

Answer

kubectl rollout pause deployment <name>

Answer

kubectl rollout resume deployment <name>

Answer

kubectl delete deployment <name> --cascade=false

Question 14

You have a Deployment with the following strategy: type: Recreate. What happens when you update the pod template?

Accepted Answer

Old pods are terminated first, then new pods are created. The Recreate strategy in a Kubernetes Deployment first terminates all existing Pods before creating new ones. When the pod template is updated, the Deployment controller scales down the ReplicaSet to 0 replicas, waits for all Pods to terminate, then scales up the new ReplicaSet to the desired number of replicas. This ensures zero overlap between old and new Pods, which is useful for workloads that cannot run concurrently.

Answer

New pods are created first, then old pods are terminated

Answer

Pods are updated in-place without termination

Answer

The update is rejected because Recreate is not a valid strategy

Question 15

You run 'kubectl apply -f deployment.yaml' and later 'kubectl replace -f deployment.yaml' on the same file. What is the difference?

Accepted Answer

apply merges changes, replace replaces the entire resource. kubectl apply creates or updates resources using declarative configuration, preserving changes made by others. kubectl replace replaces the existing resource with the provided spec, which can overwrite fields not managed by the user. Option A correctly describes the difference: apply merges changes, while replace replaces the entire resource.

Answer

apply is used for Deployments only, replace for any resource

Answer

apply requires --record flag, replace does not

Answer

apply creates, replace updates