Task 4.1: Assist in a root cause analysis

• Afields @requestId, @duration | filter @type = "REPORT" | sort @duration desc | limit 20

  Correct

  Lambda REPORT lines carry the discovered @duration and @requestId fields. Sorting by duration in descending order and limiting to 20 returns the slowest invocations.

• Bfilter @type = "REPORT" | stats max(@duration) by bin(5m)

  Incorrect

  stats aggregates into one value per 5-minute bin, so individual invocations and their request IDs are lost.

• Cfields @requestId, @duration | filter @type = "REPORT" | sort @duration asc | limit 20

  Incorrect

  Ascending order returns the shortest durations first, so this lists the 20 fastest invocations, not the slowest.

• Dfields @requestId, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20

  Incorrect

  This returns the 20 most recent log events that contain ERROR. Slow invocations do not have to log errors.

Lambda REPORT log lines expose @duration, @billedDuration and @maxMemoryUsed; filter, sort and limit turn them into a top-N list.

• ASend each data point to an SQS queue for another function that calls PutMetricData

  Incorrect

  The function would still make an API call per invocation, to SQS instead of CloudWatch, and a second function would be added to run.

• BWrite the values as embedded metric format log lines to the function's logs

  Correct

  The embedded metric format generates custom metrics asynchronously from structured logs written to CloudWatch Logs; CloudWatch extracts the metrics, and no PutMetricData call is needed.

• CTurn on CloudWatch Lambda Insights for the function

  Incorrect

  Lambda Insights collects system-level metrics such as CPU time, memory and cold starts. It does not create business metrics such as OrdersPlaced.

• DPublish the metrics with PutMetricData as high-resolution metrics

  Incorrect

  High resolution changes the granularity to one second. The function still calls PutMetricData on every invocation.

EMF is the low-overhead way to emit custom metrics from Lambda and containers: log a structured JSON line, and CloudWatch creates the metric.

• ARead the status reason of the stack's final ROLLBACK_COMPLETE event

  Incorrect

  ROLLBACK_COMPLETE only reports that the resources created during the failed creation were removed. It is the end state, not the cause.

• BRead the DELETE_COMPLETE events that the rollback produced

  Incorrect

  Those events record the cleanup after the failure. They show what was removed, not why the creation failed.

• CRun drift detection on the stack and review the drifted resources

  Incorrect

  Drift detection compares existing resources with the stack template. It does not explain why a stack creation failed.

• DRun Detect root cause in the console and read the event it labels

  Correct

  CloudFormation analyzes the failure and labels the event that is likely the root cause; its Status reason, and sometimes a linked CloudTrail event, gives the details.

For a failed stack, the useful event is the failure that started it all; Detect root cause finds it among the cancellations and rollback events.

• AReturn {"statusCode": 200, "body": body}, with body as the order in JSON

  Correct

  A proxy integration expects an object with statusCode and a string body (plus optional headers). Any other output format makes API Gateway return 502 Bad Gateway.

• BTurn on API caching for the method so that responses come from the cache

  Incorrect

  Caching stores endpoint responses for a TTL. A malformed response is still malformed, and the first request still reaches the function.

• CIncrease the function's memory so that it returns its result faster

  Incorrect

  Memory adds CPU to the function. The invocations already succeed; the problem is the shape of what the function returns.

• DReturn the original dictionary serialized into one JSON string instead

  Incorrect

  A plain string is still not the output format a proxy integration expects, so API Gateway keeps returning 502.

With Lambda proxy integrations the function owns the HTTP response: statusCode, headers and a string body, or the client sees 502.

• ARaise the function's memory to 10,240 MB, the largest available setting

  Incorrect

  More memory speeds up computation, but the function is waiting on the partner API, so it still stops at the timeout.

• BSet reserved concurrency on the function

  Incorrect

  Concurrency settings do not change how long one invocation may run.

• CTurn on AWS X-Ray active tracing

  Incorrect

  Tracing shows where time is spent but does not stop the timeout.

• DRaise the function's timeout above the API's response time

  Correct

  The default timeout is 3 seconds. Raising it above the partner API's response time lets the call finish.

New functions start with a 3-second timeout; set it to match the slowest expected calls.

• AThe container's health check command is wrong

  Incorrect

  Health checks run after the container starts; this task never pulled its image.

• BThe task definition requests too little memory for the container image

  Incorrect

  Memory limits affect running containers, not the network path to the registry.

• CThe subnets have no network route to Amazon ECR

  Correct

  A timeout means there is no route; tasks in private subnets need a NAT gateway or VPC endpoints to reach the registry.

• DThe service's desired count is set too high

  Incorrect

  The number of tasks does not cause an image pull to time out.

CannotPullContainer timeouts point to networking; permission errors point to the task execution role.

• AThe source repository credentials that the project uses to download code

  Incorrect

  The source was already downloaded and built; the failure is when writing artifacts.

• BThe service role's S3 permissions for the new bucket

  Correct

  CodeBuild uses its service role to call other services, including s3:PutObject for the artifact bucket.

• CThe compute type of the build environment

  Incorrect

  Compute size does not affect permissions to write to S3.

• DThe buildspec's install phase runtime versions

  Incorrect

  Runtime versions affect the build, which already succeeded.

AccessDenied in CodeBuild usually points to the service role; check that it covers renamed resources.

• ADelete the whole stack and recreate it later from the original template file

  Incorrect

  This destroys the other resources in the stack when the stack can be returned to a working state instead.

• BRun another stack update with the previous template

  Incorrect

  A stack in UPDATE_ROLLBACK_FAILED cannot be updated until the rollback is completed.

• CContinue the rollback and skip the resource that cannot roll back

  Correct

  Continuing the rollback, if needed with the failing resources skipped, returns the stack to UPDATE_ROLLBACK_COMPLETE.

• DTurn on termination protection and wait for the stack to recover

  Incorrect

  Termination protection prevents deletion; the stack does not recover on its own.

Fix the cause or skip the failing resources, then continue the rollback so that the stack can be updated again.

• AServer faults, meaning 500 series errors in the downstream service

  Incorrect

  X-Ray records 500 series errors as faults, and faults are at zero here.

• BThrottling, meaning 429 Too Many Requests responses

  Incorrect

  X-Ray marks 429 responses as throttles, a separate category.

• CClient errors, meaning 400 series responses

  Correct

  X-Ray marks client errors, the 400 series, as errors, so the requests sent to the service are the first place to look.

• DNetwork timeouts between the two services

  Incorrect

  Errors in X-Ray refer to the response class, not to timeouts between nodes.

In X-Ray, errors are 4xx, faults are 5xx, and throttles are 429.