Troubleshooting and Optimization practice questions

Answer: A) Create an EventBridge Scheduler schedule with cron(0 9 * * ? *) and the time zone set to America/New_York

EventBridge scheduled rules evaluate cron expressions only in UTC, so cron(0 9 * * ? *) runs at 9:00 UTC. EventBridge Scheduler lets you set a time zone such as America/New_York and adjusts for daylight saving time automatically.

• ACorrect. EventBridge Scheduler evaluates cron expressions in the IANA time zone you specify and adjusts automatically for daylight saving time. The job therefore runs at 9:00 AM New York time all year. AWS also recommends Scheduler over legacy scheduled rules.
• BIncorrect. Scheduled rules evaluate cron in UTC. 13:00 UTC is 9:00 AM only while New York is on daylight saving time (UTC-4). In winter (UTC-5) the job would run at 8:00 AM, because a fixed UTC hour does not adjust for daylight saving time.
• CIncorrect. Cron expressions for scheduled rules are evaluated in UTC (UTC+0) in every Region. Moving the rule to another Region does not change the time it fires.
• DIncorrect. A TZ variable only changes how the function's code interprets times after it is invoked. It has no effect on when EventBridge triggers the function.

Answer: A) Enable standard logging for the distribution and review the x-edge-detailed-result-type field of the 502 requests

CloudFront's generic error page and its CloudWatch error-rate metrics don't give the root cause. Standard logs do: for errors, the x-edge-detailed-result-type field (for example OriginDnsError or OriginConnectError) narrows a 502 down to a specific cause.

• ACorrect. When x-edge-result-type is Error, the x-edge-detailed-result-type field gives the specific failure, such as OriginDnsError, OriginConnectError or OriginCommError. That points to one of the documented 502 causes, for example origin DNS problems, TLS negotiation failures, or an origin that isn't responding on its ports. Logging isn't retroactive. It only records requests made after it's turned on, and CloudFront starts delivering logs reliably about four hours after logging is enabled. So the developer analyzes new occurrences of the error.
• BIncorrect. An invalidation only removes cached objects. It doesn't show why CloudFront couldn't get a valid response from the origin, and new requests would fail again for the same reason.
• CIncorrect. CloudTrail records API calls to the CloudFront service, such as UpdateDistribution. It doesn't record individual viewer requests or why they failed.
• DIncorrect. The additional metrics include an error rate for each status code, including 502. They show what percentage of requests failed, but not why each request failed, so they can't separate a DNS error from a connection or TLS error.

Answer: C) Cache the values in the execution environment, for example with the AWS Parameters and Secrets Lambda Extension; E) Enable the higher throughput setting for Parameter Store in the account and Region, which adds per-request charges

Parameter Store's default 40 TPS is easy to exceed from Lambda; cache values in the execution environment and, if needed, enable higher throughput.

• AIncorrect. Parameter tiers control size limits and features such as parameter policies. Throughput is a separate setting, so the tier change doesn't raise the request quota.
• BIncorrect. With default throughput, GetParametersByPath shares the same 40 TPS quota, and one call per invocation at this concurrency is still far above it.
• CCorrect. Values that change daily can be cached with a time to live, so each environment calls Parameter Store rarely instead of on every invocation.
• DIncorrect. Retries add requests while demand stays far above the quota, so they increase latency and cost without fixing the throttling.
• ECorrect. Default throughput is 40 TPS shared across the get-parameter APIs. Higher throughput raises GetParameter to thousands of TPS for an extra charge per API interaction.

Answer: A) The IAM policy simulator

• AThe IAM policy simulator lets you test whether a given identity's policies would allow or deny a specific action on a specific resource, without actually performing the action, which is ideal for debugging permission issues safely.
• BLogs Insights queries existing log data; it doesn't simulate hypothetical policy evaluations ahead of time.
• CX-Ray traces requests through a distributed application; it isn't a tool for testing IAM policy logic.
• DInspector performs automated vulnerability assessments of workloads; it isn't designed for testing whether a specific IAM policy allows a specific action.

Answer: A) Add a DependsOn attribute to the custom resource that names the AWS::IAM::Policy resource

CloudFormation infers ordering only from Ref, Fn::GetAtt, and Fn::Sub references and otherwise works in parallel. When a resource needs a separate IAM policy it doesn't reference, add a DependsOn on that policy.

• AThe custom resource implicitly depends on the function through Fn::GetAtt, but nothing links it to the separate policy resource. CloudFormation can therefore create the policy in parallel with the custom resource. DependsOn makes CloudFormation create the policy first, as the docs describe for resources that use a role whose policy is a separate resource.
• BCloudFormation does not create resources in the order they are declared. It works out ordering from dependencies and otherwise runs operations in parallel, so moving the declaration does not guarantee ordering.
• CCreationPolicy waits for success signals from resources such as EC2 instances or Auto Scaling groups. It does not make another resource wait for an IAM policy to be created.
• DDeletionPolicy only controls what happens to a resource when it is removed from the stack or the stack is deleted. It has no effect on creation order.

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) The deploying principal is trying to assign an IAM role (e.g., to a Lambda function or EC2 instance being created) but doesn't itself have permission to pass that specific role to the service

• Aiam:PassRole is a specific permission required whenever a principal configures a resource (like a Lambda function's execution role) to use a particular IAM role — without that permission on the specific role's ARN, the deploying principal is blocked from assigning it, even if it can otherwise create the resource itself.
• BA syntax error would produce a template-parsing failure, not this specific PassRole authorization error, which is about a permissions gap for assigning a role to a resource.
• CIAM is a global service available in every Region; this error is about a specific missing permission, not regional IAM support.
• DResource count limits would produce a different kind of error; this specific error is clearly about the PassRole permission, not stack size.

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) Switch the table to on-demand capacity mode so write throughput scales automatically

The errors come from write consumption exceeding the table's fixed provisioned capacity during spikes. Switching to on-demand mode, or increasing capacity and enabling auto scaling, addresses the cause. On-demand can still throttle if traffic more than doubles the previous peak within 30 minutes, and well-designed clients should still retry with exponential backoff.

• AAWS recommends switching to on-demand mode when traffic spikes frequently exceed provisioned write capacity. On-demand removes the fixed WCU limit and instantly handles up to double the table's previous peak traffic.
• BDAX is a write-through cache built for read-heavy workloads. Every write still goes synchronously to the table and uses its write capacity, so write throttling continues.
• CA GSI does not take writes away from the base table. Each base-table write that affects the index also writes to the GSI, which adds capacity consumption and can cause back-pressure throttling.
• DMore parallel invocations send even more write requests to a table that is already over its provisioned capacity, which increases throttling.

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.