20 cards · AWS SAA-C03 · answer each one, then read the explanation. Your score tallies below. Looking for Lambda concurrency worked example: reserved vs provisioned vs unreserved, one traffic burst traced? Read the explainer.
A team sets a Lambda function's reserved concurrency to 5 to cap its cost and blast radius. The function is invoked synchronously by an application, and 5 invocations are already executing when a 6th request arrives. What happens to that 6th request?
AThe request queues automatically and Lambda delivers a response once one of the 5 running executions finishes, with no error surfaced to the caller
BThe request overflows and reuses spare concurrency capacity borrowed from other functions' reserved pools in the same account
CThe request is throttled immediately and the caller receives a throttling error, because reserved concurrency also acts as a hard ceiling on the function's concurrent executions
DLambda automatically and temporarily raises the account's unreserved concurrency pool to absorb the extra request
Correct answer: .
Reserved concurrency does two things at once: it carves out a guaranteed slice of the account's concurrency pool exclusively for this function, and it sets a hard ceiling of 5 simultaneous executions that the function can never exceed. Once all 5 reserved execution slots are busy, any further synchronous invocation is throttled immediately and the caller gets a throttling error back, since there is nowhere for the extra request to run. There is no automatic queueing for synchronous invocations (queueing behavior applies to the internal handling of asynchronous invocations, not to synchronous callers waiting on a response). A function's reserved concurrency is dedicated to it alone and cannot borrow capacity from another function's reserved pool, and Lambda never silently raises account-level quotas on your behalf; any real increase requires a Service Quotas request.
Source: AWS Lambda docs: Understanding Lambda function scaling (reserved concurrency)
An API backed by a Lambda function sees occasional latency spikes on the first request after a period of low traffic, because a new execution environment must initialize the runtime and the function's code before it can process the request. Which configuration change removes this latency for a set number of requests, without changing the application code?
AEnable provisioned concurrency on the function's version or alias, so a chosen number of execution environments are initialized in advance and kept warm at all times
BIncrease the function's reserved concurrency limit so more concurrent invocations are permitted
CIncrease the function's configured memory so each invocation finishes faster
DSwitch the function's deployment package type from a .zip archive to a container image
Correct answer: .
Provisioned concurrency pre-initializes a specified number of execution environments, including running any init-phase code, before requests ever arrive, so invocations that land on one of those warmed environments skip the initialization step entirely and start executing the handler immediately. Raising reserved concurrency only changes how many concurrent executions are guaranteed or permitted for the function; it does not pre-initialize anything, so a request after an idle period still triggers a fresh cold start. Increasing memory can shorten a cold start somewhat because more memory also grants more CPU, but it does not eliminate the initialization phase itself, so latency spikes can still occur. Switching from a .zip package to a container image changes how the code is packaged and deployed, but container images are typically larger and do not, by themselves, remove initialization latency.
A Lambda function is configured as an SQS event source mapping with a batch size of 10, and the function has not enabled batch item failure reporting. During one invocation, the function successfully processes 8 of the 10 messages in the batch, then throws an unhandled exception while handling the 9th message (the 10th is never attempted). What happens to the batch's messages as a result?
AOnly the 9th and 10th messages (the unprocessed ones) become visible again in the queue; the 8 already-processed messages are deleted immediately
BThe event source mapping automatically retries only the 9th message using exponential backoff, leaving the rest of the batch alone
CSQS immediately moves all 10 messages to a dead-letter queue on this first failure, regardless of the source queue's redrive policy
DAll 10 messages, including the 8 that were already handled inside the function, become visible again once the queue's visibility timeout expires, so those 8 get delivered and processed again
Correct answer: .
Without batch item failure reporting enabled, Lambda's SQS event source mapping treats deletion at the level of the whole batch: messages are only removed from the queue once the invocation as a whole reports success. If the invocation instead ends in an unhandled exception, none of the batch's messages are deleted, so every one of them, including the 8 the function had already finished handling internally, stays hidden only until the visibility timeout expires and then becomes visible and gets redelivered. This is exactly why handler code must be idempotent. SQS cannot selectively expire just the unprocessed messages, because it has no visibility into which messages the function logically finished before the exception; there is no automatic per-message retry with backoff built into the mapping itself (that selective behavior only happens if the function reports partial batch failures); and a redrive to a dead-letter queue only occurs once a message's receive count exceeds the source queue's configured maxReceiveCount, not on a single failed attempt.
Source: AWS Lambda docs: Using Lambda with Amazon SQS — understanding polling and batching behavior
An S3 event notification invokes a Lambda function asynchronously. The function's code throws an unhandled exception on every invocation. The function has both an on-failure Destination (an SNS topic) and a legacy dead-letter queue (an SQS queue) configured. Which statement correctly describes when these fire relative to Lambda's built-in asynchronous retry behavior?
AThe dead-letter queue receives the event immediately after the very first failed attempt, before any retry happens
BLambda retries the invocation according to its configured retry attempts, and only once every retry is exhausted does it send the failed event, along with extra context such as the error details and invocation record, to both the destination and the dead-letter queue
CConfiguring both an on-failure destination and a dead-letter queue at the same time is invalid; Lambda silently ignores the dead-letter queue whenever a destination is present
DThe on-failure destination only ever receives a record when the invocation succeeds; failure details are exclusively available in the dead-letter queue
Correct answer: .
For asynchronous invocations, Lambda automatically retries a failing invocation a configured number of additional times with a delay between attempts, and only after those retries are exhausted does it route the failed event onward. Both an on-failure destination and a legacy dead-letter queue can be configured on the same function simultaneously, and at that point both receive the failed event, though the destination carries much richer context (the full invocation record, including the request payload, the response or error, and metadata) while the dead-letter queue only receives the raw original event. This richer detail is why AWS recommends destinations over dead-letter queues for new functions. There is no immediate dead-letter delivery on the very first failure, since retries happen first; the two mechanisms are not mutually exclusive; and the on-failure destination fires specifically on failure, which is a separate, independently configured path from any on-success destination.
Source: AWS Lambda docs: Invoking a Lambda function asynchronously — error handling and Destinations
An engineer recalls older guidance warning that attaching a Lambda function to a VPC caused significant added cold-start latency because a new elastic network interface (ENI) had to be created for every execution environment. They are now deciding whether to attach a new function to a VPC so it can reach an RDS instance in a private subnet. Which statement about Lambda's current VPC networking model is accurate?
ALambda still creates a brand-new ENI for every execution environment on every cold start; the only available mitigation is provisioned concurrency
BAttaching a function to a VPC has no effect on its ability to reach the public internet; outbound internet routing works identically whether or not the function is attached to a VPC
CLambda now provisions a shared pool of ENIs per unique VPC/subnet/security-group combination up front, and execution environments reuse them, largely eliminating the old per-invocation ENI-creation delay — though the function still needs a NAT gateway or VPC endpoints for internet or AWS-service access from a private subnet
DVPC attachment is only supported for functions packaged as container images, not for functions packaged as .zip archives
Correct answer: .
Lambda's networking model decoupled ENI lifecycle from individual execution environments: for a given VPC, subnet, and security group combination, Lambda provisions and maintains a shared pool of network interfaces up front, and execution environments attach to that existing pool instead of each one triggering its own ENI creation. This removed the old per-invocation ENI-creation delay that made VPC-attached functions noticeably slower to cold-start. The claim that a fresh ENI is still created for every execution environment on every cold start matches pre-2019 Lambda networking and is no longer how it works. Attaching a function to a VPC does change its internet reachability: a function in a private subnet loses the default internet path it had outside a VPC and needs a NAT gateway (for general internet access) or VPC endpoints (for reaching AWS services privately) to regain it, so the claim that VPC attachment leaves internet routing completely unaffected is wrong. VPC attachment is supported for both .zip-based and container-image-based functions, not restricted to one packaging type.
Source: AWS Lambda docs: Configuring a Lambda function to access resources in a VPC
A team is building a Step Functions workflow to process payment transactions. Each payment step is non-idempotent (charging a customer twice would be a real financial error), and the workflow must retain a queryable, auditable execution history for compliance for up to a year. Which workflow type should they choose, and why?
AA Standard workflow, because it guarantees exactly-once execution semantics and supports long-running, auditable executions of up to a year — appropriate for non-idempotent actions like charging a payment
BAn Express workflow, because its at-least-once execution model retries more aggressively, and its five-minute maximum duration is not a concern for a single payment step
CA Standard workflow, because it is billed by execution duration and memory consumed rather than by state transitions, which is cheaper for financial workflows
DAn Express workflow, because it supports the Distributed Map state for large-scale parallel processing, while Standard workflows do not
Correct answer: .
Standard workflows persist execution state between transitions and follow an exactly-once model, meaning a task runs more than once only if you explicitly configure retry behavior in the state machine definition — this makes them the right fit for non-idempotent actions such as charging a payment exactly once. They also support executions running for up to a year and keep queryable, auditable execution history, which fits the compliance requirement. Express workflows use an at-least-once (or, for synchronous Express, at-most-once) model where the same task can genuinely run more than once, which risks a duplicate charge, and their five-minute duration cap is a real constraint, not an advantage, for a process that must be provably reliable. Standard workflows are billed by the number of state transitions processed, not by duration and memory (that pricing model belongs to Express workflows). Distributed Map is a Standard-workflow feature and is not available in Express workflows.
Source: AWS Step Functions docs: Standard vs Express workflows
A team wants to gradually shift traffic to a new version of a Lambda function for a canary release: 90% of invocations should keep hitting the current stable version and 10% should go to the new version, without the client-facing function ARN ever changing. Which approach achieves this natively in Lambda?
APublish the new code as $LATEST and point clients directly at the $LATEST version
BSet reserved concurrency on the new version to roughly 10% of the function's total concurrency
CDeploy the new version as an entirely separate Lambda function and split traffic between the two functions using Route 53 weighted routing
DPoint clients at a Lambda alias, and configure that alias with weighted traffic routing so it splits invocations across the two published versions (for example, 90% and 10%)
Correct answer: .
A Lambda alias is a stable, named pointer that clients invoke instead of a specific version, and an alias can be configured to route a percentage of its invocations to a second, additional version — exactly the weighted canary pattern described here, with no change needed to the client-facing ARN. $LATEST is a mutable pointer that always reflects the most recently uploaded code and changes with every deployment, so pointing production clients directly at it defeats controlled, gradual rollout and is not how canaries are done. Reserved concurrency only guarantees or caps how many concurrent executions a function or version can run; it does not route a percentage of invocations by version, so it cannot produce a 90/10 traffic split on its own. Splitting into a wholly separate function fronted by Route 53 changes the client-facing identity and adds unnecessary infrastructure when native alias-based weighted routing already solves exactly this problem within a single function.
Source: AWS Lambda docs: Lambda function aliases — routing traffic with alias weights
A team wants to share a common set of dependencies across several Lambda functions without repackaging those dependencies into every function's own deployment package, so they plan to publish the shared code as one or more Lambda layers. Which statement about layers is correct?
AA function can use an unlimited number of layers, as long as the account's total code-storage quota is not exceeded
BA function can use up to 5 layers, and the combined unzipped size of the function's own code plus all attached layers cannot exceed 250 MB
CLayers can only contain compiled binaries; interpreted-language libraries, such as Python packages, cannot be distributed as layers
DOnce a layer version is published and attached to a function, it can be edited in place, and every function referencing it automatically picks up the change
Correct answer: .
Lambda enforces a hard limit of 5 layers per function, and separately caps the combined unzipped size of the function's own code plus every attached layer at 250 MB — both limits apply regardless of how much spare storage quota the account has. There is no unlimited-layers allowance tied only to storage, so a function cannot simply keep adding layers once the count of 5 is reached. Layers routinely hold interpreted-language dependencies, such as Python or Node.js packages, alongside or instead of compiled binaries, so restricting layers to compiled code only is incorrect. Layer versions are immutable once published: updating shared code means publishing a new layer version with its own ARN, and every function must be explicitly updated to reference that new version — functions do not automatically pick up changes to a layer they already reference.
Source: AWS Lambda docs: Lambda quotas — function layers and deployment package size
A team needs the simplest possible way to give a single Lambda function its own HTTPS endpoint for a lightweight webhook, with no need for request/response transformation, custom domains, usage plans, or per-route throttling tiers. Comparing Lambda function URLs to Amazon API Gateway, which statement correctly distinguishes the two?
AAPI Gateway is simpler for this case because it requires no separate resource configuration beyond the Lambda function itself
BA function URL supports request/response transformation, custom per-route authorizers, and usage-plan-based API keys, exactly like API Gateway does
CA function URL gives a dedicated HTTPS endpoint directly on a single function, configured with just IAM-based or public (NONE) auth and CORS settings, requiring far less setup, while API Gateway adds routing across many backends, request/response transformation, custom domains, usage plans, and finer-grained throttling
DA function cannot have both a function URL and an API Gateway integration configured at the same time; the two are mutually exclusive
Correct answer: .
A Lambda function URL is a dedicated, always-on HTTPS endpoint attached directly to a single function, configured with just an auth type (IAM-based or public NONE access) and a CORS setting, which makes it the minimal-setup option for a single-function webhook. API Gateway, by contrast, is the right tool when routing across multiple functions or backends, request/response mapping templates, custom domains, API keys with usage plans, or fine-grained per-route throttling are needed — capabilities that add configuration overhead the simple webhook case doesn't require. Claiming API Gateway needs no separate configuration has it backwards, since API Gateway requires defining resources, methods, and a deployment stage beyond the function itself. Function URLs do not support request/response transformation, per-route custom authorizers, or usage-plan API keys the way API Gateway does. Finally, a function can have a function URL configured while also being separately integrated behind an API Gateway; the two are not mutually exclusive.
A Lambda function subscribed to a DynamoDB Streams event source mapping processes item-level change records to keep a search index in sync. A single table item receives three rapid updates in quick succession. Which statement about the ordering of the resulting stream records is correct?
AWithin a single shard, DynamoDB Streams delivers event records in the same order the underlying item changes occurred, and since all changes for a given item's partition key are captured by the same shard, the three updates arrive and are processed in order
BDynamoDB Streams provides no ordering guarantee at all, even within a single shard, so the three updates could be delivered to the function in any order
COrdering is guaranteed globally across the entire table and across every shard at all times, regardless of how many shards the stream has
DOrdering across the three updates is only guaranteed if the event source mapping's batch size is explicitly set to 1 record per invocation
Correct answer: .
DynamoDB Streams guarantees the order of records within a single shard, and every change to a given item is always captured by the same shard because shard assignment for an item's changes is tied to its partition key. Since the Lambda event source mapping polls each shard in sequence and delivers that shard's records in order, the three rapid updates to one item are guaranteed to arrive and be processed in the order they happened. Claiming there is no ordering guarantee at all is wrong, since per-shard ordering is exactly what Streams provides. Claiming a total global order across every shard in the table is also wrong, because ordering is only guaranteed within a shard, not across the many shards a busy table's stream can have. Batch size configures how many records are delivered per invocation and has no bearing on whether per-shard ordering holds; that guarantee comes from the shard's own sequence, not from processing one record at a time.
Source: AWS documentation: Amazon DynamoDB Streams and AWS Lambda triggers
An SQS event source mapping has batch item failure reporting (ReportBatchItemFailures) enabled for its Lambda function. During one invocation processing a batch of 10 messages, the function successfully processes 8 messages, then throws an unhandled exception while handling the 9th (the 10th is never attempted), without ever returning a batchItemFailures response listing specific message IDs. What happens to the batch's messages as a result?
AEnabling ReportBatchItemFailures automatically marks the two messages the function never confirmed processing as failed even without an explicit response, so only messages 9 and 10 are redelivered while the 8 already-processed messages are deleted immediately
BBecause the function threw an unhandled exception instead of returning a response that lists specific failed message IDs, Lambda treats the whole batch as a complete failure regardless of the ReportBatchItemFailures setting, so all 10 messages, including the 8 the function had already finished, become visible again once the visibility timeout expires
CReportBatchItemFailures changes the visibility timeout mechanism itself, so the 8 successfully processed messages are held invisible indefinitely until manually deleted, while messages 9 and 10 are redelivered immediately
DSQS moves the entire batch to a dead-letter queue immediately upon detecting the exception, without waiting for the visibility timeout or checking the source queue's redrive policy
Correct answer: .
Turning on ReportBatchItemFailures only changes how a batch is scored if the function itself catches its own errors and explicitly returns a response listing the failed message IDs; it does not add any automatic detection of partial progress on top of an unhandled exception. When the function instead lets an exception propagate out of the handler, Lambda has no per-message signal to work with, so the entire invocation is scored as a complete failure exactly as it would be without the feature enabled, and every message in the batch, including the 8 that were actually finished, becomes visible again once the queue's visibility timeout expires and gets redelivered. There is no automatic partial-credit mechanism that infers which messages were done based on where the exception occurred. ReportBatchItemFailures does not alter how the visibility timeout itself works; it only changes which messages get deleted once an invocation reports back. And a dead-letter queue redrive only happens once a message's receive count exceeds the source queue's configured maxReceiveCount, not immediately on a single failed attempt.
Source: AWS Lambda docs: Handling errors for an SQS event source in Lambda — Implementing partial batch responses
A Lambda function has no reserved concurrency configured, and the account's overall concurrency limit is comfortably above what the function needs. Traffic to the function suddenly jumps from near zero to a sustained 5,000 concurrent invocations in under 2 seconds. Given Lambda's per-function concurrency scaling behavior, what is the most accurate expectation for the first few seconds of this spike?
ALambda instantly provisions all 5,000 execution environments within the first second, since account-level concurrency, not any per-function scaling rate, is the only limiting factor
BBecause reserved concurrency isn't configured, the function is hard-capped at exactly 1,000 concurrent executions no matter how much unreserved account concurrency is available
CLambda scales the function in one large step every 60 seconds, so requests queue for up to a minute before any scaling occurs
DLambda scales this function's execution environments at a fixed per-function rate of up to 1,000 additional execution environments every 10 seconds, so some invocations beyond that rate are throttled in the first few seconds even though the account has unused concurrency headroom, until the function's concurrency catches up with demand
Correct answer: .
Lambda's per-function concurrency scaling rate is a separate quota from the account-wide concurrency limit: for each function, Lambda can allocate at most 1,000 additional execution environment instances every 10 seconds, regardless of how much unreserved concurrency the account otherwise has available. A sudden jump to 5,000 concurrent invocations in under 2 seconds outpaces that ramp rate, so some requests are throttled in the first several seconds purely because the function hasn't scaled up yet, even though the account-level concurrency ceiling was never actually reached. This is why the claim that account concurrency is the only limiting factor is wrong: the scaling rate is a distinct, function-level ceiling on how fast that headroom can be used. The 1,000-concurrent-execution figure describes the default account-wide limit, not a hard per-function cap independent of reserved concurrency, so a function without reserved concurrency can still use more of the account's unreserved pool as it scales, just not instantaneously. And there is no real 60-second stepped scaling behavior in Lambda; scaling proceeds continuously against the 10-second-window rate described above.
Source: AWS Lambda docs: Understanding Lambda function scaling — concurrency scaling rate and quotas
An S3 bucket is configured with an event notification that invokes a Lambda function whenever a new object is uploaded, and the function's code needs to read that uploaded object from S3 to process it. After deployment, S3 uploads never trigger the function at all, even though the function's execution role already has an IAM policy granting s3:GetObject on the bucket. What is the most likely cause?
AThe function is missing a resource-based policy statement granting the S3 service principal permission to invoke the function (lambda:InvokeFunction); the execution role only governs what the function's code can access once it does run, not who is allowed to invoke it
BThe execution role's s3:GetObject permission is unrelated to Lambda invocation, but adding an s3:InvokeFunction action to that same execution role would have fixed the problem instead
CS3 event notifications can only invoke Lambda functions that have no execution role attached at all, so removing the role entirely would resolve the issue
DLambda functions triggered by S3 must have reserved concurrency configured before S3 is permitted to invoke them, and that configuration is what's missing here
Correct answer: .
Lambda separates two distinct permission questions: who is allowed to invoke a function, and what the function's own code is allowed to do once it's running. The first is controlled by the function's resource-based policy, which must name the calling service (here, S3, via its service principal) as a principal allowed to call lambda:InvokeFunction; without that statement, S3 is never authorized to trigger the function in the first place, no matter what else is configured. The second is controlled by the execution role, which is exactly what grants the already-running function's code permission to call s3:GetObject and read the uploaded object — but that role only takes effect after invocation has already happened, so it can't fix a problem that's blocking invocation from occurring at all. There's no such action as s3:InvokeFunction to add to an execution role; invoke permission for an external caller belongs on the function's own resource-based policy instead. Lambda functions normally do have execution roles, and reserved concurrency governs concurrency limits, not who is authorized to invoke a function.
Source: AWS Lambda docs: Working with resource-based policies in Lambda
A team wants to run custom code at CloudFront edge locations to modify an origin request before it is sent to the origin server, including making an outbound network call to a third-party API to enrich the request with additional data. Which statement correctly evaluates whether CloudFront Functions or Lambda@Edge fits this requirement?
ACloudFront Functions fits perfectly, since CloudFront Functions can run on the origin-request event and its JavaScript runtime includes full network access for outbound calls to third-party APIs
BNeither service can modify an origin request; only the viewer-request and viewer-response events can be customized anywhere at the CloudFront edge
CLambda@Edge is required here, because CloudFront Functions only supports the viewer-request and viewer-response events (not origin-request or origin-response) and has no network access at all, while Lambda@Edge supports all four event types and does allow outbound network calls
DCloudFront Functions is required here because it is the only one of the two that supports the origin-request event; Lambda@Edge is limited to the viewer-request and viewer-response events only
Correct answer: .
CloudFront Functions only runs on the viewer-request and viewer-response events, is limited to a submillisecond, no-network-access JavaScript runtime meant for lightweight tasks like cache-key normalization or header manipulation, and cannot touch the origin-request or origin-response stages at all. Lambda@Edge, by contrast, supports all four CloudFront event types, including origin-request and origin-response, runs a full Lambda execution environment with network access, and allows outbound calls such as the third-party API enrichment described here. Because this scenario needs both the origin-request trigger point and outbound network access, only Lambda@Edge covers both requirements, which rules out CloudFront Functions being sufficient on its own. The claim that neither service can touch origin requests is wrong, since Lambda@Edge explicitly supports that event; and the claim that CloudFront Functions is the one limited to viewer events while Lambda@Edge only handles origin events has the two services' event-source support exactly backwards.
Source: AWS documentation: Differences between CloudFront Functions and Lambda@Edge
In an AWS Step Functions state machine defined with the Amazon States Language, a Task state calls a downstream API that occasionally throws a transient error. The team wants the state to automatically retry that specific named error a few times with an increasing delay between attempts, and only if every retry attempt is exhausted should the workflow move to a dedicated cleanup state instead of failing outright. Which state machine construct(s) achieve this?
AA single Catch field configured with the error name and a BackoffRate; the Catch field itself performs the retries before falling back to the cleanup state
BA Retry field naming the specific error with a configured MaxAttempts and BackoffRate for exponential delay between attempts, combined with a separate Catch field that only takes effect once the Retry policy's attempts are exhausted, routing execution to the cleanup state
CNeither Retry nor Catch can target one specific named error; both apply only to every error the state could ever throw, with no way to scope them to the transient error alone
DA Parallel state is required, since Retry and Catch fields only exist on Map states, not on individual Task states
Correct answer: .
In the Amazon States Language, a Retry field is an array of retriers that can each name a specific error (via ErrorEquals) and define MaxAttempts and a BackoffRate to control automatic re-attempts with an increasing delay, all without any custom code — exactly the transient-retry behavior wanted here. A Catch field is a separate array of catchers that only takes over once a matching Retry policy's attempts are exhausted (or if no retry policy applies), routing execution to a designated fallback state such as the cleanup state; Catch itself never performs retries. Because ErrorEquals lets both Retry and Catch be scoped to one specific named error, the claim that they can only apply to every possible error is incorrect, and describing Catch as the thing that performs retries confuses the two fields' separate roles. Both Retry and Catch are supported directly on ordinary Task states in the Amazon States Language; there is no requirement to wrap the task in a Parallel or Map state to use either field.
Source: AWS Step Functions docs: Amazon States Language — error handling with Retry and Catch
A team wants a Lambda function to run automatically every night at a fixed time to generate a report, without any component polling for the time or relying on an external cron server. Which approach achieves this natively within AWS?
AConfigure the Lambda function's own reserved concurrency to 1 and have the function poll an environment variable holding a time-check on every cold start
BUse an SQS delay queue, repeating its maximum per-message delay in a loop until the target time of night is reached, then invoke the function
CAttach an RDS event subscription to the function so it fires whenever the database's internal clock reaches midnight
DCreate an Amazon EventBridge rule with a cron or rate schedule expression and configure the Lambda function as its target; EventBridge itself triggers the rule at the scheduled time and invokes the function directly, with no polling needed anywhere
Correct answer: .
Amazon EventBridge scheduled rules support either a cron expression, for firing at specific times and dates such as a fixed time every night, or a rate expression, for firing at a regular recurring interval; once such a rule is created with a Lambda function configured as its target, EventBridge itself is responsible for triggering the rule at the scheduled moment and invoking the function directly, with nothing else needing to check the clock or poll for anything. Reserved concurrency only bounds how many concurrent executions a function can run and has nothing to do with scheduling invocations, and having the function poll an environment variable at cold start would require something to already be invoking it in the first place, which defeats the purpose. SQS delay queues cap the delay on any single message at a fixed maximum, and chaining them in a loop is not how AWS scheduling is designed to work. RDS has no built-in mechanism for emitting time-of-day events to trigger downstream compute like this.
Source: AWS documentation: Amazon EventBridge — Creating a scheduled rule
An order-processing event needs to trigger three independent downstream workflows, an inventory update, a customer notification email, and analytics logging, each implemented as a separate Lambda function that should be able to process the event at its own pace without one workflow's failure or slowdown affecting the others. Which architecture achieves this?
APublish the order event once to an SNS topic with three SQS queues subscribed as fan-out targets, each queue feeding its own Lambda function through an event source mapping; each queue buffers and retries independently, so one workflow's failures or delays don't block or lose events for the others
BInvoke all three Lambda functions synchronously in a single chained call from the order service, so each function runs one after another within the same request
CPublish the event directly to a single SQS queue, then have each of the three Lambda functions poll and consume messages from that same shared queue so all three always process every event
DConfigure a single Lambda function with three separate reserved concurrency pools, one for each downstream responsibility
Correct answer: .
The SNS fan-out pattern publishes each event once to an SNS topic, and every SQS queue subscribed to that topic receives its own independent copy of the message; because each queue then feeds a separate Lambda function through its own event source mapping, that function's backlog, retries, and failures are entirely isolated from the other two workflows, so a slowdown or repeated failure in one downstream path never blocks or drops events destined for the others. Chaining the three functions synchronously in one request makes them dependent on each other's success and timing, which is exactly the coupling the requirement wants to avoid. A single shared SQS queue delivers each message to only one consumer under the standard competing-consumers model, so the other two functions would not reliably see every event, rather than all three independently receiving a copy. Partitioning one function's reserved concurrency into three pools still leaves a single function and code path handling all three responsibilities, rather than three genuinely independent functions with isolated buffering and retry behavior.
A team is building a video-transcoding workload that processes jobs ranging from a few minutes to several hours of runtime each, with predictable, steady throughput most of the day and a need for direct control over the container's CPU and memory allocation. Which compute choice fits best, and why?
AAWS Lambda, because its per-invocation timeout can be extended indefinitely for workloads with predictable, steady runtime
BAWS Lambda, because Lambda functions are billed identically to Fargate tasks for long-running work, so there is no cost reason to prefer one over the other
CAWS Fargate, because it runs containers without the fixed per-invocation duration ceiling that Lambda has, and it exposes direct, explicit control over the task's CPU and memory allocation, a better fit for long, steady-state, resource-tunable container workloads than a short-lived, event-driven function
DAWS Fargate, because it automatically decomposes any workload into 15-minute segments internally, so Lambda's timeout limitation never actually applies to Fargate-hosted code
Correct answer: .
Fargate runs containers for as long as a task genuinely needs, with no equivalent to Lambda's fixed per-invocation timeout ceiling, and it lets a team directly size the task's CPU and memory rather than working within Lambda's memory-driven, indirect CPU allocation, which together suit a workload with multi-hour jobs and steady, predictable throughput better than a short-lived, event-driven function model. Lambda's per-invocation timeout is a hard quota on standard invocations, not something that can simply be extended indefinitely to match a job's actual runtime, so relying on ever-longer Lambda invocations for multi-hour jobs isn't a realistic fit. Lambda and Fargate also don't share an identical billing model: Lambda charges per request and per-millisecond duration on ephemeral executions, while Fargate charges for the vCPU and memory provisioned for the task's running time, so the cost structures genuinely differ for steady, long-running work. Fargate has no internal mechanism that automatically chops a workload into 15-minute segments; that specific timeout characteristic belongs to Lambda, not Fargate, which is exactly why Fargate is the better fit here.
Source: AWS documentation: AWS Fargate and AWS Lambda — choosing a serverless compute option
A nightly Lambda function processes an ever-growing batch of records and now occasionally approaches its function timeout before finishing, prompting repeated requests to raise the timeout further. Lambda's per-invocation timeout is a fixed quota with a documented maximum for standard invocations. Which redesign fits AWS's recommended approach for a job that could keep growing past that ceiling?
ASplit the workload across multiple concurrent executions of the same function, each configured with a custom per-invocation timeout that exceeds the account's documented maximum
BBreak the job into smaller units of work orchestrated by an AWS Step Functions state machine, or hand the processing to a compute option without Lambda's fixed per-invocation ceiling, so no single invocation needs to run longer than the documented maximum regardless of how large the overall job grows
CRequest a Lambda function timeout quota increase from AWS Support, since the per-invocation timeout is a soft, requestable limit like account concurrency and can be raised without bound for a single invocation
DEnable provisioned concurrency on the function, since pre-initializing execution environments removes the per-invocation timeout ceiling entirely
Correct answer: .
Because Lambda's standard per-invocation timeout is a fixed, documented ceiling rather than something a single invocation can simply be granted more of as a job grows, the recommended redesign is to stop depending on one ever-longer invocation and instead break the work into smaller, bounded units, coordinated by an AWS Step Functions state machine that tracks progress between steps, or move the processing to a compute option that doesn't share Lambda's fixed per-invocation ceiling in the first place; either way, no single invocation needs to grow past the documented maximum no matter how large the overall batch becomes. There is no per-invocation timeout override available beyond the documented maximum for standard invocations, so configuring a custom value past it on individual executions isn't possible. Unlike concurrency, which is a requestable account-level quota, the per-invocation timeout for standard invocations isn't something AWS Support can raise arbitrarily for a single function. Provisioned concurrency addresses cold-start latency by pre-initializing execution environments; it has no effect on how long a single invocation is allowed to run.
Source: AWS Lambda docs: Lambda quotas — function timeout; AWS Step Functions docs: orchestrating long-running work
A team stores a handful of Lambda environment variables, including one holding a third-party API key, and assumes that because Lambda encrypts environment variables at rest by default, an IAM principal with read access to the function's configuration cannot see the API key's plaintext value anywhere. Which statement corrects this assumption?
ALambda cannot encrypt environment variables at all without the team first explicitly enabling a customer managed KMS key, so the API key is already stored as plaintext today
BThe assumption is entirely correct: default at-rest encryption alone guarantees the plaintext value is never displayed to any principal with read access to the function
CDefault at-rest encryption only applies to environment variables whose name contains the word KEY or SECRET; the API key variable specifically needs a customer managed KMS key before it is encrypted at all
DDefault at-rest encryption keeps the value encrypted in storage, but a principal with permission to view the function's configuration, through the console or the GetFunctionConfiguration API, can still see the decrypted plaintext value there; for a secret that must stay hidden even from such principals, the team should use a dedicated service like AWS Secrets Manager rather than relying on environment variable encryption alone
Correct answer: .
Lambda automatically encrypts all of a function's environment variables at rest by default with no setup required, and a team can additionally configure a customer managed KMS key in place of Lambda's own default key for that encryption; however, at-rest encryption only protects the stored value, not who can view it once decrypted, so a principal with legitimate permission to read the function's configuration through the console or the GetFunctionConfiguration API still sees the plaintext value there, because Lambda decrypts it for authorized display. That means a value that must stay hidden even from such principals, like a genuinely sensitive API key, belongs in a dedicated secret store such as AWS Secrets Manager rather than relying on this default encryption alone. Encryption at rest is automatic and does not require configuring a customer managed key first, so the assumption in the scenario is wrong precisely because authorized viewers can still see the decrypted value, not because encryption itself is missing. There is no name-based rule that selectively decides which environment variables get encrypted at rest; the default applies uniformly to the entire set.
Source: AWS Lambda docs: Working with Lambda environment variables — securing environment variables