Architecture Design and Implementation Built for the Cloud practice questions

EventBridge, SNS and SQS standard queues deliver at least once, so a consumer with side effects must be idempotent.

Duplicate delivery is part of the EventBridge contract, so the fix belongs in the consumer. Storing the event ID with a conditional write before the side effect means only one delivery can claim the event; later deliveries see the ID and skip the charge. Disabling retries loses resilience without removing duplicates, reserved concurrency only serialises them, and an archive addresses recovery rather than duplicates.

1. Recognise the symptom: the same event ID processed twice means at-least-once delivery.
2. Accept that delivery cannot be made exactly-once by tuning retries.
3. Make the side effect idempotent with a key that is stable across deliveries (the event ID or order ID).
4. Use a conditional write so the check and the claim happen atomically.

Exam tip: At-least-once delivery is fixed in the consumer: claim a stable idempotency key with a conditional write before the side effect.

For Kinesis event source mappings, the parallelization factor adds concurrency per shard while keeping per-partition-key order, and bisection plus retry/age limits stop a poison record from blocking a shard.

Two separate problems need two levers. Lag with fast invocations means too little concurrency per shard: the parallelization factor processes up to 10 batches per shard concurrently, and Lambda keeps records of the same partition key in order. The stalled shard is a poison record retried until it expires: bisecting the batch narrows it down, retry and maximum-record-age limits let the shard move on, and an on-failure destination keeps the failed record details. Random keys and SQS standard both break ordering; bigger batches make failures worse.

1. Separate the throughput problem from the failure problem.
2. For throughput with ordering, add concurrency per shard rather than changing the key.
3. For poison records, isolate them (bisect), bound retries, and send the failure record somewhere durable.
4. Reject any option that breaks per-key ordering.

Exam tip: Kinesis + Lambda: parallelization factor for speed with ordering, bisect + retry limits + on-failure destination for poison records.

EventBridge combines content-based routing, HTTPS delivery to third parties (API destinations) and archive/replay on one bus.

Three requirements decide it: content filtering per consumer, HTTPS delivery to partners and seven-day reprocessing for late joiners. EventBridge rules filter on any event field, API destinations deliver over HTTPS, and archive and replay let a new consumer reprocess past events. SNS standard has filtering and HTTPS but no replay; Kinesis has replay but no filtering or HTTPS delivery; per-consumer SQS copies couple producers to consumers.

1. List the must-haves: field filtering, HTTPS targets, history for late joiners, producer independence.
2. Check each service against every must-have, not just the first one.
3. Note that only EventBridge provides filtering, HTTPS delivery and replay without custom code.

Exam tip: Content routing + SaaS HTTPS targets + replay points to EventBridge; SNS lacks replay on standard topics, Kinesis lacks routing.

A stateless tier keeps session state outside the instance, in a shared store such as ElastiCache or DynamoDB.

The root cause is state held in instance memory. Moving carts to ElastiCache makes every instance interchangeable, which is what lets Auto Scaling replace instances freely. The other options keep the state on the instance and only delay the moment it is lost.

1. Find where the state lives: in each instance’s memory.
2. Ask whether the option moves the state or only delays losing it.
3. Choose a shared, low-latency store for session data and remove stickiness.

Exam tip: If losing an instance loses user data, externalize the state; stickiness and longer timeouts only delay the loss.

Containers become replaceable when files go to S3 and progress goes to a shared database such as DynamoDB.

Two kinds of state are trapped in the task: the uploaded file and the job progress. S3 holds the file independently of any task (and presigned URLs move the upload off the service), while a DynamoDB item per job holds progress that any task can read or update. Larger ephemeral storage and per-task EBS volumes still tie data to one task; the circuit breaker addresses a different failure.

1. Inventory the state the task holds: files and progress.
2. Move each kind to a store that outlives the task and is shared by all tasks.
3. Check that options which keep data on per-task storage do not solve replacement.

Exam tip: Files to S3, progress to DynamoDB: then any task can pick up any job and tasks can be replaced at will.

Athena cost is driven by bytes scanned; columnar formats cut columns read and partitions cut files read.

Queries read few columns and few days, so the two biggest savings are columnar storage (Parquet) and partition pruning (date partitions). Together they shrink scanned bytes by orders of magnitude for this access pattern. Capacity reservations, crawler frequency and storage classes change other costs but leave bytes scanned unchanged.

1. Note the access pattern: few columns, recent dates.
2. Match "few columns" to a columnar format and "recent dates" to partitioning.
3. Reject options that change compute purchase, schema freshness or storage price.

Exam tip: To cut Athena scans: columnar format for the columns you skip, partitions for the rows you skip.