AWS Lambda Functions — DVA-C02 Study Guide

The execution environment: one model behind every configuration knob

Your handler runs inside a managed micro-VM that Lambda creates, holds warm, and tears down, and that one fact explains nearly everything the exam tests: raising memory speeds up a CPU-bound function (CPU is geared to memory), init code runs once per environment rather than once per request, and /tmp is scratch space, not a database, because the environment can vanish. Packaging, concurrency, and cold starts are all consequences of this single model.

AWS Lambda^[1] runs your handler inside a managed execution environment, a micro-VM that Lambda creates, holds warm, and eventually tears down. Lambda bills per millisecond of execution time multiplied by configured memory, so the environment's resources are the unit of both performance and cost.

Memory is the single performance dial, and CPU is geared to it. You set memory from 128 MB to 10,240 MB, and vCPU is allocated proportionally^[2]: a function reaches roughly one full vCPU at 1,769 MB and scales up to six vCPUs at the maximum. Because CPU is coupled to memory rather than set separately, raising memory on a CPU-bound function can finish it faster and actually lower total cost, so treat memory as a tuning knob, not just a capacity limit. The timeout^[2] caps a single invocation at a maximum of 15 minutes (900 seconds); anything that needs longer must be split up or moved to Fargate, ECS, or Step Functions.

Init code runs once per environment, not once per request. When a request arrives and no warm environment is free, Lambda runs the init phase^[3]: it downloads the code, starts the runtime, and runs everything outside the handler (SDK clients, database connection pools, configuration loads). That environment is then reused for later invocations, so only the handler body runs per request. The diagram below traces this lifecycle, the init phase paid once into a fresh environment, then the warm-reuse loop that amortizes it, then teardown. This is the mental model that explains cold starts, the latency of paying that init cost when no warm environment exists, covered fully in Concurrency, cold starts, versioning below: the init cost is paid on the first invocation into a fresh environment, then amortized.

Per-environment storage and shared libraries. Each environment gets an ephemeral /tmp directory^[4], configurable from 512 MB up to 10,240 MB (10 GB), that lives only for the life of that environment. It is scratch space, never durable state, because the environment can vanish at any time. Lambda layers^[5] let you package shared libraries or a runtime separately and attach up to five layers to a function so you do not rebundle the same dependencies into every deployment package. Environment variables hold configuration outside the code (encrypted at rest with a KMS key), keeping the same artifact deployable across stages.

Execution-environment lifecycle: the init phase runs once on a cold start, then the warm environment is reused per request until Lambda tears it down.

Configuration and packaging: the limits the exam expects you to know cold

This section catalogs the hard numbers that distinguish a workable Lambda design from one that will not deploy or will throttle. Each limit is testable on its own, so memorize the value and the reason it exists.

Deployment package size depends entirely on the packaging format. A .zip deployment package^[14] is capped at 50 MB when uploaded directly (the zipped artifact) and 250 MB unzipped, including any attached layers. The unzipped ceiling is what trips people up, because five layers eat into the same 250 MB the function code lives in. Uploading the zip from Amazon S3 instead of inline raises the direct-upload limit, so large zips go through S3. A container image^[15] raises the ceiling dramatically to 10 GB, pushed to Amazon ECR. This is the standard choice for large dependencies, machine-learning models, or custom runtimes. The exam pattern: "a 400 MB dependency tree" rules out zip and points to a container image.

The two policies that control a function are easy to confuse, so anchor them by direction of access. Both are IAM policies, but they govern opposite flows, as the diagram below shows: inbound invocation versus outbound calls.

The execution role^[6] is the IAM role the function assumes at runtime to call other AWS services, read a DynamoDB table, write to S3. It is the outbound permission set: what the function may do.
The resource-based policy^[7] attached to the function controls inbound access: which accounts or services (API Gateway, Amazon S3, EventBridge) are allowed to invoke it.

The reconciling rule for poll-based sources (SQS, Kinesis, DynamoDB Streams): there is no resource policy granting them inbound access, because Lambda reads from the source on your behalf, so the execution role must carry the polling permissions instead. Push sources need the resource policy; poll sources need the execution role.

VPC attachment trades reachability for a new outbound problem. By default a function runs in a Lambda-managed network with internet access. Attaching it to a VPC^[16], by specifying subnets and security groups, lets it reach private resources like an RDS instance, and Lambda connects through the Hyperplane ENI^[17], a shared elastic network interface that is created per function-subnet-security-group combination and reused across environments (which is why VPC attachment no longer adds the heavy per-invocation ENI cost it once did). The catch: a VPC-attached function loses default internet egress, so reaching the public internet or AWS service endpoints now requires a NAT gateway or VPC interface endpoints.

Two policies by direction: the resource policy admits inbound invokes (push sources); the execution role authorizes outbound calls and polls poll sources.

Invocation models: where the request waits and where errors go

This section is the spine of Lambda troubleshooting: the invocation model decides whether the caller blocks, who owns retries, and where a failed event ends up. Three models exist, and the right answer to most failure-handling questions is "which model is this?"

Synchronous (RequestResponse^[9]; API Gateway, the CLI invoke default) runs the function and returns the result to the caller, who waits. Lambda does not retry, the caller owns retry and error handling. A 500 from API Gateway means the caller decides what happens next.

Asynchronous (Event^[10]; S3 events, EventBridge, SNS) hands the event to an internal Lambda-managed queue and immediately returns a 202 to the caller, the caller does not wait for execution. Because the caller is already gone, Lambda owns the retries: a failed invocation is retried twice by default^[10] (three attempts total) with delays. After retries are exhausted the event is dropped unless you capture it. Two capture mechanisms exist, and they are not equivalent:

A dead-letter queue^[10] (an SQS queue or SNS topic) receives only the failed event payload.
Lambda destinations^[10] route both success and failure outcomes, with richer context (request, response, error), to SQS, SNS, EventBridge, or another function.

Destinations are the modern, preferred choice precisely because they capture success too and carry more context; a DLQ is the older failure-only mechanism. When a question asks how to capture both outcomes of an async invocation, the answer is destinations.

Poll-based (event source mappings) is a distinct model for stream and queue sources: SQS, Kinesis Data Streams, DynamoDB Streams^[8], Amazon MSK. Here Lambda does not wait on a caller at all; an event source mapping is a Lambda-managed poller that reads records, groups them into a batch, and invokes your function synchronously with that batch. The mapping, not the function, owns the tuning and the retry behavior:

Batch size sets the maximum records per invocation (for example, up to 10,000 for SQS standard queues^[18], up to 10,000 for Kinesis/DynamoDB Streams).
Batch window (MaximumBatchingWindowInSeconds, up to 300 s) lets the poller wait to accumulate a fuller batch before invoking, trading latency for fewer, larger invocations.
For SQS, the source queue's visibility timeout should be at least six times the function timeout so an in-flight batch is not redelivered while still processing.

The diagram below traces a single poll cycle. The key exam distinction: async retry settings live on the function; poll-based batch and retry settings live on the event source mapping.

Poll cycle: the event source mapping polls and batches records (1), invokes the function (2), then advances on success (3a) or retries / routes on failure (3b).

Concurrency, cold starts, versioning: exam patterns and traps

This section applies the execution-environment model from the top of the page to the levers you actually configure for scale, latency, and safe releases. Read it as the answer key to the most common DVA-C02 Lambda scenarios.

Concurrency is how many environments run at once, bounded by an account ceiling. Concurrency^[11] 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 cannot starve the others below that floor. Two distinct controls sit on top of this pool, and confusing them is a classic trap:

Reserved concurrency^[12] 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 connection limit) from being overwhelmed, and it guarantees the function some capacity even when noisy neighbors are busy. It adds no extra charge and does not pre-warm anything, a reserved environment still cold-starts.
Provisioned concurrency^[13] keeps a set number of environments initialized and ready, so requests up to that number skip the init phase entirely and never cold-start. Unlike reserved concurrency, it carries an hourly charge for every provisioned environment whether or not the function is invoked, you are paying to keep them warm.

Reconcile the two by their job: reserved is a cap and a guarantee (and free); provisioned is a latency fix (and billed idle). "Eliminate cold starts on a latency-sensitive path" → provisioned concurrency. "Stop this function from exhausting the database connection pool" → reserved concurrency.

Cold starts and how to reduce them. A cold start^[3] is the latency added when a request lands with no warm environment available and Lambda must download code, start the runtime, and run init before the handler runs. Mitigations, in order of exam frequency: provisioned concurrency (deterministic, billed); slimmer packages and fewer dependencies (faster download and init); moving heavy setup outside the handler so it is reused; and for Java specifically, SnapStart^[19], which snapshots an initialized environment and restores it. SnapStart is free of additional charge only for Java managed runtimes; for other supported runtimes it is billed for caching and restore, so never state "SnapStart is free" without that qualifier.

Versions and aliases enable safe, gradual releases. Publishing a version^[20] freezes the code and configuration as an immutable, numbered snapshot; $LATEST is the mutable working copy. An alias^[21] 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. Crucially, an alias supports weighted routing^[21], it can split traffic between two versions (for example, 90% to v1, 10% to v2) to run a canary or blue/green rollout, then shift weight as confidence grows, as the diagram below shows. The exam trap: provisioned concurrency is configured per version or alias, not on $LATEST, so a deployment that re-points an alias to a fresh, un-provisioned version reintroduces cold starts until provisioning catches up.

Versions and aliases: $LATEST publishes immutable versions; the prod alias points at them, weighted routing splitting traffic (90% v1 / 10% v2) for a canary.

Concurrency control	Guarantees capacity	Eliminates cold starts	Caps maximum concurrency	Always-on charge
Reserved concurrency	Yes (carves a slice of the account pool)	No	Yes	No
Provisioned concurrency	Yes (pre-initialized environments)	Yes	No (set separately)	Yes (hourly per provisioned environment)
Unreserved (default) concurrency	No (shares the account pool)	No	No	No

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.

Tune Lambda with memory: CPU scales with it

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 Lambda invocation is capped at 15 minutes

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.

Init code runs once per environment, not once per request

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.

6 questions test this

/tmp is ephemeral scratch space, never durable state

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.

Layers share libraries without rebundling: up to five per function

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.

3 questions test this

Zip caps at 50 MB direct / 250 MB unzipped; containers go to 10 GB

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.

5 questions test this

Execution role = what the function may do (outbound)

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.

15 questions test this

Resource-based policy = who may invoke the function (inbound)

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.

6 questions test this

Poll-based sources need permissions in the execution role, not a resource policy

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.

Synchronous invocation: the caller owns retries

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.

Asynchronous invocation: Lambda owns retries, default 2

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.

5 questions test this

Capture both outcomes with destinations; a DLQ catches only failures

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.

13 questions test this

Event source mappings poll the source and own the batch/retry settings

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.

1 question tests this

A developer is building a data pipeline where an AWS Lambda function processes records from an Amazon Kinesis data stream. The function…

Batch size and batch window trade latency for fewer invocations

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.

Set an SQS visibility timeout of at least 6× the function timeout

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.

1 question tests this

A developer is configuring an event source mapping between an Amazon SQS standard queue and a Lambda function. The Lambda function has a…

Account concurrency defaults to 1,000 with a 100-execution shared floor

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 is a free cap-and-guarantee, not a warm pool

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.

Cut cold starts with provisioned concurrency, slimmer packages, and lighter init

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.

A published version is an immutable snapshot; $LATEST is mutable

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.

Shift traffic safely with an alias and weighted routing

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 attaches to a version or alias, not $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.

VPC attachment reaches private resources but loses default internet egress

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.

Layer contents must use the runtime's directory convention under /opt

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.

9 questions test this

Layer binaries must match the function's runtime version and the Linux/arm architecture

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.

3 questions test this

Share a Lambda layer across accounts with add-layer-version-permission

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.

7 questions test this

The Parameters and Secrets Lambda Extension caches values; SSM_PARAMETER_STORE_TTL controls staleness

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.

4 questions test this

Fetch a whole Parameter Store hierarchy in one call with GetParametersByPath

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.

4 questions test this

Emit structured JSON logs so CloudWatch Logs Insights can query them by field

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.

6 questions test this

Also tested in

DEA-C01 AWS Certified Data Engineer - Associate

The execution environment: one model behind every configuration knob

Configuration and packaging: the limits the exam expects you to know cold

Invocation models: where the request waits and where errors go

Concurrency, cold starts, versioning: exam patterns and traps

Decision tree

Cheat sheet

Also tested in

References