CKA Practice Question: Cluster Architecture, Installation and Configuration
Which of the following YAML snippets correctly defines a Kubernetes Deployment with 3 replicas and a rolling update strategy?
⚠ Common exam trap
The trap here is that candidates often forget that `rollingUpdate` subfields must be properly nested under `strategy` and that `extensions/v1beta1` is deprecated, leading them to choose Option A or misindented Option C, while Option D tests confusion between Deployment and DaemonSet update strategies.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
It uses the stable `apps/v1` API version, specifies 3 replicas, and defines a `RollingUpdate` strategy with both `maxUnavailable` and `maxSurge` set to 1. This ensures that during an update, at most one Pod is unavailable and at most one extra Pod is created, maintaining application availability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate
Why it's wrong here
This YAML snippet is incorrect because it uses `apiVersion: extensions/v1beta1` for a Deployment. This API version for Deployments was deprecated in Kubernetes 1.9 and completely removed in Kubernetes 1.16. Modern Kubernetes clusters require Deployments to be defined under `apiVersion: apps/v1`, making this definition incompatible with current best practices and most production environments. Attempting to apply this manifest to a recent cluster would result in an "unrecognized apiVersion" error.
- ✓
apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
Why this is correct
This YAML snippet correctly defines a Kubernetes Deployment. It utilizes the stable `apps/v1` API version, which is the standard for Deployments in current Kubernetes releases. Furthermore, it explicitly configures the `RollingUpdate` strategy with `maxUnavailable` and `maxSurge` parameters, ensuring a controlled and highly available update process by specifying how many pods can be unavailable or created beyond the desired replica count during an update.
- ✗
apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
Why it's wrong here
This YAML snippet is syntactically incorrect due to improper indentation. The `maxUnavailable` and `maxSurge` fields, which are parameters for the `rollingUpdate` strategy, are incorrectly placed at the same indentation level as `rollingUpdate` itself. In YAML, these parameters must be nested directly under `rollingUpdate` to be correctly parsed as its sub-fields, leading to a parsing error if applied to Kubernetes.
- ✗
apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: OnDelete
Why it's wrong here
This YAML snippet is incorrect because it specifies `type: OnDelete` under the `strategy` field for a Deployment. The `OnDelete` update strategy is exclusively valid for Kubernetes DaemonSets, where it dictates that pods are only replaced when manually deleted. Deployments, however, only support `RollingUpdate` (the default) and `Recreate` strategies, rendering `OnDelete` an invalid and unrecognized option for this resource type.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Deployments
A Kubernetes resource that manages a set of identical Pods, ensuring they run the correct number of replicas and can be updated or rolled back without downtime.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
This CKA question is part of Courseiva's 302-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.