Practice Test #9

Moving videos/materials to S3 is directionally good for durability and scale, but “mounted on every EC2 instance” is a red flag. S3 is object storage accessed via API/SDK, not a native shared POSIX file system mount for typical exam scenarios. The more correct shared-file replacement for EBS in an EC2 Auto Scaling architecture is Amazon EFS, or use CloudFront+S3 without mounting.

Exporting an NFS share from the primary EC2 instance and mounting it on others introduces a major single point of failure and a scaling bottleneck (network, disk, instance limits). If the primary instance fails or is overloaded, all instances lose access to course materials. This does not meet the high availability and resilience requirements and is not an AWS managed best practice.

ALB + ASG with a minimum of two instances is good for high availability and scaling, but AWS Global Accelerator primarily optimizes network path and provides static anycast IPs; it does not cache content. For a workload dominated by repeated access to videos/materials, caching is a key performance lever. Global Accelerator can help, but CloudFront is typically the more appropriate service here.

Deploying a NAT gateway per Availability Zone is an HA best practice and can reduce cross-AZ data transfer charges caused by routing to a NAT in another AZ. However, it does not eliminate Regional data transfer charges for S3 access in the most cost-effective way because all S3 traffic still incurs NAT gateway data processing charges, and you add multiple NAT hourly charges. It improves architecture but is usually more expensive than an S3 gateway endpoint.

A NAT instance might reduce hourly NAT cost in some cases, but it introduces significant operational burden (patching, scaling, failover) and can become a throughput bottleneck for 500 GB/day. It also does not inherently eliminate Regional data transfer charges; cross-AZ routing can still occur, and traffic still traverses a NAT device rather than using the optimized private path to S3. This is rarely the best answer for cost and reliability on exams.

EC2 Dedicated Hosts address licensing, compliance, and host-level isolation requirements, not VPC egress data transfer costs. Moving to Dedicated Hosts will not change how instances reach S3 (they would still use NAT or an endpoint) and will significantly increase compute costs. This option is unrelated to the networking cost driver described and is not a cost-optimized solution for S3 data transfer charges.

Incorrect. Running an SFTP server on Amazon EC2 creates unnecessary operational overhead because the organization would need to manage patching, scaling, availability, and security of the server. Storing newly arrived images in S3 Glacier Deep Archive is also incompatible with the requirement to process images as soon as they arrive because retrieval from that storage class is designed for archival use and has very high latency. In addition, invoking processing nightly directly conflicts with the near-real-time processing requirement.

Incorrect. This option also relies on a self-managed EC2-based SFTP server, which is less operationally efficient than AWS Transfer Family. Using an EBS volume as the landing area ties the data to an instance and does not provide the simple event-driven object-ingestion pattern that S3 offers. Most importantly, the images are processed nightly rather than on arrival, so the design fails the core business requirement.

Incorrect. AWS Transfer Family supports Amazon S3 or Amazon EFS as storage backends, not Amazon EBS, so this architecture is not valid as written. The option also mentions using an S3 event notification even though the files are supposedly stored on EBS, which is internally inconsistent. Although AWS Batch would be a reasonable compute choice for 4–10 minute jobs, the storage and eventing design in this option makes it incorrect.

Not the best answer. Moving processed files to another bucket/prefix can prevent reprocessing, but it introduces operational overhead (copy/delete, failure handling, permissions), additional S3 request costs, and potential governance/lineage complications. Glue provides a native incremental mechanism (job bookmarks) that is simpler and purpose-built for this requirement.

Incorrect. Setting the job to 1 DPU only reduces compute capacity; it does not change the input scope. The job would still read the same 500 GB of data and likely run even longer, potentially increasing cost due to extended runtime and risking missed reporting SLAs.

Incorrect. AWS Glue DataBrew recipes can clean and deduplicate records, but they do not prevent Glue from scanning and reading previously processed S3 objects. The problem is file-level reprocessing (re-reading 30 days of manifests), not duplicate rows within the new daily data.

AWS DataSync is useful for transferring data between on-premises NFS storage and AWS services, but it is not a storage extension solution. It does not provide a persistent hybrid file interface with local caching for active files, so it would not preserve the low-latency access pattern required for newly created datasets. The institute would also need to manage separate storage locations and movement logic, which adds operational complexity. This makes DataSync unsuitable as the primary answer for transparent capacity expansion with lifecycle-based storage management.

Amazon FSx for Lustre is designed for high-performance file processing workloads, especially analytics and HPC use cases, but that is not the main requirement here. The question focuses on extending an existing on-premises NFS environment, preserving user access patterns, and automating archival of aging data. FSx for Lustre does not function as a simple hybrid extension of the on-premises file server in the same way that S3 File Gateway does. It also does not directly solve the lifecycle-based movement of older files into archival storage for compliance retention.

Installing S3 client software on each workstation would force researchers to move from a file-based NFS workflow to direct object storage access, which likely requires application changes and user retraining. That approach does not preserve the existing on-premises file access model and does not provide transparent low-latency access to active files through a local cache. Although S3 Lifecycle to S3 Glacier Flexible Retrieval is a reasonable archival mechanism, the access method is operationally disruptive and does not meet the requirement to maintain the current file-serving experience. Therefore, this option fails on usability and architecture even though its archival class is more appropriate than Deep Archive for occasional retrieval.

Incorrect. AWS Directory Service and an AD trust relationship alone do not provide centralized SSO across all AWS accounts in an organization. The service that delivers AWS account SSO and centralized account assignments is AWS IAM Identity Center, not Directory Service by itself. Even if the directory is connected to on-premises AD, administrators would still need IAM Identity Center or another federation mechanism to grant workforce access to AWS accounts. The phrase 'automatically enable SSO for all AWS accounts' is therefore technically inaccurate.

Incorrect. Creating an AWS Managed Microsoft AD directory in AWS and using it as the identity source for IAM Identity Center could support SSO, but this option does not preserve the existing on-premises AD as the place where users and groups continue to be managed. As written, it implies that the AWS-hosted directory becomes the primary identity source rather than a trust-backed extension of the on-premises environment. That does not cleanly meet the requirement that identity administration remain in the existing on-premises Active Directory. The missing trust or linkage to the on-premises directory is the key flaw.

Incorrect. A custom identity provider on Amazon EC2 would introduce unnecessary operational overhead, including patching, scaling, high availability design, and security hardening. AWS IAM Identity Center already supports managed integration patterns for enterprise identity, making a self-hosted IdP an unnecessarily complex solution for this use case. The question does not indicate any special protocol or legacy requirement that would justify building a custom federation platform. On AWS certification exams, managed native services are generally preferred when they satisfy the requirements.

S3 with Athena is optimized for scanning large datasets in files (data lake analytics), not for low-latency, interactive traversal queries. Finding mutual connections up to five levels deep would require repeated self-joins over large datasets, leading to high query latency and cost due to full/large scans. Athena is best for ad hoc analysis and reporting, not real-time graph navigation in an application.

RDS for MySQL can represent users and connections with tables and foreign keys, but multi-level traversal and mutual-connection queries typically require recursive CTEs and multiple self-joins. At this scale (millions of nodes/edges), join-heavy queries can become slow and complex to tune, and performance may degrade as depth increases. Relational databases are not purpose-built for deep graph traversals.

DynamoDB can store adjacency lists or edge records with clever partition/sort keys, but multi-level traversal requires iterative queries/gets and application-side recursion. This increases latency (many network calls), complicates consistency and pagination, and can be costly at depth. DynamoDB excels at predictable key-based access patterns, not complex graph traversals like mutual connections several hops away.

Migrating all claims data into RDS is not appropriate for large-scale analytics and does not align with a data lake approach. RDS access controls are not designed for broad, cross-department analytics at this scale, and moving high-volume S3-based claim data into an OLTP database increases cost and operational complexity. It also does not provide the best fine-grained, analytics-oriented governance across diverse datasets.

Copying RDS data to S3 with Lambda plus Glue crawler and Athena can enable querying, but fine-grained access control is weak/complex if relying mainly on S3 bucket policies. You would need additional governance (e.g., Lake Formation) for table/column-level permissions and consistent control across datasets. Periodic Lambda copies also add operational overhead and can become brittle at scale compared to managed ingestion/governance patterns.

Redshift can provide strong analytics performance and access controls, but it introduces more operational overhead (cluster sizing, workload management, ingestion pipelines) and typically requires ongoing tuning/cost management. The requirement emphasizes fine-grained access control with minimal ops across S3 and RDS data; a governed data lake with Lake Formation is a more direct fit. Also, periodic Lambda-based loading is not an ideal ingestion strategy at this scale.

Incorrect. Running SQL Server on Amazon EC2 does provide full access to the Windows operating system and can support cross-Region disaster recovery using SQL Server native replication technologies. However, EC2 requires the most administrative effort because the organization must manage the OS, database installation, patching, backups, monitoring, and DR orchestration itself. The question explicitly asks to minimize administrative overhead for both daily operations and disaster recovery implementation. Therefore, although technically feasible, EC2 is not the best match among the listed choices.

Incorrect. Amazon RDS for SQL Server reduces operational overhead and cross-Region automated backups can support a restore-based disaster recovery strategy in another Region. However, standard RDS does not provide access to the underlying Windows operating system, so it cannot satisfy the compliance and custom security configuration requirement. In addition, copied backups are not the same as an actively replicated standby environment and generally result in higher recovery times. This option fails the critical OS-access requirement.

Incorrect. Multi-AZ for Amazon RDS for SQL Server provides high availability by maintaining a synchronous standby in another Availability Zone within the same AWS Region. That helps with local infrastructure failures but does not provide disaster recovery across multiple Regions, which is explicitly required. Standard RDS also does not allow access to the underlying Windows operating system. As a result, this option fails both the multi-Region DR requirement and the OS-level access requirement.