CKAD Application Deployment Practice Test 13 — 15 Questions

Question 1

Which THREE of the following are correct about Kustomize?

Accepted Answer

A 'kustomization.yaml' file is required in each Kustomize directory.. Options A, B, and E are correct. Option A: A kustomization.yaml file is required in each Kustomize directory to define resources, bases, and patches. Option B: The 'patches' field in kustomization.yaml allows overriding fields in resources via strategic merge patches or JSON patches. Option E: A base can be a local directory referenced via path or a remote URL (e.g., git repository). Option C is incorrect because 'kustomize build' outputs the rendered YAML to stdout; there is no 'kustomize apply' command. Option D is incorrect because Kustomize does not use templates; it uses overlays and patching without templating.

Answer

The command 'kustomize apply' deploys resources to the cluster.

Answer

Kustomize uses Helm-style templates to generate resources.

Question 2

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

Question 3

Which THREE of the following are valid reasons to use a HorizontalPodAutoscaler (HPA) with a Deployment?

Accepted Answer

To scale replicas based on the number of incoming HTTP requests per second.. Options B, C, and E are valid uses of a HorizontalPodAutoscaler (HPA). HPA can scale based on custom metrics (e.g., HTTP requests per second) via the 'custom' or 'external' metric types, making B and C correct. Option E is correct because HPA can scale based on average CPU utilization using the 'ResourceMetric' type with 'targetAverageUtilization'. Option A is incorrect: HPA scales up when CPU exceeds the target, not down; also, the deprecated 'targetCPUUtilizationPercentage' field has been replaced by a metrics array. Option D is incorrect: HPA does not enforce resource requests; it only uses them as a basis for metric calculation.

Answer

To set a fixed 'targetCPUUtilizationPercentage' that scales down the deployment when exceeded.

Answer

To ensure that each pod has at least a certain amount of CPU resources reserved.

Question 4

Which TWO of the following are correct methods to implement a canary deployment using Kubernetes resources?

Accepted Answer

Create two Deployments (stable and canary) with a shared Service that selects both based on a common label. Initially, canary has 1 replica while stable has many. Gradually increase canary replicas.. Options C and E are correct methods for canary deployment in Kubernetes. Option C uses two Deployments (stable and canary) with a shared Service that selects both based on a common label. By starting with a low number of canary replicas and gradually increasing, traffic is incrementally shifted. Option E leverages an Ingress controller (like Nginx Ingress) that supports canary annotations to route a percentage of traffic to the canary Deployment. Option A is incorrect because 'strategy.type: Canary' is not a valid Kubernetes Deployment strategy; only RollingUpdate and Recreate are supported. Option B is incorrect because header-based routing is not a standard canary method; it's more for A/B testing. Option D is incorrect because using two separate Services with DNS routing does not provide fine-grained traffic splitting and is not a typical canary approach.

Answer

Use a Deployment with 'strategy.type: Canary' in the spec.

Answer

Create two Services and use a header-based routing to send specific users to canary.

Answer

Create two separate Services, one for stable and one for canary, and use DNS to route a percentage of traffic.

Question 5

Which TWO of the following are correct about the difference between 'kubectl apply' and 'kubectl create'?

Accepted Answer

'kubectl apply' can be used to update existing resources, whereas 'kubectl create' will fail if the resource already exists.. 'kubectl apply' can update existing resources, while 'kubectl create' will fail if the resource already exists. Option B is correct: 'kubectl apply' is declarative (manages desired state), whereas 'kubectl create' is imperative (directly creates). Option C is false: 'kubectl apply' can both create and update resources. Option D is false: 'kubectl apply' does not delete resources removed from the file; it only manages the resources in the file. Option E is false: 'kubectl create' can create resources from stdin, not just YAML files.

Answer

'kubectl apply' can only be used to create resources, not update them.

Answer

'kubectl apply' will delete resources if they are removed from the file.

Answer

'kubectl create' can only create resources from YAML files, not from stdin.

Question 6

A developer wants to deploy a stateless application as a set of identical pods. They need the pods to be distributed across nodes and have stable network identities. Which resource should they use?

Accepted Answer

StatefulSet. StatefulSet is the correct resource because it provides each pod with a stable, unique network identity (e.g., pod-name-0, pod-name-1) that persists across rescheduling. While Deployment manages replicas for stateless applications, it does not assign per-pod stable hostnames. The question explicitly requires 'stable network identities' for identical pods, which is a defining feature of StatefulSet. A Service combined with a Deployment gives a stable endpoint for the set, not per-pod identities.

Answer

Job

Answer

Deployment

Answer

DaemonSet

Question 7

A company wants to ensure zero-downtime deployments for a stateless web application running in Kubernetes. They have a single Deployment with 3 replicas and a Service of type LoadBalancer. Which strategy should they use to achieve this?

Accepted Answer

Use RollingUpdate with maxSurge=25% and maxUnavailable=0. A RollingUpdate strategy with maxSurge=25% and maxUnavailable=0 ensures that during a deployment, the desired number of replicas is always available (no downtime). maxUnavailable=0 means no old Pods are terminated until new ones are ready, and maxSurge=25% allows one extra Pod (25% of 3 replicas = 0.75, rounded up to 1) to be created before terminating old ones, maintaining capacity for zero-downtime updates.

Answer

Use Recreate strategy

Answer

Use RollingUpdate with maxSurge=100% and maxUnavailable=100%

Answer

Use RollingUpdate with maxSurge=0 and maxUnavailable=25%

Question 8

Match each volume type to its use case.

Accepted Answer

emptyDir: Provides temporary storage that is created empty and persists for the lifetime of the pod.. The correct matches are: emptyDir - temporary storage, hostPath - host node directory, PVC - persistent storage, ConfigMap - configuration data. Common confusions involve mixing hostPath and PVC, or emptyDir with hostPath.

Answer

emptyDir: Mounts a file or directory from the host node's filesystem.

Answer

hostPath: Requests persistent storage that survives pod restarts.

Question 9

You have a Deployment named 'frontend' with 4 replicas. You want to perform a rolling update with the following constraints: the number of pods above the desired count should never exceed 1, and the number of unavailable pods should never exceed 0. Which deployment strategy configuration achieves this?

Accepted Answer

strategy: rollingUpdate: {maxSurge: 1, maxUnavailable: 0}. Setting `maxSurge: 1` ensures that during a rolling update, at most one additional pod is created above the desired replica count of 4, and `maxUnavailable: 0` guarantees that no pods are taken down until the new ones are ready. This satisfies the constraints of never exceeding one extra pod and never having unavailable pods.

Answer

strategy: rollingUpdate: {maxSurge: 2, maxUnavailable: 0}

Answer

strategy: rollingUpdate: {maxSurge: 25%, maxUnavailable: 25%}

Answer

strategy: type: Recreate

Question 10

You have a Deployment 'app' with the following strategy configuration: 'type: RollingUpdate', 'rollingUpdate: {maxSurge: 0, maxUnavailable: 1}'. You update the container image. What is the behavior during the update?

Accepted Answer

One old pod is terminated, then a new pod is created, repeating until all pods are updated.. With `maxSurge: 0` and `maxUnavailable: 1`, the RollingUpdate strategy ensures that during the update, no extra pods beyond the desired replica count are created (surge is zero), and at most one pod can be unavailable at any time. The Deployment controller first terminates an old pod (making one unavailable), then creates a new pod to replace it, repeating this process until all pods are updated. This guarantees a controlled, sequential rollout with minimal disruption.

Answer

A new pod is created first, then the oldest pod is terminated.

Answer

Two old pods are terminated at a time, while new pods are created.

Answer

All old pods are terminated simultaneously, then new pods are created.

Question 11

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). A Service Mesh like Istio uses a VirtualService resource to define traffic routing rules based on weights (e.g., `weight: 90` for stable and `weight: 10` for canary). This allows fine-grained, percentage-based traffic splitting between two different Kubernetes Services or subsets, which is a core requirement for canary deployments.

Answer

A single Service with multiple label selectors

Answer

NetworkPolicy

Answer

HorizontalPodAutoscaler

Question 12

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 13

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 14

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

Accepted Answer

Overlays are used to customize resources for different environments.. Overlays are used to customize resources for different environments, and they can patch resources defined in bases.

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 15

You are performing a canary deployment using two Deployments: 'app-stable' (replicas: 9) and 'app-canary' (replicas: 1), both with label 'app: myapp'. A Service selects pods with 'app: myapp' and 'version: stable'. How can you route traffic to the canary?

Accepted Answer

Add label 'version: stable' to the canary Deployment's pod template, so both Deployments have the same label, and keep the Service selector as is.. Adding the label 'version: stable' to the canary Deployment's pod template makes its pods match the Service's selector ('app: myapp' and 'version: stable'). This allows the Service to include both stable and canary pods, distributing traffic according to the replica ratio (9:1). The canary image can be different from stable, but the label ensures the Service routes traffic to both sets of pods.

Answer

Update the canary Deployment's image to a different version.

Answer

Change the Service's selector to 'version: canary'.

Answer

Add label 'version: canary' to the canary Deployment's template and update the Service selector to 'version: stable || version: canary'.