While preparing for the AWS SAP-C02, many candidates get confused by how to manage fixed IPv4 CIDR blocks when scaling Auto Scaling Groups (ASGs) across multiple Availability Zones (AZs). In the real world, this is fundamentally a decision about capacity expansion vs. operational complexity and cost. Let’s drill into a simulated scenario.
The Scenario #
TechNova Inc., an innovative SaaS company, has deployed a critical workload on Amazon EC2 instances managed by an Auto Scaling group (ASG) spread across two Availability Zones (AZs) within a single VPC. The VPC’s CIDR block is tightly scoped (10.0.0.0/23), split evenly between two AZ subnets: AZ-Alpha uses 10.0.0.0/24 and AZ-Beta uses 10.0.1.0/24. This two-AZ architecture is connected to on-premises environments with a strict requirement that connectivity cannot experience interruptions.
Recently, AWS introduced a third AZ in the same region—AZ-Gamma—and TechNova wants to include it in the ASG’s deployment to improve availability and fault tolerance. However, the company does not want to expand the VPC CIDR range due to IP address management policies and wants to avoid any downtime during this transition.
Key Requirements #
Enable the Auto Scaling group to leverage all three AZs without expanding the existing IPv4 CIDR block and without any service interruption.
The Options #
-
A) Update the ASG to only use the AZ-Beta subnet; delete and recreate the AZ-Alpha subnet splitting its original /24 into two /25 subnets; update ASG to include the new split AZ-Alpha subnet; once instances are healthy, switch ASG to use only the new AZ-Alpha subnet; remove the current AZ-Beta subnet; recreate it with the other half of the original AZ-Alpha subnet CIDR; create a /25 subnet for AZ-Gamma using half of the original AZ-Beta subnet; update ASG to use all three new subnets.
-
B) Terminate instances in AZ-Alpha subnet, delete and recreate AZ-Alpha subnet as a /25; update ASG to the new subnet; repeat the process for AZ-Beta; define a new subnet in AZ-Gamma; update ASG to point to all three subnets.
-
C) Create a new VPC with the same CIDR block; define one subnet per AZ in the new VPC; update the ASG to refer to the new subnets in the new VPC.
-
D) Update the ASG to use only the AZ-Beta subnet; shrink the AZ-Alpha subnet to a /25; adjust the ASG to include the resized AZ-Alpha subnet; after instance health checks, switch the ASG to only the resized AZ-Alpha subnet; update the AZ-Beta subnet to use the other half of AZ-Alpha’s original subnet range; create a new AZ-Gamma subnet from half of the original AZ-Beta subnet; update ASG to use all three subnets.
Correct Answer #
Option D.
Step-by-Step Winning Logic #
Option D carefully orchestrates subnet resizing within the existing VPC CIDR block without requiring CIDR range expansion. By shrinking AZ-Alpha’s subnet to a /25, it frees address space that can be reassigned to AZ-Beta and AZ-Gamma.
This approach ensures:
- No downtime as the ASG first migrates traffic to a single subnet, then shifts to newly resized subnets sequentially.
- Maintaining connectivity with on-premises while performing updates.
- Avoiding VPC or IP renumbering complexity or loss of address space control.
- Optimizing the use of existing IP space to accommodate the new AZ.
These factors make it the most operationally efficient and FinOps-friendly choice since it minimizes changes and maintains live service, reducing risk and potential cost impact on the network.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
-
Why not Option A?
Overly complex process of deleting and recreating subnets multiple times introduces operational risk and temporary subnets removal could lead to service interruption. -
Why not Option B?
Terminating instances upfront causes downtime, violating the requirement for zero service interruption. -
Why not Option C?
Creating a new VPC with the same CIDR and moving ASG is effectively a duplicated environment leading to complex migration and double cost.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
VPC[VPC 10.0.0.0/23] --> AZAlpha[AZ-Alpha Subnet 10.0.0.0/25]
VPC --> AZBeta[AZ-Beta Subnet 10.0.0.128/25]
VPC --> AZGamma[AZ-Gamma Subnet 10.0.1.0/25]
ASG[Auto Scaling Group] --> AZAlpha
ASG --> AZBeta
ASG --> AZGamma
OnPremises[On-Prem Network] --> VPC
style VPC fill:#bbf,stroke:#333
style ASG fill:#f96,stroke:#333
Diagram Note: The diagram illustrates the existing VPC with its resized subnets split to accommodate three AZs, all attached to the Auto Scaling Group without changing the overall VPC CIDR or causing downtime.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | Est. Complexity | Est. Monthly Cost (Quantified) | Pros | Cons |
|---|---|---|---|---|
| A | High | Moderate ($500) | No CIDR expansion; attempts sequential resizing | Operationally risky with subnet deletions/recreations causing potential downtime and misconfigurations |
| B | Medium | Moderate ($500) | Resizing subnets, but clear process | Requires instance termination upfront → downtime |
| C | Very High | High ($1200+) | Clean separation; new VPC | High migration cost; duplicate VPC resources; network complexity; downtime likely |
| D | Medium | Low ($300) | No downtime; no CIDR expansion; efficient use of IPs; low operational risk | Requires careful sequential subnet resizing and ASG updates |
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
For the exam, always consider adjusting and reusing existing subnet CIDR blocks when constrained by fixed IP ranges before opting to create new VPCs or terminate instances.
Real World #
In production, this approach reduces complexity and cost, but you might combine it with secondary CIDR blocks or IPv6 planning depending on growth expectations and network future-proofing.