Practice Test #2

Using Spot Instances exclusively is the lowest-cost compute option, but it cannot meet the stated reliability requirement. Spot capacity can be interrupted at any time and may be unavailable during demand surges (such as promotional events). For a fraud detection system with “zero tolerance for downtime,” relying solely on Spot introduces unacceptable risk of processing gaps and growing SQS backlog.

Using Reserved Instances exclusively for maximum capacity provides stable availability and predictable cost, but it is not cost-effective. You would pay for peak/probable promotional-event capacity 24/7 even though normal off-peak volume is much lower. This leads to significant overprovisioning and wasted spend, violating cost-optimization goals for a workload with large variability.

Reserved Instances for baseline plus Spot for spikes is a common cost-optimization pattern, but it conflicts with the requirement of zero tolerance for downtime. During promotional spikes, Spot interruptions or lack of Spot capacity could prevent scaling to required throughput, causing delayed or missed fraud checks. This option is only appropriate if the workload can tolerate interruptions and backlog delays.

Incorrect. You cannot reliably attach an IAM policy to the root user (root is not an IAM principal you manage like a user/role), and even if you deny actions via IAM for admins, a team with administrative access could remove or alter those IAM policies. IAM is not a strong governance boundary for preventing privileged users within the same account from changing mandatory controls.

Partially helpful but insufficient. AWS Config can be deployed organization-wide from the management account for centralized setup and aggregation, which is good for compliance. However, organization-wide deployment alone does not inherently guarantee that administrators in member accounts cannot stop or modify Config components unless additional preventive controls (like SCP denies) are in place.

Incorrect. Service-linked roles are managed by AWS services and are not designed as a permission boundary to restrict who can change the service configuration. Policy conditions on a service-linked role do not prevent other principals (like account admins) from calling AWS Config APIs to stop recorders or change delivery channels. Governance requirements across accounts are better met with SCPs.

Amazon EFS provides a managed NFS file system with concurrent access and POSIX semantics, which can work for many shared file use cases. However, the requirement for sub-millisecond access latency and very high parallel throughput across 300+ EC2 instances for distributed ML training strongly favors a parallel file system like Lustre. EFS performance modes help, but it is not typically the best match for extreme HPC-style training performance requirements.

Amazon S3 is object storage, not a POSIX file system. Using AWS CLI to “mount” or treat S3 like a shared file system is not appropriate for concurrent read/write file semantics required by distributed training. It can introduce consistency/rename/locking limitations and higher latencies than required. S3 is excellent for durable storage of datasets and artifacts, but not as the primary low-latency shared training file system.

AWS Resource Access Manager (RAM) can share resources across accounts, but it does not transform S3 into a low-latency shared POSIX file system. Even if all instances can access the same S3 bucket, S3 remains object storage with different access semantics than a shared file system and will not meet sub-millisecond latency requirements for distributed training with concurrent read/write to the same files.

AWS Data Pipeline is a legacy orchestration service primarily for scheduled/batch data movement, not high-volume real-time ingestion from hundreds of producers. While S3 + EMR can process large datasets, this option does not address reliable, scalable streaming ingestion and continuous delivery. It also increases operational overhead compared to Kinesis-managed ingestion and delivery services for near-real-time pipelines.

An Auto Scaling EC2 fleet can be engineered to ingest and process events, but it requires building and operating the ingestion layer (load balancing, checkpointing, retries, backpressure, ordering, and durability). This is higher operational risk for 25 TB/day and real-time requirements. Also, the flow described is unclear (processing before durable landing) and is less aligned with managed streaming best practices.

CloudFront is designed for caching and delivering content to viewers, not collecting or buffering user behavior analytics events. Triggering Lambda on S3 object creation is event-driven batch processing and can become inefficient or constrained at very high daily volumes (object explosion, concurrency, and small-file problems). This option does not provide a robust real-time ingestion and transmission mechanism.

Amazon ECS is not Kubernetes, so the company would need to convert Kubernetes manifests into ECS task definitions and services. That would likely require changes to deployment tooling and CI/CD processes, which directly conflicts with the requirement to avoid pipeline modifications. Running PostgreSQL on EC2 also creates unnecessary operational overhead for patching, backups, scaling, and high availability. This option fails both the compatibility and management-overhead goals.

Using AWS Fargate with Amazon ECS reduces compute management overhead, and Amazon RDS for PostgreSQL is a good managed database choice. However, ECS still does not support direct reuse of existing Kubernetes manifests, so the migration would require replatforming the orchestration layer and likely adjusting the CI/CD pipeline. That makes it a poor fit for a fast migration with no application or pipeline changes. The compute model is attractive operationally, but the orchestration mismatch is the deciding issue.

Amazon EKS preserves Kubernetes compatibility, and Aurora PostgreSQL-Compatible is a valid managed PostgreSQL-compatible database option. However, EKS on Fargate is not always the best lift-and-shift target for existing Kubernetes workloads because some workloads depend on capabilities or daemon patterns that are better supported on EC2-backed nodes, making migration riskier under a tight deadline. The question prioritizes completing the migration quickly without changes to the application or pipeline, and EKS with EC2 worker nodes is the more universally compatible Kubernetes landing zone. Aurora is also not required by the prompt, which asks for PostgreSQL compatibility rather than a database engine change for optimization.