AWS Developer Associate (DVA-C02) Practice Test

Answer: A
An immutable deployment launches a complete set of new instances in a separate Auto Scaling group alongside the existing ones and, if the new instances fail health checks, terminates them and leaves the original instances untouched. Rolling (D) and rolling with an additional batch (B) both deploy in batches, so completed batches serve the new version while pending batches serve the old one. All at once (C) takes every instance out of service briefly and, on failure, leaves the environment broken rather than intact.

Answer: D
A VPC peering connection links two VPCs with non-overlapping CIDR blocks so that instances communicate over private IP addresses across the AWS network; after both sides add routes to the peer CIDR and the RDS security group allows the instance, traffic never crosses the internet, a NAT gateway or a VPN. Option A reaches the RDS control-plane API (DescribeDBInstances and similar), not the database's TCP endpoint; PrivateLink does not connect you to a database listener in another VPC. Option B does not exist: gateway endpoints are available only for Amazon S3 and DynamoDB. Option C gives the application a read-only copy; writes would still have to reach the primary in the other VPC, which is the problem the question is asking you to solve.

Answer: C
Canary (a small first increment, then the rest after an interval) and linear (equal increments at fixed intervals) traffic shifting expose only part of the traffic to the new version while metrics are watched, and CodeDeploy rolls back automatically when an alarm attached to the deployment fires; blue/green switches everything at once and offers fast rollback without gradual exposure. Option A updates instances one by one in place with no traffic percentage control, and rollback depends on a human noticing and acting. Option B provisions a parallel fleet but moves 100 percent of traffic in one step after the wait; it is not gradual and the rollback described is manual. Option D replaces the fleet but says nothing about shifting traffic in steps or rolling back on an alarm, which are the two properties the question asks for.

Answer: B
Infrastructure as code turns environment changes into commits: they are diffed, peer reviewed, versioned and revertible, and a change set shows what a deployment will do before it runs. Drift is still possible when someone changes a resource outside the tooling, which is why CloudFormation offers drift detection to find and correct it. Option A overstates the control: CloudFormation does not block out-of-band changes; drift detection reports them (MODIFIED, DELETED, IN_SYNC) after the fact. Option C confuses linting with testing; cfn-lint checks template syntax and some rules, but a valid template can still fail at deploy time or produce infrastructure that does not behave as intended. Option D misunderstands billing; the resources a template creates are billed the same as resources created any other way.

Answer: A
Keeping environment-specific values in Systems Manager Parameter Store, AWS AppConfig or Secrets Manager and resolving them at startup means the artifact promoted to production is byte-for-byte the one that passed staging; only the configuration differs, and it can be changed and audited without a rebuild. Option D means the production binary is a different build from the one that was tested, so a dependency or toolchain difference can reach production untested. Option C lets the branches diverge over time, mixes configuration changes with code changes in every merge, and still produces a different build per environment. Option B leaves servers in states nobody can reproduce; CloudTrail records AWS API calls, not edits made over SSH, so the ticket documents intent rather than what is actually running.

Answer: D
A mutable tag such as latest can point at different content over time, so two hosts pulling the same tag may run different code and a rollback may not return to the previous state. Pinning a unique version tag or the sha256 digest (and turning on tag immutability in ECR) makes what is running unambiguous and reproducible. Option A is wrong about ECR, which lets a mutable tag move to a new digest on every push unless tag immutability is enabled on the repository; that is the ambiguity being avoided. Option B produces a different image on every host, because base image and package resolution can change between builds; nothing guarantees the hosts run identical code. Option C is a security control, not an identity control; scanning does not fix the fact that a tag can be reassigned.

Answer: B
Failures that appear only in production live in the differences between environments; promoting one immutable artifact (the same zip, container digest or CloudFormation package) through development, staging and production removes the build itself as a variable and confines every remaining difference to configuration that can be compared. Option A reintroduces the variable being eliminated; dependency resolution or toolchain versions can differ between the tested build and the deployed one. Option C removes the safety net; a feature flag limits blast radius but does not test the artifact before real users hit it. Option D trades away verification for speed and misdiagnoses the cause, which is environment difference rather than the time between build and deploy.

Answer: C
Rollback is only quick if the previous artifact is still available to redeploy (a kept Lambda version, container digest or S3 object) and only safe if the schema migration that shipped with the release still works with the old code, which is why expand-and-contract migrations are the enabling practice. Option A is the slow path at exactly the moment speed matters most; a rebuild and full pipeline run can take far longer than redeploying a retained artifact. Option B throws away every transaction since the snapshot and keeps the defective code running; it is data loss, not rollback. Option D produces inconsistent servers with no record of what runs where, and the next automated deployment overwrites the edits.

Answer: A
An out-of-band edit creates drift between the running configuration and the declared one; the pipeline knows nothing about it, so the next deployment applies the template's value and silently undoes the change, a confusing failure because the system worked until an unrelated release. The fix is to change the declared configuration and deploy it. Option B misstates both facts: the function keeps running with the edited value, and drift detection only reports MODIFIED resources, it never blocks execution. Option C invents a write-back; CloudFormation does not modify source repositories and drift is not propagated anywhere automatically. Option D has the direction backwards: the template is the source of truth and its value overwrites the console change on the next deployment.

Answer: B
CodeDeploy's Lambda compute platform shifts alias traffic with predefined canary (for example Canary10Percent5Minutes) or linear (Linear10PercentEvery1Minute) configurations, runs optional pre- and post-traffic hooks, and rolls back automatically when a CloudWatch alarm attached to the deployment group fires; AWS SAM exposes the same mechanism through DeploymentPreference. Option A applies only to Elastic Beanstalk EC2 environments behind an Application Load Balancer; Elastic Beanstalk does not deploy Lambda functions. Option C shifts traffic between API Gateway stage deployments, not between Lambda versions, and API Gateway has no automatic rollback tied to an alarm; $LATEST is also the unpublished version, which should not receive canary traffic. Option D is manual: someone has to watch the metric and move the weights, and nothing rolls the alias back automatically when errors rise.

Answer: D
CloudFormation provisions a set of related resources from a template as one stack that can be versioned, diffed with change sets, updated and rolled back; AWS SAM adds serverless resource types (AWS::Serverless::Function, Api, SimpleTable) that transform into CloudFormation, so a Lambda function, API and DynamoDB table deploy together as one unit. Option A runs procedural steps against existing resources with an approval workflow; it is not a declarative, versioned definition of a stack of resources. Option B captures the settings of an Elastic Beanstalk environment (instances, load balancer, platform) and cannot define a Lambda function, an API Gateway API or a DynamoDB table. Option C packages AWS Config rules that evaluate whether resources comply with policy after they exist; conformance packs do not create application resources.

Answer: A
Blue/green in Elastic Beanstalk means deploying the new version to a separate environment, testing it, and then choosing Swap environment URLs so the CNAME records of the two environments are exchanged; traffic moves instantly and swapping back is the rollback, which is the only option that keeps two independently addressable environments. Option B does provision a fresh fleet, but inside the existing environment with a single URL; there is no second environment to swap back to, and rollback means another deployment. Option C updates the existing instances batch by batch in place; it maintains capacity during the update but never provisions a complete parallel set of instances. Option D is Elastic Beanstalk's canary test within one environment (it requires an Application Load Balancer); traffic is split gradually rather than switched, and there is no URL swap.

Answer: C
CodeBuild is a managed build service that compiles source code, runs tests, and produces deployment-ready artifacts, and it's the standard build-stage action integrated into CodePipeline. CodeCommit (D) is a managed Git source-control repository service, used for storing source code, not for building or testing it. EventBridge (A) is an event bus for routing events between AWS services and applications, not a build/test execution service. Direct Connect (B) is a dedicated network connection service between on-premises and AWS, entirely unrelated to CI/CD build processes.

Answer: D
A manual approval action is a built-in CodePipeline action type: the execution stops at the action, optionally publishes an SNS notification with a review URL and comments, and resumes when someone with codepipeline:PutApprovalResult approves; if nobody responds within seven days the action fails. Option A is a coarse on/off switch for the whole stage rather than a per-execution approval: once re-enabled it lets every queued and subsequent revision through, and it records no approver, comment or timeout. Option B burns build minutes polling and gives the release manager nothing to review in the console; it is a fragile imitation of a feature CodePipeline already provides. Option C stops the execution outside the pipeline's own control flow; a stopped execution does not resume with an approval, and no review link or approver record is produced.

Answer: B
ECS's CodeDeploy blue/green deployment integration provisions a new (green) task set alongside the running (blue) one, uses ALB target group health checks to validate the new set, shifts traffic over, and can automatically roll back if health checks or CloudWatch alarms fail — matching every requirement described. Manually stopping and starting all tasks at once (C) causes downtime and provides no automated health-check gating or rollback. S3 static website hosting (D) serves static files and is unrelated to container orchestration or ECS deployments. Direct Connect (A) is a dedicated network link between on-premises infrastructure and AWS, entirely unrelated to application deployment strategy.

Answer: C
By default, if a CloudFormation stack update fails, CloudFormation automatically rolls back the changes to restore the stack to its last successful state, requiring no manual intervention. Stack termination protection (D) simply prevents a stack from being accidentally deleted, it has nothing to do with handling failed updates. Drift detection (A) identifies when actual resource configuration has diverged from the stack's template, it does not perform any rollback action. Explicitly setting DisableRollback=true (B) would do the opposite of what's needed — it prevents automatic rollback, leaving the stack in a partially updated/failed state for manual troubleshooting.

Answer: A
Once a function is attached to a VPC it can reach only what that VPC can reach, so the private RDS instance is accessible but public AWS endpoints are not; the documented answer is a NAT gateway in a public subnet or, cheaper and more direct, a gateway endpoint for S3 and DynamoDB (or interface endpoints for other services), with a security group that allows the required traffic. Option B does not work: Lambda's documentation states that connecting a function to a public subnet gives it neither internet access nor a public IP address; the ENI is always private. Option C misreads the managed policy, which only lets the Lambda service create and manage the network interfaces (ec2:CreateNetworkInterface and related actions); it provides no route to the internet. Option D abandons the private-connectivity requirement by exposing the database publicly, and Lambda has no published set of IP ranges to allow in a security group.

Answer: A
Lambda scales by adding execution environments, and each one that initializes a database client holds its own connection, so a burst of concurrency can open more connections than the instance class allows. RDS Proxy pools and multiplexes those connections in front of the database, which is the recommended fix for serverless clients. Option B would produce an authentication or access-denied error, not 'too many connections'; a missing IAM permission never consumes a connection slot. Option C describes the opposite of how Lambda works: environments never share a connection, and throttling the function to a single environment would cripple the application rather than fix the root cause. Option D blames monitoring features that do not hold client connections; the connections are coming from the many concurrent function environments.

Answer: B
The first request after idle time lands on a new execution environment, so Lambda must download the code, start the runtime and run the initialization code before the handler; that Init phase is the cold start. Provisioned concurrency keeps a configured number of environments initialized, so those requests skip the cold start (SnapStart is an alternative for Java, Python and .NET). Option A confuses the invocation timeout with environment lifetime; the timeout bounds one invocation and has no effect on how long an idle environment is kept. Option C misapplies two concurrency controls: the scaling rate governs bursts, and reserved concurrency caps how many environments may run without keeping any of them warm. Option D is outdated and wrong: Hyperplane ENIs are created when the VPC configuration is saved and shared by environments, and a public subnet gives a Lambda function neither a public IP nor faster starts.

Answer: D
X-Ray builds one trace per request: API Gateway with active tracing emits the first segment and propagates the X-Amzn-Trace-Id header, the Lambda service and function add their segments, and an instrumented DynamoDB client records a subsegment for each call, so the trace timeline and service map show the latency of every hop side by side. Option A requires stitching three different log sources together by hand and still yields no per-hop timing; CloudTrail data events record that a DynamoDB call happened, not how long it took. Option B misdescribes both features: Lambda Insights reports CPU, memory and network for the function, and Contributor Insights shows the most accessed keys in a table; neither draws a request path. Option C captures IP-level flow metadata for traffic in your VPC; API Gateway and the DynamoDB service endpoint are not in that path, and flow logs never show application request latency.

Answer: D
A trace collects the segments and subsegments that one request generated across services and shows them on a timeline, so you can see which downstream call accounts for the latency; logs scattered across services cannot reconstruct that path without a shared correlation ID and manual joining. Option A describes metrics: they show how many requests were slow or failed per service, not the path of one request or where inside it the time went. Option B describes CloudTrail event history; it is an audit record of control-plane and some data-plane calls and carries no request latency. Option C describes a code profiler, which shows where CPU time goes inside one process; it cannot follow a request into another service.

Answer: A
Emitting JSON fields lets CloudWatch Logs Insights discover the fields and filter, aggregate and chart on them (for example, stats avg(duration) by route), and lets metric filters match on field values, without regular expressions that break whenever a message is reworded; the trade-off is more bytes per entry, not fewer. Option B confuses format with storage class; the log class is chosen when the log group is created and cannot be changed, and it is unrelated to how entries are formatted. Option C invents a pricing rule; ingestion is billed per gigabyte regardless of format, and JSON entries are usually larger than the equivalent sentence. Option D invents exemptions; the 256 KB event limit and the retention policy apply to every event in the log group.

Answer: C
A dependency call without a client-side timeout can hang until the function itself is killed, which turns a slow downstream call into a hard failure with no useful error. Setting the SDK or HTTP client timeout below the function timeout lets the code catch the failure, retry or degrade, and return something meaningful. Option A misuses a real number: 1,769 MB is where a function gets one full vCPU, but smaller functions finish fine; memory affects speed, not the ability to complete. Option B invents an overhead; IAM authorization happens before the invocation starts and does not consume the function's execution time. Option D is wrong twice: 50 MB is the limit for direct upload, not a performance threshold, and code is downloaded once per execution environment, not per invocation.

Answer: B
Lambda allocates CPU in proportion to memory (a function reaches one full vCPU at 1,769 MB), so a CPU-bound function runs faster with more memory, and because billing is memory multiplied by duration the shorter run can cost the same or less; the optimum is found by measuring, for example with the Lambda Power Tuning tool. Option A confuses two independent settings; the architecture (x86_64 or arm64) is chosen separately from memory, and memory never moves a function between processor types. Option C invents a relationship; how long Lambda keeps an idle environment is not controlled by the memory setting, and a warm start does not shorten the handler's own work. Option D is wrong because /tmp size is configured independently (512 MB to 10,240 MB) and has nothing to do with how fast the handler's code executes.

Answer: B
BatchGetItem fetches up to 100 items (16 MB) by primary key in one request, retrieving them in parallel, and a ProjectionExpression returns only the attributes you name; any keys returned in UnprocessedKeys are retried with backoff. Option A reads and pays for the entire table before filtering, so its cost grows with table size regardless of how few items match; a scan is the most expensive way to answer a key-based lookup. Option C does retrieve up to 100 items, but it is the wrong tool and the cost claim is false: transactions perform two underlying reads per item, and they exist for a consistent snapshot, not for bulk retrieval. Option D issues one request per key and requires an index that is unnecessary when the primary keys are already known.

Answer: B
IteratorAge is the age of the last record in a batch when Lambda reads it, so a steadily rising value means records are being written faster than the consumer drains them. Raising ParallelizationFactor (1 to 10 concurrent batches per shard, still ordered per item), making each batch cheaper to process, or filtering unneeded events are the documented first responses. Option A confuses two features: DynamoDB Streams records do live for 24 hours, but point-in-time recovery is a backup feature for the table and has no effect on stream retention or on the consumer's lag. Option C is wrong because reading a DynamoDB stream does not consume the table's read capacity units, and a batch size of 1 makes the function process fewer records per invocation, so the lag grows. Option D would make the metric worse, not better: re-creating the mapping at TRIM_HORIZON re-reads the oldest retained records, and the starting position has nothing to do with sustained lag.

Answer: D
Throttling means the service is asking the caller to slow down. Exponential backoff with full jitter spreads retries over a widening random window (the SDK's standard mode makes 3 attempts by default, with a 1,000 ms base delay for throttling errors and a 20-second cap), which lets the service recover instead of being hit by synchronized retries. Option A turns retries off entirely, so every throttled call fails on the first attempt, and legacy mode exists only for backward compatibility. Option B is a tight fixed-interval loop that ignores backoff and misreads standard mode: the SDK's jitter applies to the SDK's own retries, not to a loop the application writes around them. Option C adds callers, which increases the request rate against a service that is already rejecting requests; the downstream quota is independent of the function's concurrency.

Answer: C
The SDKs classify errors by code: validation, access-denied and not-found errors (4xx) are returned immediately because retrying cannot fix the request, throttling errors (also 4xx) are retried with a longer backoff, and 500, 502, 503 and 504 responses are treated as transient and retried; retry logic must therefore inspect the error code, not just the status class. Option A misdescribes both classes: 4xx means the request itself was rejected, and 5xx errors are the ones most often transient and worth retrying. Option B invents meanings; a signature or clock-skew problem is one specific 4xx cause among many, and an oversized payload is reported as a 4xx validation error, not a 5xx. Option D is wrong about the SDK, which returns non-retryable 4xx errors such as ValidationException immediately and applies the 3-attempt backoff only to transient and throttling errors.

Answer: D
With active tracing on the function and the X-Ray SDK wrapping the outbound HTTP client, each trace shows the function segment with a subsegment for the downstream call, so the time inside the handler and the time waiting on the third-party API are separated per request and aggregated on the service map. Option A gives resource-level metrics (CPU, memory, network) per invocation; it does not attribute wall-clock time to an individual outbound call. Option B shows only the total duration of each invocation; the REPORT line has no breakdown of where inside the invocation the time went. Option C records AWS API activity, not HTTP calls to a third-party endpoint, and carries no latency data for them.

Answer: A
Query and Scan return at most 1 MB of data per call (or the number set by Limit) and include LastEvaluatedKey when they stopped at a page boundary; the caller passes it as ExclusiveStartKey until a response has no LastEvaluatedKey. Treating the first page as the whole result silently drops data as the table grows. Option B confuses pagination with throttling; exceeding capacity raises ProvisionedThroughputExceededException, and pagination tokens are returned on successful reads. Option C invents a storage split; a table's items are not moved to an index, and a query returns items from whatever table or index it was issued against. Option D gets the token's meaning backwards: because the filter is applied after the 1 MB read, a page can even return zero items and still carry a LastEvaluatedKey, which means keep paging.

Answer: C
A redrive policy on the source queue with a maximum receive count moves a message to the dead-letter queue after that many failed receives, so a poison message stops being redelivered and can be inspected or redriven later while healthy messages keep flowing; Lambda's documentation says to configure the DLQ on the queue itself for SQS event sources. Option A does not apply here: the function-level dead-letter queue captures only asynchronous invocation failures, and an SQS event source mapping invokes the function synchronously, so the failing message keeps returning to the queue. Option B only delays the next redelivery; the message reappears after the timeout and blocks again, and a 12-hour timeout would also stall every legitimate retry. Option D lets the message be retried for two weeks before silently disappearing, which is data loss rather than investigation, and a delivery delay applies to new messages, not to redeliveries.

Answer: D
At-least-once delivery makes a duplicate a normal event, typically because a consumer processed a message but did not delete it before the visibility timeout expired. An idempotent consumer, one that records processed message IDs or performs naturally repeatable operations such as setting a value instead of incrementing it, produces the same result no matter how many times the message arrives. Option A punishes the whole batch for one duplicate and turns an expected condition into a failure path; the other messages in the batch are retried and the duplicate lands in the DLQ for no reason. Option B is wrong about the mechanism: redelivery happens after the visibility timeout (30 seconds by default), and the retention period is when unconsumed messages are deleted. Option C invents an ordering guarantee; a standard queue makes no promise about where a redelivered message appears in a batch.

Answer: A
Kinesis Data Streams keeps records for a configurable retention period (24 hours by default, up to 365 days) and each consumer application reads with its own shard iterator or checkpoint, so several consumers process the same records independently and a new or recovering consumer can replay from an earlier position. Option B delivers and forgets: a subscriber that was down or added later never sees past events, because SNS keeps no record after delivery. Option C removes a message once a consumer deletes it, so only one consumer sees each message and there is nothing left to replay. Option D is a delivery pipeline into S3, Redshift or OpenSearch; it does not let consumer applications track a position or read the stream directly.

Answer: D
Step Functions defines the workflow in Amazon States Language: Wait states pause without running compute, Choice states branch, and each Task carries Retry (IntervalSeconds, MaxAttempts, BackoffRate) and Catch definitions; progress is persisted between steps and a Standard workflow can run for up to a year with a visual execution history. Option A pays for compute while it sleeps, loses all progress if the invocation fails, and cannot wait longer than 15 minutes in total. Option B couples every step to the next, makes a failure in step five unwind through five callers, and is bounded by the timeouts and payload limits of synchronous invocation. Option C polls instead of reacting, adds up to an hour of latency to every transition, and forces the developer to write the state tracking that orchestration provides.

Answer: B
The asynchronous request-reply pattern acknowledges the request at once (202 Accepted with a job ID), puts the work on an SQS queue or starts a Step Functions execution, and lets the client poll a status endpoint or receive a callback; the client is not held waiting and the work is not bound by request timeouts. Option D still ties the client and the connection to the duration of the work; a longer integration timeout moves the limit rather than removing it and does nothing for clients that disconnect. Option A does not perform the work at all; it pushes the request back to the client and repeats the same problem on the next attempt. Option C still keeps the client connected for the whole duration, because streaming changes how the response is delivered, not whether the caller must wait for completion.

Answer: B
Mocking the SDK client isolates the unit under test from network latency, credentials, cost and service state, so the suite is fast and deterministic enough to run on every change; integration tests against a real or emulated service remain a separate, complementary layer. Option A makes tests slow, flaky and expensive, risks mutating production data, and commits long-term credentials to the repository. Option C leaves the code that talks to AWS, usually where the bugs are, without automated coverage. Option D makes the suite slower and still nondeterministic; a fixed sleep is either too short on a bad day or wasted time on a good one.

Answer: A
After a period without requests Lambda has no initialized execution environment, so the next invocation pays the Init phase: download the code, start the runtime and run the code outside the handler. That cold start is what makes the first invocation slower; subsequent invocations reuse the warm environment. Option B describes throttling, which produces 429 errors or queued asynchronous events rather than a slow success, and a lightly used function is nowhere near the concurrency limit. Option C invents a mechanism; /tmp is ephemeral storage that persists only while the environment lives and is never restored from S3. Option D attributes the delay to name resolution, which takes milliseconds and does not explain the hundreds of milliseconds to seconds of runtime and dependency initialization.

Answer: C
Multipart upload splits the object into parts of 5 MiB to 5 GiB (up to 10,000 parts), uploads them in parallel and retries only the parts that fail, so a dropped connection costs one part rather than the whole transfer; AWS recommends it once objects reach about 100 MB, and a lifecycle rule should abort incomplete uploads that would otherwise keep billing. Option A sits exactly at the single-PUT limit with no retry granularity: any interruption restarts the entire 5 GB transfer, and the checksum only detects corruption after the fact. Option B reduces latency by entering the AWS network at an edge location, but the transfer is still one request and a broken connection still starts it over. Option D describes a lifecycle action that does not exist; lifecycle rules transition, expire and abort incomplete multipart uploads, they never concatenate objects.

Answer: D
A request validator attached to the method checks the body against a JSON Schema (draft 4) model, so a missing required 'email' property or one that fails a pattern is rejected with a 400 before the integration runs, and the validation result is written to CloudWatch Logs; the Lambda function is never invoked. Option A transforms the payload with VTL but cannot reject the request; the integration is still invoked, only with an altered body. Option B is an authorization mechanism whose identity sources are headers, query strings, stage variables and context, not the request body, and it invokes a Lambda function of its own on every request. Option C meters and throttles calls per API key; it has no knowledge of the request body and does nothing to stop a single malformed request.

Answer: C
CloudWatch Logs bills mainly on ingested volume, so the lever is how much the function emits in production. Reading a LOG_LEVEL environment variable and emitting the payload only at DEBUG keeps the detail available in dev and test while production emits INFO and above; the same idea is what Lambda's JSON log-level filtering and Powertools loggers implement. Option A leaves DEBUG on in production, so every payload is still ingested; the Infrequent Access class only lowers the ingestion price and removes metric filters, subscription filters and Live Tail, which the team may need. Option B still ingests every payload; retention only shortens how long stored data is kept and does not reduce the ingestion charge that drives the cost. Option D puts logs in ephemeral, per-environment storage (512 MB by default) that disappears when the environment is recycled, adds a custom shipping path, and removes the payload from the centralized log stream used for debugging.

Answer: D
Lambda layers let you separate shared dependencies from function code, keeping the deployment package smaller, enabling reuse across functions, and avoiding editing large payloads inline. The console code editor (C) only supports small inline edits and can't handle large dependency trees. DynamoDB (A) is a database, not a binary/code artifact store, and loading binaries from it at runtime is impractical. Downloading dependencies at invocation time (B) adds latency and violates Lambda's stateless, fast-start execution model.

Answer: A
Provisioned capacity with auto scaling lets a table scale read/write throughput up during bursts and back down during steady periods, giving predictable baseline cost with burst tolerance. Pure on-demand (D) is simpler but can be less cost-predictable for steady, well-understood workloads. A fixed provisioned setting with no auto scaling (B) throttles during unexpected bursts. DAX (C) is a caching layer that reduces read latency and load on the table but does not itself manage or replace write/read capacity provisioning.

Answer: B
Standard queues deliver at least once, so a message that was processed but not deleted before its visibility timeout expired comes back. The fix that belongs in the application is idempotent processing: a conditional write keyed on the message ID (or an idempotency table) turns a repeated delivery into a no-op. Option A only removes duplicates the producer sends within 5 minutes; a consumer-side redelivery after a visibility timeout expiry is still delivered again, and changing the queue type is not an application-code change. Option C only delays redelivery; the message becomes visible again after 12 hours if it was not deleted, and a slow or crashed consumer still causes a second delivery. Option D sends every message that is redelivered once, including messages that failed for a transient reason, straight to the dead-letter queue, losing legitimate retries without preventing the duplicate write.

Answer: D
SNS is publish/subscribe: one Publish call delivers the message to every subscription on the topic, and SQS queues, Lambda functions and HTTPS endpoints are all supported subscription protocols, with filter policies to route subsets of events. Option A delivers each message to one consumer, which then deletes it; three subscribers would compete for messages rather than each receiving every event. Option B orchestrates the steps of one workflow with retries and history; it is not a broadcast mechanism for independent subscribers. Option C does allow multiple consumer applications to read the same records, but it requires shard management, a consumer library or enhanced fan-out and offers no native delivery to email or HTTPS endpoints; it is heavier than a simple notification fan-out.

Answer: A
Stage-level caching stores integration responses for a TTL (300 seconds by default, 3,600 maximum) and answers repeated GET requests from the cache without invoking the Lambda integration, which is exactly the goal for frequently requested, rarely changing data. Option B checks required parameters and validates the body against a JSON Schema model before the integration, returning 400 on failure; it never stores a response. Option C sets a request quota per API key for a day, week or month and throttles above it; every allowed request still invokes the backend. Option D caps the request rate per method and returns 429 Too Many Requests above the limit; it protects the backend by rejecting calls rather than by serving cached responses.

Answer: B
A ConditionExpression on UpdateItem or PutItem implements optimistic concurrency: the write succeeds only if the condition (for example, version = :expected) still holds, otherwise DynamoDB rejects it with ConditionalCheckFailedException and the client re-reads and retries. Option A makes the writes atomic and isolated but does not compare the attribute with what the client read; without a ConditionCheck or condition expression the transaction still overwrites the concurrent update. Option C returns the latest committed value but leaves the gap between the read and the write open, so another writer can still change the item in between. Option D records the change after it has already happened; a stream lets you observe an overwrite, not prevent it.

Answer: C
Code at module scope runs during the Init phase, once per execution environment, and objects it creates stay in memory while the environment is reused for warm invocations. Lambda's execution environment lifecycle documentation recommends exactly this for database connections, with a check that the connection is still alive. Option A opens a new connection on every invocation, because the request ID is different for every request; it adds a check without adding any reuse. Option B misunderstands layers, which only add files to /opt of the deployment package; nothing in a layer runs per account or shares live objects across functions. Option D cannot work because environment variables hold strings (4 KB in total); a TCP connection is a live object that cannot be serialized into configuration.

Answer: B
Step Functions is built for exactly this: a state machine runs the steps in order, each Task state has its own Retry and Catch configuration, and every execution has a visual, step-by-step history in the console; Standard workflows run up to a year with exactly-once execution. Option A routes events from sources to targets by matching patterns; a rule has no notion of a sequence of steps, per-step retries inside one workflow, or an execution history for each order. Option C only forwards the result of one asynchronous invocation (success or failure) to another target; it cannot express a multi-step sequence with branching or retries. Option D holds messages for one consumer and provides neither ordering of steps nor any view of how far a particular order has progressed.

Answer: D
For asynchronous invocations Lambda retries a function error twice and then discards the event unless a dead-letter queue (a standard SQS queue or SNS topic) or an on-failure destination (SQS, SNS, Lambda, EventBridge or, for failures, S3) is configured; both capture the event for inspection or reprocessing. Option A stops the function from being invoked at all; with reserved concurrency set to zero Lambda sends new events to a dead-letter queue or on-failure destination if one exists and otherwise drops them. Option B describes the default retry settings, which only control how long and how often Lambda retries; when they are exhausted the event is still discarded unless a DLQ or destination exists. Option C is a dedicated HTTPS endpoint for invoking the function; it has no role in retaining events that fail asynchronous processing.

Answer: D
The DVA-C02 exam guide states that the exam includes 50 questions that affect the score and 15 unscored questions that AWS uses to evaluate items for future use as scored questions; the unscored questions are not identified on the exam, and the whole set is answered within the 130-minute session. Option C has the wrong split and invents an identification step; AWS says explicitly that the unscored questions are not identified on the exam. Option A invents a dropping rule; scaled scoring equates difficulty across exam forms, it does not discard the hardest 15 items, and only 50 items are scored to begin with. Option B has the wrong split and confuses the unscored content items with a post-exam survey; the unscored questions are regular exam questions mixed into the timed section.

Answer: C
AWS reports scores on a scaled range of 100 to 1,000, and the minimum passing score for this exam is 720; the scaling accounts for minor difficulty differences across exam forms, so it is not simply a raw percentage. Option D incorrectly describes the scale as a raw percentage rather than the official 100-1,000 scaled score. Option A uses the wrong scale entirely (0-100). Option B uses the correct scale but the wrong passing threshold — 500, not 720, which would misinform a candidate about how many correct answers are actually needed to pass.

Answer: B
A throttling error (ThrottlingException, TooManyRequestsException, ProvisionedThroughputExceededException and similar) means the request rate exceeded a quota, not that the request is invalid, so it is retried with exponential backoff and jitter; the SDK's standard retry mode does this by default with a longer base delay for throttling than for transient errors. Option A misreads the status code: throttling errors are classified as retryable even though they are 4xx responses, and giving up on the first one turns a transient condition into a user-visible failure. Option C hammers a service that is already rejecting requests; the standard mode's backoff applies to the SDK's own retries, and a loop written around them defeats it. Option D moves the workload to Region-scoped resources that may not exist there; quotas are per Region, and the correct response to exceeding one is to slow down or request an increase.

Answer: A
SQS is point-to-point: a message is received and deleted by one consumer, which distributes work. SNS is publish/subscribe: a message published once is delivered to every subscription (SQS queues, Lambda functions, HTTP endpoints, email), which distributes notification. Subscribing several queues to one topic combines both. Option B inverts the two models; it is the topic that fans out and the queue that hands each message to a single consumer. Option C is wrong about SNS, which does not retain messages at all; delivery is attempted to each subscription and a failed delivery is retried or dropped according to the delivery policy. Option D reverses the limits (SQS accepts up to 1 MiB, SNS up to 256 KB) and misstates ordering, which only FIFO queues and FIFO topics provide.

Answer: B
Optimistic locking uses a condition expression such as version = :expected (or attribute_not_exists for a create) so that the write is rejected with ConditionalCheckFailedException if another process changed the item after it was read; the caller then re-reads and retries with the new version. Option A is not atomic with the write: a strongly consistent read returns the latest value, but another writer can still update the item in the interval before your write lands. Option C misdescribes transactions, which do not hold locks and, without a ConditionCheck or condition expression, will happily overwrite whatever value is present. Option D acts after the damage is done; a stream lets you detect an overwrite and attempt repair, but it does not prevent the concurrent update from being lost.

Answer: A
For an SQS standard queue the batch size can go up to 10,000 records, but Lambda requires MaximumBatchingWindowInSeconds of at least 1 second for any batch size over 10, because it needs a buffering window to gather that many messages. Reserved concurrency (B) caps scaling and has no bearing on batch size validation. FIFO queues (C) are the opposite case: their maximum batch size is 10. Retention (D) governs how long unread messages survive, not how many are delivered per invocation.

Answer: B
AWS recommends a source queue visibility timeout of at least six times the function timeout, which leaves room for Lambda to retry after a throttled batch before a message becomes visible again. Retention (C) controls how long an unconsumed message survives in the queue, not how long it is hidden after a receive. A delivery delay (D) postpones first delivery of new messages and does nothing about in-flight ones. The maximum receive wait time for long polling is 20 seconds, so 30 (A) is not even a legal value.

Answer: C
Partial batch responses require both halves: ReportBatchItemFailures in FunctionResponseTypes on the event source mapping, and a response body containing a batchItemFailures list of itemIdentifier values. Throwing an exception (D) makes Lambda treat the whole batch as a complete failure regardless of the setting. BisectBatchOnFunctionError (A) is a Kinesis and DynamoDB Streams option, not an SQS one. A maxReceiveCount of 1 (B) sends every message of a failed batch to the dead-letter queue after a single failure, discarding good work rather than retrying it.

Answer: D
Maximum concurrency is an event source level setting, accepting values from 2 to 1,000, that caps how many concurrent function instances one SQS event source can invoke. Provisioned concurrency (C) pre-initializes environments and sets no upper bound at all. ParallelizationFactor (A) applies to Kinesis and DynamoDB Streams shards, not to SQS. Lowering the account quota (B) would cap every function in the Region, which is exactly the collateral damage the team is trying to avoid.

Answer: A
ParallelizationFactor lets Lambda process one shard with up to 10 concurrent batches while still preserving order within each partition key, which is the documented way to raise throughput without adding shards. MaximumRetryAttempts (C) governs how long a failed record is retried, not concurrency. A tumbling window (D) aggregates state across invocations for calculations and does not add parallel processing. A batching window (B) makes Lambda wait longer before invoking, which increases latency rather than reducing iterator age.

Answer: B
A Kinesis event source mapping accepts TRIM_HORIZON, LATEST, or AT_TIMESTAMP, and LATEST begins reading after the newest record so the backlog is skipped. TRIM_HORIZON (A) does the opposite and replays everything still inside the retention period. AT_TIMESTAMP (C) is valid but requires StartingPositionTimestamp; it has no implicit default. AT_SEQUENCE_NUMBER (D) is a shard iterator type used by the Kinesis GetShardIterator API, not a value the event source mapping accepts.

Answer: C
Each registered enhanced fan-out consumer receives a dedicated pipe of up to 2 MB per second per shard, pushed over HTTP/2 through SubscribeToShard, independently of other consumers. Shared-throughput consumers (D) contend for a single 2 MB per second per shard budget, which is exactly why latency grows as readers are added. Option A misstates the mechanism: the dedicated throughput belongs to each registered consumer, not to a shared pool. The per-shard read rate (B) is a hard characteristic of the shard, not an adjustable account quota.

Answer: D
Standard workflows run up to one year and follow an exactly-once model, which is what AWS recommends for orchestrating non-idempotent actions such as processing payments. Express workflows (C and A) cap out at five minutes, so a multi-day wait is impossible, and their history is not retained by Step Functions at all unless CloudWatch Logs is enabled. Option B names the right workflow type but the wrong semantics: at-most-once describes Synchronous Express workflows, while Standard is exactly-once.

Answer: A
Express workflows support all service integrations but not the Job-run (.sync) or Callback (.waitForTaskToken) patterns, so a task waiting on a token cannot be defined. Enabling logging (D) changes only observability, since Express executions are not recorded by Step Functions otherwise. Distributed Map (B) is itself unsupported in Express workflows, so it could not be a workaround. Option C invents a quota: the five-minute figure is the maximum Express execution duration, and Express workflows have no state transition rate limit.

Answer: B
In Amazon States Language a retrier defaults to IntervalSeconds of 1, MaxAttempts of 3, and BackoffRate of 2.0, so the waits are roughly 1, 2, and 4 seconds. Option C swaps the defaults, and a BackoffRate of 1.0 would mean fixed intervals, which is a value you must set explicitly. MaxAttempts defaults to 3, not 1, so option D understates it, and a value of 0 is what suppresses retries. Retries are never unbounded (A); MaxAttempts always caps them whether or not a state timeout is configured.

Answer: C
The reserved name States.ALL is a wildcard that must appear alone in its ErrorEquals array and must be the last entry in the Catch array, so any catcher placed after it is unreachable and the definition is rejected. States.ALL is valid in Retry blocks as well as Catch blocks, so option B is wrong. Naming specific Lambda errors alongside it is normal practice as long as they come first, which refutes option D. ResultPath (A) is an optional field on a catcher and has no bearing on ordering rules.

Answer: D
Only a local secondary index supports strongly consistent reads, and local secondary indexes must be created when the table is created, so the existing table has to be recreated and the data migrated. Option B states the opposite of the creation rule. Global secondary indexes (C) can be added at any time but support eventually consistent reads only, which fails the stated requirement. A stream-fed shadow table (A) is far more machinery than the problem needs and still leaves a replication lag that breaks strong consistency.

Answer: A
A global secondary index is maintained asynchronously from the base table, so it supports eventually consistent reads only and rejects ConsistentRead. The projection type (B) determines which attributes are copied into the index and cannot change its consistency model. Capacity mode (C) affects how throughput is billed and provisioned, not read consistency. An index that shares the table's partition key with a different sort key (D) is a local secondary index, which is a different construct and the one that does offer strong consistency.

Answer: B
TTL reads a Number attribute containing Unix epoch time at seconds granularity; items whose TTL attribute is not a Number are simply ignored by the TTL process. An ISO 8601 string (A) is never parsed. Milliseconds (C) would place the timestamp thousands of years in the future and the item would never expire. TTL stores an absolute expiration timestamp, not a relative duration added to the write time, which rules out option D. Deletion is asynchronous, typically within a few days of expiry, so reads should filter expired items.

Answer: C
TransactWriteItems groups up to 100 action requests against up to 100 distinct items in one or more tables within the same account and Region, with an aggregate item size ceiling of 4 MB. The 25-item and 16 MB figures in options B and A belong to BatchWriteItem, which is not atomic. Transactions give ACID guarantees only inside the Region where the write API was called, so cross-Region grouping (D) is not supported. Capacity mode is irrelevant, though every item costs two underlying writes: one to prepare and one to commit.

Answer: D
DAX serves eventually consistent GetItem, BatchGetItem, Query, and Scan from its caches, but a request that specifies strongly consistent reads is passed straight through to DynamoDB and the result is not cached, which is exactly the behaviour described. The query cache (A) holds Query and Scan result sets, not GetItem results, which live in the item cache. Read replicas (B) are kept in sync with the primary and do serve cached items. Projections (C) are a secondary index concept and have nothing to do with DAX caching.

Answer: A
One read capacity unit covers one strongly consistent read per second of an item up to 4 KB, or two eventually consistent reads of that size. A 3 KB item rounds up to a single 4 KB unit, and 100 eventually consistent reads per second therefore need 50 units. Option D prices the reads as strongly consistent. Option B assumes fractional billing, but DynamoDB always rounds up to the next 4 KB boundary for reads. Option C inverts the relationship: eventually consistent reads are the cheaper of the two, and transactional reads are the ones costing double.

Answer: B
BatchWriteItem trades features for throughput: it cannot specify conditions on individual put and delete requests and cannot update items, so an attribute_not_exists guard requires PutItem or TransactWriteItems. UnprocessedItems (A) carries requests that failed for throughput reasons and is retried with exponential backoff; it is not a condition failure channel. There is no batch-wide condition (C), and restricting the batch to one table (D) changes nothing about which expressions are accepted.

Answer: C
DynamoDB returns at most 1 MB of data per Query or Scan page and supplies LastEvaluatedKey so the caller can resume, with any FilterExpression applied after that 1 MB is read. Option D invents an item-count cap; Limit narrows a page but does not extend it. The 16 MB in option A is the BatchGetItem aggregate size, and 400 KB in option B is the maximum size of one item, neither of which governs pagination.

Answer: D
S3 Event Notifications support SNS topics, SQS standard queues, Lambda functions, and EventBridge, but explicitly not SQS FIFO queues; AWS documents EventBridge as the route to a FIFO queue. Option C therefore fails on its second notification. Option A fails for the same reason one step removed, since S3 cannot publish to a FIFO destination directly. A redrive policy (B) moves messages that exceed maxReceiveCount to a dead-letter queue and cannot invoke a function.

Answer: A
Amazon S3 supports at least 3,500 PUT, COPY, POST, or DELETE and 5,500 GET or HEAD requests per second per partitioned prefix, with no limit on the number of prefixes, so parallelizing across prefixes is the documented way to scale. There is no adjustable per-bucket request quota to raise (B). Transfer Acceleration (C) speeds long-distance transfers through edge locations but does not change per-prefix request rates. Multipart parts (D) are separate requests and consume the same budget rather than a fraction of it.

Answer: B
API keys with usage plans, per-client rate limiting, and request validation are all REST API features that HTTP APIs do not offer, which eliminates options A and C. Option D describes the right API type but the wrong mechanism, since usage plans meter and throttle by API key while AWS WAF inspects requests for security rules rather than enforcing per-customer quotas. HTTP APIs remain the cheaper choice when none of those REST-only features are needed.

Answer: C
The integration timeout is a custom value between 50 and 29,000 milliseconds, defaulting to 29,000, and AWS permits raising it beyond 29 seconds for Regional or private APIs only, so an edge-optimized API would still cut off at 29 seconds. Option B is the older blanket statement and is now too strong. Option D misstates both the default and the ceiling. Response streaming (A) changes how a response body is transferred and does not extend the integration timeout.

Answer: D
Stage variables act as configuration placeholders that can be substituted into the integration URI, so a single deployed API definition can invoke a different Lambda alias per stage. Mapping templates (A) transform request and response payloads and headers; they do not select the integration endpoint. Usage plans (B) associate API keys with throttling and quota settings rather than routing. Canary releases (C) split traffic between two versions of the same stage for rollout, not between environments.

Answer: A
An alias can point at a maximum of two versions, both of which must be published, must share an execution role, and must have the same dead-letter queue configuration or none. Provisioned concurrency (B) is optional; it only reduces cold starts and can even help avoid spillover during a shift. The alias cannot point to $LATEST at all, so option C is invalid regardless of weighting. CodeDeploy (D) automates weight changes on top of this feature but is not a precondition for configuring one.

Answer: B
EventBridge allows a maximum of five targets per rule and that quota is not adjustable, so the standard approach is to add another rule carrying the same event pattern. Option C fails because the quota cannot be raised. The limit applies per rule, not per event bus or per account, so options D and A misstate its scope; the default is 300 rules per event bus, leaving plenty of room for the extra rule.

Answer: C
Lazy loading writes to the cache only on a miss, so a replacement node keeps working with higher latency while it refills, but data can go stale because the cache is not updated when the database changes; adding a TTL bounds that staleness. Option B assigns lazy loading's weakness to the wrong strategy. Write-through is the one that leaves a new node with missing data (D) and it adds a write penalty of two trips rather than removing the miss penalty (A).

Answer: A
Fetching the password from Secrets Manager (or a SecureString parameter) with the execution role gives centralized rotation, access logging and revocation, and caching the value outside the handler, or using the Parameters and Secrets Lambda extension with its 300-second default TTL, avoids a lookup on every invocation. Option B exposes the value to anyone with lambda:GetFunctionConfiguration, in the console and in deployment templates; encryption at rest does not hide it from those readers, and it cannot be rotated without redeploying. Option C bakes the secret into an artifact that is copied into every build, repository and version; encryption of code storage does nothing for the developers and pipelines that handle the package. Option D hands the secret to every caller and puts it in a payload that can appear in logs, traces and dead-letter queues; the caller should never possess it at all.

Answer: D
A presigned URL (or presigned POST) is generated with the application's credentials for one HTTP method, one object key and an expiration (up to 7 days with IAM user credentials, no longer than the session for role credentials); the browser uploads directly to S3 while the server decides who gets a URL and for what. Option A is self-contradicting: Block Public Access rejects a bucket policy that grants access to the anonymous principal, and if it were disabled anyone on the internet could write anything to the prefix. Option B hands every visitor the same guest role with write access to the entire bucket, so the application no longer controls who may upload or where. Option C puts long-term credentials in client-side code where every user can read them; rotation shortens the exposure but does not make the design acceptable.

Answer: B
API Gateway enforces rate and burst limits with a token bucket at the account, stage, method and, through usage plans with API keys, per-client level, returning 429 Too Many Requests before the integration runs; an abusive client therefore consumes no Lambda or database capacity. Option D pays the full backend cost before saying no, so the limit protects nothing, and it adds a DynamoDB write to every request. Option C sizes the database connection pool for the proxy as a whole; it has no notion of an API client and rejects connections, not requests. Option A depends on the client's goodwill; a client that ignores the setting, or is malicious, is not limited at all, and retries are not the same thing as request rate.

Answer: B
SSE-S3 has AWS manage the encryption keys entirely, encrypting objects automatically at rest with no extra per-request key management from the developer, matching the 'least operational overhead' requirement. Client-side encryption (A) requires the application itself to manage encryption and keys, adding developer overhead. SSE-C (C) requires the caller to supply and manage the encryption key on every request, which is more operational burden, not less. Relying only on bucket policies (D) controls access but does not encrypt data at rest, and does not meet the stated encryption requirement.

Answer: C
Following least privilege, a custom IAM policy attached to the function's execution role that scopes exactly the needed S3 and DynamoDB actions/resources is the secure, correct pattern for Lambda permissions. AdministratorAccess (B) grants far more permission than needed, violating least privilege and increasing blast radius if compromised. Embedding long-term IAM user credentials in environment variables (D) is an anti-pattern; Lambda execution roles already provide temporary, automatically rotated credentials, so static keys are unnecessary and risky. Granting full access to all S3 buckets and DynamoDB tables (A) is also overly broad and violates least privilege.

Answer: D
An identity pool is a directory of federated identities that exchanges a Google or Facebook token (or a user pool token) for temporary AWS credentials through AssumeRoleWithWebIdentity, with an authenticated IAM role that scopes what the app may do against S3 and DynamoDB; no long-term keys ever reach the device. Option A issues OIDC JSON Web Tokens for authentication; S3 and DynamoDB require SigV4-signed requests with IAM credentials, which a user pool by itself does not vend. Option B is the workforce single sign-on service for employees using the console and CLI; it does not federate consumer identities from social providers for a mobile app. Option C embeds long-term IAM user keys in the app, which is exactly what the requirement forbids and which anyone who unpacks the binary can extract.

Answer: D
An IAM role attached through the instance profile makes the instance metadata service supply temporary credentials that are rotated automatically before they expire, and the SDK credential provider chain picks them up with no keys on disk, which satisfies the security team's requirement. Option A still places a long-term access key pair on the instance; encrypting the file changes where the key is exposed, not the fact that it is stored there. Option C still stores long-term keys on every instance and multiplies the credentials to manage; rotation shortens the exposure window but does not remove the stored key. Option B needs the IAM user's long-term access keys on the instance to sign the GetSessionToken call in the first place, so the requirement is violated before the session token exists.

Answer: C
Secrets Manager offers managed rotation for Amazon RDS, Aurora, DocumentDB and Redshift credentials with no rotation code, Lambda-based rotation for anything else, versions with AWSCURRENT and AWSPREVIOUS staging labels, and a GetSecretValue API the function calls with its execution role (optionally cached through the Parameters and Secrets Lambda extension). Option A stores SecureString values encrypted with KMS (4 KB standard, 8 KB advanced) but has no built-in rotation; you would have to write and schedule the rotation yourself. Option B manages encryption keys and performs cryptographic operations; it does not store or rotate application passwords. Option D provides dedicated hardware security modules for key material; it is not a secrets store and has no rotation workflow for database credentials.

Answer: A
KMS is unusual among AWS services: a key policy does not automatically trust the account, so an IAM policy can grant kms:Decrypt only if the key policy allows it (the default 'Enable IAM User Permissions' statement) or names the role directly. The execution role therefore needs kms:Decrypt on the key, and the key policy must permit that role to use the key. Option B gets the model backwards; without a key policy statement that enables IAM policies or names the role, IAM allow statements for the key are ineffective even inside the same account. Option C confuses two resource policies; the function's resource-based policy controls who may invoke the function, while access to the key is decided by the key policy together with the caller's IAM policy. Option D is wrong about the managed policy, which grants only the CloudWatch Logs permissions (CreateLogGroup, CreateLogStream, PutLogEvents) and nothing in KMS.

Answer: D
IAM authorization on an API Gateway method requires callers to sign requests with SigV4 using valid IAM credentials, letting API Gateway verify the caller's identity and permissions without separate API keys. API keys with usage plans (A) are meant primarily for throttling/quota tracking of API consumers and are not tied to IAM credential based SigV4 signing. Relying only on security groups (B) does not apply to API Gateway's HTTP-level access (API Gateway does not sit behind customer-managed security groups the way EC2 does for regional REST APIs invoked over the internet), and provides no request-level identity authorization. An S3 bucket resource policy (C) governs access to S3 objects, not to API Gateway API methods.

Answer: B
API Gateway caches per stage and forms the cache key from the method and path plus the query strings, headers or path parameters you explicitly mark as cache key parameters. If a parameter that changes the response, most dangerously a user identifier or Authorization header, is not part of the key, one caller's cached response is served to another; this defect appears only under concurrent use by different callers. Option A mixes up two limits: 1,048,576 bytes is the largest response API Gateway will cache, and keys are not truncated; a request whose response is too large is simply not cached. Option C is not the correctness issue; entries can also be invalidated per request with Cache-Control: max-age=0 by an authorized caller, and a short TTL merely shortens how long a cross-caller leak lasts. Option D invents a behavior; 0.5 GB is simply the smallest cache size available, and capacity affects hit rate and throughput, not how keys are formed.

Answer: C
Federation through Cognito (a user pool for authentication, an identity pool to exchange the token for STS credentials) gives each user short-lived credentials from a role whose policy can be scoped with the user's identity, so users reach only their own resources and nothing durable has to be issued or revoked per person. Option A creates a durable IAM principal per person, which does not scale, hands long-term keys to devices and leaves every credential to be rotated and revoked individually. Option B cannot distinguish one user from another, so nothing prevents an authenticated user from reading another user's data, and one leaked key exposes everyone. Option D exposes the server's own permissions to every client and, because the metadata credentials belong to the host, gives users far more than their own resources.

Answer: A
Least privilege is expressed in both dimensions of a statement: the Action list (s3:GetObject, and s3:ListBucket with a prefix condition if listing is needed) and the Resource ARN arn:aws:s3:::bucket/prefix/*; a wildcard over the bucket or over all actions grants far more than the function needs. Option B grants read access to every bucket in the account, and a permissions boundary is a separate guardrail that has to be designed and attached; convenience grants are rarely narrowed later. Option C allows every S3 action, including delete and write, on the one prefix and relies on a growing deny list that must be maintained as prefixes are added; it is the opposite of a minimal allow. Option D is false: a function has exactly the permissions of its execution role and inherits nothing from the account; with no policy it cannot read the bucket at all.

Answer: A
The standard tier allows a 4 KB maximum value and 10,000 parameters per account and Region, while the advanced tier allows 8 KB, 100,000 parameters, and parameter policies, at a cost. Higher throughput (B) is a separate setting that raises transactions per second and changes no size limit. SecureString (C) describes encryption with KMS, not capacity. Option D inflates both numbers; 8 KB is the advanced ceiling, and a parameter cannot be downgraded from advanced back to standard.

Answer: B
A SecureString value is encrypted with a KMS key, so retrieving it with decryption needs kms:Decrypt on that key in addition to the Systems Manager read permission. DescribeParameters (A) lists parameter metadata and is not consulted for a value read. GenerateDataKey (C) is the permission needed to create a data key when writing encrypted data, not to reverse it. GetParametersByPath (D) is a separate API for hierarchy reads and is not implied by a GetParameter call.

Answer: C
Parameter Store's default throughput is 40 transactions per second shared across GetParameter, GetParameters, and GetParametersByPath; AWS recommends caching values for reuse and, for sustained volume, enabling higher throughput, which raises GetParameter to 10,000 TPS at additional cost. Tiers (D) control size and features, not request rate. GetParametersByPath (A) has the lowest ceiling of the three read APIs under higher throughput, at 100 TPS, so calling it more often makes matters worse. DescribeParameters (B) returns metadata, not values.

Answer: D
The alternating users strategy maintains two credentials that swap roles, so one stays valid while the other rotates, which is why AWS recommends it for production availability. The single user strategy (C and A) changes the password of one user and leaves a brief period in which the old password is rejected, and lengthening the schedule reduces how often that happens without removing it. Option B names the right strategy but the wrong detail: alternating users requires a superuser secret to manage the second account.

Answer: A
Rotation runs createSecret, setSecret, testSecret, and finishSecret; the new version is labeled AWSPENDING at creation and only becomes AWSCURRENT when finishSecret moves the label, at which point the old version becomes AWSPREVIOUS. GetSecretValue returns AWSCURRENT by default, so the old value is correct until the swap. Option C reverses the labels, option B asserts a swap that has not happened yet and a cache Secrets Manager does not impose, and option D misdescribes the labeling, since the pending version is labeled from the moment it is created.

Answer: B
GenerateDataKey returns both a Plaintext data key and a CiphertextBlob; the documented pattern is to encrypt locally with the plaintext key, store the encrypted copy alongside the data, erase the plaintext from memory, and call Decrypt to recover the key later. Option C stores the wrong half and encrypts with the wrong one. The Encrypt API (D) is designed for small values and cannot take a large file. GenerateDataKeyWithoutPlaintext (A) deliberately withholds the usable key, so it must be decrypted before any encryption can happen.