These questions cover multi-account architecture and advanced design patterns — where SAP-C02 separates itself from the associate exam by requiring you to reason about trade-offs at organisational scale.
Question 1
A financial services company with 30 AWS accounts needs consistent network topology, shared connectivity to on-premises, and guardrails that prevent accounts from creating non-compliant VPC configurations. Which combination of services achieves this?
- A) Replicate a standard CloudFormation template into each account and trust teams to use it
- B) AWS Control Tower with network guardrails and AWS Transit Gateway shared via Resource Access Manager
- C) Create a single shared VPC and use Resource Access Manager to share subnets into all accounts
- D) Deploy a third-party network management tool with API access to all accounts
Answer: B — Control Tower with network guardrails + Transit Gateway via RAM
This is the AWS-recommended multi-account network pattern at scale:
- AWS Control Tower: Provisions accounts with guardrails (Service Control Policies) that prevent non-compliant configurations — e.g., denying VPC creation outside approved CIDRs, preventing internet gateways in production accounts
- Transit Gateway: Acts as the regional network hub for spoke VPCs across all accounts
- Resource Access Manager (RAM): Shares the Transit Gateway from a network account into all spoke accounts, so each account can attach its VPCs without owning the TGW
The separation of concerns:
| Layer | Service | Controls |
|---|---|---|
| Governance | Control Tower / SCPs | What accounts are allowed to do |
| Connectivity | Transit Gateway | How VPCs communicate |
| Sharing | RAM | Cross-account resource access |
A CloudFormation template provides deployment consistency but can't prevent teams from making changes after deployment. A shared VPC limits account isolation.
</details>Question 2
An RDS MySQL database handles 80% read traffic and 20% write traffic. Query latency has increased as the application scales. Which combination of improvements most effectively addresses this?
- A) Migrate to RDS Multi-AZ for better read throughput
- B) Add RDS Read Replicas for the application and an ElastiCache cluster in front of the most frequent queries
- C) Upgrade to a larger RDS instance type
- D) Enable RDS Performance Insights only
Answer: B — Read Replicas + ElastiCache
Each improvement targets a different layer of read scaling:
- Read Replicas: Offload read queries from the primary instance. For an application with 80% reads, directing read traffic to replicas significantly reduces primary instance load. RDS supports up to 5 read replicas per instance (Aurora supports up to 15).
- ElastiCache (Redis or Memcached): Caches the results of the most frequent, expensive queries. A cache hit never hits the database — for repeated identical queries, this is orders of magnitude faster than even a read replica.
Why Multi-AZ doesn't help reads:
Multi-AZ provides high availability by maintaining a synchronous standby replica, but the standby doesn't serve read traffic. It only takes over if the primary fails.
Upgrading the instance type buys headroom but doesn't change the architecture — you'll hit the same ceiling again at the next scale point.
</details>Question 3
A security team needs to manage encryption keys for sensitive S3 data across 10 AWS accounts. The key must be created and rotated by the security team, and any account's access can be revoked immediately. Which design meets these requirements?
- A) Each account creates its own CMK and the security team manages them via cross-account IAM
- B) A CMK in a central security account with a key policy granting cross-account
kms:Decryptandkms:GenerateDataKeyto each workload account - C) Use S3 SSE-S3 (Amazon-managed keys) across all accounts
- D) Use S3 SSE-C and distribute the key material to each account's application team
Answer: B — Centralised CMK in a security account with cross-account key policy
A single CMK in a dedicated security account provides:
- Single point of control: The security team creates, rotates, and manages one key
- Immediate revocation: Removing an account's entry from the key policy instantly blocks all future decryption from that account — existing data remains encrypted and inaccessible
- Auditability: All key usage across all accounts appears in CloudTrail in the security account
The cross-account key policy:
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::WORKLOAD_ACCOUNT_ID:root"},
"Action": ["kms:Decrypt", "kms:GenerateDataKey"],
"Resource": "*"
}
Each workload account then references this key ARN in their S3 bucket encryption configuration.
SSE-S3 uses AWS-managed keys — the security team has no control over rotation or access. SSE-C requires managing raw key material in application code, which is operationally dangerous.
</details>Key Takeaways
- Control Tower (SCPs) + Transit Gateway + RAM = the standard multi-account network governance pattern at scale
- Read Replicas offload queries from primary; ElastiCache eliminates database hits entirely for repeated queries — layer both for maximum impact
- Centralised KMS CMK with cross-account key policies enables one-command revocation and centralised audit across all accounts