AWS Certified Solutions Architect Professional Practice Test (SAP-C02)

A KMS key policy is the authoritative access-control mechanism for the key, so cross-account permissions should be granted there. For CloudTrail to write SSE-KMS encrypted objects to the bucket it needs kms:GenerateDataKey*; to create or update the trail with SSE-KMS enabled it also needs kms:Decrypt; and it must be able to describe the key. A second statement grants the analysts' IAM role kms:Decrypt so they can read the encrypted logs. Scoping the service principal's access with an aws:SourceArn or kms:EncryptionContext condition limits use of the key to the organization's trails, satisfying least-privilege requirements.

The other options are incorrect:

• Granting only kms:Encrypt or giving each account's root ARN is overly permissive and omits required actions.
• Having member accounts assume a separate role is unsupported for CloudTrail's automatic calls.
• Relying on long-lived KMS grants and kms:Encrypt does not meet the documented requirements and adds operational complexity.

The correct answer provides the most effective and scalable solution by using a combination of AWS Organizations features. A Service Control Policy (SCP) acts as a preventative guardrail, denying any s3:PutObject API call that does not meet the specified encryption requirements before it can be processed. This is more effective than reactive methods and more scalable than managing IAM policies in each account. The KMS key policy in the central SharedServices account must explicitly grant cross-account permissions to the IAM principals (roles) in the member accounts that need to use the key for encryption and decryption. Finally, creating a single organization-wide CloudTrail trail is the standard, most efficient method for centralizing audit logs from all accounts into a designated S3 bucket in the Security account.

The option to use IAM policies in each member account is incorrect because it is not scalable. It requires manual configuration and ongoing management in every account within the organization, increasing operational overhead and the risk of misconfiguration. SCPs provide a centralized enforcement mechanism.

The option to use AWS Config rules and Lambda for remediation is incorrect because it is a reactive, not preventative, approach. Non-compliant objects would be created before being detected and deleted, which may not meet the strict security requirement to deny the action outright. SCPs prevent the creation from happening in the first place.

The option to grant access only to the S3 service principal and use EventBridge is incorrect for two reasons. First, for cross-account SSE-KMS, the calling IAM principal requires permissions in the KMS key policy, not just the S3 service principal. Second, while EventBridge can be used for eventing, AWS CloudTrail is the purpose-built service for comprehensive, centralized API call auditing and logging for security and compliance purposes.

A single 10 Gbps dedicated AWS Direct Connect (DX) connection that supports MACsec meets the performance requirement while keeping traffic off the public internet. Creating one transit virtual interface (VIF) to an AWS Direct Connect gateway and associating that gateway with Regional AWS Transit Gateways allows the same encrypted DX circuit to reach dozens of VPCs in any Region without adding more VIFs or physical links. MACsec provides line-rate encryption on the DX circuit, satisfying the in-transit-encryption mandate without having to overlay IPsec tunnels. Site-to-Site VPN-only solutions ride the public internet, introduce variable latency, and would need at least seven tunnels to reach 8 Gbps, increasing operational complexity. Using private VIFs to every VPC over DX removes internet dependence but does not provide encryption and requires many additional VIFs to scale. VPN CloudHub also depends on internet paths and is limited to 1.25 Gbps per tunnel. Therefore, a MACsec-enabled DX connection with a transit VIF and Direct Connect gateway is the most operationally efficient and cost-effective choice.

The most effective design is to use Amazon Route 53 Resolver endpoints and conditional-forwarding rules:

• Create an inbound endpoint in a shared or hub VPC. This endpoint exposes two or more IP addresses (in different Availability Zones) that on-premises DNS servers forward queries to, allowing on-premises hosts to resolve records stored in Route 53 private hosted zones.

• Create an outbound endpoint in the same VPC and configure Resolver rules (for example, *.corp.internal) that forward VPC-originated queries to the on-premises DNS servers. The outbound endpoint sends the traffic across Direct Connect or the site-to-site VPN link.

Because each endpoint requires at least two IP addresses in different AZs, the solution is highly available by design and fully managed-no EC2-hosted DNS servers need to be deployed or patched.

• Self-managed BIND servers on EC2 can work but introduce operational overhead for scaling, patching, and failure handling, so they do not best satisfy the requirements.

• Deploying only inbound endpoints enables on-premises-to-AWS lookups but provides no path for VPC-originated queries to reach on-premises DNS, so bidirectional resolution is not achieved.

• Creating a private hosted zone for corp.internal plus an outbound endpoint still lacks an inbound endpoint, so on-premises resolvers cannot query AWS records. In addition, the private hosted zone would be redundant because a forwarding rule for the same domain would take precedence and send the queries to the on-premises DNS servers anyway.

A dedicated AWS Direct Connect cross-connect placed in the same colocation facility provides a private, fiber link that bypasses the internet. Terminating a single private virtual interface on a Direct Connect gateway lets you attach the virtual private gateways of up to 20 VPCs-even across multiple AWS accounts and Regions-over that one 10-Gbps circuit, so future VPCs can be added with only configuration changes. The VPN-based design relies on internet transport and therefore cannot guarantee low or consistent latency. Extending a hosted connection from another site adds an additional carrier circuit and extra hops, undermining the latency goal and adding operational complexity. An Outposts rack still relies on a service-link tunnel (public or Direct Connect public VIF) to reach its parent Region and does not provide direct, high-bandwidth connectivity to multiple VPCs; it also introduces unnecessary hardware and cost.

A /20 VPC has 4,096 IPv4 addresses-insufficient for 18 subnets that each need at least 400 usable addresses. The smallest subnet that meets the usable-address target is a /23 (512 total, 507 usable after AWS reserves 5). 18 × 512 = 9,216 addresses, so additional space is needed.

AWS does not allow resizing a VPC's primary CIDR, but you can associate up to five secondary IPv4 CIDR blocks of size /28-/16. Adding a non-overlapping block (for example, 10.2.8.0/18, which supplies 16,384 addresses) immediately expands the address pool without disturbing existing workloads. New /23 public and private subnets can then be carved from the secondary range and distributed across the three AZs.

Changing the primary CIDR is impossible, creating an entirely new VPC requires a full migration, and shrinking each subnet to /25 would leave only 123 usable addresses-well below the requirement. Therefore, adding a sufficiently large secondary CIDR to the existing VPC is the simplest, lowest-risk solution.

The correct answer is to use AWS Transit Gateway. AWS Transit Gateway acts as a cloud router and is specifically designed to simplify network connectivity at scale. By creating a Transit Gateway in each region, attaching all the VPCs in that region, and then peering the Transit Gateways, you create a global network that allows for transitive routing. This means a resource in any connected network (VPC or on-premises) can communicate with a resource in any other connected network through the Transit Gateway hub-and-spoke model. Connecting the on-premises network via a Direct Connect Gateway to a Transit Gateway integrates the hybrid connectivity seamlessly into this architecture. This solution is scalable to thousands of VPCs, centralizes network management, and reduces the operational overhead of managing complex peering relationships.

• Creating a full mesh of VPC peering connections is incorrect because it is not scalable. The number of peering connections grows quadratically with the number of VPCs, leading to significant management complexity and being limited to 125 peers per VPC. This approach is not centrally managed.

• Using a designated 'transit hub' VPC with routing instances is an outdated pattern known as a 'Transit VPC'. While it can provide transitive routing, it relies on self-managed EC2 instances, which introduces bottlenecks, single points of failure, and high operational overhead for maintenance and scaling compared to the fully managed Transit Gateway service.

• Using a Direct Connect Gateway associated with a Virtual Private Gateway (VGW) in each VPC is incorrect. Although a Direct Connect Gateway connects an on-premises site to multiple VPCs, it does not support transitive routing between those VPCs. Traffic cannot flow from one VPC to another through the Direct Connect Gateway, failing a key requirement.

The correct solution is to use a combination of AWS Transit Gateway (TGW) and Gateway Load Balancer (GWLB). The TGW acts as a central hub, which is necessary because the Application VPCs have overlapping CIDRs, making VPC Peering impossible. TGW route tables can be configured to direct all inter-VPC traffic to the Inspection VPC. Inside the Inspection VPC, a Gateway Load Balancer is used to deploy, scale, and manage the fleet of NGFW appliances transparently. It operates at Layer 3 and uses GENEVE encapsulation to preserve the original source and destination of the traffic. Routing is configured to send traffic from the TGW to the GWLB Endpoints, through the appliances for inspection, and then back to the TGW to be forwarded to its final destination.

Using VPC Peering is incorrect because it does not support connections between VPCs with overlapping CIDR blocks. It also does not scale well for this hub-and-spoke inspection model, as it would require a complex mesh of connections. Using a Network Load Balancer (NLB) instead of a GWLB is suboptimal because NLBs are designed for Layer 4 load balancing and are not transparent. This would require Source NAT (SNAT) on the firewall appliances, which complicates routing and causes loss of the original source IP address. AWS PrivateLink is designed to provide private, unidirectional access to specific services and is not the appropriate tool for transparently inspecting all network traffic between VPCs.

The correct answer is to use VPC Reachability Analyzer. This tool is specifically designed to perform static analysis of network paths between a source and a destination. It checks the configurations of route tables, security groups, network ACLs, and Transit Gateways without sending any live packets. This allows it to quickly identify the specific component that is blocking connectivity, making it the most efficient first step for this scenario.

• Using VPC Flow Logs and Amazon Athena is a valid troubleshooting method, but it is less efficient. It requires enabling logs, waiting for traffic to be captured, and then performing complex queries on potentially large datasets to find the problem. This is more time-consuming than using the purpose-built Reachability Analyzer.
• The Route Analyzer feature in Transit Gateway Network Manager is not the best tool for this task because it only analyzes routes within the Transit Gateway route tables. It does not analyze VPC route tables, security group rules, or network ACLs, which are common sources of connectivity problems.
• Configuring Route 53 Resolver Query Logging would be appropriate if the problem were related to DNS name resolution. However, the scenario describes a failure to connect to a specific IP address, which points to a network path issue, not a DNS issue.

Security groups operate at the instance level and are stateful, so response traffic is automatically allowed without extra rules. Referencing the ALB's security-group ID in the application-server security group limits inbound traffic to only the ALB while blocking all other sources in the VPC. Changes to either security group automatically apply to any new load-balancer nodes or Auto Scaling instances, eliminating manual updates as the environment grows.
Network ACLs are stateless and would require matching inbound and outbound rules for the return (ephemeral) ports, creating ongoing maintenance overhead. The default network ACL already allows all traffic, so leaving it unchanged keeps administration simple and still enforces least-privilege access through the security groups.
Using a third-party firewall or opening the application-server security group to 0.0.0.0/0 either adds unnecessary complexity or violates the requirement to restrict access solely to the ALB.

AWS Control Tower sets up a landing-zone architecture that automatically creates a dedicated log-archive account, enables an organization-wide CloudTrail, and provides preventive guardrails such as CT.EC2.PV.2 and CT.S3.PV.6 to block unencrypted EBS volumes and S3 uploads. Account Factory, integrated with IAM Identity Center, gives developers governed self-service account provisioning. An enforced AWS Organizations tag policy applied at the OU level standardizes the CostCenter and Environment tags across resources, and consolidated billing combined with activated cost-allocation tags supplies the required per-business-unit cost view. The alternative options either rely on manual or ticket-based account creation, lack enforced encryption or tagging controls, or spread logging and cost management across multiple locations, resulting in higher operational overhead and incomplete compliance.

The correct solution is to use Amazon VPC IP Address Manager (IPAM) integrated with AWS Organizations. IPAM allows for central planning, tracking, and monitoring of IP address space across multiple accounts and Regions. By creating a top-level pool in IPAM with the company's private IP space, the architect can then create smaller, delegated pools for different business units or environments, preventing overlaps. IPAM's rule-based allocation can enforce that new VPCs are created with non-overlapping CIDRs and meet compliance requirements, such as mandatory tagging. Furthermore, by using the Bring Your Own IP (BYOIP) feature, the company can import its public /24 block into IPAM's public scope, allowing them to manage and allocate their own public IP addresses to resources like NAT Gateways and Load Balancers centrally.

• Using a spreadsheet is a manual, error-prone process that does not scale for hundreds of VPCs and is contrary to the automation requirement.

• While secondary CIDR blocks allow a VPC to be expanded, they do not provide a centralized, proactive mechanism for managing IP allocation across an entire organization. This approach is reactive and does not prevent initial CIDR overlaps between VPCs.

• Using the 100.64.0.0/10 range is incorrect for general VPC workloads. This range is reserved by RFC 6598 for Carrier-Grade NAT (CGN) and should not be used for private enterprise networking, although it is supported for specific use cases like Amazon EKS custom networking. Using it for general VPCs could lead to unpredictable connectivity issues.

The optimal solution is to deploy an AWS Transit Gateway in each region and use inter-region peering to connect them. A central inspection VPC should be created in each region, containing a Gateway Load Balancer (GWLB) with a fleet of security appliances behind it. Transit Gateway route tables will be configured to direct all inter-VPC and egress traffic to the GWLB endpoint in the inspection VPC. This design creates a scalable, manageable hub-and-spoke network. The Transit Gateway acts as a cloud router, simplifying connectivity and eliminating the need for complex VPC peering meshes. Using a Gateway Load Balancer is the correct approach for deploying, scaling, and managing third-party virtual security appliances transparently within the network traffic path. This architecture centralizes traffic inspection without requiring security appliances to be deployed in each spoke VPC.

A full-mesh VPC peering configuration is incorrect because it is not scalable. Managing peering connections for hundreds of VPCs (which would require thousands of connections) is operationally complex and error-prone. Furthermore, VPC peering does not support transitive routing, so it cannot be used to route traffic from a spoke VPC through a central VPC to an on-premises network.

The legacy 'Transit VPC' model using EC2-based VPN appliances is also incorrect. While it provides transitive routing, it is a self-managed solution that has been largely superseded by the fully managed, more scalable, and highly available AWS Transit Gateway service.

Using AWS PrivateLink is not suitable for this scenario. PrivateLink is designed to provide secure, private connectivity from a VPC to specific services, not for routing all network traffic. It cannot be used to inspect general inter-VPC or egress traffic.

AWS Global Accelerator provides two static anycast IP addresses and continuously probes the health of each regional endpoint. If the ALB in us-east-1 becomes unhealthy, Global Accelerator removes it from service and starts directing new connections to the healthy ALB in us-west-2 in approximately 30 seconds, eliminating dependence on DNS TTL expiration. Aurora Global Database replicates changes across Regions with typical latency below 1 second and, with the managed cross-Region failover feature, can promote the secondary cluster to the writer role in under a minute. Together, these services meet the RPO of less than 1 second and an RTO of under 60 seconds, satisfying the business continuity targets while requiring only minimal configuration.

The weighted Route 53 design still depends on DNS caching and manual weight adjustments, so traffic might continue to flow to an unhealthy Region for longer than the RTO. AWS Elastic Disaster Recovery must boot new instances, which takes minutes and breaches the RTO. Re-architecting around DynamoDB global tables would meet cross-Region data durability but would not preserve the existing Aurora workload and would add significant development and operational effort.

Creating a multi-Region customer managed AWS KMS key in the security account satisfies every control:

• Multi-Region keys are generated, stored, and used only inside AWS-managed FIPS 140-3 HSMs, so key material never leaves KMS in plaintext.
• Enabling automatic rotation on the primary key rotates the key material every 365 days and KMS retains older key versions indefinitely, allowing decryption of data encrypted up to (and beyond) the required 7-year window.
• Replicating the key to us-west-2 produces a replica with an identical key ID and key material. Applications can decrypt data in either Region with no code changes, meeting the 15-minute DR objective without manual replication scripts.
• A single key set (one primary and one replica) is managed centrally. Only the key policy needs to grant cryptographic permissions to workload-account roles, so administrators avoid maintaining separate keys per account or Region.

The other options introduce extra keys, manual key movement, or expose plaintext key material-failing one or more stated requirements.