Practice Test #5

AWS Trusted Advisor provides best-practice recommendations across categories such as security, cost optimization, performance, fault tolerance, and service limits. Although it may highlight some risky S3 settings, it does not continuously record every bucket configuration change or maintain a detailed historical timeline of those changes. It also is not the primary AWS service for rule-based compliance evaluation of resource configurations. Therefore, it cannot satisfy the requirement for continuous monitoring and historical configuration tracking for HIPAA-style audits.

Amazon Inspector is a vulnerability management service that assesses workloads such as EC2 instances, container images in Amazon ECR, and some Lambda functions for software vulnerabilities and unintended network exposure. It does not monitor S3 bucket configuration settings like bucket policies, ACLs, encryption configuration, or public access block status. It also does not provide configuration history for S3 resources. As a result, it is not suitable for continuous compliance monitoring of S3 bucket configurations.

S3 server access logging captures requests made to S3 objects and buckets, which is useful for analyzing access patterns and data-plane activity. EventBridge can route events and trigger notifications or automation when certain API calls occur, but by itself it does not maintain a normalized configuration history or evaluate resources against compliance rules. This combination may help detect that a change happened, but it does not provide the full compliance framework requested in the question. The requirement for automated compliance checking and historical configuration tracking points to AWS Config instead.

Auto Scaling can reduce CPU pressure by adding EC2 instances, and S3 event notifications to SNS is a solid notification pattern. However, operational overhead remains high: you must manage AMIs/patching, scaling policies, instance coordination to avoid duplicate polling, and potentially shared state for 15 API pulls every 30 minutes. It improves performance but does not minimize management overhead compared to a managed ingestion service.

EventBridge is excellent for routing events from AWS services and supported SaaS partners, but it cannot inherently “capture data events” from arbitrary EHR APIs without something generating events (custom code, partner integration, or an API destination pattern). You would still need a polling/ingestion component to call each EHR API and put data into S3. This increases complexity and does not directly solve the compute bottleneck.

ECS with auto scaling can handle higher throughput than a single EC2 instance and provides better deployment primitives than pets-on-EC2. However, it introduces container build/deploy pipelines, task definitions, scaling policies, and ongoing operational management. It also keeps the same fundamental approach (poll, process, upload, notify) running on compute you manage, which is higher overhead than a fully managed ingestion service like AppFlow.

DataSync and S3 Transfer Acceleration address data movement to S3, not providing a POSIX-compliant parallel file system. Mounting S3 with s3fs is not equivalent to a native POSIX parallel file system (different consistency/locking semantics, metadata behavior, and typically lower performance for HPC I/O patterns). This option focuses on transfer, not low-latency parallel shared storage for compute nodes.

Storage Gateway Volume Gateway (stored volumes) is intended for hybrid architectures where on-premises applications access cloud-backed block storage via iSCSI. It does not provide a shared POSIX parallel file system for many EC2 instances, and iSCSI volumes are not designed for concurrent parallel access by multiple clients without a clustered file system layer. It also adds unnecessary hybrid complexity for a cloud-native HPC solution.

Amazon EFS is a fully managed, POSIX-compliant shared file system accessed over NFS v4.1 and can scale throughput, but it is not a parallel file system like Lustre. Even with Max I/O mode, EFS is generally better for shared file workloads (home directories, content management, web serving) than for extreme HPC parallel I/O requiring very high throughput and low latency across many compute nodes.

DynamoDB global tables provide multi-Region, active-active replication and are excellent for high availability and low-latency global access. However, they do not protect against logical corruption because writes (including bad or corrupted updates) replicate to all Regions. Without an additional mechanism like PITR, you cannot reliably roll back to a pre-corruption state. This option addresses Region failure more than corruption recovery.

Daily exports to S3 Glacier Deep Archive are designed for low-cost, long-term retention, not rapid operational recovery. A daily cadence cannot meet a 15-minute RPO, and Deep Archive retrieval times (hours) generally cannot meet a 1-hour RTO. Even if exports were more frequent, the restore process (retrieve, re-import) is operationally heavy compared to PITR.

This is not feasible because DynamoDB is a fully managed service; customers do not manage or access the underlying storage volumes, so EBS snapshots cannot be used to back up DynamoDB tables. For DynamoDB, backups are handled via on-demand backups, PITR, or exports to S3. This option reflects a common misconception of treating managed services like self-managed databases.

Incorrect. EventBridge Scheduler is for time-based invocations (cron/rate) and does not “capture” AWS Batch SUCCEEDED events. While using EventBridge (rules) to trigger Lambda would work, the option’s use of Scheduler is conceptually wrong for event capture. Even if corrected to an EventBridge rule, Lambda adds code and cost and is less cost-optimized than API Destinations for simple HTTP notifications.

Incorrect. AWS Batch does not natively publish job SUCCEEDED events to API Gateway. API Gateway is designed to front APIs for clients, not to act as an event target for Batch without an intermediary like EventBridge. Additionally, HTTP proxy integration is for forwarding inbound API requests to a backend; it does not solve the need to originate a call to an external system upon a Batch completion event.

Incorrect. Like option C, AWS Batch cannot directly publish job SUCCEEDED events to API Gateway. Even if you inserted EventBridge to call API Gateway, this adds unnecessary components (API Gateway + Lambda) compared to EventBridge API Destinations. Lambda proxy integration is useful when you must run custom logic, transform payloads, or handle complex auth, but it is not the most cost-effective for a straightforward notification.

Partially meets requirements but not best. ALB improves availability, but the option does not explicitly use an Auto Scaling group, so application auto-scaling is not guaranteed. Also, “RDS for MySQL cluster with multiple instances” is ambiguous: RDS Multi-AZ improves availability, and read replicas scale reads, but write capacity generally does not auto-scale. It’s less aligned with “automatically scale” for the database.

Incorrect. Auto Scaling + ALB can scale the application tier, but ElastiCache for Redis is a caching layer, not a durable MySQL database replacement. A “MySQL connector” does not make Redis a system of record for transactional data. This would not satisfy the requirement to scale the database layer for MySQL workloads with durability, backups, and relational features.

Incorrect. Moving to a single new EC2 instance does not provide high availability or scaling. Amazon Redshift is a columnar data warehouse optimized for analytics (OLAP), not transactional MySQL workloads (OLTP). Even if some compatibility exists via integrations, Redshift is not a drop-in MySQL database and would not meet the requirement for an auto-scaling, highly available MySQL database layer.

A Lambda custom authorizer can validate tokens and implement complex authorization logic, but it introduces additional development and operational overhead (code, deployments, monitoring, scaling, and potential cold starts). With rapid growth and high request volume, per-request Lambda invocations can increase latency and cost. This is not the least-operations approach when Cognito user pool authorizers provide managed JWT validation.

API keys are intended for API Gateway usage plans (throttling/quotas) and identifying calling applications, not authenticating individual mobile banking customers. Storing and validating per-customer API keys in DynamoDB plus a Lambda validation layer adds complexity and creates key-rotation and leakage risks in mobile clients. It also duplicates functionality already provided by Cognito JWTs.

Including an account number in headers is not a secure access control mechanism because headers can be manipulated by the client. You would still need strong authentication (e.g., JWT) and server-side authorization checks mapping identity to allowed resources. Using Lambda to validate this increases custom logic and operational burden, and it risks insecure direct object reference (IDOR) issues if not perfectly implemented.

S3 Glacier Instant Retrieval provides millisecond access but is intended for archive data that is rarely accessed. It typically has minimum storage duration charges (commonly 90 days) and retrieval fees, which can become expensive if access is more frequent than expected. Because the company’s access is highly unpredictable across multiple departments, Glacier Instant Retrieval can introduce unnecessary retrieval costs compared to Intelligent-Tiering’s automatic optimization.

S3 Standard offers the highest availability and millisecond access with no retrieval fees, making it attractive for immediate access requirements. However, it is generally the most expensive option for data that is not consistently accessed. Given the unpredictable access pattern and 90-day retention, many reports may be accessed infrequently, so Standard would likely cost more than necessary compared to Intelligent-Tiering.

S3 Standard-IA provides millisecond access at a lower storage price than Standard, but it charges retrieval fees and is optimized for data that is known to be infrequently accessed. With highly unpredictable access, retrieval charges can accumulate and negate savings. It also has a minimum storage duration charge (typically 30 days), which is not a problem for 90-day retention but does not address the uncertainty as well as Intelligent-Tiering.

A manual snapshot/restore is operationally straightforward but usually causes significant downtime and cannot guarantee near-zero data loss at cutover. You must stop or accept losing in-flight writes after the snapshot time, then restore into Aurora, which can take longer than 5 minutes for large databases. This approach is better for non-critical systems or when longer maintenance windows are acceptable.

Using mysqldump to S3 and importing into Aurora is highly manual and typically slow for large, busy databases. It requires coordinating exports, handling consistency (often needing locks or transaction snapshots), and then importing, which can exceed the 5-minute downtime requirement. It also increases risk of human error and is not ideal for mission-critical, high-transaction workloads.

AWS DMS can perform full load plus ongoing CDC replication and can meet low-downtime and low-data-loss goals. However, it generally has higher operational overhead than the Aurora read replica approach: you must provision and manage a replication instance, configure tasks, monitor latency, handle errors, and tune performance. DMS is excellent when native replication isn’t available or for complex migrations, but it’s not the least-ops option here.