Practice Test #5

Systems Manager Parameter Store SecureString can store sensitive values and can be shared across accounts in some scenarios by using resource policies on advanced parameters. However, this option specifies an AWS managed KMS key, and cross-account use of the encrypted value requires KMS permissions that are not appropriately controllable with an AWS managed key. Because the workloads in both accounts must retrieve and decrypt the same token, a customer managed KMS key is the correct pattern. Even aside from that, Secrets Manager is the more purpose-built service for runtime secret retrieval with lower operational overhead.

DynamoDB plus KMS can securely store encrypted data, but it is not a managed secrets solution. You would need to implement your own retrieval, caching, rotation strategy, and careful IAM scoping for DynamoDB reads and KMS decrypt. This adds operational and development overhead and increases the chance of mistakes (e.g., logging plaintext, improper key policies). It meets encryption requirements but not “least management overhead.”

S3 with SSE-KMS can encrypt objects at rest and TLS protects in transit, and bucket policies can grant cross-account access. However, S3 is not a secret store: you must manage object formats, retrieval logic, caching, and potential exposure risks (e.g., accidental broader bucket permissions). Using an AWS managed KMS key also reduces control. This is higher overhead and less aligned with best practices than Secrets Manager.

Incorrect. A scheduled table scan is extremely expensive and inefficient at this scale because Scan reads large portions of the table repeatedly, consuming significant read capacity (or on-demand read charges) and requiring ongoing EC2 costs and operations. BatchWriteItem helps reduce API calls but does not eliminate the fundamental cost of scanning and explicit deletes. This is not the most cost-effective approach for time-based expiration.

Incorrect. Running scheduled ECS/Fargate tasks adds compute cost and operational overhead, and the approach still relies on scanning the table to find expired items. Even if it runs frequently, it will generate substantial DynamoDB read traffic and explicit deletes. Fargate is convenient but not cost-optimal for a simple, continuous cleanup job when DynamoDB TTL can handle expiration natively.

Incorrect. While querying a GSI is better than scanning the base table, it still incurs ongoing read costs on the index plus Lambda invocation costs and explicit delete write operations. Also, DynamoDB does not have a native “Date” attribute type; you’d store dates as String or Number. This design is more complex than necessary and is not as cost-effective as TTL.

Incorrect. AWS Systems Manager Parameter Store can securely store encrypted values using SecureString, but it is not the primary AWS service for managed database credential rotation. The phrase 'turn on rotation' aligns with AWS Secrets Manager, which is purpose-built for scheduled secret rotation and database integration. For Aurora PostgreSQL credentials that must rotate automatically every 30 days, Secrets Manager is the better and expected choice.

Incorrect. This option fails the core database requirement because the workload is being migrated to an Amazon Aurora PostgreSQL-Compatible cluster, not Amazon DynamoDB. It also pairs that incorrect database choice with Parameter Store, which is not the best service for managed automatic database credential rotation. Therefore it is wrong on both the database platform and the secret-management requirement.

Incorrect. Although AWS Secrets Manager is the correct service for securely storing and rotating credentials, DynamoDB is not the database specified in the scenario. The question explicitly requires an Aurora PostgreSQL-Compatible cluster with one writer and two readers, which describes an Aurora architecture rather than DynamoDB. Because the database service is wrong, this option cannot be the best answer.

Incorrect. Directly invoking allocation and then payment from the initial Lambda introduces tight coupling and reduces parallelism (the question states allocation and payment run in parallel). It also does not provide durable ordering across concurrent requests, retries, or partial failures. Two near-simultaneous requests could still interleave, and without FIFO semantics or a distributed lock/conditional write, “first received wins” is not reliably enforced.

Incorrect. SNS standard topics provide at-least-once delivery with no ordering guarantees and possible duplicates. With concurrent requests arriving within milliseconds, the second request could be delivered/processed before the first, violating the “first request received must get the slot” rule. Duplicate deliveries could also cause multiple payment attempts unless additional idempotency and coordination logic is implemented beyond what the option provides.

Incorrect. A single SQS standard queue does not guarantee ordering and can deliver messages more than once. Even if it were FIFO, using one queue for two Lambda consumers is problematic: each message would be processed by only one consumer, not both, so you would not reliably run allocation and payment in parallel for the same reservation. Fan-out requires separate queues or a pub/sub mechanism.

Incorrect. A customer managed KMS key requires key creation, key policy management, and potentially rotation/permissions administration. That directly violates the requirement to avoid KMS key administration. While it would satisfy encryption at rest, it is the most operationally heavy option and not aligned with “AWS owned key.”

Incorrect. alias/aws/dynamodb is an AWS managed KMS key, not an AWS owned key. Although AWS managed keys reduce some overhead (AWS handles rotation), they still involve KMS constructs in your account and are not the same as AWS owned keys. The requirement explicitly calls for AWS owned keys to avoid KMS key administration.

Incorrect. Customers cannot create or supply an ARN for an AWS owned key. AWS owned keys are fully controlled by AWS and are not visible or manageable in the customer account, so there is no ARN you can reference in SSESpecification.KMSMasterKeyId. This option is not technically feasible.