While preparing for the AWS SAP-C02, many candidates get confused by Transit Gateway attachment strategies for ephemeral workloads. In the real world, this is fundamentally a decision about automation granularity vs. resource sprawl. Let’s drill into a simulated scenario.
The Scenario #
TechVelocity Labs, a fintech software development company, is modernizing its continuous integration pipeline. The DevOps team needs to spin up isolated test environments automatically whenever developers submit pull requests for review. Each environment consists of an Auto Scaling group running application containers on EC2 instances.
A critical requirement: every test environment must establish secure communication with the company’s legacy test result aggregation server hosted in their on-premises data center to upload performance metrics and compliance reports.
The infrastructure team has already deployed an AWS Transit Gateway with a VPN attachment connecting to the corporate network. However, test environments are created and destroyed 15-20 times per day, and the current manual setup process (VPC creation, Transit Gateway association, route table configuration) is causing 2-hour delays and developer frustration.
Key Requirements #
Implement a solution that enables fully automated creation and teardown of test environments with on-premises connectivity, minimizing operational overhead and eliminating manual network configuration steps.
The Options #
-
A) Create an AWS CloudFormation template containing Transit Gateway attachment and routing configuration; deploy the template as a CloudFormation StackSet; use the StackSet to provision a new stack for each VPC in the account; deploy a new VPC for every test environment.
-
B) Provision a single shared VPC for all test environments; attach it to the Transit Gateway once; use AWS CloudFormation to deploy all test environment EC2 resources into this shared VPC.
-
C) Create a new Organizational Unit (OU) in AWS Organizations for testing; build a CloudFormation template including VPC, networking resources, Transit Gateway attachment, and routing; deploy the template via CloudFormation StackSets to each account under the test OU; create a new AWS account for each test environment.
-
D) Convert test environment EC2 instances to Docker images; use CloudFormation to provision an Amazon EKS cluster in a new VPC, create a Transit Gateway attachment, and configure routing; manage test environment lifecycle using Kubernetes deployments.
Correct Answer #
Option B — Provision a single shared VPC for all test environments; attach it to the Transit Gateway once; use AWS CloudFormation to deploy all test environment EC2 resources into this shared VPC.
Step-by-Step Winning Logic #
This solution achieves the optimal trade-off between automation efficiency and operational simplicity:
-
Network Configuration is Static, Workloads are Dynamic: The Transit Gateway attachment and routing configuration is provisioned once as foundational infrastructure. Test environments (Auto Scaling groups, EC2 instances, security groups) are deployed and destroyed frequently, but they inherit the existing network connectivity.
-
Minimal Operational Overhead: CloudFormation stacks only manage compute resources. No network state changes occur during environment creation/deletion, eliminating:
- Transit Gateway attachment propagation delays (2-5 minutes per lifecycle)
- Route table update race conditions
- CloudFormation stack deletion failures due to attached ENIs
-
Cost Efficiency:
- 1 Transit Gateway attachment ($36/month) vs. 15-20 ephemeral attachments ($540-720/month if never cleaned up)
- Reduced CloudFormation API calls (networking stacks are expensive to create/delete)
- No risk of orphaned VPC resources from failed stack deletions
-
Isolation at the Right Layer: Test environments achieve isolation through security groups and IAM roles, not network boundaries. This is appropriate for internal dev/test workloads where the threat model doesn’t require VPC-level segmentation.
💎 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?
- Resource Sprawl: Creates a new VPC and Transit Gateway attachment for every test environment. With 15-20 environments/day, you’d generate 300-400 VPCs/month. Even with automation, CloudFormation stack cleanup failures are common (e.g., ENI detachment issues), leading to zombie VPCs and unexpected costs.
- Transit Gateway Limits: Default quota is 5,000 attachments per TGW, but route propagation performance degrades significantly above 100 attachments.
- Operational Complexity: Each VPC requires unique CIDR planning, route table management, and troubleshooting surface area.
-
Why not Option C?
- Massive Over-Engineering: Creating a new AWS account for each test environment is architecturally absurd for ephemeral workloads. Account provisioning takes 5-10 minutes via AWS Organizations, negating automation benefits.
- Cost Explosion: Each account incurs:
- CloudTrail logs ($0.10 per 100k events)
- Config recorder fees ($0.003 per configuration item)
- Support plan allocation (if consolidated billing is used)
- Compliance Nightmare: 300+ test accounts/month create audit, tagging, and governance overhead that violates the “least operational overhead” requirement.
-
Why not Option D?
- Technology Mismatch: Introducing EKS ($0.10/hour = $73/month per cluster) and containerization adds complexity without solving the core problem. The question states environments already use Auto Scaling groups—migrating to Kubernetes is a multi-month effort.
- Transit Gateway Configuration Still Required: EKS doesn’t eliminate the need for VPC/TGW setup; it just adds an orchestration layer on top.
- Cost: EKS control plane + NAT Gateway for private subnets + ALB for ingress = $150-200/month baseline before any workloads run.
🔐 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 TB
%% Define Nodes with specific width using line breaks
CFN["CloudFormation Stack
(Management Layer)"]
subgraph Target_VPC [AWS Cloud - Shared VPC]
direction TB
TGW[Transit Gateway
VPN Attachment]
TGWAttach[TGW VPC Attachment]
RouteTable[VPC Route Table
Destination: 10.0.0.0/8]
%% Environments stacked vertically
Env1[Test Environment 1
ASG + EC2 Instances
SG: test-env-1]
Env2[Test Environment 2
ASG + EC2 Instances
SG: test-env-2]
EnvN[Test Environment N
ASG + EC2 Instances
SG: test-env-n]
end
subgraph OnPrem [On-Premises Center]
TestServer[Test Result
Aggregation Server
IP: 10.0.0.0/8]
end
%% Vertical Logic Flow
CFN -.->|Deploys| Env1
CFN -.->|Deploys| Env2
CFN -.->|Deploys| EnvN
TGW --> TGWAttach
TGWAttach --> RouteTable
RouteTable --> Env1
RouteTable --> Env2
RouteTable --> EnvN
%% Data Reporting Flow
Env1 -->|Report| TestServer
Env2 -->|Report| TestServer
EnvN -->|Report| TestServer
%% Styling for clarity
style TGWAttach fill:#2ecc71,stroke:#27ae60,stroke-width:2px,color:#fff
style CFN fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
style RouteTable fill:#f39c12,stroke:#e67e22,stroke-width:2px,color:#fff
style TestServer fill:#e74c3c,stroke:#c0392b,stroke-width:2px,color:#fff
Diagram Note: The Transit Gateway attachment and routing are provisioned once as foundational infrastructure; CloudFormation stacks only manage ephemeral compute resources, achieving clean separation of concerns.
🔐 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 (20 envs/day) | Pros | Cons |
|---|---|---|---|---|
| A: VPC per Environment | High – CloudFormation StackSets + per-VPC TGW attachments | High ($720-1200) • 20 TGW attachments: $720/mo • VPC endpoints (if used): $140-280/mo • Risk of zombie resources |
• Full network isolation • Supports complex compliance scenarios |
• 300+ VPCs/month to manage • Stack deletion failures common • TGW route table bloat • CIDR exhaustion risk |
| B: Shared VPC (Correct) | Low – Single VPC + simple CFN stacks for compute | Low ($50-100) • 1 TGW attachment: $36/mo • Compute costs only • No network resource churn |
• Minimal ops overhead • Instant environment startup • No network state changes • Clean stack deletions |
• Shared IP space (requires CIDR planning) • Security group isolation only • Not suitable for multi-tenant production |
| C: Account per Environment | Very High – AWS Organizations + StackSets + account lifecycle mgmt | Very High ($2000-3000) • 20 accounts × $73/mo (CloudTrail + Config): $1460/mo • TGW attachments: $720/mo • Cross-account networking overhead |
• Ultimate isolation • Independent billing • Supports org-wide policies |
• Account provisioning latency (5-10 min) • 300+ accounts/month to close • Violates “least overhead” requirement • Audit complexity |
| D: EKS + Containers | Very High – Container migration + EKS + TGW | High ($300-500) • EKS control plane: $73/mo • NAT Gateway: $32/mo • ALB: $23/mo • TGW attachment: $36/mo • Worker node overhead |
• Modern orchestration • Container benefits |
• Requires app re-architecture • Doesn’t eliminate TGW setup • EKS learning curve • Overkill for simple test envs |
🔐 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 SAP-C02 exam, when you see “ephemeral workloads” + “minimize operational overhead” + “existing Transit Gateway”, immediately favor shared network infrastructure with workload-level isolation (security groups, IAM). AWS wants you to recognize that not every workload needs VPC-level isolation.
Real World #
In reality, we would likely enhance Option B with:
-
VPC Endpoint for S3/ECR to avoid NAT Gateway costs for container image pulls ($0.045/GB can add up with frequent deployments).
-
CloudFormation Stack Policies to prevent accidental deletion of the shared VPC while allowing test environment stacks to be freely created/destroyed.
-
Tagging Strategy with
EnvironmentandTTLtags to enable automatic cleanup via Lambda (e.g., delete any stack withTTL < current_time). -
Security Group Prefix Lists to centrally manage the on-premises CIDR (10.0.0.0/8) instead of hardcoding it in every CloudFormation template.
-
Consideration for Production Environments: If these were customer-facing production environments (not internal dev/test), we would absolutely use separate VPCs or even separate accounts for blast radius control, despite the operational overhead. The “shared VPC” pattern is appropriate here because:
- Threat model is internal (developers testing code)
- Environments are ephemeral (max lifespan ~2 hours)
- Data classification is non-production
-
Hybrid Alternative: For organizations with stricter isolation requirements, a middle ground is VPC sharing via AWS Resource Access Manager (RAM)—provision one VPC per AWS account, but share subnets across multiple test environments. This maintains account-level billing separation while avoiding Transit Gateway attachment sprawl.