Development with AWS Services practice questions

Answer: B) Set the SDK client's connect and request timeouts and maximum attempts so that the total call time stays under about 2 seconds; D) Catch the SDK timeout error and return the page with a default or cached list of recommendations

Fault tolerance in code means bounded timeouts and retries that fit the caller's latency budget, plus a fallback when an optional dependency fails.

• AIncorrect. The page would take longer than 3 seconds, and the API Gateway integration timeout would still end the request first.
• BCorrect. Bounding timeouts and retries makes the SDK call fail fast, leaving time to build the page.
• CIncorrect. Adaptive mode limits the client's request rate, but 10 attempts make a hanging dependency take even longer.
• DCorrect. This is graceful degradation. The page still renders when the optional dependency is unavailable.
• EIncorrect. Provisioned concurrency removes cold starts. It doesn't stop calls to an unreachable endpoint from hanging.

Answer: A) The function is effectively disabled from processing new invocations, since it's reserved zero capacity to run

• ASetting reserved concurrency to 0 gives the function no capacity to execute at all, so new invocations will be throttled — a technique sometimes deliberately used as an emergency "kill switch" to stop a misbehaving function from running without deleting it.
• BZero reserved concurrency does the opposite — it eliminates the function's execution capacity rather than granting it unlimited capacity.
• CSetting concurrency to 0 doesn't delete the function or its configuration; it just prevents it from being invoked until changed.
• DThis setting has a very real, immediate effect — it blocks the function from executing at all while set to 0.

Answer: A) Create a CloudFront invalidation for the affected path(s)

• AAn invalidation request tells CloudFront to treat cached copies of the specified paths as expired immediately, forcing the next request to fetch a fresh copy from the origin, rather than waiting for the normal TTL to elapse.
• BRecreating the whole distribution is a drastic, disruptive way to solve what invalidation handles directly and non-disruptively for specific paths.
• CA version ID changing in S3 doesn't automatically invalidate CloudFront's existing cached copy — an explicit invalidation (or a cache-busting filename/version in the URL) is needed.
• DRead replicas are a relational database concept, unrelated to CloudFront's caching of S3 content.

Answer: A) One GSI can serve several different query patterns across entity types, so the table needs fewer GSIs than one per access pattern

GSI overloading reuses generically named GSI key attributes across entity types. This lets one index support many access patterns and reduces the number of GSIs a single-table design needs.

• ACorrect. The same attribute can hold different kinds of information in different items. Because of this, one GSI keyed on generic attributes can answer several different queries, such as looking up an employee by name, finding employees by warehouse, or listing recent hires. This lets you index far more data fields than the GSI count alone would suggest.
• BIncorrect. Overloading does not change the GSI quota, which defaults to 20 per table. Its value is that you can index across more than 20 data fields while staying within that quota.
• CIncorrect. You still choose the projection (KEYS_ONLY, INCLUDE, or ALL) when you define the GSI. Overloading the key attributes does not change which attributes are projected.
• DIncorrect. GSIs support only eventually consistent reads, and overloading does not change this. Overloading only affects how key attributes are reused across entity types.

Answer: A) Set the invoke mode to RESPONSE_STREAM so that Lambda invokes the function with the InvokeWithResponseStream API

Function URLs have two invoke modes. BUFFERED is the default and uses Invoke, returning the full payload up to 6 MB. RESPONSE_STREAM uses InvokeWithResponseStream to stream partial results, up to 200 MB.

• ACorrect. The RESPONSE_STREAM invoke mode makes Lambda use InvokeWithResponseStream, so payload results stream to the client as they become available. Streamed responses can be up to 200 MB.
• BIncorrect. BUFFERED is the default mode. Lambda uses the Invoke API and makes results available only after the payload is complete, with a 6 MB maximum. Nothing is delivered progressively.
• CIncorrect. EVENT is an InvocationType value for the Invoke API (asynchronous invocation), not a function URL invoke mode. Asynchronous invocations return no function output to the caller.
• DIncorrect. The auth type (AWS_IAM or NONE) controls only how requests to the URL are authorized. It has no effect on whether the response is buffered or streamed.

Answer: B) Resend only the entries that have an ErrorCode, with exponential backoff and jitter; E) Add a random suffix, for example 0 to 9, to the hot merchant's partition key so that its records spread across shards

PutRecords can partly fail with HTTP 200; retry only failed entries with backoff. Fix a hot shard by spreading the hot key when ordering isn't needed.

• AIncorrect. Resending successful records creates duplicates and adds load to the throttled shard.
• BCorrect. PutRecords isn't all-or-nothing. Each result entry reports success or an error, and only failed entries need to be retried.
• CIncorrect. Single-record calls hit the same shard limits and add many more requests.
• DIncorrect. Enhanced fan-out raises read throughput for consumers. The throttling here is on writes to one shard.
• ECorrect. One partition key always maps to one shard. Because ordering isn't required, a suffix spreads the hot merchant's writes across shards.

Answer: C) Use the device ID as the partition key

Pick a high-cardinality Kinesis partition key that keeps the required ordering (for example device ID), so load spreads across shards.

• AIncorrect. Random keys spread load but send one device's readings to different shards, so their order is lost.
• BIncorrect. All records with the same partition key still go to one shard, so the hot country's traffic still hits a single shard's limit.
• CCorrect. A high-cardinality key spreads devices across all shards, while all readings from one device still go to the same shard and stay in order.
• DIncorrect. Sending records one at a time adds overhead and doesn't change which shard they go to.

Answer: A) Create an Amazon EventBridge Scheduler one-time schedule for each order, using an at() expression that targets the function

EventBridge Scheduler one-time schedules (at() expressions) run a target once at a set time, to within a minute, and can handle a very large number of schedules. SQS can delay messages by at most 15 minutes, and DynamoDB TTL deletions can lag by days.

• ACorrect. EventBridge Scheduler supports one-time schedules defined with an at() expression, invokes targets with 60-second precision, and can handle millions of schedules. It is built for per-item scheduling like this.
• BIncorrect. SQS message timers and delay queues can delay a message by at most 15 minutes, so a 45-minute delay isn't possible. The SQS documentation points to EventBridge Scheduler for longer delays.
• CIncorrect. DynamoDB deletes expired items on a best-effort basis, typically within a few days of expiry. That is far too imprecise for a 45-minute deadline.
• DIncorrect. The Lambda Invoke API has no parameter for delaying an invocation. An asynchronous invocation is queued and processed as soon as possible.

Answer: A) It retries starting from record 40, so records 41 through 100 are processed again along with the two failed records

For Kinesis and DynamoDB Streams partial batch responses, Lambda checkpoints at the lowest reported sequence number and retries everything after it.

• ACorrect. When several sequence numbers are returned, Lambda uses the lowest as the checkpoint and retries every record from there. The handler must therefore be idempotent.
• BIncorrect. Stream processing is ordered by shard. Lambda can't skip records between failures; it checkpoints and resumes from a position.
• CIncorrect. Lambda uses the lowest sequence number. Starting at record 75 would lose the failure at record 40.
• DIncorrect. Records go to an on-failure destination only after retries are exhausted or the record age limit is reached, not on the first failure.

Answer: A) BatchExecuteStatement, sending all of the INSERT statements together in a single request

BatchExecuteStatement is PartiQL's non-transactional batch operation. It runs up to 25 read-only or write-only statements in one call, and each statement succeeds or fails on its own. ExecuteTransaction is the atomic, all-or-nothing alternative.

• ACorrect. BatchExecuteStatement runs up to 25 PartiQL statements in one call. A single batch must be all reads or all writes. It isn't transactional: each statement returns its own result, and an HTTP 200 response doesn't mean every statement succeeded. The application can check the per-statement Error field and retry only the failures.
• BIncorrect. ExecuteTransaction is all-or-nothing. If any statement fails, the whole transaction is canceled with TransactionCanceledException, so none of the writes are applied. That conflicts with the requirement that the other INSERTs still succeed.
• CIncorrect. ExecuteStatement runs one PartiQL statement per call. It would work, but it needs up to 20 round trips instead of one, which fails the requirement to minimize network calls.
• DIncorrect. BatchWriteItem is a classic DynamoDB API, not a PartiQL operation. Using it would mean leaving the PartiQL interface the application uses for all DynamoDB access, when a PartiQL batch operation already exists.