Troubleshooting and Optimization practice questions

Answer: A) The URL leaves out the stage name, so the request doesn't match any deployed resource and method

In REST APIs, API Gateway returns 403 "Missing Authentication Token" both for missing credentials and when a request doesn't match a deployed resource and method. A common cause is a URL that leaves out the stage name.

• ACorrect. API Gateway returns the MISSING_AUTHENTICATION_TOKEN gateway response (default status 403) when a client calls an unsupported resource or method. Without /prod in the path, the request doesn't route to the deployed GET /orders method, even though the method needs no authentication.
• BIncorrect. A REST API requires an API key only on methods where API key required is enabled, and this method doesn't have it enabled. A missing or invalid key on such a method would also be reported as an API key error, not as this routing response.
• CIncorrect. The request never matched a method, so API Gateway never reached the integration. A missing invoke permission would show up as an integration or server-side error once the method was actually reached.
• DIncorrect. SigV4 signing is needed only for methods that use IAM (AWS_IAM) authorization. This method's authorization is NONE, so leaving the request unsigned isn't the cause here.

Answer: A) Amazon CloudWatch Synthetics canaries that run scripted checks against the API on a schedule

CloudWatch Synthetics canaries run scheduled scripts that imitate customer actions against endpoints, so they find availability and latency problems even when there is no real traffic. RUM, X-Ray, and log metric filters only observe traffic that real users have already generated.

• ACorrect. Canaries are configurable scripts that run on a schedule, as often as once per minute. They follow the same routes and perform the same actions as a customer, check the availability and latency of endpoints, and publish CloudWatch metrics that alarms can watch. Because they generate their own traffic, they work even when there is no customer traffic.
• BIncorrect. CloudWatch RUM collects client-side data from actual user sessions. It needs real users to produce data, so it can't detect problems during quiet periods or before customers run into them.
• CIncorrect. X-Ray traces requests that the application actually receives, which helps diagnose latency and errors. It does not generate scheduled, scripted requests, so with no traffic there is nothing to trace.
• DIncorrect. Metric filters turn log entries that already exist into metrics. They only react to errors that real requests have produced, so they can't proactively test the endpoint when there is no traffic.

Answer: A) The function URL uses the AWS_IAM auth type, and the client's requests are not signed with SigV4 using credentials that are allowed to invoke the URL.

A 403 from a function URL is an authorization failure. With AuthType AWS_IAM, unsigned or improperly signed requests are rejected. Even with AuthType NONE, a resource-based policy that doesn't grant lambda:InvokeFunctionUrl and lambda:InvokeFunction also returns 403.

• ACorrect. With AuthType AWS_IAM, every request must be signed with AWS Signature Version 4, and the caller needs lambda:InvokeFunctionUrl and lambda:InvokeFunction permissions. Lambda processes the request only if the signatures match, so unsigned requests are rejected before the function code runs.
• BIncorrect. The execution role controls what the function can do when it runs. Permission to invoke a function URL is checked against the caller, through the caller's identity-based policy and/or the function's resource-based policy, not the execution role.
• CIncorrect. A function URL can point to an alias or to the unqualified function. Attaching it to an alias doesn't cause requests to be rejected as unauthorized.
• DIncorrect. Running out of concurrency causes throttling errors, not an authorization failure. It also wouldn't explain a consistent 403 for a client that is simply calling the URL.

Answer: A) The function's execution role doesn't allow xray:PutTraceSegments and xray:PutTelemetryRecords, so Lambda can't upload the trace data it generates.

Active tracing makes Lambda generate trace segments, but the execution role still needs xray:PutTraceSegments and xray:PutTelemetryRecords (for example, through AWSXRayDaemonWriteAccess) to deliver them. The console adds these permissions automatically; the CLI and API don't.

• ACorrect. Lambda needs xray:PutTraceSegments and xray:PutTelemetryRecords in the function's execution role to send trace data (both are in the AWSXRayDaemonWriteAccess managed policy). Lambda adds these permissions automatically only when tracing is turned on in the console, so enabling it through the CLI can leave them missing.
• BIncorrect. With Active tracing, Lambda automatically creates trace segments for function invocations. The X-Ray SDK is needed only to add custom subsegments, annotations, or metadata.
• CIncorrect. Lambda samples 1 request per second plus 5 percent of additional requests, and you can't configure the X-Ray sampling rate for Lambda functions.
• DIncorrect. X-Ray tracing doesn't require VPC attachment; functions that aren't in a VPC can use Active tracing.

Answer: A) Increase the function's timeout setting to a value above the API's observed response time

When an invocation needs longer than the configured timeout (3 seconds by default) because of expected downstream latency, the fix is to raise the timeout above that latency. Concurrency settings and retry settings don't change how long a single invocation can run.

• AThe default Lambda timeout is 3 seconds, and it can be raised to 900 seconds. A downstream service that takes longer to respond is a documented common cause of timeouts. Because the 4–6 second wait is expected, the timeout should be set above it with some headroom.
• BProvisioned concurrency reduces cold-start initialization latency. It doesn't shorten the 4–6 second wait for the API or extend the 3-second limit on each invocation.
• CReserved concurrency sets the minimum and maximum number of concurrent instances for the function. It doesn't change how long a single invocation may run.
• DLambda already retries timeouts on asynchronous invocations, but each retry has the same 3-second limit and will also time out while waiting on the API. More retries only add duplicate work.

Answer: A) The bucket policy in account 222222222222 does not grant the function's execution role access to the objects

For cross-account access, both the caller's identity-based policy and the resource-based policy in the resource owner's account must allow the request. A bucket policy that doesn't name the execution role causes a consistent AccessDenied even when the identity policy is correct.

• AFor cross-account requests, AWS evaluates both accounts. The caller's identity-based policy must allow the action, and the resource-based policy in the trusting account (here, the bucket policy) must also allow that principal. Without a bucket policy statement for the execution role, the request is denied even though the identity policy is correct.
• BA Lambda function's resource-based policy controls who can invoke or manage the function, for example letting S3 invoke it on events. It does not govern outbound calls that the function makes to S3.
• CThe execution role's trust policy must trust the Lambda service principal (lambda.amazonaws.com) so that Lambda can assume the role. The bucket-owning account does not need to assume the role, so adding it would not fix the denial.
• DMissing network connectivity makes S3 calls hang and time out. It does not cause an AccessDenied authorization error, which shows the request reached S3 and was rejected by policy evaluation.

Answer: A) Writes are propagated from the base table to the GSI asynchronously, so a query issued right after the write can briefly return stale results.

DynamoDB updates GSIs asynchronously and they support only eventually consistent reads. A query issued immediately after a write may briefly miss the new item, so applications must allow for slightly stale results.

• ACorrect. DynamoDB updates GSIs asynchronously using an eventually consistent model. Under normal conditions changes reach the index within a fraction of a second, and applications must expect that a GSI query may return results that are not yet up to date.
• BIncorrect. GSIs support only eventually consistent reads. Strongly consistent reads aren't available on a GSI, so changing ConsistentRead can't remove the propagation delay.
• CIncorrect. GSI propagation is eventually consistent in both capacity modes. On-demand mode doesn't hold index writes until read capacity builds up.
• DIncorrect. DynamoDB keeps each GSI synchronized with its base table automatically. New items that have the index key attributes are propagated to the index without any manual backfill.

Answer: A) Run the IAM policy simulator against the role for s3:PutObject on the bucket ARN and review the matched statement it reports for the denial

CloudTrail and the AccessDenied message show that a request was denied and which policy type was responsible, sometimes with the policy ARN. The IAM policy simulator evaluates the role's policies for the action and resource and names the specific statement that caused the explicit deny.

• AThe policy simulator can test a role's attached policies together or one at a time. For an allow or explicit deny result, it identifies the specific statement that produced the outcome, which pinpoints the denying statement.
• BThe access denied message gives the policy type and sometimes the policy ARN. It does not give the statement Sid. Here it gives no ARN at all, so it cannot isolate the statement.
• CAccess Analyzer policy validation checks policy grammar and best practices, such as security warnings and errors. It does not evaluate a specific request to show which statement allows or denies it.
• DLast accessed information shows when a role last used a service or action, to help remove unused permissions. It does not record denials or show which policy statement denied a request.

Answer: A) Raise the queue's visibility timeout to at least six times the function timeout

Set the SQS visibility timeout to at least six times the Lambda function timeout. If it is too short, messages can become visible again and be processed twice while an invocation, or a retry after throttling, is still handling them.

• ACorrect. AWS recommends a visibility timeout of at least six times the function timeout (plus any batching window). The extra time lets Lambda retry after throttling without messages becoming visible to another invocation while they are still being processed.
• BIncorrect. A shorter visibility timeout makes messages reappear even sooner. Lambda also rejects an event source mapping when the function timeout exceeds the queue's visibility timeout.
• CIncorrect. maxReceiveCount controls how many receives happen before a message moves to the dead-letter queue. It does not stop a message from becoming visible during in-progress processing.
• DIncorrect. Long polling reduces empty receive responses, but it has no effect on how long a received message stays hidden from other consumers.

Answer: A) Key-based Query calls were replaced with Scan calls that use a FilterExpression to pick items

A Scan consumes read capacity for every item it evaluates, even items its filter discards. Replacing Query with a filtered Scan can sharply increase read consumption without any change in traffic or results.

• AScan capacity is based on the size of every item evaluated, not the items returned after filtering. Replacing a targeted Query with a filtered Scan can multiply read consumption while the application still gets the same results.
• BRequesting a subset of attributes has no effect on the item size calculation for read capacity. It neither increases nor decreases the read units consumed.
• CDynamoDB processes each item in a BatchGetItem as an individual GetItem request. Batching the same items doesn't increase read capacity consumption.
• DAn eventually consistent read of an item up to 4 KB uses half a read unit, compared with one for a strongly consistent read. This change would lower consumption, not raise it.