Practice Test #8

SQS + Auto Scaling workers is a solid decoupled pattern, but scheduled scaling is not “maximum resilience and automatic scaling” for highly variable workloads. It relies on predictions and historical patterns, which can miss unexpected spikes or changes in month-end timing/volume. It can also keep excess capacity running during low periods, increasing cost and operational tuning effort compared to queue-depth-driven scaling.

Keeping a coordinator server preserves a single point of failure and a scaling choke point, reducing resilience. CloudTrail is for auditing API calls, not for capturing or routing job distribution events. Scaling based on coordinator CPU is an indirect metric that may not correlate with backlog or throughput, and it can lead to delayed or unstable scaling behavior during spikes.

EventBridge can route events, but it does not replace the need for durable task buffering and back-pressure the way SQS does for batch workloads. Retaining a coordinator server still introduces a single point of failure and operational overhead. CPU-based scaling on workers is less accurate than queue-depth scaling because CPU may not reflect pending work (e.g., I/O waits), causing under/over-scaling.

DynamoDB Streams can emit item-level changes, but DynamoDB is not the best primary ingestion bus for millions of concurrent events that must be shared broadly in near real time. Also, DynamoDB does not provide a native “rule” mechanism to remove/mask PII on write; you would need application logic or a Lambda-based pipeline. This option also couples ingestion directly to the database, reducing flexibility for multiple analytics consumers.

Kinesis Data Firehose is optimized for loading streaming data into storage/analytics destinations (commonly S3, Redshift, OpenSearch) with optional Lambda transformation. However, Firehose is not designed for multiple independent near-real-time consumers; it delivers to destinations rather than acting as a shared event stream. Additionally, DynamoDB is not a typical/native Firehose destination, making this architecture mismatched to the stated DynamoDB requirement.

Storing batched events as S3 files and processing them with Lambda is a batch-oriented pattern that increases end-to-end latency and is less suitable for “near-real-time” requirements. It also adds operational complexity around file sizing, partitioning, and reprocessing. While S3 is excellent for durable data lakes, it is not the right primary mechanism for real-time event fan-out to multiple analytics applications.

Amazon S3 provides excellent durability and availability, but it is object storage accessed via APIs, not an NFS/POSIX file system. Even with S3 access points, workstations would need different tooling (SDK/CLI) or a file gateway/mount solution, and file locking/rename semantics differ. This violates the requirement to keep the current shared file access patterns without workflow changes.

AWS Storage Gateway File Gateway is intended mainly for hybrid use cases where on-premises clients need NFS/SMB access with cached local performance and S3 as the backing store. Mounting a File Gateway “on EC2 NFS servers” adds complexity and does not inherently provide a clean, highly available shared file system for multiple editing workstations. It also doesn’t directly replace the need for HA shared storage in AWS like EFS does.

Amazon FSx for Lustre is optimized for high-performance parallel workloads (HPC, large-scale rendering/compute) and can integrate with S3, but it is not the simplest match for “keep NFS workflow” and general shared storage. The option’s mention of “cross-AZ replication” is misleading; FSx for Lustre HA is not typically configured as cross-AZ replication in this manner. It can be overkill and adds operational/design complexity compared to EFS.

EFS encryption at rest/in transit and security groups provide strong protection against network interception and storage media exposure, but they do not ensure confidentiality from privileged users who can mount the file system or manage instances with access. Administrators with OS-level access could still read files in plaintext once mounted. Also, EFS is a file system, not ideal as the primary system of record for structured medical/prescription data requiring query/transaction semantics.

DynamoDB SSE-KMS encrypts data at rest, but DynamoDB decrypts data for authorized reads. This typically does not meet the requirement to keep data confidential from administrators/operators with legitimate access because access to the table (or roles with read permissions) can still retrieve plaintext. IAM restrictions help, but the question explicitly requires protection even from admins, which usually implies client-side/field-level encryption rather than only server-side encryption.

FSx for Lustre is optimized for high-performance compute workloads (e.g., HPC, ML, media processing) and is not a typical choice for storing and querying patient records/prescriptions. Encryption and AD integration address at-rest protection and authentication, but do not inherently prevent privileged administrators from accessing plaintext once they have filesystem access. It also doesn’t directly address the need for database-like access patterns and fine-grained field confidentiality.

Network Access Analyzer evaluates network reachability inside Amazon VPC environments. It analyzes paths based on constructs such as route tables, security groups, network ACLs, and gateways. It does not inspect IAM identity-based permissions or determine whether an IAM user has excessive privileges. As a result, it is unrelated to the requirement to audit IAM user permissions.

A CloudWatch alarm can notify administrators when certain events occur, typically by using CloudTrail logs and metric filters. However, that approach only shows actions that users actually perform, not the full set of permissions they have been granted. A user can still be over-privileged even if they never exercise those permissions. This option also creates more operational overhead because alarms, filters, and event patterns must be designed and maintained.

Amazon Inspector is a vulnerability management service for workloads such as Amazon EC2, container images in Amazon ECR, and AWS Lambda functions. It does not review IAM user permissions to determine whether identities are over-privileged. Inspector findings focus on software vulnerabilities and exposure issues rather than IAM authorization design. Therefore it does not satisfy the requirement to audit IAM permissions across multiple accounts.