DVA-C02 Cheat Sheet

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

Memory is the only direct sizing dial on a Lambda function, settable from 128 MB to 10,240 MB, and vCPU is allocated proportionally rather than configured separately. A function reaches roughly one full vCPU at 1,769 MB and up to six vCPUs at the maximum, so a CPU-bound function can finish faster at higher memory and sometimes cost less overall even though the per-millisecond rate rises. Treat memory as the performance tuning knob, not just a capacity ceiling.

Trap Assuming raising memory always costs more: for a CPU-bound function the shorter duration can offset or beat the higher per-ms rate.

A single Lambda execution can run at most 15 minutes (900 seconds), the maximum configurable timeout. Work that needs longer must be split into smaller invocations or moved to a service built for long-running compute such as ECS, Fargate, or Step Functions for orchestration.

Lambda runs everything outside the handler (SDK clients, database connection pools, configuration loads) once during the init phase of a new execution environment, then reuses that warm environment across later invocations where only the handler body runs. This is why you place expensive setup at module scope: it is amortized across many requests instead of repeated per call.

Trap Putting SDK client and connection-pool setup inside the handler, where it re-runs on every invocation and throws away the warm-environment reuse that makes module-scope init cheap.

Each execution environment gets an ephemeral /tmp directory, configurable from 512 MB up to 10,240 MB (10 GB), that lives only for the life of that environment and can vanish at any time. Use it for scratch work within an invocation, but never as a database or for state that must survive: persist anything durable to S3, DynamoDB, or EFS instead.

Trap Caching data in /tmp and expecting later invocations to read it: a fresh environment starts with an empty /tmp and the data is gone.

A Lambda layer packages shared libraries, a custom runtime, or dependencies separately so multiple functions reuse them instead of bundling the same code into every deployment package. You can attach up to five layers to a function, and their unzipped contents count against the same 250 MB unzipped limit as the function code.

Trap Treating layers as a way around the 250 MB unzipped limit, when layer contents count against that same ceiling and so don't expand your total package budget.

A .zip deployment package is limited to 50 MB when uploaded directly and 250 MB unzipped including all attached layers, and uploading the zip from S3 raises only the direct-upload limit, not the 250 MB unzipped ceiling. A container image pushed to Amazon ECR raises the ceiling all the way to 10 GB, so large dependency trees, ML models, or custom runtimes point to a container image rather than a zip.

Trap Reaching for an S3-hosted zip to fit a 400 MB dependency tree: S3 lifts the upload size but the 250 MB unzipped limit still applies, so the answer is a container image.

The execution role is the IAM role a Lambda function assumes at runtime to call other AWS services, such as reading a DynamoDB table or writing to S3: it is the function's outbound permission set. Without the right action in this role, the function's own SDK calls to other services fail with access-denied, regardless of who is allowed to invoke the function.

Trap Fixing the function's own access-denied SDK calls by editing who can invoke it, when outbound calls fail because the execution role lacks the action, not because of an invoke permission.

A Lambda function's resource-based policy controls inbound access: which accounts or services (API Gateway, Amazon S3, EventBridge, SNS) are permitted to invoke it. When you wire up an S3 event or an API Gateway integration, that grant is added here: it governs the opposite direction from the execution role, so anchor the two by direction of access.

Trap Adding the invoke permission to the execution role: inbound invoke rights belong on the function's resource-based policy, not the role the function assumes.

For poll-based sources like SQS, Kinesis Data Streams, and DynamoDB Streams there is no resource-based policy granting them inbound access, because Lambda itself reads from the source on your behalf. The execution role must therefore carry the polling permissions (such as sqs:ReceiveMessage or the stream read/describe actions). Push sources need the resource policy; poll sources need the execution role.

Trap Adding a resource-based policy to let SQS or Kinesis invoke the function, when poll sources are read by Lambda using the execution role's permissions, so the resource policy does nothing here.

A synchronous (RequestResponse) invocation (API Gateway, the CLI invoke default) runs the function and returns the result to a caller that waits. Lambda performs no retry on its own, so if the function errors the caller decides what happens next; a 500 from API Gateway means the client (or the integration) must handle the retry and error path.

Trap Expecting Lambda to retry a failed synchronous invocation, when on the RequestResponse path Lambda retries nothing and the waiting caller owns the retry and error handling.

An asynchronous (Event) invocation (S3 events, EventBridge, SNS) hands the event to an internal Lambda-managed queue and immediately returns a 202, so the caller does not wait. Because the caller is already gone, Lambda owns the retries and re-attempts a failed invocation twice by default (three attempts total) with delays before the event is dropped unless you capture it.

Trap Reading the immediate 202 from an async invocation as the function having succeeded, when it only means the event was accepted onto Lambda's queue and the function may still fail and be retried.

For asynchronous invocations, a dead-letter queue (an SQS queue or SNS topic) receives only the failed event payload, whereas Lambda destinations route both success and failure outcomes (with richer context including the request, response, and error) to SQS, SNS, EventBridge, or another function. Destinations are the modern, preferred mechanism, so when a question asks how to capture both success and failure of an async invocation, the answer is destinations.

Trap Choosing a dead-letter queue to capture successful async outcomes: a DLQ only ever receives failed events; success capture requires destinations.

An event source mapping is a Lambda-managed poller for stream and queue sources (SQS, Kinesis Data Streams, DynamoDB Streams, Amazon MSK) that reads records, groups them into a batch, and invokes the function with that batch. The mapping (not the function) owns the tuning and retry behavior, which is the key distinction from async invocation where retry settings live on the function.

Trap Tuning batch and retry behavior for an SQS or Kinesis source on the function's async settings, when for poll-based sources those settings live on the event source mapping instead.

An event source mapping's batch size sets the maximum records per invocation, while the batch window (MaximumBatchingWindowInSeconds, up to 300 seconds) lets the poller wait to accumulate a fuller batch before invoking. Raising either reduces the number of invocations at the cost of added latency, so tune them together to balance throughput against how quickly records must be processed.

Trap Raising the batch window to cut invocation count without expecting added latency, when the poller waits to fill the batch, so records sit longer before processing.

When SQS is the event source, set the source queue's visibility timeout to at least six times the function's timeout. The longer window keeps an in-flight batch hidden from other consumers while the function processes it, so a slow batch is not redelivered and processed twice before the original invocation finishes.

Trap Leaving the SQS visibility timeout at the 30-second default for a multi-minute function: the message reappears mid-processing and gets handled again.

Concurrency is the number of requests in flight simultaneously across a function, and every function in a Region shares a default account ceiling of 1,000 concurrent executions (raisable via a quota request). Lambda always keeps at least 100 of that pool unreserved as a shared floor, so reserving capacity for one function can never starve all the others below that minimum.

Trap Reserving concurrency until the pool's unreserved remainder hits zero, when Lambda blocks reservations that would drop the shared unreserved floor below 100.

Reserved concurrency carves out a guaranteed slice of the account pool for one function and simultaneously caps that function at that number. It protects a downstream resource (say a database with a fixed connection limit) from being overwhelmed and guarantees the function some capacity against noisy neighbors. It adds no extra charge and pre-warms nothing, so a reserved environment still cold-starts.

Trap Reaching for reserved concurrency to eliminate cold starts: it caps and guarantees capacity but pre-warms nothing; the latency fix is provisioned concurrency.

A cold start is the latency added when a request lands with no warm environment and Lambda must download code, start the runtime, and run init before the handler. Reduce it by using provisioned concurrency for a deterministic fix, shipping slimmer packages with fewer dependencies for faster download and init, and moving heavy one-time setup outside the handler so it is reused across invocations.

Trap Adding RAM to a function purely to shrink cold starts, when more memory speeds the handler's CPU-bound work but doesn't remove the init phase, whereas provisioned concurrency does.

Publishing a version freezes the function's code and configuration as an immutable, numbered snapshot, while $LATEST is the mutable working copy you keep editing. You publish a version to pin a known-good build that later releases and aliases can point at, since the numbered version can never change after publication.

Trap Expecting to patch the code of a published numbered version in place, when versions are immutable, so a fix means publishing a new version and re-pointing the alias.

An alias is a named, movable pointer (for example prod) to a version, so callers target the alias and you re-point it to ship a release. An alias also supports weighted routing, splitting traffic between two versions (say 90% to v1 and 10% to v2) to run a canary or blue/green rollout and shift weight as confidence grows.

Trap Pointing an alias's weighted routing at $LATEST for a canary, when weighted aliases split traffic between two published numbered versions, not the mutable $LATEST.

Provisioned concurrency is configured on a specific version or alias, not on $LATEST. A deployment that re-points an alias to a fresh, un-provisioned version reintroduces cold starts until provisioning catches up on the new target, so plan provisioning around the release rather than assuming it follows the alias automatically.

Trap Expecting provisioned concurrency to follow an alias to a new version: the new version starts un-provisioned and cold-starts until you provision it.

By default a Lambda function runs in a Lambda-managed network with internet access. Attaching it to a VPC by specifying subnets and security groups lets it reach private resources like an RDS instance, but it then loses default internet egress, so reaching the public internet or AWS service endpoints now requires a NAT gateway or VPC interface endpoints.

Trap Assuming a VPC-attached function keeps internet access: it does not; outbound to the internet or public AWS endpoints needs a NAT gateway or VPC endpoints.

Lambda extracts every attached layer into /opt and adds language-specific subpaths to the search path, so a layer's zip must place dependencies in the directory the runtime expects: python/ (or python/lib/python3.x/site-packages/) for Python, nodejs/node_modules/ for Node.js. Dependencies zipped at the archive root are not found and imports fail with ModuleNotFound. The same rule lets container-image functions reuse a layer by copying its contents into /opt during the Docker build, since layers cannot be attached to container-based functions.

Trap Zipping libraries at the root of the layer archive: they must sit under python/ or nodejs/node_modules/ for the runtime to import them.

A layer's native code is tied to the runtime and platform it was built for: packages compiled against Python 3.12 fail on a 3.9 function, and libraries built on Windows or for the wrong CPU architecture fail in Lambda's Linux environment. Build layer dependencies (especially compiled ones like pandas/numpy) on Linux for the target runtime version and architecture (x86_64 or arm64). Interpreted languages like Go that compile to a single self-contained binary don't benefit from layers: bundle dependencies into the deployment package instead.

Trap Packaging a Lambda layer with pip on a Windows laptop and attaching it directly: Windows-compiled native modules are incompatible with Lambda's Linux runtime.

Grant other accounts use of a layer version with lambda add-layer-version-permission, which sets a resource policy granting lambda:GetLayerVersion. Permissions are per layer VERSION, so each new version must be re-shared. Name a specific account ID as the principal for one account; to share with a whole AWS Organization, set the principal to '*' and pass the organization-id parameter so only accounts in that org can use it.

Trap Assuming sharing a layer covers future versions: each published version is a separate resource, so consumers can't see version N+1 until you run add-layer-version-permission for it.

The AWS Parameters and Secrets Lambda Extension fetches Parameter Store and Secrets Manager values over a local HTTP endpoint and caches them in the execution environment, cutting API calls, latency, and throttling for frequently invoked functions. The cache lifetime is the SSM_PARAMETER_STORE_TTL environment variable: a longer TTL means fewer API calls but a value can stay stale for that window after a change, so lower the TTL when freshness matters. Requests to the extension endpoint must include the X-Aws-Parameters-Secrets-Token header set to AWS_SESSION_TOKEN.

Trap Blaming Parameter Store when a Lambda keeps returning an old value after an update: it is the extension's cache; shorten SSM_PARAMETER_STORE_TTL.

When configuration is organized as a path hierarchy (e.g. /myapp/prod/database/...), retrieve all of it in a single GetParametersByPath call instead of one GetParameter per key; set Recursive=true to include nested levels. Storing the environment name in an env var and building the path lets the same function load per-environment config. The execution role needs ssm:GetParametersByPath permission for that path.

Trap Calling GetParameter (or GetParameters) per key for a whole tree: GetParametersByPath with Recursive=true returns the entire branch in one request.

To make Lambda logs searchable by custom fields (correlationId, errorType, status code) and Lambda context (request ID, function name), output structured JSON, either via the Lambda advanced logging controls (set log format to JSON and an application log level) or the Powertools for AWS Lambda Logger, whose inject_lambda_context decorator auto-adds request context. Then query with CloudWatch Logs Insights using fields/filter/stats, e.g. filter on a field and stats count(*) by bin(1h) to trend errors over time.

Trap Logging free-text strings and trying to parse them later: Logs Insights filters and aggregates by field only when entries are structured JSON.

Authentication and authorization are two separate steps, and an exam scenario almost always turns on telling them apart. Authentication verifies an identity (a SigV4-signed AWS request, a JWT validated by Cognito, or a federated login) while authorization is a distinct policy decision about what that verified identity may do, so a perfectly authenticated caller can still be denied. The practical consequence: a credential that proves identity (a Cognito ID token) is not the credential that grants access (an OAuth 2.0 access token or temporary AWS credentials).

Trap Treating a successful sign-in as proof a call is allowed: authorization is evaluated separately, so an authenticated principal can still hit an explicit deny.

AWS authorization is allow + no-explicit-deny: a request is permitted only when some policy allows the action on the resource AND no policy anywhere contains an explicit Deny. A single explicit Deny overrides every Allow, which is why even an admin principal can be blocked from an S3 bucket whose bucket policy denies its ARN. Anything not explicitly allowed is denied by default (implicit deny), but that default is weaker than an explicit deny. Only an explicit Allow can overcome an implicit deny, and nothing overcomes an explicit one.

Trap Assuming an Allow on an admin or broadly-permissive policy can override an explicit Deny elsewhere, when a single explicit Deny wins over every Allow in the evaluation.

For a request within one account, AWS takes the union of the identity-based policy (attached to the user/role) and the resource-based policy (attached to the S3 bucket, Lambda function, SQS queue, etc.): an Allow in either one (or both) grants the action. Identity-based policies attached to a principal are themselves additive, so multiple attached policies combine. The notable exception is KMS, where the key policy must allow the principal explicitly for IAM permissions to take effect.

Trap Assuming KMS follows the union rule: a KMS key policy must grant the principal explicitly, so an identity policy alone is not sufficient.

When the principal and the resource live in different accounts, the union rule no longer applies: you need an Allow in the caller's identity-based policy in its own account AND an Allow in the resource-based policy (or role trust policy) in the resource's account. Both sides must opt in, either one alone fails. This is the single behavioral difference between same-account and cross-account evaluation.

Trap Granting only the resource-based policy in the target account and expecting cross-account access to work: the caller's own account must also allow the action on its identity.

Application code should carry an IAM role attached to the compute, not an access key ID and secret baked into code or config. Embedding static keys is the antipattern the exam punishes. With a role, the AWS SDK transparently obtains temporary credentials that auto-rotate and expire, so there is no long-lived secret to leak or rotate manually. Reach for the role mechanism that matches the compute: instance profile (EC2), task role (ECS), or execution role (Lambda).

Trap Storing IAM access keys in environment variables or config files on EC2/ECS/Lambda: attach a role instead and let the SDK fetch rotating STS credentials.

Each compute service exposes role credentials differently and the names are tested as distractors. An EC2 instance profile wraps a role and the SDK fetches credentials from the Instance Metadata Service. Enforce IMDSv2 (HttpTokens=required) to block SSRF-based credential theft. A Lambda execution role is set at function creation and auto-discovered by the SDK. For ECS, the task role is what the application code inside the container uses for its own AWS calls, distinct from the task execution role, which only lets the ECS agent pull images from ECR and ship logs to CloudWatch.

Trap Putting the application's AWS permissions on the ECS task execution role: that role is for the agent (ECR pull, CloudWatch logs); app calls use the task role.

When code switches identity it calls sts:AssumeRole, which returns temporary credentials valid for DurationSeconds: 3600 seconds (1 hour) when omitted. The value may range from 900 seconds (15 minutes) up to the role's configured maximum session duration, which an admin can set anywhere from 1 to 12 hours. Requesting more than the role's maximum fails, so the role's ceiling caps the session.

Role chaining (using one already-assumed role to assume a second role) always caps the new session at 1 hour, even if the target role's maximum session duration is set to 12 hours. This is a frequently tested gotcha: the 12-hour maximum applies to a directly assumed role, not to one reached by chaining from temporary credentials.

Trap Expecting a chained AssumeRole to honor a 12-hour role maximum: chaining silently caps the session at 1 hour.

Who may assume a role is governed by the role's trust policy (its resource-based policy). A trust policy Principal of arn:aws:iam::<account-id>:root denotes account-level delegation: the entire account is trusted, NOT the AWS account root user. It means any IAM principal in that account whose own identity policy also permits sts:AssumeRole may assume the role. To trust a single entity, name it explicitly, e.g. arn:aws:iam::<account-id>:role/Build.

Trap Reading :root in a trust policy as the account's root user: it is account-wide delegation; the assuming principal still needs its own AssumeRole permission.

When a third-party SaaS assumes a role in your account, add a Condition on sts:ExternalId in the role's trust policy and share that agreed value with the vendor. The vendor must pass the matching ExternalId on AssumeRole or the call fails. This defends against the confused-deputy problem, where an attacker tricks the trusted third party into using its access on your behalf without knowing your secret value.

Trap Treating ExternalId as a secret password that authenticates the vendor, when it is a confused-deputy guard rather than a credential and offers no protection if the vendor is itself compromised.

Grants union, but ceilings intersect. Where a ceiling is present (a permissions boundary on the principal, or a session policy passed to AssumeRole) effective permissions become the intersection of the identity's grants and that ceiling, so a session can never exceed what the role's own policy already allows. A boundary with no matching grant in the identity policy authorizes nothing; you still need an explicit Allow in the identity policy for any action.

Trap Treating a permissions boundary or session policy as a way to add permissions: it only narrows; the underlying identity policy must still grant the action.

A Cognito user pool is a user directory that performs authentication: users sign in and the pool returns an ID token, an access token (both JWTs you can verify against the pool's public JWKS), and a refresh token (opaque and encrypted, used only to mint new ID/access tokens). It answers "who is this user?": reach for a user pool when you need to sign your own application's end users in and protect your own API. The Hosted UI / managed login implements standard OAuth 2.0 grant flows (such as authorization code) so you do not hand-roll sign-in.

Trap Assuming the refresh token is a JWT you can verify against the JWKS like the others, when it is opaque and encrypted, usable only to mint new ID/access tokens.

Of the user-pool JWTs, the ID token carries identity claims (email, name, sub) and proves who the user is: consume it in your app to learn about the user, never to authorize a call. The access token is the OAuth 2.0 bearer token carrying scopes and groups, and it is what you present to a protected API to be authorized. The refresh token only mints new ID/access tokens and is never sent to your API.

Trap Sending the Cognito ID token to an API authorizer: it proves identity, not authorization; pass the access token, whose scopes the authorizer checks.

A Cognito identity pool (federated identities) performs authorization to AWS: it exchanges a verified login (from a user pool, or a third-party IdP like Google, Apple, Facebook, or any SAML/OIDC provider) for temporary AWS credentials from STS, scoped by an IAM role. Reach for it only when a signed-in user must call an AWS service such as S3 or DynamoDB directly from the client. Identity pools also support an unauthenticated (guest) role, granting limited access to users who have not signed in.

Trap Reaching for an identity pool just to authenticate users or protect your own API: that is the user pool's job; the identity pool exists to vend AWS credentials.

The decision rule the exam relentlessly tests: need to authenticate a user and protect your own API? Use a user pool and validate the access token. Need to give that user scoped AWS credentials to hit an AWS service directly? Use an identity pool, which returns STS credentials. Used together, the user pool authenticates and issues JWTs, then the identity pool swaps a token via STS for AWS credentials.

Trap Picking a user pool for "let the signed-in user write to S3 directly": that needs an identity pool's STS credentials, not just a JWT.

Match the identity service to the audience. Amazon Cognito signs in an application's external end users (customers of your app). IAM Identity Center signs in your own workforce: employees needing access to AWS accounts and business applications. The two are not interchangeable, and a scenario that names one where the other belongs is a deliberate distractor.

Trap Using Cognito for employee access to AWS accounts (or Identity Center for app customers): Cognito = app end users, Identity Center = workforce.

An API Gateway Cognito authorizer (REST API) or JWT authorizer (HTTP API) validates an incoming bearer JWT's signature, expiry, and scopes/claims and allows or denies the route with no custom code. Point it at a Cognito user pool or any OIDC issuer and pass the access token. This is the default answer when sign-in is already Cognito and you only need standard token validation at the edge.

Trap Writing a Lambda authorizer to validate a standard Cognito/OIDC JWT, when the built-in Cognito or JWT authorizer does signature, expiry, and scope checks declaratively with no code.

A Lambda authorizer (formerly custom authorizer) runs your function to return an allow/deny decision (an IAM policy document, or a simple boolean for HTTP APIs) and is the right choice for validating an opaque or non-Cognito token, or applying custom logic a declarative authorizer can't express. A TOKEN authorizer receives only the bearer token from a single header; a REQUEST authorizer receives the full request context (headers, query string, path, stage variables) and is needed when the decision depends on more than one input. Results can be cached by TTL to avoid invoking the function on every request.

Trap Choosing a TOKEN Lambda authorizer when the decision needs query strings or multiple headers: TOKEN sees only one header's token; use REQUEST for full request context.

API Gateway IAM authorization (AWS_IAM) requires the caller to sign the request with SigV4 using IAM credentials, and the request is evaluated through the same identity/resource-policy model as any AWS API call. It fits service-to-service or internal callers that already hold IAM credentials, not browser or mobile end users, who carry JWTs and should use a Cognito/JWT or Lambda authorizer instead.

Trap Choosing AWS_IAM authorization for browser or mobile end users, who hold JWTs rather than signable IAM credentials; SigV4/IAM auth fits service-to-service callers.

OAuth 2.0 is the authorization framework (delegating access via tokens); OIDC adds the identity (authentication) layer on top. Mapped to Cognito: the ID token is the OIDC artifact answering who the user is, and the access token is the OAuth 2.0 artifact carrying scopes for what the bearer may do. A JWT/Cognito authorizer enforces the access token's scopes at the API edge.

Trap Treating OAuth 2.0 itself as an authentication protocol, when OAuth 2.0 handles authorization and OIDC is the identity layer added on top to authenticate the user.

API Gateway authorizers and IAM gate whether a caller may reach a route or action: they do not express per-resource business rules like "can THIS user edit THIS document?". For fine-grained, per-request decisions beyond what scopes capture, validate claims in your application code or use Amazon Verified Permissions. Don't expect a scope check at the edge to enforce row-level ownership.

Trap Expecting an edge scope or JWT authorizer to enforce row-level ownership like "can this user edit this document", when per-resource rules belong in code or Verified Permissions.

Each policy should grant only the actions and resources an identity needs, narrowed with Condition keys where possible. When gating a sensitive action on MFA, know the two condition keys differ: aws:MultiFactorAuthPresent is true only when the CURRENT credentials were obtained with MFA, while aws:MultiFactorAuthAge measures how long ago that MFA happened. Use the age key when you need recency, not just presence.

Trap Relying on aws:MultiFactorAuthAge to require MFA at all: the age key is absent (so a deny-on-absence can misfire) when no MFA occurred; aws:MultiFactorAuthPresent checks that MFA happened, the age key checks how recently.

A Principal of "*" on a resource-based or trust policy grants the action to any principal in any account (effectively public) and is almost always the wrong answer on a security scenario. Scope access instead to a specific principal ARN, a specific account, or aws:PrincipalOrgID to bound it to your organization. The exam dangles "*" as a tempting "it just works" option.

Trap Accepting Principal: "*" to make access "just work": it exposes the resource to every AWS account; scope to a principal ARN, account, or PrincipalOrgID.

Attribute-based access control grants access only when a tag on the calling principal matches a tag on the target resource. The policy uses a Condition with StringEquals comparing aws:ResourceTag/<Key> to the policy variable ${aws:PrincipalTag/<Key>} (for example team or Environment) so one policy scales to every team without per-team rules. When the principal is an IAM user rather than a tagged role, ${aws:username} is the matching variable against the resource's owner tag.

Trap Hard-coding a tag value as a literal string instead of the ${aws:PrincipalTag/...} policy variable: ABAC's whole point is the dynamic principal-vs-resource tag comparison.

A REST API Lambda authorizer's output must include a principalId and a policyDocument (an IAM policy with execute-api:Invoke statements); omit either and API Gateway returns 500, not 403. Any context map it returns may hold only stringified primitives: you cannot set a JSON object or array as a context value. The backend reads those values via $context.authorizer.<key>.

Trap Returning a JSON object or array in the authorizer's context map: every context value must be a stringified primitive (string, number, boolean) or the request fails.

A deployment artifact is the immutable bundle you hand to AWS to run, and it must include the code plus every library the code imports at runtime, because the managed execution environment adds nothing you did not package. The one deliberate exception is environment-specific configuration and secrets, which are injected at deploy or run time so the same bundle promotes unchanged across dev, test, and prod. Configuration files and other static assets do travel inside the package; only per-environment values and credentials stay out.

Trap Assuming the managed runtime supplies common third-party libraries so you can leave them out of the bundle. Only the language's standard library and AWS SDK are present, so any other dependency you import must be packaged.

A Lambda .zip archive holds your handler plus third-party libraries compiled for the function's runtime and CPU architecture: x86_64 or arm64. A package built for the wrong architecture passes upload but fails at invoke, because native dependencies are architecture-specific. When you switch a function between arm64 and x86_64, rebuild the dependencies for the new architecture.

Trap Assuming a working x86_64 .zip runs unchanged on arm64. Native extensions are compiled per-architecture and break at invoke, not at upload.

A Lambda .zip is limited to 50 MB when uploaded directly through the API, SDK, or console, and to 250 MB unzipped, a ceiling that includes the function code plus all attached layers and custom runtimes. A .zip larger than 50 MB cannot be uploaded inline; you upload it to Amazon S3 first and point Lambda at the S3 object. The 250 MB unzipped figure is the hard ceiling on total uncompressed size.

Trap Trying to push a .zip over 50 MB straight through the console or API. Anything larger must be staged in S3 and referenced from there.

When a function's dependencies, native binaries, machine-learning models, or custom runtime exceed the .zip ceiling, package it as a container image instead. Lambda accepts an image up to 10 GB uncompressed, stored in Amazon ECR (Elastic Container Registry, AWS's managed image registry). The image bakes in its own dependencies, so it has no layers. Reach for .zip for small, pure-language or prebuilt-dependency functions; reach for a container image when size or native tooling rules .zip out.

Trap Picking a .zip for a large ML model or native-binary workload. It blows past the 250 MB unzipped cap, where a 10 GB container image is the intended path.

You choose .zip or container image when you create a Lambda function, and you cannot switch a function from one package type to the other afterward. To change type you create a new function. The package type is an immutable property, unlike code or configuration, which you can update in place.

Trap Assuming you can convert an existing .zip function to a container image in place. The type is locked at creation, so you must stand up a new function.

A Lambda layer is a separate .zip of libraries or a runtime that multiple functions reference, so a common dependency is uploaded and stored once rather than rebundled into every function. A function can attach up to 5 layers. Layers cut duplication and per-function upload size, but a layer's unzipped contents still count toward the same 250 MB unzipped quota as the function code. They reduce duplication, not the total uncompressed ceiling. Layers apply only to .zip functions; a container-image function bakes its dependencies into the image and has no layers.

Trap Treating layers as a way around the 250 MB limit. A layer's unzipped size counts toward that same ceiling.

An AWS SAM (Serverless Application Model) template is an extension of CloudFormation: it adds shorthand serverless resource types such as AWS::Serverless::Function, and those expand into standard CloudFormation resources at deploy time. Because SAM resources sit beside plain CloudFormation resources in one template, anything you can write in raw CloudFormation you can also write in a SAM template. There is no separate SAM provisioning service to choose instead of CloudFormation.

Trap Treating "SAM vs CloudFormation" as mutually exclusive engines. SAM is CloudFormation plus a macro, so it is never an alternative to it.

The line Transform: AWS::Serverless-2016-10-31 at the top of a template is the CloudFormation macro that marks it as a SAM template and expands the shorthand serverless resources into standard CloudFormation resources during deployment. Spotting that exact Transform value (or an AWS::Serverless::* resource type) is how you identify a template as SAM rather than plain CloudFormation.

The SAM CLI ships an artifact in three steps. sam build resolves and installs each function's dependencies into a local .aws-sam/build directory. This is where the self-contained artifact is assembled. sam package uploads those built artifacts to Amazon S3 (or to Amazon ECR for container images) and rewrites the template's local code paths to the uploaded URIs. sam deploy submits that rewritten template to CloudFormation to create or update the stack, and it runs the package step for you if you have not already.

Trap Thinking sam build is the step that uploads the artifact to S3. Build only assembles dependencies locally; sam package (or sam deploy) is what uploads to S3 and rewrites the code URIs.

A CloudFormation template uses Parameters as the per-environment input knobs (instance size, table name, log level) that vary one template into different stacks; Mappings as static lookup tables resolved at deploy time (for example region to AMI ID); and Outputs to export values such as an API URL or bucket name for other stacks or operators to consume. Passing different Parameter values is what lets the same template produce a dev stack or a prod stack without editing it.

Trap Using Mappings to feed per-environment values like instance size or table name. Mappings are static lookup tables, so caller-supplied per-environment differences belong in Parameters.

CloudFormation intrinsic functions connect resources. Ref returns a resource's primary identifier (or a parameter's value), typically the name or ID. Fn::GetAtt returns a specific attribute of a resource, such as a bucket's ARN or a DynamoDB table's stream ARN, which Ref does not give you. Fn::Sub substitutes variables into a string, letting you interpolate references inline. Pick Fn::GetAtt when you need an attribute like an ARN; pick Ref when the primary ID or a parameter value is enough.

Trap Using Ref to get a resource's ARN. Ref returns the primary identifier, so an ARN or other attribute needs Fn::GetAtt.

A change set is a preview of exactly what a stack update would add, modify, or delete, generated before you execute it, the safe way to update a stack because you confirm the blast radius first, including any resource replacements. When a question asks how to see the impact of a template change before applying it, the answer is a change set, not a blind stack update.

Trap Running a plain stack update when the stem wants a preview of the changes. Only a change set shows what will change before you commit.

Nested stacks let one parent template reference child templates as resources, so a large architecture is built from reusable, modular pieces instead of one monolithic file. Each child is its own stack the parent provisions, which keeps templates within size limits and lets common patterns (a standard VPC, a logging bucket) be reused across stacks.

Trap Reaching for cross-stack references (Export/Fn::ImportValue) when the goal is to provision and manage child templates as one unit. That lifecycle composition is what nested stacks provide, while exports only share values between independently managed stacks.

Drift detection compares a stack's actual resource configuration against what its template declares and reports any differences caused by out-of-band changes, for example, someone editing a resource directly in the console or CLI. It is the tool for catching configuration that no longer matches the source-of-truth template, not for previewing a planned update.

Trap Reaching for a change set to find manual console edits. Change sets preview intended updates, while drift detection surfaces unintended out-of-band changes.

Lambda .zip artifacts and CloudFormation/SAM templates are stored in Amazon S3; container images live in Amazon ECR; and your language packages (the npm, PyPI, or Maven dependencies a build pulls in) can be hosted privately in AWS CodeArtifact, AWS's managed package repository. CodeArtifact gives builds a controlled, versioned source for dependencies rather than pulling them from public registries directly.

Trap Reaching for S3 or ECR to host private npm, PyPI, or Maven packages. Hosting those package registries is CodeArtifact's job, while S3 holds .zip/templates and ECR holds container images.

AWS AppConfig (a feature of AWS Systems Manager) decouples configuration from code so you can change application behavior (a feature flag, an operational setting) without a code deployment. Its defining feature is validators that check the configuration is syntactically and semantically correct before a rollout, so a bad config never reaches the running application. It can source data from its own hosted store, SSM Parameter Store, Secrets Manager, or S3. Reach for AppConfig when the stem stresses changing behavior at runtime or validating config before it goes live.

Trap Choosing plain Parameter Store when the question stresses validating config before rollout or toggling a feature flag without a deploy. That validation-and-rollout machinery is AppConfig, not a bare named value.

SSM Parameter Store holds plain configuration values an application fetches at runtime by name, such as an endpoint URL or a numeric setting. A SecureString parameter additionally encrypts the value with AWS KMS, which is how you store a sensitive value without Secrets Manager. Choose Parameter Store when you just need a named value retrieved at runtime, not the validation-and-rollout machinery of AppConfig.

Trap Reaching for Secrets Manager for any sensitive value when no rotation or generation is needed. A KMS-encrypted SecureString parameter stores a secret in Parameter Store at lower cost.

Bake environment-specific values into the artifact and you must build a separate bundle per environment, which breaks the guarantee that what you tested is byte-for-byte what you ship. Instead build the artifact once and vary it externally: CloudFormation/SAM Parameters supply the deploy-time differences, while AppConfig and Parameter Store supply the run-time differences. The artifact and its template stay identical across dev, test, and prod.

Database passwords, API keys, and other secrets are never packaged into the deployment artifact; the bundle carries only the code that fetches the secret. At runtime the application reads the value from AWS Secrets Manager or an SSM SecureString parameter. Embedding the secret in the package leaks it into every copy of the artifact and ties the build to one environment.

Trap Putting a database password or API key in an environment variable baked into the package. It leaks into the artifact; fetch it at runtime from Secrets Manager or a SecureString instead.

To customize an Elastic Beanstalk environment (install packages, set options), place YAML or JSON configuration files with the .config extension in a folder named exactly .ebextensions (leading dot required) at the root of the source bundle. Files outside that folder, without the .config extension, or in a folder misnamed 'ebextensions' are silently ignored. When zipping, include hidden dot-folders (for example zip -r app.zip * .[^.]*) and produce a bundle with no parent folder so .ebextensions sits at the root.

Trap Naming the folder 'ebextensions' without the leading dot, or zipping with a wrapping parent folder. Elastic Beanstalk then ignores the config files entirely.

An Elastic Beanstalk source bundle is a single ZIP (or a WAR for Java) with special files at its root. A Procfile declares multiple long-running processes (the main one must be named 'web' and is listed first) and Elastic Beanstalk restarts any that exit; it is also how you pass JVM options per Java process. A worker environment's periodic background jobs are defined in a cron.yaml at the root, each with a name, URL path, and a CRON schedule. The multi-container ECS-managed Docker platform instead uses a Dockerrun.aws.json v2 at the root (with a .dockercfg in S3 for private-registry auth).

Trap Hand-rolling a startup script for several processes. Elastic Beanstalk monitors and restarts processes only when they are declared in a root Procfile (web first).

When you create an Elastic Beanstalk application version from a source bundle in S3, the bucket must be in the same AWS Region as the environment, or the call fails with an invalid-S3-location error. If the bundle lives in a custom bucket with a restrictive policy, also grant the IAM identity creating the version s3:GetObject (and s3:GetObjectVersion) on the bundle object, or the create fails with access denied.

Trap Assuming a valid, existing S3 bundle is enough. A different-Region bucket fails as 'invalid S3 location', and a restrictive bucket policy fails as access denied without explicit s3:GetObject.

Elastic Beanstalk caps application versions per Region; to avoid hitting the quota, configure an application version lifecycle policy that auto-deletes old versions by a MaxCount rule (keep the N most recent) or a MaxAge rule. Set DeleteSourceFromS3 to true to also remove the source bundles from S3, or false to keep them for compliance. Elastic Beanstalk never deletes a version currently deployed to any environment, and it applies the policy each time you create a new version.

Trap Worrying a lifecycle policy will remove an in-use version. Elastic Beanstalk protects versions deployed to any environment; DeleteSourceFromS3 only controls whether the S3 bundle is also deleted.

Lambda extracts layer contents into /opt, and the Python runtime searches /opt/python for imports, so a Python layer .zip must contain a top-level 'python/' directory with the libraries inside it. A layer whose modules sit at the archive root (or under any other folder) extracts to the wrong place and the function fails with 'Unable to import module' / ModuleNotFoundError even though the libraries are present.

Trap Zipping the dependencies at the layer root. Python only finds them under /opt/python, so they must be wrapped in a top-level python/ directory.

A stack policy that denies updates to a protected resource (such as an RDS database) blocks even an authorized urgent change. To update the protected resource for a single operation without permanently editing the stack policy, run update-stack with --stack-policy-during-update-body (or --stack-policy-during-update-url) specifying a temporary policy that allows the needed action. The override applies only to that update; the original stack policy stays intact afterward.

Trap Calling SetStackPolicy to permanently loosen the policy for one urgent change. The temporary --stack-policy-during-update-body override leaves the original policy unchanged.

Stack policy statements use granular update actions: Update:Modify (in-place changes that keep the physical ID), Update:Replace (changes that recreate the resource with a new physical ID), and Update:Delete (removal). To protect a resource from being recreated or removed while still allowing harmless in-place edits, Deny Update:Replace and Update:Delete (or Allow Update:Modify and Deny Update:Replace). When a stack policy is set, all resources are protected by default, so guarding one resource means an Allow for the rest plus a targeted Deny.

Trap Denying all Update:* to protect a resource when in-place changes must still be allowed. Deny only Update:Replace and Update:Delete so Update:Modify edits still go through.

For scheduled, continuous drift detection across stacks and accounts, enable the AWS Config managed rule cloudformation-stack-drift-detection-check: it runs DetectStackDrift, marking a stack COMPLIANT when IN_SYNC and NON_COMPLIANT when DRIFTED. Pair it with an EventBridge rule matching the Config compliance-change events to notify via SNS. This is the low-overhead automated answer, versus the manual CLI sequence detect-stack-drift then poll describe-stack-drift-detection-status then describe-stack-resource-drifts.

Trap Scripting repeated detect-stack-drift CLI calls for ongoing monitoring. The low-overhead continuous solution is the AWS Config managed rule with EventBridge and SNS.

On a versioning-enabled artifact bucket, choose the protection by requirement. Object Lock governance mode blocks deletes for most users but lets holders of s3:BypassGovernanceRetention override; compliance mode blocks deletes for everyone including root until retention expires, and supports legal holds. MFA Delete (enabled only by the root account via CLI/API) requires MFA to permanently delete a version or change versioning state. To prune by version, NoncurrentVersionExpiration with NewerNoncurrentVersions keeps the N most recent noncurrent versions and expires older ones after NoncurrentDays, and NoncurrentVersionTransition moves them to a cheaper class first.

Trap Reaching for governance mode when the rule says even the root account must never delete. That requires compliance mode; governance mode is overridable with the bypass permission.

ECR basic scanning covers only operating-system packages. To scan both OS and programming-language dependencies (Python, Java, etc.) and to keep re-scanning images as new CVEs are published, enable enhanced scanning on the private registry with a continuous scan filter. It integrates with Amazon Inspector. Inspector emits scan-finding events to EventBridge, so an EventBridge rule to SNS gives automated alerts when new findings appear.

Trap Choosing basic scanning for language-dependency CVEs or ongoing monitoring. Basic scans only OS packages once; continuous OS+language scanning requires enhanced scanning via Inspector.

AWS root cause analysis reads four complementary signals, each answering exactly one question: CloudWatch Logs answers "what happened in this one request?", CloudWatch metrics answer "how often, how much, is it trending?", X-Ray answers "where in the call chain did time or errors build up?", and CloudTrail answers "who called which AWS API, when, from where?". The DVA-C02 reflex is this mapping itself, so when a stem describes a symptom, name the question first and the service follows. A spike on a dashboard is a metrics question, a single failed transaction is a logs question, slow end-to-end latency across services is a trace question, and an unexplained config or permission change is a CloudTrail question.

Trap Grepping raw logs by hand to judge whether errors are trending up. That is a metrics job, and scanning log text for a rate is slow and error-prone.

CloudWatch Logs holds the line-level event record: the timestamped text or JSON your code and managed services emit into a log group such as /aws/lambda/<function-name>. It is the signal that tells you what exactly happened inside a single failed transaction, down to the stack trace or message. Use it when you already know which request failed and need its precise cause, rather than when you are trying to spot a trend across many requests, which is a metrics question.

Trap Reaching for CloudWatch Logs to spot a trend across many requests, when a rate or count over time is a metrics question and Logs answers what happened inside one specific request.

CloudWatch Logs Insights is an interactive query engine over your log groups with a purpose-built query language built from fields, filter, stats, sort, and limit commands, run ad hoc during an investigation to surface the exact events behind a failure. It can search multiple log groups in one query, and a running query is stopped after 60 minutes if it has not completed. Reach for it when the question is "what was the error on request X?", the reactive hunt, in contrast to a metric filter, which is a standing rule that watches every new log event.

Trap Standing up a Logs Insights query to continuously watch for and alert on new failures, when Insights is an on-demand reactive hunt and a metric filter plus an alarm is the proactive standing rule.

A metric filter is a standing rule on a log group that scans every incoming event for a pattern (say the term ERROR or a 5xx status) and emits a numeric CloudWatch metric you can alarm on. This is how you turn unstructured log text into a measurable trend that pages you proactively, rather than discovering the problem only when you go hunting. Logs Insights is the reactive query you run after the fact; a metric filter plus an alarm is the proactive trigger set up in advance.

Trap Trying to detect a rising error rate by repeatedly running a Logs Insights query: use a metric filter feeding an alarm so the trend pages you instead of you polling for it.

A metric is a numeric time series (error count, p99 latency, throttle count) identified by a namespace that isolates one service's metrics (for example AWS/Lambda) plus a set of dimensions, which are name/value pairs such as FunctionName=checkout that scope the series to one resource. Dimensions are how you narrow a chart from "all functions" down to the single function that is misbehaving. You set alarms on metrics, and a metric spike bounds the time window you then drill into with logs and traces.

Trap Treating a namespace/dimension pair as interchangeable with another after the fact, forgetting that a dimension is part of a metric's identity, so an alarm created on a specific dimension combination does not retroactively cover series you never published with those exact dimensions.

Lambda's Errors metric counts only function errors (an unhandled exception or a timeout raised inside your handler) so a rising Errors line points at your code. Throttles is a separate metric that counts invocations rejected because concurrency was exhausted, surfaced as TooManyRequestsException / HTTP 429, and a throttle does NOT increment Errors. So if Errors stays flat while Throttles climb, the fix is to raise reserved or provisioned concurrency or the account concurrency limit, not to read your handler code.

Trap Debugging handler logic because invocations are failing, when the Errors metric is flat and only Throttles is rising. A throttle is a concurrency limit, not a code fault.

Lambda's Duration metric measures execution time per invocation, and it is the early-warning signal for a performance regression: a Duration line trending up toward the configured timeout is what eventually turns into function errors once invocations actually hit the ceiling and time out. Treat a rising Duration as the metric to investigate proactively, since by the time it shows up as timeouts in the Errors metric the user impact has already begun.

Trap Waiting for the Errors metric to rise before investigating a slowdown, since by then invocations are already timing out, whereas a Duration line climbing toward the configured timeout warns you while there is still headroom to act.

A function error is raised inside your handler (an unhandled exception or a timeout) and is the case where you actually debug your code. An invocation error happens before or around your code: a throttle when concurrency is exhausted (TooManyRequestsException / 429), or a permission/configuration failure such as the caller lacking lambda:InvokeFunction. Read the error type and the metric first, because the two classes point at different layers: fix the handler for a function error, but fix concurrency limits or IAM permissions for an invocation error.

Trap Reading application logs to fix a "not authorized to perform lambda:InvokeFunction" failure. That is an invocation-level permission problem, not a bug in your handler.

X-Ray records each request as a segment (the work one service did) and breaks that service's downstream calls into subsegments, then stitches all segments sharing one trace ID into a service map, the visual graph of services and the edges between them, color-coded for errors, faults, and throttles. Reach for it when end-to-end latency is high across microservices but no single component looks broken: the service map shows which hop accumulates the time, which a single service's logs cannot reveal.

Trap Reading one service's logs to explain high end-to-end latency across services: logs from a single hop cannot show where across the chain the time was spent.

To control cost and overhead X-Ray does not trace every request: the default sampling rule records the first request each second (the reservoir) plus five percent of any additional requests that second. The consequence for root cause analysis is that a low-volume intermittent error may simply not have been sampled, so the absence of a trace is not proof the request succeeded. When you need fuller capture, raise the sampling rate or add a targeted sampling rule for the affected path.

Trap Concluding an intermittent request succeeded because no X-Ray trace exists for it, when default sampling captures only the first request each second plus 5% of the rest, so a missing trace may just mean it was not sampled.

CloudTrail is the control-plane audit trail: it records management-event API activity, the principal who made the call, the API action, the timestamp, and the source IP. Reach for it when behavior changed without a deployment you initiated, or a call suddenly started being denied, for example a security group was edited or an IAM role's permissions changed. Logs, metrics, and traces observe your application, so none of them captures a control-plane change; CloudTrail is the only one of the four signals that answers "who or what changed it?".

Trap Hunting through CloudWatch Logs or X-Ray for the cause of an unexplained permission or config change, when those observe your application and only CloudTrail records who called the AWS API that changed it.

CloudTrail records that a principal called an API (say ModifySecurityGroupRules at 14:02 from a given IP) but it does not contain your function's internal log lines, error messages, or request payloads. For those you read CloudWatch Logs. Keep the boundary sharp: CloudTrail answers the "who changed the configuration" question only, and using it to debug application behavior will turn up nothing because it never sees inside your code.

Trap Searching CloudTrail for an application's runtime error or request payload: it logs AWS API calls, not your code's internal events; read CloudWatch Logs for those.

A 4xx status generally means the caller (your application or the client) sent a bad request (malformed input, missing auth, a 429 throttle), while a 5xx means the serving side faulted. This split tells you which direction to investigate first. On a multi-service path do not assume a 5xx is your code: narrow it by checking which hop reported the 5xx on the X-Ray service map, since the failing service may be a downstream dependency rather than your own.

Trap Assuming every 5xx on a multi-service path is your own service's fault, when the X-Ray service map may show the 5xx originated at a downstream dependency you call rather than in your code.

The disciplined RCA loop aligns timestamps across signals: when a metric spikes, note the exact window, then pull the X-Ray traces, the CloudWatch Logs lines, and any CloudTrail event inside that same window. A 5xx spike whose window lines up with a CloudTrail ModifySecurityGroupRules event is a configuration regression, not a code bug, a conclusion no single signal could reach. Metrics localize the blast radius and bound the window; logs and traces then explain exactly what failed inside it.

Trap Declaring a code bug from a 5xx spike alone, when correlating its time window against CloudTrail can reveal a ModifySecurityGroupRules event that points at a configuration regression rather than your code.

When ECS tasks start then stop, run describe-tasks and read the stopCode (the category, such as ResourceInitializationError or EssentialContainerExited) and stoppedReason (the human-readable detail) before anything else. The most common container-level cause is a SIGKILL: a container exit code of 137 (128 + 9) means the OOM killer terminated it for exceeding its task-definition memory limit, so the fix is to raise the allocated memory, not to debug code. A ResourceInitializationError points instead at setup failing before the app ran (logging-driver or secrets connectivity).

Trap Reading container application logs to explain a 137 exit when there are none: the process was killed by the OS for exceeding its memory limit, which surfaces in stopCode/stoppedReason, not in app output.

Fargate tasks using the awslogs driver fail at startup with ResourceInitializationError / 'failed to initialize logging driver' for one of two reasons. First, connectivity: a task in a private subnet with no NAT gateway needs an interface VPC endpoint for CloudWatch Logs (com.amazonaws.region.logs), and that same private-subnet rule causes silently missing logs even when the task stays up. Second, permission: the task execution role must allow logs:CreateLogStream and logs:PutLogEvents, which the AmazonECSTaskExecutionRolePolicy managed policy grants. The identical 'unable to pull secrets or registry auth' failure needs the task's security group to allow outbound HTTPS (443) to Secrets Manager / ECR.

Trap Assuming a NAT gateway is enough on its own: the task's security group must still permit outbound 443 to reach CloudWatch Logs, Secrets Manager, or ECR endpoints.

Active tracing makes Lambda record two segments per invocation, so the X-Ray service map shows two nodes for one function. AWS::Lambda is the Lambda service overhead (scheduling, creating or unfreezing the execution environment, and downloading function code) and an error or latency here is a platform/init problem (including throttling), not your code. AWS::Lambda::Function is the handler running, so an error or high latency on that node is in your application logic. Decide which node shows the symptom before you touch anything.

Trap Debugging handler code because the function's X-Ray node shows latency, when the slow node is AWS::Lambda, which is service overhead like cold-start init or throttling rather than your application logic.

When Logs Insights queries that filter on a field such as requestId scan huge volumes and run slow and expensive, create a field index policy for that field (PutIndexPolicy / console) without changing the log format. Queries written as filter requestId = 'value' (equality) then skip log events known not to contain the indexed value, cutting scan volume and cost. Across hundreds of log groups, the filterIndex command restricts a query to only the groups indexed on that field.

Trap Expecting a field index to speed up a non-equality filter such as a wildcard or range on requestId, when the index only lets an equality match skip events known not to contain the indexed value.

To turn logs into a time series, use stats with aggregations grouped by bin(5m) (for example stats count(*) by endpoint, bin(5m)); bin() creates the time buckets a chart needs. Filter HTTP errors by numeric range (filter status>=400 and status<=499 for 4XX). Lambda timeouts do NOT log as ERROR (they emit a 'Task timed out' message) so capturing all failures needs a pattern like filter @message like /ERROR/ or @message like /Task timed out/.

Trap Filtering only on /ERROR/ to count all Lambda failures, when a timeout emits a 'Task timed out' message rather than ERROR, so it slips past that filter unless you match it explicitly.

VPC Reachability Analyzer performs static configuration analysis between a source and destination (it sends no packets) making it the tool to proactively prove a path or pinpoint what blocks it (security group, network ACL, or route table) before any traffic flows. It reports the blocking component with explanation codes. Because it snapshots configuration at analysis time, after you change a rule you must run a NEW analysis; re-reading the old result still shows the stale, pre-change state.

Trap Expecting an existing Reachability Analyzer result to update after you fix a security group: it is a point-in-time snapshot, so you must analyze the path again.

An action=REJECT record means a security group or network ACL blocked the traffic; check the security group first since it is evaluated first and is the most common cause. Because NACLs are stateless, return traffic is evaluated independently and needs explicit ephemeral-port rules. This is why one direction can show ACCEPT while the reply shows REJECT, or why an SG that allows a port still fails when the subnet's NACL does not. Flow logs only appear once there is real traffic on the interface (the log group is created on first traffic), and custom formats can add fields like instance-id, subnet-id, flow-direction, and tcp-flags.

Trap Blaming the security group for a REJECT on return traffic when the outbound request showed ACCEPT, when NACLs are stateless, so the reply needs its own explicit ephemeral-port rule that the SG, being stateful, does not require.

Before any API Gateway logs appear, the account must have an IAM role (trusting apigateway.amazonaws.com, with AmazonAPIGatewayPushToCloudWatchLogs) configured in API Gateway Settings; without it, requests succeed but produce no logs. Even with logging on, API Gateway does not write certain client errors to execution logs (such as 403 from a wrong resource path, and excessive 429 or 413 errors), so enable custom access logging to capture them. To surface integration failures behind 500 errors, add $context.integrationErrorMessage to the access log format.

Trap Assuming execution logging captures every failed request, then concluding a missing 403 means the call never reached API Gateway, when certain client errors like a wrong-path 403 are absent from execution logs unless you turn on custom access logging.

A ReplicaLag value of -1 does not mean zero lag: it means replication is not active or the lag can't be determined (for MySQL/MariaDB, equivalent to Seconds_Behind_Master = NULL), so check the replication state and event log for errors. Sustained positive lag often comes from a read replica with a smaller instance class than the primary: a replica replays the primary's full write load and must match or exceed its compute/storage to keep up. For consistent reads, the app can check ReplicaLag and route time-sensitive queries only to replicas below an acceptable threshold.

Trap Reading a ReplicaLag of -1 as zero lag and a perfectly healthy replica, when the value actually signals replication is not active or cannot be measured, so the replica may be receiving nothing.