Practice Test #5

This option uses CloudFront in front of EKS clusters, but CloudFront is not the best fit for selecting the nearest regional backend for a write-heavy dynamic API. Requests would still traverse from the edge to an origin Region, and CloudFront does not provide the same purpose-built global anycast routing model for regional application endpoints that Global Accelerator does. It also adds unnecessary operational complexity by using EKS when the question is focused on latency rather than container orchestration features. Aurora Global Database still leaves the design less compelling than the Global Accelerator pattern in option A.

CloudFront Functions cannot make network calls to external services such as DynamoDB, so they cannot validate a pass against a database or perform an atomic redemption update. They are limited to lightweight request and response manipulation at the edge with very constrained execution capabilities. Because the core requirement is a database-backed validation plus atomic state change, this option is technically incapable of implementing the workflow. Therefore it cannot be the correct answer regardless of DynamoDB global tables being a strong database choice.

Although DynamoDB global tables are a strong fit for multi-Region active-active data and atomic conditional updates, Lambda@Edge is not the right service for implementing this transactional backend pattern. Lambda@Edge is designed for request and response customization around CloudFront, not as a primary globally distributed application runtime for database-driven API writes. The architecture is also less direct and less aligned with AWS best practices for low-latency dynamic API routing than using Global Accelerator with regional application endpoints. As a result, this option is less appropriate than option A for the stated requirement.

Increasing Lambda memory can reduce function runtime, but it does not directly solve the database connection limit or connection storm. Explicitly closing the DB connection after each query is usually counterproductive for Lambda-to-RDS because it increases connection churn (auth/TLS setup) and can raise DB CPU. This option might slightly reduce concurrent duration, but it won’t reliably prevent exhausting 500 connections during bursts.

ElastiCache for Redis is useful when repeated read queries dominate and results can be cached (e.g., course catalog browsing). However, the workload is described as transactional reads and writes for enrollment, and the symptoms include near-max DB connections and high CPU. Caching does not reduce the number of concurrent DB connections created by Lambda, and it does not help write-heavy or strongly consistent transactional paths.

Initializing the DB client outside the handler and reusing connections is a good Lambda optimization, but it only helps within a single warm execution environment. With concurrency spiking to 3,200, Lambda will create many parallel environments, each potentially holding one or more connections, still overwhelming a 500-connection RDS limit. This is a partial mitigation, not a robust solution for burst conditions compared to RDS Proxy.

A trail in the management account that writes to an S3 bucket is not necessarily an organization trail. Without enabling an organization-level trail, CloudTrail will not automatically capture events from all member accounts. Even with multi-Region enabled and S3 encryption/MFA Delete, it fails the requirement to record every API call across all current and future accounts with minimal ongoing effort.

Creating a trail and bucket in each member account can capture API activity per account and can be configured for all Regions with encryption and MFA Delete. However, it has high operational overhead (30+ accounts, new accounts monthly, many Regions) and increases the chance of configuration drift. This contradicts the requirement to minimize ongoing operational effort.

Adding SNS notifications to an external management system introduces extra integration and operational burden and is not required to meet the core logging and retention requirements. Also, a trail in the management account alone does not guarantee coverage of all member accounts unless it is configured as an organization trail. This option is both incomplete and higher-ops than necessary.

Partially relevant but incomplete/misaligned. Aurora logical cross-Region replication (e.g., PostgreSQL logical replication) is more complex and typically higher-latency than Aurora Global Database physical replication. Replacing the web tier with S3 only works for fully static sites; most hackathon platforms need dynamic web/app logic. S3 cross-Region replication helps DR and regional availability but does not provide edge caching like CloudFront, which is key for global p95 latency.

Auto Scaling and multi-Region web/app tiers can help, but adding AWS Direct Connect is not an effective lever for a global internet-facing audience; Direct Connect benefits private connectivity from corporate/on-prem networks to AWS. It won’t reduce latency for end users on the public internet. Also, without a global routing/caching layer (Route 53 LBR/CloudFront) and a multi-Region database read strategy, p95 latency and database bottlenecks remain.

Incorrect for the goal. Migrating from Aurora PostgreSQL to RDS for PostgreSQL generally removes Aurora-specific performance and global features and does not inherently reduce latency. Placing all tiers in private subnets is a security posture choice, not a performance optimization, and it can complicate ingress/egress without improving global response times. This option ignores the need for edge caching, global routing, and cross-Region read scaling.

Incorrect because AWS Server Migration Service rehosts a VM onto Amazon EC2 rather than migrating the database into Amazon RDS for PostgreSQL. The requirement explicitly states that the database must run on RDS after migration, so lifting and shifting the database VM does not satisfy the target-state architecture. Even if SMS could reduce downtime for a VM move, it is the wrong service for a managed PostgreSQL destination.

Incorrect because VM Import/Export is primarily a one-time image import/export mechanism and does not provide continuous replication or an efficient low-downtime migration workflow for an active production application server. It also does not address the challenge of repeatedly synchronizing changes across a 420 TB footprint. For a strict cutover target, a one-time import process is generally too rigid and operationally disruptive.

Incorrect because although AWS SMS can replicate an application VM, it is not the strongest answer in a scenario dominated by extremely large attached storage volumes totaling 420 TB. The initial data movement is the primary bottleneck, and Snowball Edge is better suited than SMS for seeding such a large amount of data into AWS. SMS also does not solve the database modernization requirement, so pairing it with DMS is less optimal than using Snowball for bulk transfer and DMS for the database.