CKAD Application Deployment Practice Test 3 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

1. The HPA calculates the desired number of replicas using the formula: desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)]. With current CPU at 60% and target at 80%, the ratio is 0.75. If the current replica count is 1, the result is ceil(1 * 0.75) = 1. Since the ratio is below 1.0, the HPA does not scale up; it only scales down if the ratio falls below a configurable threshold (default 0.5) for a sustained period, which is not the case here.

Answer

The HPA would not be created if current usage is below target

Answer

2

Answer

0

Question 2

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)

Accepted Answer

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 2. Option A is correct because maxSurge: 1 allows exactly 1 extra pod above the desired 6, and maxUnavailable: 2 allows at most 2 pods to be unavailable, matching both constraints exactly. Option B is correct because maxSurge: 16% of 6 replicas rounds up to 1 extra pod, and maxUnavailable: 33% of 6 replicas rounds down to 1 unavailable pod, which satisfies the limits of at most 1 extra and at most 2 unavailable. Option C is incorrect because maxSurge: 2 would allow 2 extra pods, exceeding the stated limit of 1 extra pod. Option D is incorrect because maxUnavailable: 3 would allow 3 unavailable pods, exceeding the stated limit of 2. Option E is incorrect because maxUnavailable: 1 is more restrictive than required and does not match the specified constraint of allowing up to 2 unavailable pods.

Answer

strategy:
  rollingUpdate:
    maxSurge: 2
    maxUnavailable: 2

Answer

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 3

Answer

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

Question 3

A canary deployment is being implemented using two Deployments (stable and canary) and a Service. The Service's label selector has two entries: 'app: myapp' and 'version: stable'. Initially, the canary Deployment's pods have label 'version: canary'. To route a small percentage of traffic to the canary, what should you do?

Accepted Answer

Change the canary Deployment's pod template labels to also include 'version: stable' so that the Service selects them. A Service selector matches pods based on AND logic for the specified key-value pairs. Since the Service requires 'version: stable', canary pods with 'version: canary' do not match. You cannot add a second 'version' label because label keys must be unique within a pod. Therefore, Option B is invalid. A proper canary setup would use a selector with a shared label (e.g., just 'app: myapp') and control traffic via replica counts.

Answer

Update the Service's selector to include both 'version: stable' and 'version: canary'

Answer

Use a NetworkPolicy to allow traffic to the canary

Answer

Create a new Service that points to both Deployments

Question 4

You are using Kustomize with the following structure: a base with a Deployment YAML, and an overlay that patches the image tag. The overlay's kustomization.yaml contains: 'patches: - target: kind: Deployment, name: myapp, patch: |- ...'. After running 'kubectl apply -k ./overlay', the Deployment is created but the image tag is not updated. What is the most likely cause?

Accepted Answer

The base Deployment has a different name than 'myapp'. The most common issue is that the patch is not matching the Deployment's name or kind correctly. The target's name must match exactly, or the patch may not be applied. Also, the patch format (strategic merge or JSON patch) must be correct. But the most likely cause is that the patch is not being applied because the patch target does not match the resource.

Answer

The image tag is defined in the base and cannot be overridden

Answer

You need to run 'kustomize build' first

Answer

The overlay is not referencing the base correctly

Question 5

When using Helm, which command installs a chart from a repository into a namespace, overriding a value?

Accepted Answer

helm install myrelease repo/chart --set key=value --namespace ns. `helm install` is the standard command to deploy a new release from a chart repository into a namespace, and `--set` overrides default values. `helm upgrade --install` is also a valid idempotent alternative that installs the release if it does not already exist. `helm template` only renders YAML, and `helm create` scaffolds a new chart.

Answer

helm template myrelease repo/chart --set key=value --namespace ns

Answer

helm create myrelease repo/chart --set key=value --namespace ns

Question 6

After upgrading a Helm release, you want to revert to the previous revision. Which command achieves this?

Accepted Answer

helm rollback release-name (previous-revision). 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.

Answer

helm undo release-name

Answer

helm upgrade --rollback release-name

Answer

helm rollback release-name 0

Question 7

Which command lists all Helm releases in the current namespace?

Accepted Answer

helm list. The `helm list` command (aliased as `helm ls`) queries the Helm release storage backend (default: Kubernetes Secrets of type `helm.sh/release.v1`) and returns all releases in the current namespace, showing name, namespace, revision, status, chart, and app version. It is the canonical way to enumerate deployed releases. Adding `-A` or `--all-namespaces` extends the listing cluster-wide.

Answer

helm show

Answer

helm status

Answer

helm get all

Question 8

Which field in a HorizontalPodAutoscaler spec defines the target CPU utilization percentage?

Accepted Answer

spec.targetCPUUtilizationPercentage. The targetCPUUtilizationPercentage field in the HPA spec (for autoscaling/v1) or in the metric spec (for autoscaling/v2) defines the CPU target.

Answer

spec.behavior

Answer

spec.metrics[0].resource.target.averageUtilization

Answer

spec.maxReplicas

Question 9

Which TWO options are valid annotations for a Pod?

Accepted Answer

version: v1. Option A (version: v1) is a valid annotation because annotations are arbitrary key/value metadata, and a simple key like version with the value v1 is syntactically and semantically acceptable. Option D (description: 'This pod runs the frontend') is also valid because annotation values may be free-form strings, including human-readable descriptions, and this key/value pair follows the annotation format. Option B (pod-template-hash: 12345) is not a valid annotation for a Pod in this context because pod-template-hash is a label automatically added by Deployments/ReplicaSets, not an annotation. Option C (environment: production) is a label-style key/value pair commonly used for selection and grouping, not an annotation. Option E (app.kubernetes.io/name: myapp) is a recommended label from the Kubernetes common labels convention, not an annotation.

Answer

pod-template-hash: 12345

Answer

environment: production

Answer

app.kubernetes.io/name: myapp

Question 10

Which command is used to scale a Deployment named 'frontend' to 10 replicas?

Accepted Answer

kubectl scale deploy frontend --replicas 10. Both Option A and Option B are valid commands to scale a Deployment. Option A uses the abbreviation 'deploy' and the --replicas flag without equals sign, which is accepted. Option B uses the full resource type 'deployment/frontend' with the equals sign. Both achieve the same result. Options C and D are not the direct scale command; Option C uses 'set replicas' which is not a valid kubectl command for scaling, and Option D uses 'edit' which is indirect and not the command for scaling.

Answer

kubectl set replicas deployment/frontend 10

Answer

kubectl edit deployment frontend and change replicas to 10

Question 11

Which TWO statements are true about Helm releases? (Select two)

Accepted Answer

Helm stores release information in the same namespace as the chart's resources.. Helm allows multiple releases of the same chart in the same namespace, each with a unique release name and configuration (Option null). This enables deploying different versions or configurations of an application side by side. Option D is correct because Helm stores release metadata (e.g., revision history) in Secrets or ConfigMaps within the same namespace as the deployed resources, ensuring scoped management. Options A and E are incorrect: Helm does not automatically delete previous releases on upgrade unless --history-max is set; rollback works on any revision, not only the latest. Option B is false because Helm rollback works regardless of whether the initial release was created with Helm. Option C is false: Helm releases are mutable and can be upgraded or rolled back. Thus, options null and D are both correct.

Answer

Helm automatically deletes the previous release when upgrading.

Answer

Helm rollback only works if the current release was created with Helm.

Answer

A Helm release is immutable once installed.

Answer

Helm rollback only works on the most recent release revision.

Question 12

Which TWO statements about kubectl apply vs kubectl create are correct? (Select two)

Accepted Answer

kubectl apply can update existing resources; kubectl create cannot.. Option C is correct because kubectl apply performs a declarative create-or-update against the live object, computing a three-way merge from the last-applied-configuration annotation, whereas kubectl create is imperative and fails with an AlreadyExists error if the resource is already present. Option 'null' (the statement that kubectl apply stores the last applied configuration in an annotation) is correct because apply records the submitted manifest in the kubectl.kubernetes.io/last-applied-configuration annotation, which is what enables subsequent three-way merges and pruning of removed fields. Option A is not marked correct: although both commands do accept --dry-run=client, that statement is not one of the two selected answers here. Option B is wrong because kubectl create also accepts inline flags (e.g., kubectl create deployment nginx --image=nginx) and stdin, not only full YAML files. Option D is wrong because apply, not create, is the recommended declarative approach for managing production resources. Option E is wrong because apply explicitly updates existing resources, and create can also be used with kubectl replace or edit workflows.

Answer

Both commands support the --dry-run=client flag.

Answer

Both commands require a full YAML manifest file.

Answer

kubectl create is the recommended way to manage production resources.

Answer

Both commands can only be used to create resources, not update.

Question 13

Which TWO are valid reasons to use a HorizontalPodAutoscaler (HPA) with a custom metric? (Select two)

Accepted Answer

To scale based on the length of a message queue.. HPA can scale based on custom metrics like requests per second or queue length, not just CPU/memory.

Answer

To scale based on the number of pods in a different Deployment.

Answer

To scale based on disk I/O utilization.

Answer

To scale based on the node's CPU temperature.

Question 14

Which TWO of the following are valid ways to scale a Deployment named 'my-app' to 5 replicas?

Accepted Answer

kubectl apply -f deployment.yaml where deployment.yaml has 'replicas: 5'. Option B is correct because `kubectl apply -f deployment.yaml` with `replicas: 5` in the manifest declaratively updates the Deployment's spec.replicas field to 5, which the Deployment controller reconciles by creating the additional pods. Option E is correct because `kubectl scale deployment my-app --replicas=5` is the dedicated imperative command that directly sets the Deployment's replica count to 5. Option A is not a scaling method per se: `kubectl edit deployment my-app` opens the manifest in an editor where you could manually change replicas, but the command itself does not scale anything and is not a valid standalone scaling answer here. Option C is invalid because the syntax is wrong; the verb `scale` must come before the resource, as in `kubectl scale deployment my-app --replicas=5`. Option D is invalid because `kubectl scale` does not accept a `--selector` flag for a named Deployment; selectors are used with resource types like `--all` or in other contexts, not to scale a specific named Deployment.

Answer

kubectl edit deployment my-app

Answer

kubectl deployment my-app scale --replicas=5

Answer

kubectl scale deployment my-app --selector=app=my-app

Question 15

Which TWO kubectl commands can be used to view the rollout history of a Deployment named 'web-app'?

Accepted Answer

kubectl rollout history deployment web-app. Options C and D are correct. 'kubectl rollout history deployment web-app' displays the rollout history of the deployment. Adding '--revision=2' shows details of revision 2 specifically. Option A, 'kubectl describe deployment web-app', shows current details but not revision history. Option B, 'kubectl rollout status deployment web-app', shows the current status of the rollout, not historical revisions. Option E, 'kubectl get rollout web-app', is invalid as 'rollout' is not a Kubernetes resource; the correct command uses 'rollout' as a subcommand of kubectl.

Answer

kubectl describe deployment web-app

Answer

kubectl rollout status deployment web-app

Answer

kubectl get rollout web-app