CKAD Application Deployment Practice Test 7 — 15 Questions

Question 1

During a rolling update, you want to ensure that at most 2 pods are unavailable at any time. Which field should you set in the Deployment spec?

Accepted Answer

spec.strategy.rollingUpdate.maxUnavailable: 2. `spec.strategy.rollingUpdate.maxUnavailable` specifies the maximum number of Pods that can be unavailable during a rolling update. Setting `maxUnavailable: 2` ensures that at most 2 Pods are unavailable at any time, allowing the update to proceed while maintaining the desired availability.

Answer

spec.strategy.type: Recreate

Answer

spec.replicas: 2

Answer

spec.strategy.rollingUpdate.maxSurge: 2

Question 2

You have a Deployment named 'web-app' with 5 replicas. You run 'kubectl set image deployment/web-app app=nginx:1.21'. What is the effect of this command?

Accepted Answer

It updates the image of the container named 'app' to nginx:1.21, triggering a rolling update.. The `kubectl set image` command updates the container image in the Deployment's pod template. This triggers a rolling update, where the Deployment's ReplicaSet creates new pods with the new image and gradually terminates old pods, ensuring zero downtime. The container name 'app' matches the container in the pod spec, so the image is updated to nginx:1.21.

Answer

It scales the Deployment to 0 replicas and then scales back up.

Answer

It immediately terminates all running pods and creates new ones with the new image.

Answer

It creates a new Deployment with the updated image.

Question 3

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?

Accepted Answer

Add the label 'version: canary' to the canary Deployment's pod template and update the Service's selector to 'app: web, version in (stable, canary)'.. The Service 'web-svc' currently selects pods with 'app: web' and 'version: stable'. To route traffic to the canary pods (version 2), you need to add the label 'version: canary' to the canary Deployment's pod template so that those pods are created with that label. Then, updating the Service's selector to 'app: web, version in (stable, canary)' allows the Service to match both stable and canary pods, distributing traffic between them according to the Service's default round-robin behavior.

Answer

Use kubectl rollout canary on the stable Deployment.

Answer

Create a new Service with selector 'app: web, version: canary' and use an ingress to split traffic.

Answer

Change the Service selector to 'app: web' only (remove version label).

Question 4

Which kubectl command shows the rollout history of a Deployment named 'app'?

Accepted Answer

kubectl rollout history deployment app. `kubectl rollout history deployment app` is the specific command designed to display the revision history of a Deployment, including revision numbers and, if configured, the change-cause annotation. This command retrieves the stored rollout history from the Deployment's annotation `deployment.kubernetes.io/revision` and lists all previous ReplicaSets that were created during rollouts.

Answer

kubectl rollout status deployment app

Answer

kubectl describe deployment app

Answer

kubectl get events --field-selector involvedObject.kind=Deployment

Question 5

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?

Accepted Answer

helm upgrade --dry-run my-release ./mychart. `helm upgrade --dry-run` simulates the upgrade process and validates the chart against the cluster without actually applying changes. The `--dry-run` flag allows you to detect breaking changes (e.g., missing required values, API deprecations, or incompatible resource definitions) before committing to the upgrade, ensuring the release remains stable.

Answer

helm install --dry-run my-release ./mychart

Answer

helm rollback my-release 0

Answer

helm diff upgrade my-release ./mychart

Question 6

A Deployment has a rolling update strategy with maxSurge: 1 and maxUnavailable: 0. The Deployment has 4 replicas. During a rollout, what is the maximum number of pods that can exist at any point?

Accepted Answer

5. With maxSurge: 1 and maxUnavailable: 0, the Deployment controller ensures that during a rolling update, at most one additional pod (beyond the desired 4 replicas) is created before terminating old pods. Since no pods can be unavailable, the maximum number of pods at any point is 4 (desired) + 1 (surge) = 5.

Answer

6

Answer

8

Answer

4

Question 7

Which of the following is a valid method to perform a blue-green deployment in Kubernetes?

Accepted Answer

Create two Deployments and a Service, then change the Service's selector to point to the new version.. A blue-green deployment in Kubernetes is achieved by running two separate Deployments (blue and green) and using a Service to route traffic to the active version. By updating the Service's selector to match the labels of the new Deployment (green), traffic is instantly switched without downtime. This method does not rely on any built-in Deployment strategy, as Kubernetes does not have a native 'BlueGreen' strategy type.

Answer

Use kubectl rollout undo to switch between revisions.

Answer

Set spec.strategy.type: BlueGreen in the Deployment.

Answer

Use a DaemonSet to run both versions.

Question 8

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?

Accepted Answer

3. With 4 replicas and a rolling update strategy of maxSurge: 25% and maxUnavailable: 25%, the maximum number of pods that can be unavailable during the update is 25% of 4, which is 1. Therefore, the minimum number of pods guaranteed to be available is 4 - 1 = 3. This is calculated by rounding down the maxUnavailable value (1) and ensuring the desired replica count minus unavailable pods equals the minimum available.

Answer

2

Answer

4

Answer

1

Question 9

What is the purpose of the 'values.yaml' file in a Helm chart?

Accepted Answer

It contains default configuration values for the chart.. The `values.yaml` file in a Helm chart provides default configuration values that can be overridden at install or upgrade time using the `--values` or `--set` flags. These values are injected into the chart's templates via Go template syntax, enabling parameterized deployments without modifying the chart itself.

Answer

It stores the release history.

Answer

It defines the Kubernetes resources to be created.

Answer

It lists dependencies of the chart.

Question 10

Which commands list all Helm releases in the current namespace? (Select all that apply)

Accepted Answer

helm list. Both `helm list` and its alias `helm ls` are valid commands to list all Helm releases in the current namespace. `helm get all` retrieves all information about a specific release, and `helm status` shows the status of a single release.

Answer

helm get all

Answer

helm status

Question 11

You want to undo a rollout to the previous revision. Which command should you use?

Accepted Answer

kubectl rollout undo deployment/myapp. `kubectl rollout undo deployment/myapp` reverts the deployment to the previous revision by default, using the rollout history stored in the deployment's ReplicaSet annotations. This command directly triggers a new rollout that matches the pod template of the prior revision, effectively undoing the last change.

Answer

kubectl delete deployment/myapp --cascade=orphan

Answer

kubectl set image deployment/myapp app=myapp:previous

Answer

kubectl rollout history deployment/myapp --revision=2

Question 12

Which TWO of the following are true about Kustomize overlays? (Select 2)

Accepted Answer

Overlays are used to customize resources for different environments.. Option B is correct because Kustomize overlays exist precisely to adapt a shared base for distinct environments such as dev, staging, and prod, applying environment-specific settings without duplicating the base manifests. Option D is correct because overlays use patches (strategic merge patches, JSON 6902 patches, or JSON merge patches) to modify resources declared in the base, and they can also add new resources. Option A is wrong because overlays can both add and modify labels, for example via the labels and commonLabels fields, so they are not limited to additions. Option C is wrong because overlays are typically placed in separate directories that reference the base via a relative path in kustomization.yaml, not in the same directory. Option E is wrong because Kustomize works with plain Kubernetes YAML manifests and is not restricted to Helm charts.

Answer

Overlays can only add labels, not modify existing ones.

Answer

Overlays must be stored in the same directory as the base.

Answer

Overlays can only be used with Helm charts.

Question 13

Which of the following are valid kubectl commands for managing rollouts? (Select all that apply)

Accepted Answer

kubectl rollout status deployment/myapp. Option A, `kubectl rollout status deployment/myapp`, is correct because it is a valid subcommand that watches the progress of a Deployment rollout until it completes or fails, reporting the current status. Option C, `kubectl rollout history deployment/myapp`, is correct because it lists the revision history of the Deployment, showing each revision number and change-cause annotation. Option D, `kubectl rollout restart deployment/myapp`, is correct because it performs a rolling restart of the Deployment by adding a restartedAt annotation to the pod template, triggering a new rollout. Option E, `kubectl rollout pause deployment/myapp`, is correct because it pauses an in-progress rollout, allowing multiple changes to be applied before resuming with `kubectl rollout resume`. Option B, `kubectl rollout diff deployment/myapp`, is not a valid kubectl subcommand; `kubectl rollout` supports status, history, undo, restart, pause, and resume, but not diff.

Answer

kubectl rollout diff deployment/myapp

Question 14

Which TWO are valid fields in a Deployment's rollingUpdate configuration? (Select 2)

Accepted Answer

maxSurge. In a Deployment's rolling update configuration, the `maxSurge` field defines the maximum number of Pods that can be created above the desired replica count during the update, while `maxUnavailable` defines the maximum number of Pods that can be unavailable during the update. Both are valid fields within the `spec.strategy.rollingUpdate` object in a Kubernetes Deployment.

Answer

minReadySeconds

Answer

progressDeadlineSeconds

Answer

revisionHistoryLimit

Question 15

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?

Accepted Answer

1. 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.

Answer

0

Answer

Unlimited

Answer

100%