Practice Test #4

This uses self-managed EC2 for SFTP, archives new files in Glacier Deep Archive, and waits for nightly processing, all of which conflict with immediate operationally efficient processing. Trap: AWS Batch sounds suitable for longer jobs, but the storage class and nightly trigger fail the core timing requirement.

An EC2 SFTP server and EBS landing volume add management overhead and still process files nightly rather than on arrival. Trap: EBS can store incoming files, but it does not give the native S3 event-driven ingestion pattern.

AWS Transfer Family does not use EBS as a storage backend, and the option inconsistently refers to S3 events for files stored on EBS. Trap: Transfer Family and per-file events are the right direction, but the backend storage makes the design invalid.

AWS Config is not the most direct target for immediately canceling a KMS key deletion event, and this option does not describe the managed cancellation path as cleanly as Systems Manager Automation. Trap: Config sounds like compliance remediation, but EventBridge to Automation is the lower-overhead event response.

A Lambda function could be written to cancel deletion, but that custom logic must be built, secured, tested, and maintained. Trap: Lambda is flexible, but the prompt rewards least operational overhead.

CloudTrail, CloudWatch Logs, alarms, and SNS can alert on activity, but this option does not automatically cancel the key deletion. Trap: It satisfies notification, but misses the automatic blocking requirement.

Incorrect. Running the entire monolithic stack on EC2 in public subnets increases exposure and does not provide strong tier isolation. While Auto Scaling can help availability, placing app and database components in public subnets is not aligned with regulated financial workloads or Well-Architected security best practices. Security groups/NACLs alone do not compensate for poor subnet placement and lack of separation of duties between tiers. Trap: Auto Scaling and Amazon EC2 sounds related, but it does not satisfy the scenario's tier isolation, multi-AZ resilience, and least-privilege database access as directly as the correct design.

Incorrect. A single RDS instance in one AZ is a single point of failure and typically cannot meet a 99.9% uptime target for the database layer. Even with security groups and NACLs, this option prioritizes cost over resilience and availability. For financial systems, Multi-AZ (or equivalent HA) is the expected baseline, especially when the question explicitly requires high availability. Trap: Amazon RDS sounds related, but it does not satisfy the scenario's tier isolation, multi-AZ resilience, and least-privilege database access as directly as the correct design.

Incorrect. Making the database publicly accessible is a major security and compliance risk for sensitive financial data. Allowing connections from any source within the VPC is overly permissive and violates least privilege. This design increases blast radius and makes it harder to demonstrate regulatory controls. In exam scenarios, databases for regulated workloads should be in private subnets with tightly scoped inbound rules. Trap: Amazon RDS sounds related, but it does not satisfy the scenario's tier isolation, multi-AZ resilience, and least-privilege database access as directly as the correct design.

Standard RDS Multi-AZ does not let the application write to the standby, and sending reads to the primary does not reduce the read bottleneck. Trap: Multi-AZ sounds like extra capacity, but it is for failover, not active read/write splitting.

A standard RDS Multi-AZ standby is not readable, so analytical reads cannot be routed there to reduce primary CPU. Trap: The secondary Availability Zone is a failover target, not a reporting endpoint in this pattern.

Read replicas are correct, but matching the full primary size is a larger and more expensive first step than the smaller replica option given the minimal-change wording. Trap: It uses the right feature, but overprovisions relative to the stated goal.

A target group behind an ALB improves distribution, but the option does not define an Auto Scaling group. Standard RDS MySQL with multiple instances improves availability or read scaling, not automatic database capacity scaling. Trap: It resembles a high-availability design, but it misses the automatic scaling requirement for both tiers.

ElastiCache for Redis is a cache, not a durable MySQL database replacement for the application system of record. Trap: Redis can reduce load, but it does not replace the MySQL database layer.

A new single EC2 instance is still a single point of failure, and Redshift is an analytics warehouse rather than an OLTP MySQL database. Trap: Redshift has scale, but for analytics, not this transactional MySQL workload.

CloudWatch Logs subscription filters do not directly stream to OpenSearch as the native low-ops destination. Trap: It sounds simplest, but it skips the supported delivery service in the path.

Lambda-based delivery requires custom batching, OpenSearch bulk indexing, retry handling, and scaling management during peak traffic. Trap: Lambda can process log events, but it increases operations compared with Firehose.

Kinesis Agent, Data Streams, and custom consumers require server agents, shard planning, and consumer operations. Trap: It can stream data, but it is heavier than the managed Firehose delivery pattern.

S3 Intelligent-Tiering can reduce storage cost, but moving from EFS (NFS/POSIX file system) to S3 (object storage) requires application changes to use the S3 API and adapt to object semantics (no true POSIX operations, different rename/locking behavior). The question explicitly asks to avoid significant changes to file access patterns, so this is not the best fit even if raw storage cost could be lower. Trap: This may look relevant to the service mix, but the deciding scenario clues point to EFS lifecycle management to EFS Infrequent Access.

Amazon FSx for OpenZFS can provide NFS-compatible shared storage for Linux workloads, but it is not the most cost-effective answer in this scenario. Migrating from EFS to FSx introduces a new storage platform, requires data migration, and adds operational change without any stated need for OpenZFS-specific capabilities such as clones, snapshots, or specialized performance tuning. Trap: This may look relevant to the service mix, but the deciding scenario clues point to EFS lifecycle management to EFS Infrequent Access.

FSx for Windows File Server uses SMB/CIFS and is designed for Windows workloads. The application runs on Linux EC2 and currently uses EFS (NFS). Trap: This may look relevant to the service mix, but the deciding scenario clues point to EFS lifecycle management to EFS Infrequent Access.

Public read access to medical records would directly violate the security and HIPAA compliance goals. Trap: Public access might sound convenient for a portal, but PHI must be protected with least-privilege controls.

Embedding IAM access keys in EC2 application code creates long-lived secrets that are hard to rotate and easy to leak. Trap: Access keys may appear to solve authentication, but EC2 roles are the secure pattern.

A NAT gateway sends private subnet traffic to public service endpoints and adds NAT data processing charges; it is not the highest-security or lowest-cost S3 path. Trap: Private subnet egress through NAT can sound private, but it still uses the public endpoint path for S3.

EC2 Auto Scaling groups can scale servers, but the team still manages instances, AMIs, patching, container runtime updates, and capacity. That misses the lowest-overhead goal. Trap: It uses auto scaling, but it still leaves server operations in place.

ElastiCache can reduce database load, but the question does not describe a cacheable read bottleneck. It also does not remove container host or database maintenance. Trap: Caching can improve performance, but it is not the core answer to operational overhead and capacity planning.

CloudWatch alarms improve visibility but do not by themselves migrate containers, scale tasks, or reduce database administration. Trap: Alarms may trigger actions, but this option does not implement the managed scaling actions.