SAP-C02 Practice Question 52: IP Address Governance
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 6 · question 2 of 10
A group operates about 400 VPCs across 120 accounts in five Regions, all attached to transit gateways. CIDR blocks have been handed out from a spreadsheet maintained by two network engineers.
Two problems came to a head last quarter. An acquired business unit was onboarded with VPC ranges that overlapped an existing production VPC, which was discovered only when the transit gateway attachment failed to route. And a Region ran out of allocatable space with no warning, because nobody could say which of the recorded ranges were actually in use.
The target state is that a team creating a VPC receives a CIDR automatically from the pool for its Region and environment rather than asking for one, that an allocation which would overlap is impossible rather than merely discouraged, that the group can see utilization of every pool and be alerted before exhaustion, and that ranges already deployed across the 120 accounts are discovered rather than re-entered by hand.
What should the solutions architect implement?
Show answer and explanation
Answer:
IPAM is the AWS feature for planning, tracking, and monitoring IP addresses across an estate this size. Each requirement in the stem maps to something AWS lists as an IPAM capability: organizing address space into routing and security domains (the pool hierarchy by Region and environment), automatically allocating CIDRs to VPCs using business rules (so a team creating a VPC draws from a pool instead of asking an engineer), monitoring the space in use and the resources using it against those rules, and viewing the history of IP address assignments across the organization. Because allocations come from a pool that tracks what is already assigned, an overlapping allocation is prevented at creation time instead of being reported afterwards. Integrating IPAM with AWS Organizations is what lets it monitor and discover existing VPC CIDRs across all 120 accounts and five Regions, so nothing has to be re-entered, and pool utilization metrics give the advance warning that was missing before the Region filled up.
Option A is detective and depends on the very manual record-keeping that failed. A tag records what someone typed, not what exists, and a Config rule reports the overlap after both VPCs are already deployed.
Option C rebuilds a small part of IPAM, a reservation ledger, and still relies on engineers calling it before creating a VPC. It provides no discovery of what already exists and no utilization monitoring.
Option D is a different architecture, not an address management solution. Consolidating into shared VPCs is a legitimate pattern but does not reconcile the overlapping ranges already in place, does not suit five Regions and 120 accounts wholesale, and leaves the group with no visibility into address consumption.
Reference: What is IPAM?