Amazon EKS — Cluster Upgrades Practice Questions
Test your understanding of EKS cluster upgrade processes.
Q1. What is the correct order for upgrading an EKS cluster?
- A. Nodes → Control plane → Add-ons
- B. Add-ons → Control plane → Nodes
- C. Control plane → Add-ons → Nodes
- D. Control plane → Nodes → Add-ons
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — nodes cannot be upgraded before the control plane |
| B | Incorrect — add-ons should be upgraded after the control plane |
| C | ✅ Correct — control plane first, then add-ons for compatibility, then nodes |
| D | Incorrect — add-ons should be upgraded before nodes to avoid compatibility issues |
Q2. What tool scans a cluster for deprecated Kubernetes APIs?
- A. kubectl audit
- B. pluto
- C. eks-node-viewer
- D. kubent
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect — kubectl audit is not a real command for this purpose |
| B | ✅ Correct — pluto (by Fairwinds) detects deprecated and removed APIs in cluster resources and Helm releases |
| C | Incorrect — eks-node-viewer shows node utilization, not API deprecations |
| D | Incorrect — kubent (kube-no-trouble) also detects deprecations but pluto is more widely used with EKS |
Q3. Can an EKS control plane upgrade be rolled back?
- A. Yes, using
aws eks rollback-cluster - B. Yes, by running the upgrade command with the previous version
- C. No, but AWS will attempt automatic rollback on failure
- D. No, once successful it cannot be changed
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — there is no rollback-cluster API |
| B | Incorrect — you cannot downgrade a control plane to a previous version |
| C | ✅ Correct — EKS control plane upgrades are irreversible; AWS attempts automatic rollback only on failure |
| D | Incorrect — partially true after success, but AWS does handle failures with automatic rollback |
Q4. What resolve-conflicts value should you use when updating a VPC CNI add-on that has custom environment variables?
- A. NONE
- B. OVERWRITE
- C. PRESERVE
- D. MERGE
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — NONE would fail if any custom configuration exists |
| B | Incorrect — OVERWRITE replaces your custom config with defaults, losing your changes |
| C | ✅ Correct — PRESERVE keeps your custom configuration while updating the add-on binary |
| D | Incorrect — MERGE is not a valid resolve-conflicts option |
Q5. What is the maximum version skew allowed between the EKS control plane and worker node kubelet?
- A. 1 minor version
- B. 2 minor versions
- C. 3 minor versions
- D. Must be the same version
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect — EKS recommends 1 but allows 2 per Kubernetes policy |
| B | ✅ Correct — Kubernetes allows kubelet to be up to 2 minor versions behind the API server |
| C | Incorrect — 3 minor versions exceeds the Kubernetes version skew policy |
| D | Incorrect — same version is not required; some skew is allowed |
Q6. How does Karpenter handle node upgrades when the AMI changes?
- A. Automatically restarts kubelet on existing nodes
- B. Detects drift and replaces nodes with updated AMI
- C. Requires manual node group update
- D. Patches the existing node in-place
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect — Karpenter doesn’t patch existing nodes |
| B | ✅ Correct — Karpenter detects configuration drift (new AMI), cordons/drains old nodes, and launches replacements |
| C | Incorrect — Karpenter nodes are not in managed node groups |
| D | Incorrect — Karpenter replaces nodes entirely, not in-place patching |
Q7. What EKS feature provides automated pre-upgrade compatibility checks?
- A. EKS Upgrade Advisor
- B. EKS Upgrade Insights
- C. AWS Config EKS rules
- D. CloudWatch Upgrade Metrics
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect — there is no feature called EKS Upgrade Advisor |
| B | ✅ Correct — EKS Upgrade Insights flags deprecated APIs, add-on issues, and workload compatibility |
| C | Incorrect — AWS Config rules check compliance, not upgrade readiness |
| D | Incorrect — CloudWatch doesn’t have specific upgrade metrics |
Q8. When performing a blue-green cluster upgrade, which resource should NOT be shared between clusters?
- A. VPC and subnets
- B. RDS database
- C. IRSA IAM roles
- D. ECR container images
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — VPC and subnets are commonly shared between blue and green clusters |
| B | Incorrect — RDS databases should be shared to avoid data migration |
| C | ✅ Correct — IRSA roles include the cluster’s OIDC provider in the trust policy, making them cluster-specific |
| D | Incorrect — ECR images are account-level and easily shared between clusters |
Q9. What maxUnavailable setting should you use for a production node group upgrade prioritizing safety?
- A. maxUnavailable: 0
- B. maxUnavailable: 1
- C. maxUnavailablePercentage: 50
- D. maxUnavailable: 10
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect — 0 is not a valid value; at least 1 node must be unavailable for progress |
| B | ✅ Correct — upgrading one node at a time minimizes risk and ensures capacity |
| C | Incorrect — 50% is aggressive and could cause capacity issues |
| D | Incorrect — 10 nodes simultaneously is too aggressive for production |
Q10. What happens when an EKS cluster reaches end of life after extended support expires?
- A. The cluster is terminated
- B. The cluster continues at the same version indefinitely
- C. AWS automatically upgrades the cluster
- D. The API server becomes read-only
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — AWS does not terminate clusters at end of life |
| B | Incorrect — clusters do not stay on unsupported versions indefinitely |
| C | ✅ Correct — AWS will automatically upgrade the cluster to the latest supported version |
| D | Incorrect — the API server does not switch to read-only mode |