Application Code on AWS

Coupling, state, and sync vs. async: the one model

When one component calls another, three choices decide how well the pair survives load and failure: do they talk directly or through a managed intermediary, is the call synchronous or asynchronous, and does the worker hold state or not. Those three axes resolve most DVA-C02 design stems on this page, and everything later hangs off them.

Tight vs. loose coupling. Two components are tightly coupled when the caller invokes the worker directly and blocks until it answers: if the worker is slow or down, the caller fails too. The fix the exam rewards is loose coupling. Insert a managed buffer (an Amazon SQS queue, an Amazon SNS topic, or an Amazon EventBridge bus) so the producer hands off the message and returns immediately while the consumer works on its own schedule. The single mental model for all three services: a buffer between caller and worker that lets them scale, retry, and fail independently. A backlog then shows up as queue depth, not as caller errors. The services differ only in who reads each message (developed in the next section).

Synchronous vs. asynchronous. A synchronous call blocks the caller until a result returns (an API Gateway REST request hitting a Lambda function and waiting for the JSON response). An asynchronous call hands the work off and returns before it finishes (publishing to SNS, putting a message on SQS, or invoking Lambda with the Event invocation type). Asynchronous is how you get loose coupling, but it changes the contract: the caller no longer learns the outcome inline, so failures surface later through retries, dead-letter queues, or destinations rather than as an immediate error.

Stateful vs. stateless. A stateless component keeps no client-specific data between requests, so any instance can serve any request. That is what lets a fleet (or a pool of Lambda execution environments) scale horizontally and lets one worker's failure be retried on another. A stateful component remembers prior requests in local memory, which breaks horizontal scaling because a follow-up request must reach the same instance. The exam's rule: push shared state out of the compute tier into a managed store, Amazon DynamoDB^[1], Amazon ElastiCache^[2], or an SQS queue, so the compute stays stateless and disposable. Statelessness is also what makes a retry safe, which the idempotency section builds on.

The shared model behind SQS, SNS, and EventBridge: a managed buffer makes a worker outage show up as backlog, not as caller failure.

Choosing the messaging backbone: SQS vs. SNS vs. EventBridge

All three services are the buffer from the previous section; this section explains how each delivers a message so you can match the service to the stem. The deciding question is who reads each message: one consumer from a competing pool (SQS), every subscriber in parallel (SNS), or every target whose rule matches the event's content (EventBridge).

Amazon SQS: poll-based queue, one consumer per message. A queue holds messages until a consumer polls and deletes them; competing consumers share the load, so SQS is the choice for work distribution, load leveling, and durable buffering. Messages persist for a retention period of 4 days by default, up to 14 days maximum^[3]. Visibility timeout is the core queue-semantics fact: when a consumer receives a message it becomes invisible to others for the timeout window (30 seconds default, 12 hours maximum^[3]); if the consumer deletes it before the window expires it is gone, but if processing exceeds the window the message reappears and may be processed twice, so for Lambda consumers AWS recommends setting the visibility timeout to at least six times the function timeout^[3]. Standard vs. FIFO is the other core split: Standard queues give at-least-once delivery with best-effort ordering at nearly unlimited throughput; FIFO queues give first-in-first-out ordering and exactly-once processing^[4] within a deduplication interval, at a lower throughput ceiling. When a Lambda event source mapping reads a queue, the batch size defaults to 10, up to 10,000 for Standard queues but only 10 for FIFO^[5], and any batch size over 10 requires MaximumBatchingWindowInSeconds of at least 1.

Amazon SNS: push-based pub/sub, every subscriber gets a copy. A publisher sends one message to a topic and SNS pushes a copy to every subscriber in parallel, the fanout pattern. SNS does not store messages for later polling; a subscriber offline at publish time loses that message unless an SQS queue is subscribed to buffer it. That is why the canonical resilient fanout^[6] subscribes several SQS queues to one SNS topic (diagrammed below): each downstream system gets its own durable copy. Subscription filter policies^[7] let a subscriber receive only messages whose attributes match, so you can fan out selectively.

Amazon EventBridge: content-based event router. EventBridge routes events to targets by rules that match fields inside the event JSON, not just a flat topic. Reach for it when routing depends on event content, when you consume AWS-service or SaaS event sources, or when you need a schema registry and an archive with replay^[8]. One reconciliation worth fixing now: an EventBridge archive retains events for a configurable number of days but defaults to indefinite retention; do not assume a 24-hour default. Rule of thumb: raw throughput and load leveling → SQS; one event to many endpoints → SNS; routing by event content or external sources → EventBridge.

Canonical SNS-to-SQS fanout: one publish, a durable copy pushed to every subscribed queue, each polled by its own worker.

Idempotency, retries, and calling AWS with the SDK

An asynchronous backbone delivers at-least-once, so the same message can arrive twice and your consumer code must survive that. Building on the messaging backbone above, this section is about what the consumer does with each delivery: why it must be idempotent, and how the AWS SDK already handles transient failures so you do not hand-roll them.

Why idempotency is mandatory. Standard SQS delivery, SNS delivery to each subscriber, and EventBridge delivery to each target are all at-least-once. AWS states a Standard queue means "more than one copy of a message might be delivered" and ordering is best-effort. A consumer is idempotent when processing the same message twice yields the same result as processing it once. The exam's canonical implementation: derive a stable key from the message (its message ID or a business key) and write it with a DynamoDB conditional write^[9] using attribute_not_exists. The first delivery's write succeeds and the consumer runs its side effects; the second delivery's write fails the condition, so the duplicate is dropped without re-running side effects (the dedup flow is diagrammed above). If duplicates are simply unacceptable and ordering is required, switch to an SQS FIFO queue, whose exactly-once processing removes the burden from your code at the cost of throughput.

Retries with exponential backoff and jitter. When a dependency throttles or returns a 5xx, retrying immediately and in lockstep across many callers creates a synchronized retry storm. The fix the exam expects is exponential backoff (each retry waits roughly double the previous delay) plus jitter (a random offset) so callers spread out instead of retrying in unison. The key point: the AWS SDKs already implement automatic retries with exponential backoff and jitter^[10] for throttling and transient errors, so you tune the SDK's retry configuration (retry mode, max attempts) rather than writing sleep loops by hand. Reserve hand-written retry-with-backoff, and a circuit breaker that stops calling a dependency that keeps failing, for third-party HTTP integrations the SDK does not own, so a failing downstream does not exhaust your function's concurrency.

Calling AWS services: SDK and CLI. Application code reaches AWS services through the language-specific AWS SDK (Boto3 for Python^[11], AWS SDK for JavaScript v3^[12], and others), and the AWS CLI does the same from the shell. Both resolve credentials through the default credential provider chain^[13]. On Lambda or EC2 this means the attached IAM role's temporary credentials, never long-lived access keys baked into code. The SDK signs every request with those credentials (SigV4) automatically. The exam-correct posture: grant the compute an IAM role, let the SDK pull role credentials from the chain, and never embed access keys in source or environment variables.

Idempotent consumer under at-least-once delivery: a DynamoDB conditional write lets the first copy run side effects and silently drops every duplicate.

Exam-pattern recognition: stem cues to service

This section is the page's payoff: map the recurring DVA-C02 stem signals to the right answer and name why the common distractors fail. Each rule restates a fact from the sections above, see those for the full explanation.

Cue: "decouple," "absorb spikes," "process on its own schedule," "a slow background job." → Amazon SQS between the request tier and the worker. The request returns immediately and a worker drains the queue. Distractor that fails: calling the worker synchronously (re-creates the tight coupling) or using SNS alone (no durable buffer, an offline worker loses the message).

Cue: "one event must trigger several independent systems," "notify multiple endpoints," "fanout." → Amazon SNS, and if each consumer needs a durable, independently-processed copy, the SNS-to-SQS fanout (subscribe one SQS queue per consumer). Distractor that fails: a single SQS queue, its message goes to only one consumer from the pool, not all of them.

Cue: "route based on the content of the event," "match a field in the event," "events from a SaaS / AWS service," "replay past events." → Amazon EventBridge with content-based rules and an archive. Distractor that fails: SNS subscription filters operate on message attributes, not arbitrary fields in the event body, and SNS has no replay.

Cue: "messages are being processed more than once," "duplicate side effects," "at-least-once." → make the consumer idempotent (DynamoDB conditional write on a dedup key); if strict ordering and no duplicates are required, use an SQS FIFO queue. Distractor that fails: increasing the visibility timeout alone does not prevent duplicates inherent to at-least-once delivery, it only reduces re-delivery while a single consumer is still working.

Cue: "a message reappears and is processed again before the consumer finishes," "Lambda times out and the message comes back." → the visibility timeout is too short; raise it to at least six times the consumer/Lambda timeout. Distractor that fails: changing the retention period (controls how long an unconsumed message survives, not in-flight invisibility).

Cue: "throttling errors / 5xx when calling an AWS API," "retry storm," "calls fail under load." → rely on the SDK's built-in exponential backoff with jitter (tune retry config); add a custom circuit breaker only for third-party dependencies. Distractor that fails: a fixed-interval sleep retry loop (no jitter → synchronized retries) or hardcoding access keys instead of using the role's credentials from the provider chain.

Cue: "ordered, auditable, multi-step workflow," "need to see where it failed," "exactly-once." → AWS Step Functions Standard workflow (orchestration: central state, built-in Retry/Catch, exactly-once execution). Distractor that fails: pure event choreography via SNS/EventBridge, scalable but with no central coordinator it is hard to trace end-to-end; and Express workflows lack Standard's exactly-once execution either way. Asynchronous Express is at-least-once (the figure the overview and cheat-sheet cite) while synchronous Express is at-most-once, so neither matches the exactly-once a durable workflow stem asks for.

SQS vs SNS vs EventBridge: picking the messaging backbone

Dimension	Amazon SQS	Amazon SNS	Amazon EventBridge
Model	Queue (poll-based, pull)	Pub/sub topic (push)	Event bus / router (push)
Consumers per message	One consumer from a competing pool	All subscribers in parallel (fanout)	All matching rule targets
Routing logic	None: FIFO or unordered draining	Subscription filter policies on attributes	Content-based rules matching event JSON
Durability / retention	Persists 4 days default, 14 days max	No storage; deliver-then-forget	Optional archive (retention defaults to indefinite)
Delivery guarantee	Standard at-least-once; FIFO exactly-once	At-least-once to each subscriber	At-least-once to each target
Best for	Work distribution, load leveling, buffering	Fanout one event to many endpoints	Event-driven routing, SaaS/AWS event sources, replay

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Loose coupling means putting a managed buffer between caller and worker

Two components are tightly coupled when the caller invokes the worker directly and blocks for the answer, so a slow or down worker fails the caller too. The fix is to insert a managed intermediary (an Amazon SQS queue, an Amazon SNS topic, or an Amazon EventBridge bus) so the producer hands off and returns immediately while the consumer works on its own schedule. Decoupled, the two scale, retry, and fail independently, and a worker outage shows up as queue depth rather than caller errors.

Trap Adding more compute capacity to the worker to stop a slow worker from failing the caller, when the real fix is to decouple them with a managed buffer so the caller no longer blocks on the worker at all.

Asynchronous handoff changes the contract: the caller no longer learns the outcome inline

A synchronous call blocks until a result returns, like an API Gateway request waiting on a Lambda response; an asynchronous call hands the work off and returns before it finishes, like publishing to SNS, enqueuing to SQS, or invoking Lambda with the Event invocation type. Asynchronous is what buys loose coupling, but because the caller gets no inline result, failures surface later through retries, dead-letter queues, or destinations instead of as an immediate error.

Trap Expecting an asynchronous (Event) invocation to return the function's result to the caller, when it returns immediately after accepting the request and the outcome surfaces only later through retries, a DLQ, or destinations.

Push shared state out of the compute tier so the compute stays stateless and disposable

A stateless component keeps no client-specific data between requests, so any instance (or any Lambda execution environment) can serve any request, which is what lets a fleet scale horizontally and lets a failed unit's work be retried elsewhere. A stateful component remembers prior requests locally, breaking horizontal scaling because a follow-up must reach the same instance. Move shared state into a managed store such as DynamoDB, ElastiCache, or an SQS queue; statelessness is also what makes a retry safe to repeat.

Trap Storing session or client-specific state in a Lambda function's /tmp or in module-level globals to persist it between requests, when the execution environment is reused unpredictably and never guaranteed, so shared state belongs in DynamoDB or ElastiCache.

1 question tests this

A development team is building a web application that runs on Amazon EC2 instances behind an Application Load Balancer with Auto Scaling.…

Pick the messaging service by who reads each message

The deciding question across SQS, SNS, and EventBridge is who consumes a given message. SQS delivers each message to exactly one consumer from a competing pool, so it suits work distribution and load leveling. SNS pushes a copy to every subscriber in parallel, so it suits fanout to many endpoints. EventBridge routes to every target whose rule matches fields inside the event JSON, so it suits content-based routing and consuming AWS-service or SaaS event sources.

Trap Picking SNS to distribute a workload across a pool of competing workers so each item is handled once, when SNS copies every message to every subscriber; single-consumer-per-message work distribution is SQS.

SQS is a poll-based queue where one consumer claims each message

An SQS queue durably holds messages until a consumer polls and explicitly deletes them, and competing consumers share the load, so it is the choice for distributing work, leveling spiky load, and buffering between tiers. Because each message is claimed by one consumer at a time, SQS is not a fanout mechanism. If several independent systems each need the same message, give each its own queue.

Trap Reaching for a single SQS queue to notify several independent systems: the message goes to just one consumer from the pool, not to all of them.

SQS messages are retained 4 days by default, up to 14 days maximum

An unconsumed SQS message survives for the queue's retention period, which defaults to 4 days and can be raised to a 14-day maximum, after which SQS deletes it automatically. Retention governs how long an undelivered message waits for a consumer. It is unrelated to how long an in-flight message stays hidden while one consumer works on it.

Trap Raising the retention period to stop a message from reappearing mid-processing: retention controls how long an unconsumed message lives, not in-flight invisibility, which is the visibility timeout.

Visibility timeout hides a received message so a second consumer doesn't grab it

When a consumer receives an SQS message it becomes invisible to other consumers for the visibility-timeout window, which defaults to 30 seconds and can be set up to 12 hours. If the consumer deletes the message before the window expires it is gone for good; if processing overruns the window the message reappears and may be processed again. So size the timeout to the real processing time, not the default.

Trap Leaving the visibility timeout at the 30-second default when processing routinely takes longer, so the message reappears and a second consumer reprocesses it before the first one finishes.

1 question tests this

A developer is troubleshooting an Amazon SQS consumer application that occasionally processes the same message multiple times. The…

Standard queues are at-least-once with best-effort ordering; FIFO queues add ordering and exactly-once processing

An SQS Standard queue gives at-least-once delivery (AWS states more than one copy of a message might be delivered) with only best-effort ordering, in exchange for nearly unlimited throughput. A FIFO queue preserves first-in-first-out order and provides exactly-once processing within its deduplication interval, at a lower throughput ceiling. Choose FIFO only when ordering or no-duplicates is a hard requirement, because it trades away throughput.

Trap Assuming a Standard queue preserves order because messages usually arrive in sequence: ordering is only best-effort, and duplicates can occur; strict order or no-duplicates needs FIFO.

High-throughput FIFO mode raises a FIFO queue's per-queue throughput when you need more

A plain FIFO queue trades throughput for ordering and exactly-once processing. When you need higher throughput while keeping FIFO semantics, enable high-throughput FIFO mode, which raises the per-queue / per-API-action quota and scales with the number of distinct message group IDs: spreading messages across more message groups increases capacity. Without enough distinct group IDs the throughput gain doesn't materialize.

Trap Enabling high-throughput FIFO but routing every message through one message group ID, so the throughput stays bottlenecked because capacity scales with the number of distinct group IDs.

A Lambda SQS event source mapping batches up to 10,000 messages for Standard but only 10 for FIFO

The Lambda SQS event source mapping reads messages in batches with a batch size that defaults to 10. Standard queues allow up to 10,000 messages per batch, but FIFO queues are capped at 10. Any batch size above 10 also requires a MaximumBatchingWindowInSeconds of at least 1 second so Lambda waits long enough to fill the larger batch.

Trap Setting a batch size above 10 for a FIFO source queue, which is capped at 10; the larger 10,000-message batches apply only to Standard queues.

SNS is push-based pub/sub that delivers a copy to every subscriber: the fanout pattern

A publisher sends one message to an SNS topic and SNS pushes a copy to every subscriber in parallel, which is the fanout pattern for triggering several independent systems from one event. SNS does not store messages for later polling, so a subscriber that is offline at publish time loses that message. It is the right tool when one event must reach many endpoints at once.

Trap Assuming an offline SNS subscriber will pick up the message later: SNS is deliver-then-forget and keeps nothing for polling, so the message is lost unless a queue buffers it.

Subscribe an SQS queue per consumer to SNS for durable, independent fanout

Because SNS itself keeps no copy, the resilient fanout pattern subscribes an SQS queue to the SNS topic for each downstream consumer. SNS pushes the message to every queue, and each consumer polls its own durable copy on its own schedule, so a consumer that is offline at publish time still processes the message when it returns. This combines SNS's one-to-many fanout with SQS's durability.

Trap Subscribing one shared SQS queue to the topic for several consumers, which makes them compete for each message so only one processes it; durable independent fanout needs one queue per consumer.

3 questions test this

SNS subscription filter policies match on message attributes, not arbitrary body fields

An SNS subscription filter policy lets a subscriber receive only messages whose message attributes match the policy, so you can fan out selectively from one topic. The match is on attributes, not on arbitrary fields inside the message body. If routing must depend on content within the event JSON, that is EventBridge's job, not SNS's.

Trap Expecting an SNS filter policy to route on a field buried in the message body: SNS filters match message attributes only; content-based routing on the event JSON is EventBridge.

EventBridge routes events to targets by rules that match fields inside the event JSON

EventBridge is a content-based event router: rules match on fields within the event's JSON body and deliver to the targets whose rule matches, rather than to a flat topic of subscribers. Reach for it when routing depends on event content, when consuming AWS-service or SaaS partner event sources, or when you need a schema registry. It delivers at-least-once to each target, just like SQS Standard and SNS.

Trap Choosing SNS subscription filter policies to route on fields inside the event payload, when those filters match only message attributes; matching on the event JSON body is EventBridge's content-based routing.

An EventBridge archive retains events indefinitely by default and can replay them

EventBridge can archive matching events and later replay them onto a bus, useful for reprocessing or recovery. The archive's retention is configurable in days, but it defaults to indefinite retention, not a short window, so events are kept until you set a limit. SNS has no comparable replay; needing to replay past events is a strong cue for EventBridge.

Trap Assuming an EventBridge archive defaults to a short retention like 24 hours: the default is indefinite retention until you configure a day limit.

At-least-once delivery makes idempotent consumers mandatory

SQS Standard delivery, SNS delivery to each subscriber, and EventBridge delivery to each target are all at-least-once, so a consumer can legitimately receive the same message more than once. A consumer is idempotent when processing the same message twice yields the same result as once. Without idempotency, duplicate deliveries produce duplicate side effects (double charges, double records), so design the consumer to tolerate repeats.

Trap Trusting that a Standard queue or SNS delivers each message exactly once so the consumer need not handle repeats, when these services are at-least-once and duplicates are expected, not exceptional.

1 question tests this

A financial services company uses AWS Lambda with an Amazon EventBridge rule to process stock trade events. Due to network issues, the same…

Implement idempotency with a DynamoDB conditional write on a dedup key

The canonical idempotency implementation derives a stable key from the message (its message ID or a business key) and writes it to DynamoDB with a conditional attribute_not_exists check. The first delivery's write succeeds; a duplicate delivery fails the condition, so the consumer skips the side effect instead of re-running it. If duplicates are simply unacceptable and ordering matters, an SQS FIFO queue removes the burden from your code instead.

Trap Keying the dedup record on a value that changes between deliveries of the same logical message rather than a stable message ID or business key, so the conditional write never collides and duplicates slip through.

3 questions test this

Retry transient failures with exponential backoff plus jitter, not fixed-interval loops

When a dependency throttles or returns a 5xx, retrying immediately and in lockstep across many callers creates a synchronized retry storm that keeps the dependency overwhelmed. Exponential backoff roughly doubles the wait each attempt, and jitter adds a random offset so callers spread out instead of retrying in unison. Together they let a struggling dependency recover.

Trap Using a fixed-interval sleep-and-retry loop: without jitter every caller retries in unison, re-creating the retry storm the backoff was meant to avoid.

5 questions test this

The AWS SDK already retries throttling and transient errors, so tune its config instead of hand-rolling

The AWS SDKs implement automatic retries with exponential backoff and jitter for throttling and transient errors, so you adjust the SDK's retry configuration (retry mode and max attempts) rather than writing sleep loops by hand. Reserve custom retry-with-backoff, and a circuit breaker that stops calling a dependency that keeps failing, for third-party HTTP integrations the SDK does not own, so a failing downstream doesn't exhaust your function's concurrency.

Trap Hand-coding an exponential-backoff retry loop around AWS SDK calls to handle throttling, when the SDK already retries those errors and you only need to tune its retry mode and max attempts.

3 questions test this

Let the SDK pull temporary role credentials from the provider chain: never hardcode access keys

Application code reaches AWS through the language-specific AWS SDK (Boto3, AWS SDK for JavaScript v3, others) and the AWS CLI from the shell; both resolve credentials through the default credential provider chain. On Lambda or EC2 that means the attached IAM role's temporary credentials, and the SDK signs every request with them (SigV4) automatically. Grant the compute a role and let the SDK pull credentials from the chain rather than baking long-lived access keys into source or environment variables.

Orchestration centralizes workflow control; choreography distributes it

In orchestration a single coordinator (an AWS Step Functions state machine) drives the steps, owns retries, and holds the workflow state in one place, which makes runs easy to visualize and debug. In choreography each service reacts to events via SNS or EventBridge with no central brain, which is looser and more scalable but hard to trace end-to-end. Choose orchestration when a multi-step workflow must be auditable and centrally coordinated.

Trap Using pure SNS/EventBridge choreography for a workflow that must be debugged end-to-end: with no central coordinator, tracing where a multi-step run failed is hard; Step Functions orchestration gives that visibility.

Step Functions Standard workflows are exactly-once with built-in Retry/Catch; Express trades that for high volume

A Step Functions Standard workflow gives exactly-once execution, an auditable run history, and built-in Retry and Catch with backoff per state: the right fit for ordered, durable, traceable multi-step processes. Express workflows are tuned for high-volume, short-duration runs and do not provide the exactly-once durability of Standard. When a stem asks for an ordered, auditable workflow with visible state, that points to Standard.

Trap Choosing Express workflows for a long-running, auditable, exactly-once process because they cost less per run, when Express favors high-volume short bursts and gives up the exactly-once durability and full run history Standard provides.

Long polling eliminates empty SQS ReceiveMessage responses and cuts cost

When an SQS consumer keeps getting empty ReceiveMessage responses on a sporadic queue and paying for those calls, enable long polling by setting ReceiveMessageWaitTimeSeconds to a value from 1 to 20 seconds (20 is the maximum). Long polling queries all SQS servers and waits until a message is available or the wait time expires, so it returns far fewer empty responses, lowers request cost, and still delivers messages promptly. Short polling (wait time 0) is the default and is what generates the costly empty replies.

Trap Switching to short polling, raising the visibility timeout, or adding more consumers to fix empty responses: the dial that removes empty responses is long polling via ReceiveMessageWaitTimeSeconds.

6 questions test this

Route poison SQS messages to a DLQ with a redrive policy and maxReceiveCount

To stop messages that repeatedly fail from blocking a queue, configure a redrive policy on the source queue that names the dead-letter queue in deadLetterTargetArn and sets maxReceiveCount to the number of receives allowed before SQS moves the message to the DLQ (for example 5). The DLQ must be the same type as the source: a FIFO source needs a FIFO DLQ. The redrive policy lives on the source queue, not the DLQ.

Trap Setting the redrive policy on the dead-letter queue itself: the policy and maxReceiveCount belong on the SOURCE queue, which points at the DLQ.

7 questions test this

ReportBatchItemFailures retries only the failed records in a batch

By default, when one record in a Lambda batch from SQS, Kinesis, or DynamoDB Streams fails, the whole batch is retried and already-succeeded records are reprocessed. To retry only the failures, set the event source mapping's FunctionResponseTypes to ReportBatchItemFailures and return a batchItemFailures list containing the identifiers (messageId for SQS, sequence number for Kinesis/DynamoDB Streams) of just the failed records. Lambda then makes only those records visible again.

Trap Expecting partial-batch behavior automatically: without ReportBatchItemFailures enabled AND a batchItemFailures response, a single failure re-drives the entire batch.

5 questions test this

Lambda proxy integration passes the whole request in the event object

With Lambda proxy integration (AWS_PROXY), API Gateway maps the entire client request into the Lambda event object: event.httpMethod, event.path, event.pathParameters, event.queryStringParameters, event.headers, and the raw event.body (a string the function must parse, e.g. json.loads). Caller metadata such as the source IP and stage name live under event.requestContext (requestContext.identity.sourceIp, requestContext.stage). The function reads request data from this event rather than from any framework-style request object.

Trap Multi-value headers and query strings are NOT in headers/queryStringParameters: they are exposed separately as multiValueHeaders and multiValueQueryStringParameters.

10 questions test this

A proxy-integration Lambda must return statusCode, headers, and a string body or API Gateway answers 502

With Lambda proxy integration the function itself shapes the HTTP response, which must be a JSON object with an integer statusCode, a headers map, and a body that is a STRING (serialize objects yourself). If the function returns a malformed shape (a bare object, a non-string body, or missing statusCode), API Gateway cannot translate it and returns 502 Bad Gateway with 'Internal server error', even though the function ran successfully.

Trap Seeing a 502 with successful function logs and blaming the function code: the cause is almost always a response not in the {statusCode, headers, body-as-string} shape.

2 questions test this

With proxy integration, CORS headers must come from the Lambda response

Under Lambda proxy integration, API Gateway passes responses straight through, so the actual cross-origin headers (Access-Control-Allow-Origin, and as needed Access-Control-Allow-Methods/Headers) must be added by the Lambda function in its response object. The console's 'Enable CORS' only wires up the OPTIONS preflight (a MOCK integration) and cannot inject headers into your GET/POST responses. Configure both: an OPTIONS method for preflight plus the headers returned by the function.

Trap Assuming the console 'Enable CORS' button alone fixes proxy-integration CORS: it handles only preflight; the per-method response headers still have to be returned by the Lambda function.

8 questions test this

API Gateway request validation rejects bad payloads before the backend runs

To validate that requests carry required fields and conform to types/ranges without writing validation in Lambda, define a JSON Schema model in API Gateway and attach a request validator (with ValidateRequestBody enabled) to the method. API Gateway checks the body against the model and returns 400 Bad Request itself for invalid requests, so the backend Lambda is never invoked, saving cost and centralizing validation.

Trap Validating required fields inside the Lambda function when the goal is to block invalid requests early: a model plus request validator rejects them at API Gateway before invocation.

4 questions test this

Use non-proxy (custom AWS) integration with VTL mapping templates to transform requests/responses

When the API must reshape the payload (transform the incoming request before Lambda, convert the Lambda response before the client, or override the status code) use Lambda custom (non-proxy, AWS-type) integration and write Velocity Template Language (VTL) mapping templates in the integration request and integration response. Lambda proxy integration passes data through unchanged and offers no mapping templates, so it cannot do this transformation.

Trap Choosing proxy integration when payload transformation/mapping templates are required: proxy is pass-through; mapping templates exist only on non-proxy (AWS) integrations.

6 questions test this

Lambda authorizers do custom auth and return an IAM policy; TOKEN vs REQUEST differ by identity source

For authorization logic API Gateway can't do natively (validating a JWT, checking custom claims, or querying a database) use a Lambda authorizer, which returns an IAM policy (Allow/Deny) plus an optional context object passed to the backend. A TOKEN authorizer takes a single bearer token from one header and can pre-screen it with a regex before invoking; a REQUEST authorizer can use multiple identity sources (headers, query strings, stage variables) as both input and the authorization cache key.

Trap Reaching for a Cognito authorizer when business rules require a database lookup or multi-source input: that custom logic needs a Lambda authorizer (REQUEST type for multiple identity sources).

4 questions test this

Coupling, state, and sync vs. async: the one model

Choosing the messaging backbone: SQS vs. SNS vs. EventBridge

Idempotency, retries, and calling AWS with the SDK

Exam-pattern recognition: stem cues to service

SQS vs SNS vs EventBridge: picking the messaging backbone

Decision tree

Cheat sheet

Also tested in

References