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

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.

AWS Elastic Disaster Recovery (AWS DRS) meets the sub-5-minute RPO requirement through continuous, block-level replication of the EC2 instances to a low-cost staging area. For the database, an Amazon RDS cross-Region read replica's asynchronous replication lag is typically within seconds or a few minutes, satisfying the RPO. During a disaster, recovery instances can be launched from DRS and the read replica can be promoted to a standalone, writable instance in minutes. An Amazon Route 53 failover record set can then be updated to redirect traffic. This entire process meets the 15-minute RTO requirement. This solution is the most cost-effective as it avoids running idle compute capacity and uses a low-cost staging area and a single read replica during normal operations.

A backup-and-restore strategy involving daily snapshots has an RPO of up to 24 hours and an RTO of potentially several hours, failing to meet the requirements. A pilot-light or warm-standby approach with a running Multi-AZ RDS instance in the DR region would be significantly more expensive and is not the most cost-effective option. Using CloudEndure Migration is not ideal as the service is being phased out in favor of AWS DRS, and relying on snapshot copies for the database cannot meet both the RPO and RTO.

AWS Global Accelerator lets clients enter the AWS network at the nearest edge location and then routes traffic over AWS's private backbone to the ALB endpoint, reducing internet hops and TCP handshake time without requiring changes to the application code or additional Regional infrastructure. CloudFront can improve some dynamic traffic but is optimized for caching and still requires header configuration; it offers less benefit for purely uncached WebSocket streams. Adding a second Regional ALB with Route 53 latency-based routing breaks the single-Region constraint and introduces data-consistency challenges. Deploying custom reverse-proxy EC2 instances adds operational overhead and does not provide the global, anycast entry points or health-based routing that Global Accelerator offers.

A single Snowball Edge Storage Optimized device provides 210 TB of usable storage capacity-enough to hold the 120-TB dataset on a single appliance. Because the device is loaded locally, the customer avoids sending 120 TB across the 50-Mbps link, a transfer that would otherwise require months. Snowball jobs use 256-bit encryption, and the service offers FIPS 140-2 validated hardware, satisfying the security requirement. The DataSync options rely on the constrained WAN link and would fail to meet the deadline. Using multiple smaller devices would introduce unnecessary operational overhead compared to using a single, appropriately-sized appliance.

AWS Systems Manager Quick Setup can create a single Patch Manager policy that targets every account and Region in an organization. In the wizard the operations team chooses Scan and install, sets a daily installation schedule, and selects a custom patch baseline whose auto-approval delay is set to 0 days for Critical and Important updates. Quick Setup then uses CloudFormation StackSets to deploy a State Manager association that runs AWS-RunPatchBaselineAssociation on each managed node and continually heals configuration drift. Compliance data is aggregated automatically in Patch Manager and no additional agents are required, so day-to-day maintenance is minimal.

The Config-based alternative first detects non-compliance and then runs an Automation document for every instance, which adds rule management, remediation configuration, and periodic evaluations in every account. The Inspector-based proposal only identifies vulnerabilities; it still needs custom EventBridge and Automation logic for patching and introduces an extra paid service. Building and managing StackSets, maintenance windows, and dashboards in every account provides the same technical result but requires significantly more manual coordination and ongoing upkeep. Therefore, the Quick Setup patch policy is the most operationally efficient way to satisfy the 24-hour patching requirement.

AWS DRS on its own implements a pilot-light pattern: it keeps data and conversion resources in a staging area and launches EC2 instances only when you start a recovery job. A warm-standby pattern, by contrast, requires a scaled-down but running copy of the workload that can accept traffic immediately. The correct approach therefore launches the recovery instances once (for example during a drill), keeps them running on cost-optimized instance types behind a load balancer, and relies on Auto Scaling or scripted post-launch actions to resize the fleet to production capacity when failover is declared. The other options either leave all instances powered off (still pilot light), change launch-template settings without keeping servers running, or replace AWS DRS with a backup/restore process that cannot meet the 15-minute RTO.

The correct answer is to deploy the application within an AWS Local Zone in the NYC metropolitan area. AWS Local Zones are a type of infrastructure deployment that places AWS compute, storage, database, and other select services closer to large population, industry, and IT centers. This is the only option that physically places the compute resources within the same metropolitan area as the stock exchange, which is essential for achieving the single-digit millisecond latency required for HFT applications.

• Deploying in the us-east-1 Region, even with a Direct Connect, is incorrect because of the physical distance. The us-east-1 region is in Northern Virginia, and the round-trip network latency to NYC would be too high for this HFT use case.
• Using AWS Global Accelerator is incorrect because it is designed to optimize the network path from global end-users to applications on AWS by routing them over the AWS global network from the nearest edge location. It does not reduce the inherent physical latency between the AWS Region where the application is hosted and a fixed, non-AWS endpoint like a stock exchange.
• Using Amazon Route 53 with Geoproximity routing is incorrect. Route 53 routing policies are used to direct end-user traffic at the DNS level. This service is not suited for optimizing latency for server-to-server communication with a fixed, external data source.

Amazon Route 53 Application Recovery Controller (ARC) provides zonal autoshift for supported resources such as Application Load Balancers. When enabled, AWS automatically shifts traffic away from an impaired AZ and shifts it back when the AZ is healthy again. ARC also requires and orchestrates weekly practice runs that simulate the loss of one AZ for about 30 minutes, providing outcome reports without any customer-written scripts. Therefore, enabling zonal autoshift on the existing ALB meets all three requirements with the least operational overhead.

The other options rely on custom Lambda, Fault Injection Simulator, cron jobs, or Route 53 scripting. These add operational burden and do not provide the built-in automatic practice tests that the requirement specifies.

Registering the security-tooling account as the delegated administrator allows IAM Access Analyzer to be managed centrally for the entire organization. Creating an organization-level external-access analyzer in that account continuously scans all resource-based policies in every member account and produces findings whenever a bucket is made public or shared with an external AWS principal. IAM Access Analyzer automatically publishes a finding event to Amazon EventBridge in less than an hour, so an EventBridge rule that matches the aws.access-analyzer source and targets the existing SNS topic delivers the required near-real-time alert. The Access Analyzer console in the delegated administrator account provides the single place to review current and historical findings.

The other options either require per-account configuration (AWS Config), rely on services that do not specifically detect cross-account bucket policies in near-real time (Amazon Macie, Amazon GuardDuty), or involve additional operational overhead that the requirement seeks to avoid.

The correct answer is that the network ACL (NACL) for the public subnet is missing an outbound rule for ephemeral ports. Security groups are stateful, meaning that if inbound traffic is allowed, the corresponding return traffic is automatically permitted. NACLs, however, are stateless. This means that for every inbound request allowed, a corresponding outbound rule must exist to allow the response traffic back to the source. When a client connects to a server, it opens a random, high-numbered port (an ephemeral port, typically in the range of 1024-65535) to receive the return traffic. The public subnet's NACL must explicitly allow outbound traffic destined for this ephemeral port range to permit the web server's response to reach the client. Without this rule, the server's response packets are dropped at the subnet boundary, causing the client to eventually time out.

• Modifying the security group's outbound rules is incorrect because security groups are stateful; return traffic for an allowed inbound connection is automatically permitted without a specific outbound rule.
• Adding an inbound NACL rule for port 443 is not the solution because the scenario states that SYN packets are already reaching the web servers, indicating that inbound traffic is permitted. The issue lies with the return (outbound) traffic.
• Modifying the NACL for the private subnet is incorrect as the problem described is between the internet clients and the web servers in the public subnet, not between the web and application tiers.

A Standard Step Functions workflow provides exactly-once execution semantics and can run for up to one year, so it can wait several hours for the fraud-scoring response. By using a Task state with the Wait for Callback (.waitForTaskToken) integration pattern, the workflow pauses while the external system holds the task token and resumes only after the vendor calls SendTaskSuccess. This removes the need for custom polling code and preserves a full execution history for audit.

Express workflows are limited to five minutes and do not support the callback pattern, so they cannot wait three hours. Building a solution with EventBridge Scheduler, Lambda, and DynamoDB adds unnecessary custom code and still lacks exactly-once guarantees. The Run-a-Job (.sync) pattern is only for supported AWS services; it cannot invoke an arbitrary third-party HTTPS endpoint, so it will not work for the external API.

The correct approach is to use AWS Cost and Usage Reports (CUR) with Amazon Athena and Amazon QuickSight. This combination provides the most detailed and comprehensive solution for long-term cost analysis in a multi-account environment. CUR provides granular line-item data that can be stored indefinitely in Amazon S3. By integrating CUR with AWS Glue and Amazon Athena, the finance team can perform complex SQL queries directly on the data stored in S3. Amazon QuickSight can then connect to Athena to build interactive dashboards for visualization and reporting, fulfilling all the specified requirements with a serverless, managed architecture.

Using AWS Budgets and Cost Explorer is an incorrect choice because while these tools are useful for high-level monitoring and alerting, they lack the granularity and long-term, ad-hoc query capabilities required. Cost Explorer is limited in its historical data retention and is not designed for the deep, SQL-based analysis that CUR and Athena provide.

Creating a custom solution with AWS Lambda and Amazon RDS is not optimal. This approach represents undifferentiated heavy lifting, requiring significant development and maintenance effort. The serverless pattern of CUR, Athena, and QuickSight is the recommended AWS best practice that directly replaces such custom solutions. Additionally, Detailed Billing Reports are a legacy feature that AWS has replaced with the more comprehensive Cost and Usage Reports.

Using AWS Config is incorrect because it is a service for assessing and auditing resource configurations and compliance, not for analyzing detailed billing and usage data. While it can be used for cost-related governance (e.g., enforcing tags), it is not the primary tool for the type of deep cost analysis required by the finance department.

The correct answer is to use AWS Glue for the ETL jobs. AWS Glue is a fully managed, serverless data integration service that runs ETL jobs on a managed Apache Spark environment. This solution is the most cost-effective because it directly addresses the primary sources of high TCO in the scenario: operational overhead and idle compute time. With Glue, the company only pays for the Data Processing Units (DPUs) consumed while the ETL job is actively running, completely eliminating costs for the 20 hours of daily idle time. AWS also manages all the underlying infrastructure, including provisioning, patching, and scaling, which removes the maintenance burden from the operations team.

• Amazon EMR with Spot Instances: This is a plausible but less optimal solution. While using a transient EMR cluster with Spot Instances would significantly reduce compute costs compared to the current setup, it does not fully eliminate management overhead. The team would still need to configure, launch, and manage the EMR cluster lifecycle. For a pure, scheduled ETL workload, the completely serverless nature of Glue offers a lower overall TCO.
• AWS Batch with Fargate compute environments: This is incorrect because AWS Batch is a general-purpose batch processing service and is not purpose-built for running distributed Apache Spark jobs. Containerizing a Spark application and orchestrating it with AWS Batch would require significant custom engineering and maintenance, increasing complexity and TCO compared to a dedicated managed Spark service.
• Amazon EMR on EC2 with an Instance Savings Plan: This is the least effective option. An Instance Savings Plan provides a discount in exchange for a commitment to a consistent level of compute usage over a 1 or 3-year term. Applying a Savings Plan to a cluster that is idle for 20 hours a day would mean committing to pay for unused resources, which locks in the inefficiency instead of eliminating it.

Moving the workload to Amazon DynamoDB and enabling a global table that spans the three Regions meets every stated requirement. DynamoDB global tables replicate data automatically in a multi-active fashion, so each Region can serve local reads and writes even if another Region is unavailable. On-demand capacity mode eliminates capacity planning and instantly scales to new traffic peaks, while adaptive capacity protects against "hot" partitions without manual tuning. The alternative options all fail to meet one or more of the goals:

• Aurora global databases have a single writable primary Region; secondary Regions (even with write-forwarding) incur cross-Region round-trips, so they cannot guarantee sub-10 ms local writes and become unavailable for writes if the primary fails.
• Using AWS DMS to replicate RDS instances makes secondary databases read-only and still leaves a single write Region and capacity-planning burden.
• ElastiCache for Redis Global Datastore is an in-memory cache, not a durable primary data store; it is limited by node memory size, incurs higher operational management for large persistent datasets, and does not automatically scale storage.

Therefore, migrating to DynamoDB with global tables and on-demand capacity is the only option that fully addresses performance, availability, scalability, and operational requirements.

An auto-adjusting cost budget in AWS Budgets can set its monthly budget amount to the average spend from the previous six months. Adding a notification at 120 percent of that automatically calculated budget and publishing the alert to an SNS topic linked to AWS Chatbot delivers the required Slack message with no recurring code or manual updates. The CloudWatch alarm approach requires a Lambda job to update the static threshold each month, Cost Anomaly Detection does not evaluate spend against a user-defined percentage of historical averages, and the Step Functions/Cost Explorer workflow is far more complex than necessary.

The correct answer is AWS Application Migration Service (AWS MGN). AWS MGN is the primary service recommended for lift-and-shift migrations to AWS. It addresses all the requirements in the scenario. MGN uses a lightweight agent installed on source servers (both physical and virtual) to perform continuous, block-level replication to a staging area in the target AWS account. This continuous replication ensures that the data in AWS is only seconds or minutes behind the on-premises servers, which is critical for achieving a cutover downtime of under 10 minutes. Furthermore, MGN allows for the non-disruptive launch of test instances at any time from the replicated data, enabling thorough testing without impacting the source production servers.

• AWS Server Migration Service (SMS) is an older service being replaced by AWS MGN. It primarily migrates on-premises VMs to Amazon Machine Images (AMIs) and does not support physical servers. Its replication is based on periodic snapshots, leading to a longer cutover window compared to MGN's continuous replication.

• VM Import/Export is a service used to import virtual machine images (like VMDK or VHD files) to create AMIs. It is a manual, offline process that requires significant downtime to export, upload, and convert the image. It does not support continuous replication or live cutovers.

• AWS DataSync is a service for transferring file and object data between on-premises storage (such as NFS or SMB file shares) and AWS storage services like Amazon S3 or Amazon EFS. It does not migrate entire operating systems and applications to create bootable EC2 instances.

The correct answer is to use SSM State Manager associations. State Manager is a configuration management service that automates the process of keeping managed nodes in a defined state. By creating an association, you link managed instances (both EC2 and on-premises) with an SSM document that defines the target configuration. State Manager will apply this configuration on a schedule you define, automatically detecting and remediating any configuration drift, which directly addresses the core requirements of the scenario.

• SSM Run Command is designed for ad-hoc or one-time remote command execution, not for maintaining a consistent state over time. While it can be used for applying configurations, it doesn't have the built-in scheduling and drift-remediation capabilities of State Manager.
• SSM Inventory combined with AWS Config is an excellent solution for detecting and reporting on configuration compliance, but it does not natively enforce the state or perform the remediation itself. Remediation would need to be triggered as a separate action, making it a less direct and less efficient solution for this specific problem.
• SSM Automation is used for orchestrating complex workflows and multi-step tasks, which can include AWS API calls across different services. While a custom automation could be built for this purpose, it is overly complex for declarative state management. State Manager is the purpose-built, more direct, and efficient tool for maintaining a desired state.

A cluster placement group packs EC2 instances close together inside a single Availability Zone on the same high-bisection-bandwidth segment of the AWS network. This placement maximizes per-flow throughput (up to 10 Gbps per TCP flow with enhanced networking) and minimizes internode latency, making it the recommended pattern for tightly coupled HPC or MPI workloads.

A partition placement group distributes instances across partitions and can span multiple AZs, which helps with fault isolation but does not optimize network proximity; traffic between partitions can traverse different racks or even AZs, increasing latency. A rack-level spread placement group intentionally separates instances onto distinct racks and is limited to seven instances per Availability Zone, so it cannot support 128 nodes in a single group. Launching instances without a placement group-even with EFA-offers no placement guarantees; network performance may vary because the nodes could end up on different racks. Therefore, placing all 128 instances in a cluster placement group within one AZ is the most suitable and straightforward choice.

Amazon DynamoDB in on-demand mode delivers single-digit-millisecond latency and can scale to hundreds of thousands of writes per second without capacity planning. Enabling point-in-time recovery lets you export the table to Amazon S3 asynchronously and without consuming read capacity. Analysts can then use Amazon Athena to run serverless SQL directly against the exported objects in S3, isolating analytic scans from the transactional store. The alternative solutions either cannot handle the write throughput, couple analytic queries to the primary database, or require additional clusters and complex ETL processes that add cost and operational burden.

Publishing to a single Amazon SNS standard topic and attaching a filter policy to each subscription offloads all routing logic to the managed service. Each microservice still consumes from its own SQS queue, but it now receives only the event types that match its payload-based filter policy. This removes the custom Lambda router and scales automatically with no additional code or infrastructure.

EventBridge rules (second choice) could also filter messages, but it introduces another managed service and additional cost when SNS alone is sufficient. Creating three separate SNS topics (third choice) forces application changes and duplicates publishes, increasing complexity. Using an SNS FIFO topic with the eventType as the message-group ID (fourth choice) does not restrict delivery to particular subscribers-every subscribed queue still receives all messages unless a filter policy is added, so the router logic would remain necessary.