Practice Test #5

Incorrect. Systems Manager Parameter Store SecureString provides encrypted storage and IAM-controlled access, but it is not the best fit for automated database credential rotation at scale compared to Secrets Manager. While rotation can be engineered with custom automation, it increases operational burden and complexity. For exam scenarios involving RDS credential rotation and compliance, Secrets Manager is typically the intended service.

Incorrect. Storing encrypted credential files in S3 still relies on distributing and managing credential artifacts and does not provide a robust, integrated rotation mechanism with RDS. It also increases the risk of misconfiguration (bucket policies, object ACLs) and complicates least-privilege access patterns. S3 encryption addresses data at rest, not secret lifecycle management and rotation.

Incorrect. Encrypting EBS volumes protects credentials at rest on each instance, but credentials remain locally stored and must be rotated across 15 instances, increasing administrative burden and risk of inconsistency. A custom Lambda rotation script adds complexity and does not inherently ensure atomic rotation with RDS and immediate propagation to all instances. This is not the recommended AWS-native approach.

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.