Simulado AWS Certified Solutions Architect - Professional (SAP-C02)

A company runs hundreds of EC2 instances across many VPCs attached to a Transit Gateway. The instances make frequent API calls to Amazon S3 and DynamoDB, and currently route this traffic out through NAT gateways to the public S3/DynamoDB endpoints, incurring high NAT gateway data-processing costs and unnecessary internet exposure. They want to keep the traffic on the AWS private network and reduce cost, with minimal per-VPC configuration overhead. Which approach is most appropriate?

1. Replace the NAT gateways with NAT instances to lower the data-processing cost while keeping the same public-endpoint routing to S3 and DynamoDB.
2. Provision a Direct Connect public VIF and route S3 and DynamoDB traffic over it to keep the traffic off the internet.
3. Create gateway VPC endpoints for S3 and DynamoDB in each VPC and update the relevant route tables, removing the S3/DynamoDB traffic from the NAT gateway path. ✓ (correta)
4. Create a single interface VPC endpoint for S3 in one central VPC and route every other VPC's S3 traffic to it through the Transit Gateway.

A financial reporting platform runs a synchronous REST API on Amazon API Gateway integrated with an AWS Lambda function that writes to an Amazon Aurora MySQL cluster. During end-of-month batch periods, clients submit thousands of 'generate statement' requests within a few minutes. The Lambda function frequently times out at the 29-second API Gateway integration limit because statement generation takes 40-120 seconds, and Aurora connections are exhausted by the Lambda concurrency spikes. Clients receive 504 errors and retry, amplifying the load. A solutions architect must improve reliability and remove the bottleneck while keeping the existing client contract that submits a request and later checks for a result. Which change BEST addresses the root causes?

1. Enable provisioned concurrency on the Lambda function to eliminate cold starts and turn on API Gateway throttling at the account level so the burst is smoothed out before reaching the function.
2. Move the generate endpoint behind an Application Load Balancer with the Lambda function as a target so the 29-second integration timeout no longer applies, and enable Aurora read replicas so statement generation reads scale horizontally.
3. Increase the Lambda function timeout to 180 seconds and raise the function's reserved concurrency limit so that all incoming requests are processed in parallel, then enable API Gateway caching on the generate endpoint to absorb the retries.
4. Convert the API to an asynchronous pattern: have API Gateway place the request on an Amazon SQS queue and immediately return a 202 with a job ID, process the queue with a Lambda function whose reserved concurrency is capped below the Aurora connection ceiling, use RDS Proxy to pool connections, and expose a separate status endpoint that reads job state from DynamoDB. ✓ (correta)

A global application currently runs active in us-east-1 with all data in an Amazon Aurora cluster and serves users worldwide through a single Regional endpoint. Leadership now requires an RTO of under 5 minutes and an RPO of seconds for a full Region failure, but wants to avoid the cost and complexity of running a second full active read/write stack continuously. Read latency for international users should also improve. Which disaster-recovery strategy BEST fits these requirements?

1. Build a pilot-light architecture where only the Aurora secondary is replicated and all application servers are kept stopped, starting and scaling them out only after the primary Region fails.
2. Deploy a full active-active multi-Region architecture with Aurora writes accepted in both Regions simultaneously and Route 53 latency-based routing distributing all read and write traffic globally.
3. Implement a warm standby in a second Region: deploy Aurora Global Database with a secondary Region (typical cross-Region replication lag under a second and managed failover in minutes), run a scaled-down but always-on application stack there fronted by the same infrastructure, and use Amazon Route 53 health checks with failover routing to shift traffic. ✓ (correta)
4. Use a backup-and-restore strategy: take Aurora snapshots copied to a second Region every hour and use CloudFormation to recreate the stack on demand when the primary Region fails.