Complete SAA-C03 Amazon Web Services Materials

Option B: FSx for Lustre is designed for HPC workloads with high IOPS.

Option E: A cluster placement group ensures low-latency networking for HPC analytics workloads.

Option A: Amazon EFS is not optimized for HPC.

Option D: Mountpoint for S3 does not meet high IOPS needs.

The correct answer isAbecause the application must acceptTLS connections from IPv4 clients, provideoutbound internet access, present asingle entry point, and maintain thelowest possible attack surface. Placing the Amazon ECS tasks inprivate subnetsis the key security design decision because it prevents direct inbound access from the internet to the tasks themselves. The public-facing entry point is the load balancer, while outbound internet access for the private tasks is provided through aNAT gatewayin the public subnet.

ANetwork Load Balancer (NLB)is well suited for handlingTLSat Layer 4 and can expose a single public endpoint for client connections. Withawsvpcnetwork mode, each ECS task receives its own elastic network interface, making it straightforward to place tasks securely in private subnets while still registering them as targets behind the load balancer.

Option B is incorrect because anegress-only internet gatewayis forIPv6 outbound traffic only, while the requirement specifically mentionsIPv4 clients. Option C is incorrect because placing ECS tasks inpublic subnetsincreases the attack surface by exposing application infrastructure more directly to the internet. Option D is also incorrect for two reasons: it uses anegress-only internet gateway, which does not satisfy IPv4 outbound needs, and it places tasks inpublic subnets, which violates the goal of minimizing exposure.

AWS security design guidance emphasizes reducing exposure by placing application workloads in private subnets and exposing only the required front-end endpoint. Therefore, a publicNLBwith private ECS tasks and aNAT gatewayis the most secure and appropriate architecture.

Sporadic HTTP 500 errors in an application that depends on DynamoDB often indicate intermittent downstream failures (for example, transient throttling, temporary network issues, request timeouts, or service-side retryable exceptions). The prompt notes that the DynamoDB table is in on-demand mode and other applications use it without problems, which suggests the issue is not a sustained capacity shortfall or a systemic DynamoDB outage. Instead, the web application likely needs to handle occasional retryable failures more gracefully.

Option C is the best practice for improving reliability when calling AWS services: implement exponential backoff with retries. AWS SDKs commonly include retry behavior, but many systems still require tuning (for example, increasing maximum retries, adding jitter, ensuring idempotent operations where required, and retrying only on retryable errors). Exponential backoff reduces the chance of overwhelming a service during brief contention periods and helps the application recover quickly from transient errors without user-visible failures. This approach is also minimally disruptive because it is a configuration and logic improvement rather than an architectural migration.

Option A is not a standard DynamoDB configuration; DynamoDB has item size limits and throughput is managed via on-demand or provisioned capacity, not by “supporting larger write requests.” Option B (Streams) provides a change data capture feed but does not prevent or mitigate request failures; it is for event processing, replication, or auditing. Option D (strongly consistent reads) addresses stale reads, not HTTP 500 errors, and could increase read cost/RCU consumption without solving the root cause.

Therefore, adding exponential backoff and retries is the most appropriate and operationally sound way to reduce sporadic failures without disrupting the application’s architecture or performance.

Business-critical applications often require predictable, low-latency I/O and high durability. Provisioned IOPS SSD (io1 or io2) Amazon EBS volumes are specifically engineered for these workloads.

Option C provides consistent, high-performance storage with guaranteed IOPS and low latency. EBS volumes are network-attached and persist independently of the EC2 instance lifecycle, ensuring durability and data protection. Provisioned IOPS volumes are commonly used for databases, transactional systems, and latency-sensitive applications.

Option A (instance store) offers low latency but is ephemeral and loses data on instance stop or failure. Option B is in-memory caching and not durable storage. Option D is optimized for large, sequential workloads and does not provide consistent low latency.

Therefore, C is the correct choice because it delivers the required performance, durability, and reliability for mission-critical applications.