Professional-level AWS certification covering organisational complexity, new solution design, continuous improvement, and workload migration and modernisation, with a worked explanation on every practice question.
Free sample questions
No account needed. Every question has a worked explanation, just like the full bank.
lock_openFree sampleDesign Solutions for Organizational Complexityhard
A multinational runs around 200 VPCs spread across 40 AWS accounts under a single organisation, and the count grows monthly as new product teams onboard. Every VPC must reach a shared services VPC for DNS and patching, and many must also reach each other, with full transitive routing and central control of which routes propagate where. The networking team wants to avoid managing an ever-expanding mesh of point-to-point links. Which design MOST scalably meets these requirements?
- ADeploy an AWS Transit Gateway shared through AWS Resource Access Manager, attach every VPC to it, and use Transit Gateway route tables to control which attachments can route to the shared services VPC and to each other.check_circle Correct
- BCreate a full mesh of VPC peering connections between every pair of VPCs and add the shared services VPC as another peer, relying on the peering links for any VPC to reach any other VPC directly.
- CExpose the shared services through AWS PrivateLink endpoint services and create interface endpoints in every VPC, then add PrivateLink endpoints between product VPCs wherever two teams need to reach each other.
- DDesignate one central VPC as a transit hub, run software routers on EC2 instances inside it, and peer every other VPC to that hub so traffic is forwarded between VPCs through the EC2 routing layer.
Select AWS Transit Gateway as the scalable transitive hub for connecting many VPCs and accounts with centrally controlled routing. Transit Gateway acts as a regional routing hub that every VPC attaches to, giving transitive any-to-any routing without a quadratic mesh of links. Sharing it through Resource Access Manager lets accounts across the organisation attach, and Transit Gateway route tables centrally decide which attachments propagate routes to which, something a peering mesh, PrivateLink endpoints or self-managed EC2 routers cannot do at this scale.
Why A is correct: A Transit Gateway is a hub that provides transitive routing for all attached VPCs and accounts, scales to thousands of attachments, and its route tables centrally govern which VPCs reach the shared services VPC or each other.
Why B is wrong: A peering mesh seems to give any-to-any reachability, but peering is non-transitive and the number of links grows roughly with the square of the VPC count, which becomes unmanageable well before 200 VPCs.
Why C is wrong: PrivateLink cleanly publishes the shared services, but it exposes single services rather than whole VPCs, so building any-to-any product connectivity from endpoints does not provide the general transitive routing the estate needs.
Why D is wrong: EC2 software routers can forward traffic to work around non-transitive peering, but they add instances to patch, scale and make highly available, duplicating a managed capability Transit Gateway already provides.
lock_openFree sampleDesign Solutions for Organizational Complexityhard
A software vendor hosts a payments API behind a Network Load Balancer in its own VPC and account. Dozens of customer accounts, each with their own VPC and some using overlapping private CIDR ranges, must call only this single API over private networking, never reach anything else in the vendor VPC, and onboard without the vendor coordinating IP addressing with them. The vendor also wants no transitive path back into customer networks. Which approach BEST satisfies these constraints?
- AAttach the vendor VPC and every customer VPC to a shared AWS Transit Gateway and use route tables so that customer attachments can route only to the subnet hosting the payments API in the vendor VPC.
- BExpose the payments API as an AWS PrivateLink endpoint service fronted by the Network Load Balancer and let each customer create an interface endpoint to it, so they reach only that service over private connectivity.check_circle Correct
- CCreate VPC peering connections from the vendor VPC to each customer VPC and add specific routes and security group rules so that only the payments API instances are reachable from each peered customer network.
- DPublish the payments API as a Gateway VPC endpoint and have each customer create a gateway endpoint with a route table entry so traffic to the service stays on the AWS private network.
Use AWS PrivateLink to expose one private service across accounts with overlapping CIDRs and no transitive network path. PrivateLink publishes a single service behind a Network Load Balancer as an endpoint service, and consumers reach it through an interface endpoint that maps to a local ENI in their own VPC. Because connectivity is service-level and not IP routing, overlapping CIDR ranges do not matter, only the one service is reachable, and there is no transitive route back into either network, which peering and Transit Gateway cannot guarantee.
Why A is wrong: A Transit Gateway can scope routes per attachment, but it relies on IP routing, so overlapping customer CIDR ranges break it and it exposes a routed path into the vendor VPC rather than a single service.
Why B is correct: PrivateLink publishes the single API as an endpoint service, and each customer interface endpoint reaches only that service with no IP routing between VPCs, so overlapping CIDR ranges are irrelevant and nothing else is exposed.
Why C is wrong: Peering can restrict reachable hosts with routes and security groups, yet peering cannot be established between VPCs with overlapping CIDR ranges and still exposes IP-level reachability into the vendor VPC.
Why D is wrong: Gateway VPC endpoints exist only for Amazon S3 and DynamoDB, so they cannot expose a customer-built payments API and are not a mechanism for sharing a private service across accounts.
lock_openFree sampleDesign Solutions for Organizational Complexityhard
Two teams in the same account each own a VPC in eu-west-1 with non-overlapping CIDR ranges. A reporting service in one VPC must query a database in the other with high, sustained throughput and the lowest possible inter-VPC latency. There are only these two VPCs, no plan to add more, and no requirement for either VPC to route through to any third network. The architect must keep both data-transfer cost and operational overhead to a minimum. Which connectivity option is MOST appropriate?
- AProvision an AWS Transit Gateway in the Region, attach both VPCs to it, and configure its route tables so the reporting service reaches the database through the gateway as a central hub.
- BFront the database with a Network Load Balancer, publish it as an AWS PrivateLink endpoint service, and create an interface endpoint in the reporting VPC for the service to connect through.
- CEstablish a single VPC peering connection between the two VPCs and add routes on each side so the reporting service and the database communicate directly over the AWS backbone.check_circle Correct
- DCreate a Site-to-Site VPN between the two VPCs over the public internet using virtual private gateways so the reporting service tunnels through to the database securely.
Choose VPC peering for a simple, high-throughput, non-transitive link between two VPCs at the lowest cost and overhead. For exactly two VPCs that need a direct, high-throughput path and no transitive routing, VPC peering is the simplest and cheapest option because traffic uses the AWS backbone with no data processing charge, no hourly hub fee and no managed appliance. Transit Gateway and PrivateLink both add cost and operational pieces that only pay off when many VPCs or service-level isolation are involved.
Why A is wrong: A Transit Gateway would connect the two VPCs, but it adds an hourly attachment charge and a per-gigabyte data processing fee, so it is needless cost and overhead when only two VPCs need to talk and no transitivity is required.
Why B is wrong: PrivateLink suits exposing a single service across account boundaries, but here both VPCs are in one account and it adds endpoint and per-gigabyte charges plus a load balancer to manage for a simple two-VPC link.
Why C is correct: VPC peering gives a direct, full-bandwidth path over the AWS backbone with no per-gigabyte processing charge or appliance to run, which is the cheapest and lowest-overhead fit for connecting just two VPCs that need no transitive routing.
Why D is wrong: A Site-to-Site VPN is meant for hybrid or cross-network connectivity, caps throughput per tunnel, and adds encryption overhead and latency, which is the wrong tool for two VPCs already inside the same Region.
Examworthy is not affiliated with or endorsed by Amazon Web Services. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. SAP-C02 and related marks belong to their respective owners.
