Practice Test #2

Incorrect. AWS DataSync does not support transferring data directly into Amazon FSx for Lustre as described in this option. The explanation's claim that FSx for Lustre exposes an NFS endpoint for DataSync destination use is inaccurate; FSx for Lustre uses the Lustre protocol rather than acting as a generic NFS destination for DataSync. Because the transfer path itself is not valid, this option cannot be selected even though DataSync does preserve POSIX metadata in supported scenarios.

Incorrect. Using rsync to copy files into Amazon S3 converts filesystem data into objects and does not preserve POSIX permissions, ownership, and symbolic links as native filesystem constructs. Once the data is staged in S3 this way, the required metadata fidelity may already be lost before DataSync is used. This makes the option unsuitable for a compliance-sensitive migration that explicitly requires preservation of POSIX attributes and symlinks.

Incorrect. AWS Snowmobile is intended for extremely large migrations, typically in the multi-petabyte range or larger, so it is excessive for a 500 TB workload. The option also introduces Amazon S3 as an intermediate staging layer, which is not ideal when strict preservation of POSIX permissions and symbolic links is required. Snowball Edge is the more appropriate offline transfer service for this data volume and operational scenario.

This option meets the performance requirement because S3 Standard provides immediate access, and transitioning to IA later can reduce some cost. However, it is not the most cost-effective option because all content starts in the most expensive storage class, even though older movies are explicitly lower demand. The question asks to minimize hosting cost based on demand, and this option does not take advantage of lower-cost archival storage for older content.

This option is flawed because it refers to 'standard retrieval' for old movies in S3 Standard-IA, but Standard-IA does not use Glacier-style retrieval tiers or restore operations. While Standard-IA does provide immediate access and could meet the timing requirement, the wording indicates confusion about the service behavior. More importantly, it is not as cost-efficient for very old, low-demand movies as Glacier Flexible Retrieval with expedited retrieval, which is what the question is steering toward.

This option fails the 5-minute requirement because bulk retrieval from S3 Glacier Flexible Retrieval typically takes hours, not minutes. Although Glacier Flexible Retrieval is cost-effective for storage, the selected retrieval tier is too slow for on-demand streaming shortly after purchase. Therefore, it cannot satisfy the stated availability target.

Migrating 15 TB of analytical Parquet data into Amazon RDS PostgreSQL is typically not cost-effective. RDS is optimized for OLTP, not large-scale analytics and full-table scans. You would pay for continuous database instance uptime, storage, backups, and likely need significant tuning (indexes, vacuuming). The migration effort and ongoing operational overhead are high compared to querying in place on S3.

Redshift Spectrum can query data in S3, but it is usually used alongside an Amazon Redshift cluster for data warehousing workloads. For monthly reporting, paying for a provisioned cluster (or managed capacity) can be more expensive than a serverless pay-per-query model. Redshift is a strong choice for frequent, high-concurrency BI and complex warehouse needs, not intermittent ad hoc queries.

Amazon EMR with Spark SQL can query S3 and is excellent for large-scale ETL, machine learning, and complex distributed processing. However, for monthly BI-style SQL queries, EMR is typically less cost-effective due to cluster provisioning, runtime costs, and operational management. Even with transient clusters, it is generally more complex and expensive than Athena for straightforward interactive SQL reporting.

A bucket policy can restrict who can call s3:DeleteObject, but it is not the best primary control for accidental deletion protection because policies can be misconfigured, changed by privileged principals, or may not cover all deletion paths (e.g., version deletions). Also, a policy does not provide recovery if deletion occurs; it only attempts prevention.

Default encryption (SSE-S3, SSE-KMS, or DSSE) protects data at rest by ensuring objects are encrypted when stored in S3. It addresses confidentiality and compliance requirements related to encryption, but it does not prevent deletion or provide a mechanism to recover deleted objects. Therefore it is not a control for accidental deletion protection.

Lifecycle policies automate transitions and expirations. While they can help with cost optimization and retention management, they can also delete objects or noncurrent versions after a set period. That increases the risk of unintended data loss if configured incorrectly. Lifecycle rules are not the primary safeguard against accidental deletion for critical long-term research data.

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.