AWS Certified Solutions Architect - Associate SAA-C03 Practice Test 40
Question 390
An SQS consumer spends up to ninety seconds processing an order, but the queue visibility timeout is thirty seconds. Another worker sometimes receives and processes the same still-running order. What setting should the architect address?
- Change the queue from Standard to FIFO and ignore job duration because FIFO disables visibility timeout entirely.
- Set a suitable visibility timeout or extend message visibility during long processing.
- Reduce the visibility timeout to five seconds to guarantee no duplicate processing.
- Increase only message retention from four to fourteen days, leaving visibility unchanged.
Explanation
Correct Answer
B:Visibility controls how long a received message is hidden before retry. It should accommodate the job duration and failure recovery design.
Incorrect Answers
A:FIFO queues still use visibility controls and application failure/retry semantics; queue type alone does not fix timing.
C:Shorter invisibility causes messages to become available sooner, increasing concurrent duplicate-processing risk.
D:Retention governs queue lifetime, not how quickly an in-flight message can reappear to competing consumers.
Question 391
A security team operates a shared SQS dead-letter queue for two approved payment processing queues. Other queues in the same account and Region must not be able to designate that DLQ as their dead-letter target. The approved queues already have their own redrive policies and retry thresholds. Which additional configuration enforces the source-queue eligibility requirement?
- Increase maxReceiveCount on the approved source queues so any unapproved queue is rejected when trying to reference the shared DLQ.
- Enable SQS FIFO content-based deduplication on the DLQ; that attribute controls which source queues are permitted to send failed messages.
- Set the DLQ RedriveAllowPolicy to byQueue with the two approved source queue ARNs, retaining the source queues’ ordinary redrive policies.
- Increase the DLQ visibility timeout and remove its message-retention period; both settings determine who is authorized to use the DLQ.
Explanation
Correct Answer
C:RedriveAllowPolicy on the dead-letter queue governs which same-account/Region source queues may use it; byQueue explicitly limits eligible source ARNs, separate from each source queue’s maxReceiveCount.
Incorrect Answers
A:maxReceiveCount governs when a failed message is moved from its source queue. It does not limit which other source queues may designate the DLQ.
B:FIFO content-based deduplication addresses repeated message bodies in FIFO delivery. It is not a source queue allowlist and may be incompatible with the source queue types here.
D:Visibility timeout controls how long received messages remain hidden, and retention controls their lifetime. Neither selects which source queues may configure the target DLQ.
Question 392
A billing worker reads from an SQS Standard queue and occasionally receives the same payment event twice after a network timeout. The database must not charge twice. What property must the application implement?
- Increase the queue's maximum message size so the service refuses duplicate transaction IDs automatically.
- Use a longer visibility timeout as the sole measure and skip idempotency checks in durable storage.
- Assume SQS Standard guarantees exactly-once delivery and remove payment uniqueness checks.
- Use idempotent processing keyed by a stable business event or transaction identifier.
Explanation
Correct Answer
D:SQS Standard delivery can repeat messages. The consumer must recognize previously committed work so a retry does not perform a second charge.
Incorrect Answers
A:Message-size limits do not identify or suppress duplicate business operations in the payment database.
B:A long timeout lowers overlap risk but cannot eliminate retries after failures or all duplicate deliveries.
C:Standard queue delivery is at least once; without deduplication the downstream payment side effect can repeat.
Question 393
A marketplace uses an SQS FIFO queue for all merchants. One merchant has a slow order update; other merchants' orders must process independently without violating ordering within each merchant. What should publishers set?
- Assign a consistent MessageGroupId per merchant, allowing independent message groups to progress separately.
- Use a single MessageGroupId for all merchants so one slow message never blocks any other merchant.
- Switch to an SQS Standard queue without redesign because it preserves exact per-merchant order.
- Set each message's group ID to a random value even for messages from the same merchant.
Explanation
Correct Answer
A:FIFO ordering is enforced within message groups. Separate groups allow ordered concurrency for independent merchants subject to consumer scaling.
Incorrect Answers
B:One global group serializes the entire flow and can cause head-of-line blocking across unrelated merchants.
C:Standard queues do not guarantee the strict ordering within merchant groups that the business explicitly needs.
D:Random grouping can defeat per-merchant order because related updates enter different independently ordered groups.
Question 394
A producer retries a timed-out SendMessage request to an SQS FIFO queue. The order event must not be enqueued twice during a short deduplication window. Which field or supported configuration addresses this?
- Disable FIFO deduplication and depend on a longer visibility timeout to reject repeated SendMessage calls.
- Move the payload to a Standard queue, which enforces stricter producer deduplication than FIFO.
- Change only the SQS MessageGroupId on every retry to ensure no duplicate event is stored.
- Supply stable MessageDeduplicationId values or use appropriate content-based deduplication.
Explanation
Correct Answer
D:FIFO deduplication suppresses eligible repeated sends within its deduplication interval. Producers should preserve an identifier across retries of the same business event.
Incorrect Answers
A:Visibility timeout governs received messages, not duplicate producer submissions to the queue.
B:Standard queues do not offer the FIFO-specific deduplication mechanism needed for this producer retry case.
C:Changing grouping changes ordering behavior and does not establish the same deduplication identity for the retry.
Question 395
An SQS FIFO queue delivers purchase events in the required order, but the database transaction sometimes commits and the worker crashes before deleting the SQS message. A retry can run the write again. Which design statement is correct?
- Set MessageGroupId to the current wall-clock second so database writes become irreversible after that second.
- Preserve downstream idempotency and transaction deduplication even when using a FIFO queue.
- Remove the database's transaction uniqueness constraint because FIFO means each external commit can happen only once.
- Increase the queue retention to fourteen days; the longer horizon eliminates replayed database commits.
Explanation
Correct Answer
B:FIFO ordering and queue-side deduplication do not guarantee exactly-once committed business side effects across an external database failure boundary.
Incorrect Answers
A:Grouping determines in-queue ordered processing; it does not supply durable database-side deduplication.
C:Queue behavior does not atomically coordinate a database commit with deleting the SQS message after a worker failure.
D:Retention extends how long messages remain eligible for processing and can increase, not remove, retry opportunities.
Question 396
A worker uses SQS long polling with WaitTimeSeconds set to 20 seconds, but its HTTP client's socket timeout is five seconds. Receive calls frequently abort before returning. What client setting should change?
- Change the queue to FIFO because FIFO long polls are always returned in less than five seconds.
- Disable the client's HTTP retries while preserving the five-second timeout, which repairs the mismatch.
- Make the HTTP response/read timeout longer than the selected long-poll wait, with reasonable margin.
- Set the queue visibility timeout to five seconds because it overrides the client's HTTP socket timeout.
Explanation
Correct Answer
C:A long-poll request can legitimately wait for available messages. A shorter socket timeout interrupts that wait and creates unnecessary retry/error cycles.
Incorrect Answers
A:FIFO does not guarantee an immediate response for a long-poll request on an empty queue.
B:Removing retries may hide repeat errors but leaves the client unable to wait for a valid twenty-second receive call.
D:Visibility applies after receiving a message; it cannot extend a transport client's premature request timeout.
Question 397
An SQS queue's ApproximateNumberOfMessagesVisible rises steadily after a marketing campaign while the consumer fleet shows low CPU utilization. Its Auto Scaling group scales only on average CPU. What would better match the work backlog?
- Drive worker scaling with queue backlog per instance or a similar backlog/latency-aware metric.
- Scale only on the number of registered ALB targets in the unrelated web tier.
- Increase the API frontend's desired EC2 count because additional producers always drain the queue faster.
- Use the queue's message retention period as the scaling metric, because retention is proportional to workload.
Explanation
Correct Answer
A:CPU can remain low while workers block on I/O and messages accumulate. Queue depth relative to active consumers reflects delivery pressure more directly.
Incorrect Answers
B:Frontend health count does not track queued worker throughput or delayed messages in this independent tier.
C:More producers can increase the backlog; worker capacity must respond to queued processing demand.
D:Retention is a configured lifetime, not a measure of outstanding tasks or worker saturation.
Question 398
A nightly processor can be offline for two days during maintenance. The SQS queue currently retains messages for one day, and jobs vanish before service resumes. What queue setting protects pending work?
- Increase visibility timeout only; hidden messages are never subject to retention expiry after receipt.
- Enable long polling, which stores messages forever when consumers are disconnected.
- Increase SQS message retention beyond the supported maximum expected outage and recovery interval.
- Switch from Standard to FIFO, because FIFO queues have unlimited default retention.
Explanation
Correct Answer
C:Retention determines how long unprocessed messages remain in the queue. It must cover outage duration within SQS's supported retention range.
Incorrect Answers
A:Visibility does not override the queue retention deadline, so old unprocessed jobs can still expire.
B:Long polling changes receive request behavior, not how many days SQS retains messages.
D:FIFO retains messages under explicit retention settings and does not grant indefinite preservation.
Question 399
An order-event SNS topic already successfully delivers JSON event bodies to SQS, but consumers receive an SNS notification envelope containing Message, TopicArn, and metadata. The consumer is intentionally designed to parse the publisher payload directly without the SNS wrapper. What subscription configuration should be considered?
- Grant an arbitrary public sqs:SendMessage policy to every principal so that SNS removes its notification envelope.
- Set the SQS visibility timeout to zero because it strips SNS metadata from the delivered message body.
- Enable S3 static website hosting on the topic and assume SQS receives raw message bytes automatically.
- Enable the SNS subscription RawMessageDelivery attribute for the SQS endpoint, after validating any message-attribute limits.
Explanation
Correct Answer
D:SNS raw delivery sends the published message body to supported subscribers without the normal SNS JSON envelope. When enabled for SQS, the service applies a limit on the number of forwarded message attributes.
Incorrect Answers
A:Queue policy authorizes senders and does not alter the shape of a message successfully published by SNS.
B:Visibility timeout controls when a received message becomes available again, not its published payload format.
C:S3 website hosting is unrelated to an SNS-to-SQS subscription and cannot change the delivery envelope.
Question 400
An SNS topic broadcasts five event types, but a fulfillment queue needs only shipped and cancelled order events. The team does not want the worker to download and reject every unrelated event. Which SNS mechanism should be used?
- Configure SQS ReceiveMessage calls with an SNS message-attribute predicate so the queue rejects unrelated topic events before SNS delivery.
- Attach an SNS subscription filter policy selecting the allowed event attributes or supported message-body fields.
- Reduce SNS message size limit until unwanted event types no longer fit in the published payload.
- Create a second SNS topic with no publishers and assume all unwanted event types move there automatically.
Explanation
Correct Answer
B:Subscription filtering routes only matching published messages to the fulfillment subscription, reducing consumer-side irrelevant work.
Incorrect Answers
A:An SQS consumer cannot retroactively apply an SNS topic subscription filter through ReceiveMessage. The SNS subscription filter policy is evaluated before topic messages are delivered to that queue.
C:Arbitrary payload truncation is not an event-type filter and risks rejecting legitimate shipments.
D:A new topic without changed publishing or filtering rules has no effect on routing existing events.
