Chapter 4

Troubleshooting and Optimization

AWS Certified Developer – Associate (DVA-C03) Study GuideDomain 4 · 22% of the examBased on the official DVA-C03 exam objectives

definitions, Step Functions state machines) and applies them directly through service APIs, skipping

CloudFormation. The trade-off is drift from CloudFormation's recorded state, which is why it is a development-only tool. --method=direct still performs a full CloudFormation deployment, sam deploy does not deploy CDK apps, and bootstrapping is a one-time environment setup.

6. C - Only a manual approval action actually pauses a pipeline execution until a person approves or rejects it

(and it can notify via SNS). The AI summary helps the reviewer but enforces nothing; a test action cannot judge review status, rollback undoes a deployment rather than gating it, and an SNS subscription by itself does not block the stage transition.

7. B - Feature flags are built for exactly this: gradual exposure via a deployment strategy, and alarm-driven automatic rollback (plus the ability to flip the flag off immediately). A freeform profile with AllAtOnce gives no gradual rollout, manual parameter edits have no rollout or rollback machinery, and secret rotation is about credentials, not feature exposure.

8. C - Equal increments at fixed intervals is the definition of a linear deployment, and the Lambda-scoped name matches the target platform. Options A and D describe canary (single step) and the ECS-scoped linear configuration respectively; option B shifts everything immediately.

Domain 4 grew from 18% of the exam in DVA-C02 to 22% in DVA-C03, and that shift tells you something about how AWS sees the developer role: writing the code is only half the job. The other half is proving what the code did in production, finding the hop where a request failed, and tuning the system once you understand it. This chapter builds those skills around the three pillars of AWS observability - CloudWatch for logs and metrics, X-Ray for traces, CloudTrail for the audit record - then works through the failure patterns the exam returns to again and again, and finishes with the optimization levers and the AI-assisted tooling now layered on top.

A note on method: troubleshooting here is mostly correlation - one request leaves a log line, metrics, a trace, and a CloudTrail entry for any API call it made. Read them in order: symptom (metrics), request path (traces), detail (logs), "who changed what" (audit trail).

The Observability Toolkit at a Glance

Hold onto that table's core distinction: why did the application behave this way - logs and traces; who performed this action - CloudTrail. Scenarios profit from confusing the two.

Amazon CloudWatch Logs

Log groups, log streams, and retention

Every Lambda function automatically gets a log group named /aws/lambda/<function-name>, with log streams separated by date and execution environment. Other workloads - containers using the awslogs driver, applications using the CloudWatch agent or an SDK - follow the same model: a log group is the container you apply settings to, a log stream is a sequence of events from one source, and a log event is a single timestamped record (up to 1 MB).

Retention is set on the log group, and the default is never expire - which is why "log group retention" is the cost-control lever in exam questions. Fixed periods run from 1 day to 10 years. Three operational facts matter for troubleshooting:

• Changing retention affects existing data immediately: shortening it deletes older events, so "last month's

logs are gone" is often a retention change, not an outage. And log groups are Region-scoped - "no logs"

frequently means the wrong Region or account.

• Lambda writes through its execution role. A missing logs:CreateLogGroup, logs:CreateLogStream, or

logs:PutLogEvents permission means the function still runs - just silently. Check the execution role when

a function produces no output.

For moving log data elsewhere, subscription filters stream events out of a log group in near real time to a

Lambda function, a Kinesis data stream, or Amazon Data Firehose (for delivery to S3, OpenSearch, and other destinations). A log group can have up to two subscription filters.

Metric filters: turning log events into metrics

A metric filter watches a log group, matches incoming events against a pattern, and publishes a CloudWatch metric on each match - how you alarm on something no AWS service measures for you, such as occurrences of a specific application error code.

Key behaviors to internalize:

• Filters come in two dialects. Term/space-delimited patterns match plain text (the word ERROR, or

positional fields such as a 5xx status code). JSON patterns match properties inside JSON log events, for example { $.errorCode = "AccessDenied" }.

• A filter can extract a numeric value from the event - a latency field, a byte count - and publish that as the

metric value rather than a simple count of 1.

• You can assign a default value published when the pattern does not match, so the metric reports

continuously (zero errors produces a 0 data point instead of a gap).

• Filters apply only to events ingested after the filter is created; they never backfill. If a scenario needs last

week's error counts from a filter created yesterday, the answer is a Logs Insights query over the retained logs.

• The output is an ordinary CloudWatch metric, so dashboards, alarms, and anomaly detection all work on it

unchanged.

CloudWatch Logs Insights queries

Logs Insights is the interactive query engine over log groups - the tool for ad-hoc investigation: aggregating, filtering, parsing fields out of unstructured text, and ranking results. A query runs across up to 50 log groups at a time and returns up to 1,000 rows by default (configurable to 10,000).

The core commands, in the order you will usually write them:

Lambda log groups get discovered fields such as @timestamp, @message, @requestId, and on the REPORT line, @duration, @billedDuration, @memorySize, and @maxMemoryUsed. A canonical troubleshooting query - the slowest recent invocations - looks like this:

fields @timestamp, @requestId, @duration, @maxMemoryUsed, @memorySize
| filter @type = "REPORT"
| sort @duration desc
| limit 20

Two habits separate effective Logs Insights work from flailing: bound the time range and start from an aggregate (stats - for example, error counts with stats count(*) by bin(5m)) before drilling into raw events; and use parse when a needed field is trapped inside a text message, since parsed fields can then be filtered and aggregated like native ones.

The embedded metric format (EMF)

Metric filters extract metrics from logs after the fact. The embedded metric format is the opposite arrangement: your application deliberately writes a structured JSON log line containing both the log data and a metrics directive, and CloudWatch Logs extracts the metric automatically on ingestion. There is no

PutMetricData call in the code path - the log line is the metric publication.

An EMF event carries a _aws metadata block naming the timestamp, the namespace, the dimension sets, and which top-level properties are metrics:

{
"_aws": {
"Timestamp": 1718042400000,
"CloudWatchMetrics": [
{
"Namespace": "CheckoutService",
"Dimensions": [["Service", "Endpoint"]],
"Metrics": [{ "Name": "OrderLatency", "Unit": "Milliseconds" }]
}
]
},
"Service": "checkout",
"Endpoint": "/orders",
"OrderLatency": 187
}

Facts the exam leans on:

• A single EMF event can carry up to 100 metrics, and each dimension set can include up to 30 dimension

keys - making EMF the natural fit for high-cardinality dimensions (per tenant, per endpoint, per feature flag) that would be impractical to publish one API call at a time.

• Properties named in the directive become metrics or dimensions; every other property stays in the log

event as searchable context, so you get the metric and the log line behind it.

• EMF works anywhere you can write to CloudWatch Logs - the AWS Embedded Metrics libraries (and

Powertools for AWS Lambda's Metrics feature) generate the format for you - and because publication rides on log ingestion, there is no separate metrics API to throttle and no added call in a hot code path.

Choosing between the two: metric filters retrofit metrics onto logs you already emit; EMF is a design-time choice for code you own, when you want rich custom metrics with dimensions from day one.

Common trap: An EMF event with a malformed _aws block is stored as an ordinary log event and silently produces no metric - suspect a wrong namespace, or a directive metric name that matches no property in the event.

CloudWatch Metrics and Alarms

Logs tell you what happened; metrics tell you whether it is still happening and how bad it is. Every service here publishes metrics under a namespace - AWS/Lambda, AWS/ApiGateway, AWS/DynamoDB, AWS/SQS - and the troubleshooting vocabulary starts with knowing the key metric names cold:

The most useful diagnostic habit here is comparing the pair that splits a problem at the service boundary. For

API Gateway, Latency is end-to-end client time while IntegrationLatency is only the wait for the backend: if the two track together, the backend is slow; if Latency soars while IntegrationLatency stays flat, the problem sits in API Gateway or the network path. (The Lambda playbook below leans on the same kind of split, between Errors and Throttles.)

An alarm watches one metric (or a metric math expression, or a Logs Insights query result) over an evaluation window and transitions between OK, ALARM, and INSUFFICIENT_DATA. The vocabulary that appears in scenarios:

• Period, statistic, threshold, and datapoints to alarm - for example, average Duration over 5 minutes

exceeding 3,000 ms, breaching in 3 of the last 5 periods (which smooths over single spikes; "1 out of 1"

pages you on noise). Percentile statistics (p90, p99) are usually fairer than averages for latency, because averages hide a suffering minority of requests.

• Treat missing data - what an absent data point means: breaching (gaps are bad - right for

heartbeat-style metrics), notBreaching (gaps are fine), ignore (keep the previous state), or missing (fall back to INSUFFICIENT_DATA). Scenarios about alarms that "never fire even when the service stops reporting" test exactly this setting.

• Composite alarms - combine other alarms with AND/OR logic so a page means "errors high AND latency

high," not two noisy alerts.

• Anomaly detection - CloudWatch models a metric's expected range (accounting for daily/weekly

seasonality) and alarms when it leaves the band; useful when nobody knows a sensible static threshold.

Practically, an alarm is the start of the workflow below: it fixes when the problem began, the timestamp every log query and trace search should anchor to. (Its actions route to SNS, Lambda, Auto Scaling, or Systems

Manager.)

AWS X-Ray: Distributed Tracing

Metrics can tell you the checkout service got slow at 14:03; they cannot tell you the slowness lives in a sub-call three services downstream. That is the job of distributed tracing - AWS X-Ray.

Segments and subsegments

A trace is the end-to-end record of one request as it crosses services. Each service contributes a segment: a

JSON document recording the service name, start and end times, inbound HTTP details, AWS resource details, and three flags that drive most analysis - error (4xx-class), fault (5xx-class), and throttle.

Within a segment, subsegments break the work down further. The SDK automatically creates subsegments for downstream calls it instruments - HTTP requests, AWS SDK calls to DynamoDB, SQS, and so on - and you can open custom subsegments around your own code blocks to time a pricing calculation or a call to a legacy system. When the exam shows a slow request and asks where the time went, picture the trace timeline: a segment with nested subsegments, each carrying its own duration.

Supporting facts worth knowing:

• API Gateway supports active tracing (it samples and starts traces itself) and passive tracing (it only

participates when an upstream service already started a trace).

• Lambda does not run the X-Ray daemon - the Lambda service hosts the listener. The execution role needs

X-Ray write permissions, and tracing is enabled per function.

• On EC2, ECS, and similar compute, the X-Ray daemon (UDP port 2000) or the AWS Distro for OpenTelemetry

(ADOT) collector receives segment data from your application and forwards it to X-Ray; ADOT is the modern path.

• A missing local segment raises a context-missing error; setting AWS_XRAY_CONTEXT_MISSING to

LOG_ERROR converts that crash into a log line - the classic fix when the SDK throws exceptions in a service

receiving untraced requests.

Sampling rules

Tracing everything is expensive and mostly unnecessary, so X-Ray samples: it records a subset of requests chosen by rules. Every rule combines a reservoir - a guaranteed number of requests per second that are always traced - with a fixed rate applied to the remainder. The default rule is a reservoir of 1 request per second plus

5% of additional requests, which guarantees at least one trace per second from any active service while keeping volume low.

Custom rules target a subset of traffic by attributes such as service name, service type, host, HTTP method, and

URL path, and are evaluated in priority order (lower number wins, 1 to 9,999, default rule last). Two behaviors matter operationally:

• Rules are managed centrally in X-Ray and picked up by SDKs without redeploying code - raising the rate

on a failing endpoint mid-incident is a console change, not a release.

• Sampling is parent-based: the decision is made once, by the first instrumented service to see the request,

and downstream services honor it. A 100% rule on an internal service never fires for requests whose upstream service already declined to sample. Put investigative rules on the root service - or on genuine new trace roots such as asynchronous workers.

Annotations versus metadata

Both attach key-value data to segments and subsegments, and the exam tests the difference relentlessly:

Trace search uses filter expressions over indexed fields and annotations - all faulted traces for one service, or

annotation.orderId = "A123" for every trace touching one order. The rule: "search traces by X" means X is an

annotation; "store the full payload for later inspection" means metadata.

The service map and trace analysis

The service map renders every traced service as a node and every observed call path as an edge, annotated with latency and error/throttle rates - in incident terms, "which node turned red." The workflow: start at the map, find the faulting node, open its traces filtered to faults, and read the segment timeline down to the failing subsegment, which typically names the exact downstream call and error. Groups save a filter expression as a named lens over traces; X-Ray Insights raises events with a root-cause summary when trace behavior deviates from baseline. Traces are retained for 30 days; older comparisons belong in logs and metrics.

Common trap: X-Ray shows sampled requests only. A clean service map does not prove an error is absent - at a

5% rate, a one-in-a-thousand failure may never have been sampled. Raise the rate (or check Logs Insights, which sees everything) before concluding the problem is elsewhere.

AWS CloudTrail: Auditing API Activity

CloudTrail records the API calls made in your account - by users, roles, and AWS services - with caller identity, source IP, timestamp, request parameters, and any error code returned. It is the tool that converts "the table is gone" or "this started right after a deploy" into a specific principal and a specific call.

Events come in three kinds:

• Management events - control-plane operations such as CreateFunction, CreateTable,

UpdateFunctionConfiguration, and PutBucketPolicy. These are recorded by default and are the first

place to look for configuration changes.

• Data events - object- and item-level operations such as S3 GetObject/PutObject, Lambda Invoke, and

DynamoDB item activity. These are not recorded by default; you opt in per resource because the volume

(and cost) is high. This is the most tested CloudTrail fact in developer scenarios: "which process read this S3 object" requires data events to have been enabled in advance - they cannot be reconstructed afterwards.

• Insights events - when enabled, CloudTrail analyzes management events for unusual API call volume or

error rates and records an insight: an early warning for runaway automation or a bad deployment.

Access paths matter too. The event history (console, or LookupEvents) covers the last 90 days of management events with no setup. A trail delivers events to S3 for durable retention, can be organization-wide and all-Regions, and can stream to CloudWatch Logs for alarming on specific calls (alert whenever DeleteTable occurs, say); log file validation adds digest files proving delivered logs were not altered. CloudTrail Lake is the managed alternative: an event data store with configurable retention (up to 10 years), queried with SQL.

In practice, developers use it three ways: blast-radius checks (filter event history by the deploy window to see every configuration change, in order, with its identity); explaining an AccessDenied (the denied call appears with the exact error code, principal, and resource - far faster than guessing at policies); and correlation (take a timestamp from a log entry, then find that role's API calls in the same minute).

Common trap: CloudTrail records API calls, not application behavior. A function that miscalculates a price leaves no CloudTrail trace of the miscalculation - only of the Invoke and the API calls it made. The calculation itself is in CloudWatch Logs.

Root-Cause Analysis Playbooks

The sections above are instruments; this section is the flying - the five failure patterns that dominate real incidents and Domain 4 scenarios alike. Each follows the same discipline: read the symptom precisely, check the cheapest discriminating metric first, confirm in logs or traces, then change something.

Playbook: Lambda timeouts and throttling

Lambda produces two similar complaints - "requests are failing" - with opposite fixes, so separating them is step one. A timeout means the invocation started and ran past the configured timeout (maximum 15 minutes); a throttle means Lambda refused to start it at all because a concurrency limit was reached, returning a 429 with a TooManyRequestsException ("Rate Exceeded").

Symptom Likely cause Fix

Playbook: DynamoDB hot partitions and throttling

DynamoDB spreads a table's provisioned capacity across its partitions, and each partition has hard physical ceilings: roughly 3,000 read capacity units and 1,000 write capacity units per second per partition.

Throughput trouble therefore comes in two flavors that look identical at the API -

ProvisionedThroughputExceededException - but differ completely in distribution:

• Table-level throttling: total demand exceeds the table's (or index's) provisioned capacity, or bursts outrun

the roughly 5 minutes of unused capacity DynamoDB retains for bursting. Consumed capacity sits at or above provisioned levels across the board.

• Hot partition throttling: the table has spare capacity, but traffic concentrates on one partition key value -

a celebrity user, a single "today" partition. One partition hits its ceiling while the rest idle. This is a key design problem, not a capacity problem, and raising table capacity does nothing for it.

Discrimination and fixes:

The diagnostic tool built for this is CloudWatch Contributor Insights for DynamoDB, which reports the most accessed and most throttled partition keys. "Throttling with low overall utilization" plus "one key dominating in

Contributor Insights" is the complete hot-partition signature; the answer is a key-design change (distribution, sharding), never merely "increase provisioned capacity."

Common trap: Adaptive capacity - DynamoDB's automatic rebalancing toward busy partitions - helps with moderate imbalance, but it is neither instant nor unlimited and does not repeal the per-partition ceilings. A single key value receiving thousands of writes per second still throttles; answers relying on adaptive capacity alone for an extreme hot key are wrong.

Playbook: API Gateway errors - 403 vs 429 vs 5xx

API Gateway failures are classified by who is rejecting the request, and the status code tells you which layer that is.

Reading the code correctly is most of the battle:

The workflow that resolves most scenarios:

1. Separate the classes with metrics: graph 4XXError and 5XXError against Count. A wall of 403s starting exactly at a deploy points at policy or authorizer changes; 429s tracking total traffic points at throttling;

5xx on one method points at that method's integration.

2. Enable (or read) execution logging for the stage and access logs carrying $context variables such as

$context.authorizer.error and $context.integrationErrorMessage. The authorizer error variable

alone resolves most 401/403 mysteries.

3. Correlate the API Gateway request ID with the backend logs (the integration playbook below generalizes this) to join "API Gateway returned 502" to the exact function exception.

Common trap: A Lambda error behind a proxy integration surfaces as 502, not 500 - from API Gateway's perspective the integration failed to produce a valid response. The crash is real, but the code it produces is

502. Conversely, a function that catches its errors and returns a well-formed 500 response object passes that

500 through untouched.

aws:SourceVpce condition still names the old endpoint ID, so the recreated endpoint no longer matches.

Playbook: SQS poison messages and DLQ redrive

A poison message can never be processed successfully - malformed payload, reference to a deleted record, a payload that deterministically crashes the consumer. Unprotected, the consumer receives it, fails, the visibility timeout expires, and it receives it again: an infinite loop that burns compute and blocks progress behind it (in

FIFO, every later message in the same message group; in a Lambda batch, the whole batch retries).

The standard defense is a redrive policy on the source queue: after maxReceiveCount failed receives, SQS moves the message to a dead-letter queue (DLQ) instead of offering it again. Operational essentials:

• Set the visibility timeout with the consumer in mind. For Lambda event source mappings, AWS

recommends at least six times the function's timeout, so a message in active processing is never redelivered mid-flight; too-short timeouts create the duplicate-processing version of this incident.

• For Lambda consumers, enable partial batch responses (ReportBatchItemFailures in the event source

mapping's function response types). Without it, one bad message fails the entire batch and every healthy message retries too; with it, only failed IDs return.

• Alarm on the DLQ itself (ApproximateNumberOfMessagesVisible greater than zero;

ApproximateAgeOfOldestMessage on the source queue) so a poison-message stall pages someone

instead of sitting silent.

• Diagnose before redriving: read the message in the DLQ, reproduce the failure, fix the code or the data.

Redrive then moves messages back to the source queue (or a chosen destination) via the console's Start

DLQ redrive or the StartMessageMoveTask API; redriving before fixing just re-poisons the queue. (If a redrive is refused, check the DLQ's redrive allow policy, which controls which source queues may redrive into it.) Set maxReceiveCount modestly - commonly 3-5.

Playbook: integration failures - finding the failing hop

The generic multi-service incident - "the order flow is broken somewhere" - yields to a fixed sequence rather than intuition:

1. Bound the blast radius with metrics. Which services show elevated error metrics, and since when? The earliest timestamp usually names patient zero; the IntegrationLatency vs Latency split and per-function Errors narrow the field.

2. Walk the path with the service map. Faults cluster on the failing node's inbound edges; latency bulges on the slow node's outbound edges. Open traces filtered to faults there.

3. Read the failing segment's timeline, then join to logs. The subsegment tree shows the exact downstream call - the DynamoDB Query, the HTTP call, the SQS SendMessage - with its error and cause;

the segment's request ID and trace ID then locate the full stack trace and offending input in that service's

CloudWatch logs.

4. Interrogate the change record. Check CloudTrail history and recent deployments for the window. Many

"mystery" failures are a rotated secret, a tightened security group, a new IAM policy version, or an environment variable changed by the last deploy.

5. Reproduce and verify. Re-run the failing request shape with a test invocation or a CloudWatch Synthetics canary, and confirm the trace goes green end to end - not merely that the first hop responds.

Keep a checklist of mundane causes, because they account for most real cases: expired or rotated secrets;

security group or NACL changes; an endpoint or environment variable pointing at the wrong Region or the pre-migration resource; TLS issues; and a downstream service hitting its own limits - DynamoDB throttling and

Lambda concurrency both masquerade as "the integration is down."

Optimization

Optimization questions here are never "make it faster" in the abstract; they present a measured symptom - a cost line, a latency percentile, a throttle count - and four levers, three of which address a different symptom.

Anchor every choice to a metric from the troubleshooting half of this chapter.

Lambda memory and the Power Tuning approach

Lambda's memory setting is secretly three settings in one: it allocates memory, CPU, and network bandwidth in proportion, from 128 MB to 10,240 MB. At about 1,769 MB a function gets the equivalent of one full vCPU;

multi-threaded or CPU-bound code keeps gaining beyond that, single-threaded code mostly does not. Billing is per GB-second, so memory and cost are not monotonic: doubling memory doubles the per-second price but can cut duration by more than half on CPU-bound work, making the function both faster and cheaper. I/O-bound functions gain almost nothing - duration barely moves while the price rises.

Because the sweet spot depends on the workload, guessing is a losing strategy, and the canonical tool is AWS

Lambda Power Tuning, an open-source project (maintained by Alex Casalboni and referenced in AWS's own

Lambda documentation) that you deploy from the AWS Serverless Application Repository. It is a Step Functions state machine that works like this:

1. You give it a function ARN, the power values to test (for example 128, 256, 512, 1,024, 1,536, 3,008 MB), a representative payload, and the invocations to run per configuration.

2. It creates temporary versions of the function at each memory size, invokes each the requested number of times, and collects actual billed durations from the logs.

3. Its analyzer applies a strategy - cost (lowest average cost per invocation), speed (lowest average duration), or balanced (a weighted compromise) - and returns the optimal value plus a visualization plotting cost and duration against memory. It can optionally apply the winner to an alias automatically.

The approach generalizes: measure with production-shaped payloads and re-tune when the workload changes character.

Concurrency and provisioned concurrency

Lambda concurrency has three flavors, and exam questions hinge on which problem each solves:

• Unreserved (account) concurrency - the shared pool (default 1,000 per Region, raisable via Service

Quotas). Exhaust it, and every function in the Region can throttle.

• Reserved concurrency - a slice of the pool guaranteed to one function, doubling as its cap. Its purpose is

protective: stopping a runaway function from starving the others, and capping downstream load (how hard a function can hit a database, say).

• Provisioned concurrency - environments initialized in advance and kept warm, assigned to a version or

alias. Invocations within the provisioned count skip initialization entirely - the direct cure for cold-start latency. Requests beyond it spill over to on-demand environments, and provisioned capacity can auto-scale via Application Auto Scaling.

Choose by symptom: throttling under load -> raise limits or reserve deliberately; cold-start latency -> provisioned concurrency or SnapStart; one function endangering the rest -> reserved concurrency as a fence.

DynamoDB capacity modes and DAX

DynamoDB offers two capacity postures. Provisioned capacity with auto scaling suits steady, predictable traffic and is cheaper at sustained volume. On-demand suits spiky, unpredictable, or new workloads: you pay per request, and capacity adapts instantly up to roughly double your previous peak (beyond that, ramping can briefly throttle - see the hot-partition playbook). The exam frames the choice as an operations-versus-cost trade;

both modes share the same per-partition ceilings.

For read performance, Amazon DynamoDB Accelerator (DAX) is a managed in-memory cache that sits in front of a table inside your VPC and answers reads in microseconds instead of milliseconds. Its exam-relevant properties:

• DAX maintains an item cache (results of GetItem / BatchGetItem) and a query cache (results of Query /

Scan), each with a TTL defaulting to 5 minutes.

• It is a write-through cache: writes go to DynamoDB and update the cache; read misses are fetched and

cached. Items that do not exist are negatively cached, so repeated lookups of absent keys also stop hitting the table.

• DAX serves eventually consistent reads from the cache; strongly consistent reads pass through to

DynamoDB itself.

• It requires the DAX client rather than the standard SDK DynamoDB client, and it runs as a cluster in your

VPC - real operational surface area.

• It fixes read hot spots (a few items read relentlessly). It does nothing for write hot partitions, and it is the

wrong answer for write-dominated workloads or when every read must be strongly consistent. When a stem demands microsecond DynamoDB reads with minimal code change, DAX is the intended answer.

API Gateway caching

REST APIs can cache responses at the stage level, absorbing repeated reads before they reach your backend:

enable caching per stage, choose a cluster size, and set a time-to-live (default 300 seconds, maximum 3,600 seconds). Behavior details that show up in scenarios:

• Caching is overridden per method - enable it for safe, slowly changing GETs, disable it elsewhere. Cached

responses are capped at 1 MB, and the cache can be encrypted.

• The cache key is built from the request parameters you designate (selected query string parameters,

headers, path parameters). Two requests differing in an undesignated parameter return the same cached response - the classic source of "users see each other's data" bugs, fixed by including the discriminating parameter in the cache key or not caching that method at all.

• Clients can force a refresh of one entry with Cache-Control: max-age=0, but only when you authorize

that behavior; otherwise invalidation is an operator action (flush the stage cache), with a repopulation cost.

• HTTP APIs do not offer this built-in caching - the standard pattern there is CloudFront in front of the API.

Caching fits when identical repeated reads crush the backend and the data tolerates seconds of staleness - not for personalized, rapidly changing, or write-path problems. Any scenario mentioning data leaking between users is testing the cache-key bullet above.

RDS Proxy

Lambda and relational databases have a structural mismatch: every execution environment opens its own connections, setup is slow, and a concurrency burst becomes a connection storm that can exhaust the database.

Amazon RDS Proxy sits between application and database as a managed connection pool:

• It multiplexes many application connections onto a smaller pool of database connections, so a thousand

concurrent functions no longer means a thousand database connections.

• Failovers complete faster because the proxy keeps its position in the network path and re-points

connections - AWS quotes failover times reduced by up to roughly two-thirds versus direct reconnects.

• Authentication can use IAM authentication plus credentials in AWS Secrets Manager, removing

hard-coded database passwords from function configuration - the property that makes Proxy the answer in combined security-plus-performance scenarios.

• Caveat: certain session state - SET statements, temporary tables, advisory locks, some uses of prepared

statements - pins a client connection to one database connection for its lifetime, quietly defeating multiplexing. A workload that pins everything gains failover benefits but little pooling benefit. (Proxy targets RDS and Aurora; applications switch to the proxy endpoint, but query code is unchanged.)

AI-Assisted Troubleshooting

DVA-C03 threads AI assistance through every domain, and Domain 4's share is operational: using Amazon Q

Developer and CloudWatch's AI features to shorten the distance between symptom and root cause - knowing what they do and where their output must be verified.

Amazon Q Developer in the AWS console and IDE can reason over your actual environment: ask why a function is erroring, or what an error code means for a specific resource, and get an explanation plus candidate fixes grounded in AWS documentation and the resource's configuration. Treat its answers as a strong draft hypothesis - it can be confidently wrong about your configuration, and it acts within your IAM permissions, so least-privilege discipline applies to it as to any other tool.

CloudWatch investigations formalize that assistance around an incident. Starting from an alarm, a metric anomaly, or a log pattern, an investigation sweeps related telemetry - metrics, logs, traces, recent changes - and produces observations (supporting evidence) and root-cause hypotheses in natural language; lightweight, session-based investigations can also be launched from the console's operational troubleshooting views with no setup. In exam terms, it automates the correlation steps of the integration-failure playbook while the human still decides and acts.

Natural-language querying removes the syntax barrier in this chapter's tools. The Logs Insights query generator turns a plain-English request ("show me the 10 slowest Lambda invocations in the last day") into a correct query, explains it line by line, and refines it iteratively; the same capability generates Metrics Insights queries, and Logs Insights can produce a natural-language summary of query results. These features accelerate the authoring of queries, not the evidence itself - a generated query deserves the same read-before-you-run scrutiny as any generated code.

A closing note the exam's scenario writers share: AI assistance optimizes the hypothesis step, not the verification step. Every fix above still ends with a metric, a trace, or a log line proving the system now behaves.

End-of-Chapter Test