CKAD Application Deployment Practice Test 6 — 15 Questions

Question 1

Which kubectl command is used to view 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 progress of a rollout for a Deployment named 'web-app'. It blocks until the rollout completes successfully or reports a failure, providing real-time status updates such as 'Waiting for rollout to finish' or 'deployment "web-app" successfully rolled out'.

Answer

kubectl rollout history deployment web-app

Answer

kubectl describe deployment web-app

Answer

kubectl status deployment web-app

Question 2

A Deployment has been updated with a new image. After running 'kubectl rollout status deployment/myapp', you see that the rollout has stalled. You want to undo the rollout to the previous revision. What command do you run?

Accepted Answer

kubectl rollout undo deployment/myapp. 'kubectl rollout undo deployment/myapp' reverts the Deployment to the previous revision, which is the standard Kubernetes command for rolling back a stalled or failed rollout. This command uses the Deployment's revision history stored in its annotations to restore the prior pod template specification.

Answer

kubectl rollout restart deployment/myapp

Answer

kubectl delete deployment/myapp --cascade=orphan

Answer

kubectl set image deployment/myapp app=old-image

Question 3

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?

Accepted Answer

Update the Service's label selector to match the green Deployment's pod labels. By updating the Service's label selector to match the green Deployment's pod labels, the Service routes traffic to the new version.

Answer

Scale down the blue Deployment to 0 replicas

Answer

Delete the blue Deployment

Answer

Change the Service type from ClusterIP to NodePort

Question 4

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?

Accepted Answer

Ingress resource with a canary annotation. An Ingress resource with a canary annotation (e.g., `nginx.ingress.kubernetes.io/canary-weight: "10"`) allows you to split traffic between two Services by weight. This is the standard Kubernetes approach for canary deployments, where the Ingress controller (like NGINX) routes a specified percentage of traffic to the canary Service (app-v2) and the rest to the primary Service (app-v1).

Answer

A single Service with multiple selectors

Answer

NetworkPolicy

Answer

HorizontalPodAutoscaler

Question 5

When using 'kubectl apply' vs 'kubectl create', which statement is correct?

Accepted Answer

'kubectl apply' can create or update resources; 'kubectl create' only creates and fails if resource exists. 'kubectl apply' uses a declarative approach that creates a resource if it does not exist and updates it if it does, while 'kubectl create' is imperative and will fail with an error if the resource already exists. This distinction is fundamental to Kubernetes resource management, where 'apply' manages the full object state via last-applied-configuration annotations, and 'create' only handles initial creation.

Answer

'kubectl create' will update a resource if it already exists

Answer

'kubectl apply' and 'kubectl create' are interchangeable

Answer

'kubectl apply' can only create resources, not update them

Question 6

You want to scale a Deployment named 'frontend' to 5 replicas. Which command should you use?

Accepted Answer

kubectl scale deployment frontend --replicas=5. `kubectl scale` is the dedicated Kubernetes command to adjust the number of replicas for a Deployment (or other scalable resources). The syntax `kubectl scale deployment frontend --replicas=5` directly instructs the API server to update the Deployment's `spec.replicas` field to 5, triggering the ReplicaSet controller to create or remove Pods to match the desired count.

Answer

kubectl set replicas deployment frontend=5

Answer

kubectl update deployment frontend --replicas=5

Answer

kubectl scale --replicas=5 frontend

Question 7

Which field in a Deployment's rolling update strategy controls the maximum number of pods that can be created above the desired replicas during a rolling update?

Accepted Answer

maxSurge. In a Deployment's rolling update strategy, `maxSurge` controls the maximum number of pods that can be created above the desired replica count during the update. This allows the system to spin up new pods before terminating old ones, ensuring zero downtime. The value can be an absolute number or a percentage of the desired replicas.

Answer

maxUnavailable

Answer

revisionHistoryLimit

Answer

minReadySeconds

Question 8

You have a Deployment that uses the 'Recreate' strategy. What happens when you update the pod template (e.g., change the image)?

Accepted Answer

All existing pods are terminated before new pods are created. The 'Recreate' strategy in a Kubernetes Deployment terminates all existing pods before creating new ones when the pod template is updated. This ensures zero overlapping pods during the update, which is useful for applications that cannot handle multiple versions running simultaneously.

Answer

The update is not allowed; you must delete the Deployment first

Answer

New pods are created gradually while old pods are terminated

Answer

Pods are updated in-place without restart

Question 9

You want to use Kustomize to apply a patch that adds a sidecar container to all pods in a Deployment. Which Kustomize feature should you use?

Accepted Answer

patchesStrategicMerge. `patchesStrategicMerge`, is correct because it allows you to apply a strategic merge patch to a Kubernetes resource, such as adding a sidecar container to all pods in a Deployment. This feature merges the patch into the base resource definition, enabling modifications like appending containers to the pod spec without overwriting the entire resource.

Answer

namePrefix

Answer

replicas

Answer

images

Question 10

Which command lists all Helm releases in the current namespace?

Accepted Answer

helm list. The `helm list` command is the correct way to list all Helm releases in the current namespace. It queries the Helm release storage (typically Secrets in the cluster) and returns the release names, status, chart versions, and other metadata for the namespace set in the current kubeconfig context.

Answer

helm get all

Answer

helm status

Answer

helm show

Question 11

You have created a HorizontalPodAutoscaler (HPA) for a Deployment. The HPA is configured with targetCPUUtilizationPercentage: 50. The current CPU utilization is 80%. What will the HPA do?

Accepted Answer

It will increase the number of replicas. The HPA will increase the number of replicas to bring average CPU utilization down to the target.

Answer

It will restart the pods

Answer

It will do nothing because HPA only scales based on memory

Answer

It will decrease the number of replicas

Question 12

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?

Accepted Answer

1. In a rolling update with `maxSurge=1` and `maxUnavailable=0`, Kubernetes ensures that at most one extra pod can be created above the desired replica count during the update. This is controlled by the `maxSurge` field, which defines the maximum number of pods that can be created over the desired number, and here it is set to 1 (either an absolute number or a percentage, defaulting to 25%). Since `maxUnavailable=0`, no pods can be taken down before new ones are ready, so the surge allows exactly one additional pod to be created temporarily.

Answer

Unlimited

Answer

0

Answer

Desired replicas

Question 13

Which TWO of the following are correct ways to pause a rollout of a Deployment named 'myapp'? (Select TWO)

Accepted Answer

kubectl rollout pause deployment/myapp. `kubectl rollout pause deployment/myapp` is the dedicated command to pause a rollout. Option C is also correct because the Deployment spec includes a `paused` field; setting `spec.paused: true` via `kubectl edit` or `kubectl patch` achieves the same effect. Option B (`kubectl rollout undo`) rolls back a rollout, not pauses it. Option D (`kubectl rollout resume`) resumes a paused rollout. Option E triggers a new rollout with `set image` before pausing, which does not simply pause the current rollout.

Answer

kubectl rollout undo deployment/myapp

Answer

kubectl rollout resume deployment/myapp

Answer

kubectl set image deployment/myapp app=nginx && kubectl rollout pause deployment/myapp

Question 14

Which THREE of the following are valid Kustomize features? (Select THREE)

Accepted Answer

resources. `resources` is a core Kustomize field used to list the YAML files (or directories) that form the base set of Kubernetes resources to be customized. Without `resources`, Kustomize has no manifests to process, making it essential for defining the input to the kustomization build.

Answer

serviceAccount

Answer

ingress

Question 15

You need to perform a canary deployment using a Service and two Deployments (stable and canary). Which TWO resources or configurations are typically used to route a percentage of traffic to the canary? (Select TWO)

Accepted Answer

Service Mesh (e.g., Istio VirtualService). Option A (Service Mesh, e.g., Istio VirtualService) is correct because a service mesh like Istio can split traffic between the stable and canary Deployments at the L7 level, using VirtualService/DestinationRule weights to send a precise percentage of requests to the canary subset. Option D (Ingress with canary annotation) is correct because ingress controllers such as NGINX Ingress support canary annotations (e.g., nginx.ingress.kubernetes.io/canary and canary-weight) to route a defined percentage of traffic to a canary backend Service. Option B is not valid because a Kubernetes Service has a single label selector and cannot natively split traffic by percentage across two Deployments. Option C is incorrect because NetworkPolicy only controls L3/L4 pod-level ingress/egress firewall rules, not HTTP traffic weighting. Option E is incorrect because a HorizontalPodAutoscaler only scales replica counts based on metrics and does not perform traffic routing or canary splitting.

Answer

A single Service with multiple label selectors

Answer

NetworkPolicy

Answer

HorizontalPodAutoscaler