Practice Test #2

Incorrect. You cannot convert an existing KMS key into a multi-Region key. Also, AWS managed keys are not multi-Region keys you can replicate across Regions in the way required here, and you cannot “reuse” an AWS managed key across Regions. The correct approach is to create a new multi-Region customer managed key and replicate it.

Incorrect. Manually creating separate secrets and copying values increases operational overhead and introduces drift risk (values can diverge across Regions). It also complicates rotation and auditing. The requirement explicitly asks for least operational overhead, which is best met by Secrets Manager replication rather than manual duplication.

Incorrect. While you do need to deploy Lambda and API Gateway in each Region for active-active, the option claims there is a “multi-Region option” for the existing API to attach each Region’s Lambda as the backend. API Gateway does not provide a single multi-Region API deployment that fans out to regional Lambdas; you deploy separate regional APIs and use DNS/global routing to distribute traffic.

EKS on EC2 fails the “least operational overhead” requirement because you must manage EC2 node groups, scaling, patching, and Kubernetes lifecycle. Also, the statement about using an EKS CLI “--tags” to tag a pod is misleading for cost allocation: Kubernetes pod labels are not AWS billing tags. Even if you tag underlying AWS resources, mapping per-pod costs is nontrivial and not aligned with the requirement for tagging running units per category.

EKS on Fargate reduces node management, but still carries Kubernetes operational overhead (cluster operations, add-ons, RBAC, networking policies, upgrades). More importantly, tagging a Kubernetes pod via AWS tag-resource is not a standard/clean mechanism for cost allocation; cost allocation relies on AWS resource tags on billable resources. EKS/Fargate cost attribution is typically at namespace/label via Kubecost or CUR analysis, not simple per-pod AWS tags.

ECS on EC2 supports task tagging with --tags, but it does not meet the requirement to “scale resources cost-effectively purely based on the number of running containers with the least possible operational overhead.” You would need to manage EC2 capacity (Auto Scaling groups, capacity providers, bin packing, scaling policies) to handle bursts up to 600 concurrent containers (12x50). That adds operational burden and risks capacity shortfalls.

Incorrect. Application Load Balancers do not support assigning Elastic IP addresses or otherwise guaranteeing static IPs. ALB nodes scale and their underlying IP addresses can change over time. For allow-listing by destination IP, you need a service that supports static IPs (typically NLB with EIPs) or another fixed egress/ingress mechanism. Therefore, you cannot meet the firewall allow list requirement by “reconfiguring” the ALB.

Incorrect. While an NLB can provide static IPs, it operates at Layer 4 and cannot perform HTTP path-based routing (e.g., /api, /images, /admin). Migrating ALB target groups directly to an NLB would remove L7 routing and TLS termination behavior as described. To keep routing and TLS termination on the ALB, the ALB must remain in the data path.

Incorrect. Gateway Load Balancer is designed to deploy and scale third-party virtual appliances (firewalls/IDS/IPS) using GENEVE tunneling and is not intended as a client-facing load balancer for web applications. It does not provide the required pattern of “clients connect to GWLB, GWLB targets ALB for HTTPS and path routing.” Using GWLB here is an architectural mismatch and would not meet the stated requirements.

S3 + API Gateway + SQS are aligned, but ECS is not “serverless-first” in the exam sense because you still manage task definitions, scaling, capacity (Fargate would be closer), and operational overhead. Also, “SQS long polling to retain failed checkouts” is incorrect: long polling reduces empty receives; it does not provide failure retention. Proper failure handling is via DLQ and retention/redrive policies.

Elastic Beanstalk introduces server/instance management (even if simplified), conflicting with eliminating server management. Amazon MQ is typically chosen for JMS/AMQP compatibility and is not the simplest low-ops choice for high-throughput burst buffering compared to SQS. Storing failed events in S3 Glacier Deep Archive meets retention but is poor for “later replay” due to retrieval delays and operational complexity versus SQS DLQ redrive.

Lightsail and EKS are not serverless-first and require server/cluster management, which violates the cost/ops requirement. SES is not an order queueing service and does not provide the semantics needed for reliable event buffering and replay. OpenSearch is not an appropriate mechanism for retaining failed checkout events for replay; it’s a search/analytics engine, not a durable failure queue with redrive.

Incorrect. Amazon FSx for Lustre is a high-performance parallel file system, not a POSIX-compliant NFSv4 shared file system like Amazon EFS. More importantly for this scenario, ECS tasks on AWS Fargate support Amazon EFS integration for persistent shared storage, not FSx for Lustre mounts in the task definition. The requirement explicitly calls for a shared NFSv4 mount across tasks in multiple AZs with IAM-based access control and no server management, which aligns directly with EFS rather than FSx for Lustre. Even though FSx for Lustre is managed and POSIX-compliant, it does not satisfy the specific NFSv4 and Fargate integration requirements in this question.

Incorrect. While EFS is the right shared storage, using ECS with the EC2 launch type requires provisioning and managing EC2 container instances and an Auto Scaling group (capacity management, patching, AMIs, scaling policies). That violates the explicit requirement: “must not require provisioning or managing any servers or cluster infrastructure.” Fargate is the intended compute model when the question emphasizes no server management.

Incorrect. EBS Multi-Attach is block storage, not a shared NFS file system, and it has significant limitations (only certain volume types, same AZ attachment constraints, and application-level coordination requirements). It does not provide an NFSv4 POSIX shared mount across two Availability Zones. Additionally, the EC2 launch type with an ASG again violates the “no servers/cluster infrastructure management” requirement.

Incorrect. Attaching additional ENIs is not a typical or reliable way to improve MPI performance, and “multiples of four” is not an HPC scaling rule. MPI bottlenecks are usually about latency/message rate and network fabric behavior, where EFA is the purpose-built solution. More ENIs can add complexity and may not increase effective bandwidth for MPI traffic.

Incorrect. Distributing a tightly coupled MPI cluster across multiple AZs generally harms performance due to increased latency, jitter, and reduced effective bandwidth between nodes. While multi-AZ improves resiliency, the question prioritizes maximizing performance and time-to-solution. For HPC, resiliency is often handled via checkpointing rather than cross-AZ placement.

Incorrect. A single instance hosting a RAID 0 EBS set as a shared store becomes a massive bottleneck and single point of failure at 1,200 nodes. It cannot provide the parallel metadata and throughput characteristics required for millions of shared files. This design also undermines scalability and availability compared to purpose-built parallel file systems.

Creating a new VPC and TGW attachment per sandbox adds significant operational overhead and increases the chance of transient failures (attachment creation, TGW route propagation/updates, quota limits). TGW attachments are relatively heavyweight compared to launching an EC2 instance. For 30 sandboxes/day, this approach is slow, complex, and harder to troubleshoot, even if automated with StackSets.

Using AWS Organizations and creating a new account per sandbox is operationally excessive and slow (account vending, guardrails, SCPs, baseline setup). It also introduces additional TGW attachment and routing work per account/VPC. This pattern is appropriate for strong isolation boundaries for long-lived environments, not for <3-hour sandboxes created up to 30 times per day.

EKS in a new VPC plus TGW attachment is a major increase in complexity and operational overhead (cluster lifecycle, node groups/Fargate, networking, upgrades). The workload is explicitly a single EC2 instance managed by an Auto Scaling group, so containerization and Kubernetes orchestration are unnecessary. This option modernizes the stack without addressing the core requirement of minimal ops and rapid ephemeral provisioning.

AWS DMS can perform ongoing replication, but it adds operational overhead (replication instances, task management, monitoring, schema evolution handling) and may not reliably meet an RPO ≤ 1 second under sustained 600 writes/sec. DMS is primarily a migration/replication tool, not the preferred mechanism for stringent Aurora DR objectives compared to Aurora Global Database.

AWS DataSync is designed for file/object transfer (NFS/SMB/EFS/FSx/S3) and is not a database replication service. Copying database files to S3 and restoring during failure is effectively a backup/restore workflow, which will not achieve RPO ≤ 1 second and is unlikely to meet RTO ≤ 15 minutes due to restore time, consistency concerns, and operational complexity.

Automated snapshots every 5 minutes with cross-Region copy provide a backup strategy, not near-real-time DR. The best-case RPO is roughly the snapshot interval (minutes, not ≤ 1 second), and RTO includes snapshot copy lag, restore time, and application cutover—often exceeding 15 minutes. This option is suitable for less stringent DR requirements, not near-zero RPO.

Kinesis Data Firehose to Redshift is a common analytics pipeline, but it conflicts with two requirements. Redshift is a schema-based data warehouse, so evolving attributes typically require schema changes. Firehose also buffers data before delivery (by size/time), which can introduce latency that may exceed a strict <3 second end-to-end target, especially under variable load.

Amazon MSK can handle streaming, but streaming directly into Aurora MySQL is not a natural fit for high-rate telemetry without additional consumers/connectors and careful batching. Aurora MySQL is relational and schema-based, which contradicts the requirement for evolving attributes without migrations. Also, achieving consistent sub-3-second end-to-end latency into Aurora at this write rate can be challenging and costly.

Kinesis Data Firehose does not natively deliver to Amazon Keyspaces as a direct destination. Even if an intermediate step were added, Firehose buffering can add latency that risks missing the <3 second requirement. Keyspaces is schema-based in the Cassandra sense (tables/columns are defined), so while it is flexible, it is not “schema-less” in the same way as DynamoDB for evolving JSON attributes.