Development with AWS Services practice questions

API Gateway can invoke a Lambda non-proxy integration asynchronously so the API returns at once.

The client only needs an acknowledgement, so the work does not belong in the request/response path. API Gateway's integration timeout (29 seconds by default) is well below the build time, so any synchronous design returns 504. In a Lambda non-proxy integration, mapping the X-Amz-Invocation-Type header to 'Event' makes API Gateway use asynchronous invocation, which returns at once and needs no function code change. A longer Lambda timeout or a 202 sent after the build both leave the call synchronous.

1. Find where the 504 comes from: the API Gateway integration timeout, not Lambda.
2. Note that the client needs only an acknowledgement, so asynchronous processing fits.
3. Recall that a non-proxy Lambda integration can request asynchronous invocation through the X-Amz-Invocation-Type header.
4. Reject changes that keep the invocation synchronous.

Exam tip: Long work behind API Gateway: invoke it asynchronously and acknowledge, rather than make the client wait.

Split a request into the part the caller must wait for and the parts that can run later.

Two requirements pull in different directions: the payment result is needed immediately (synchronous), while the other steps tolerate delay and must not affect latency (asynchronous). Only the split design satisfies both. Making everything asynchronous (SQS or a Standard workflow) fixes latency but loses the immediate payment result; keeping everything synchronous keeps the slow email step on the critical path.

1. Mark which outputs the caller needs in the response: only the payment result.
2. Move every step not needed in the response off the request path.
3. Check each option against both requirements: immediate payment result and no email-driven latency.
4. Prefer the design that is synchronous only where the caller truly waits.

Exam tip: Synchronous only for what the caller must see now; everything else becomes an event.

EventBridge rules filter events with event patterns before they reach any target.

Filtering in EventBridge happens in the rule's event pattern, which can match field values and numeric ranges such as greater than 1000. Matching events go to the target; others are never delivered. An input transformer only changes the payload, Lambda event source mapping filters apply to poll-based sources, and an SNS topic with a filter policy would work but adds resources the rule does not need.

1. Note that filtering must happen without publisher or function code changes.
2. Recall that an EventBridge rule's event pattern decides which events match.
3. Confirm event patterns support numeric comparisons.
4. Reject features that transform payloads or belong to other services.

Exam tip: Filter EventBridge events in the rule's event pattern, not in the target's code.

EventBridge target retry policy plus a dead-letter queue keeps events that a target could not receive.

EventBridge retries delivery to a target with backoff for up to 24 hours (the configurable maximum event age) and then drops the event, unless the target has a dead-letter queue. The DLQ captures exactly the events that failed for that target. Replaying an archive to the bus's rules would duplicate work for the internal targets. A 48-hour event age is outside the allowed range, and a log of every matching event does not show which deliveries failed.

1. Recall EventBridge's retry window: at most 24 hours of maximum event age.
2. Recognise that a 30-hour outage needs somewhere for undeliverable events to go.
3. Compare a DLQ (only failed events for one target) with a replay to the bus's rules (re-sends events to their targets).
4. Apply the constraint that internal targets must not receive duplicates.

Exam tip: Failed deliveries for one target go to that target's DLQ, where they can be reprocessed later.

Jitter breaks up synchronized retries; exponential backoff reduces their rate.

The symptom is synchronized retry waves. Exponential backoff alone grows the delay but keeps clients in lockstep because they all start from the same moment with the same schedule. Adding random jitter desynchronizes them. AWS SDKs use exponential backoff with jitter in their standard retry behavior for this reason.

1. Read the symptom: retries arrive together and throttle again.
2. Recall that backoff lowers the retry rate but does not desynchronize clients.
3. Add randomness (jitter) to spread retries over time.

Exam tip: Backoff slows retries down; jitter spreads them out. Use both.

AWS SDK retry modes: standard retries with backoff; adaptive also limits the client's own send rate.

Standard mode retries with exponential backoff and jitter, but it does not reduce the overall rate at which the client starts new requests. Adaptive mode adds a client-side token-bucket rate limiter that reacts to throttling responses, which is what a high-volume batch job needs. It is set in configuration (for example retry_mode in a botocore Config or AWS_RETRY_MODE), so no retry code is written.

1. Note that retries alone are already failing.
2. Identify the need: the client must slow its request rate.
3. Recall that only the adaptive retry mode adds client-side rate limiting.
4. Reject solutions that require hand-written retry loops.

Exam tip: Throttled even with retries? Adaptive retry mode makes the SDK slow down its own request rate.