Proposed flow for this scenario

  1. Identify invocation source
  2. Caller action and function resource
  3. Service resource-policy scope if applicable
  4. Execution-role trust
  5. Handler downstream permissions
  6. Outcome

This flow describes a design to evaluate. Follow the supported console workflow below to practice with local resources. Its scope appears with the controls; no cloud resources are provisioned.

Decision checkpoints

ChoiceFits whenWatch for
Caller invocation permissionThe direct identity may invoke the intended function.Adding S3 access to the execution role to fix an invocation denial.
Service invocation grantThe selected AWS service needs a correctly scoped function resource-policy permission.Allowing every source when one API route is intended.

Name the actor that failed

A synthetic LetX function exists and has a role that can write its selected observations. A direct local invocation can still fail if the active identity is not allowed to invoke that function. The execution role is not the identity making the caller’s request.

If the source is an API Gateway integration, inspect the function’s modeled resource-policy permission for that service and source ARN. A function can pass direct testing while a service integration is denied. Record the invocation path rather than comparing only the function name.

Trust and downstream permissions are later boundaries

The function’s execution role must have the appropriate service trust and the selected downstream actions. Those requirements answer what the function may do after it is invoked. They do not automatically authorize every caller or every API integration.

An execution that starts and then fails an S3 or logging operation should be diagnosed at that downstream action. Adding a broader invoke permission does not grant object access or create a missing log-group permission. Preserve distinct errors instead of calling every failure a Lambda permission issue.

Run the two-actor drill

Inspect the LetX function, role and invoking identity in the console. Reproduce a denied direct invocation under a bounded identity and repair its intended function action. Then separately create an API integration without the scoped invoke permission and inspect its failure.

Use the integration’s permission repair for the intended source and repeat the local request. The simulation models selected policies, role trust and named presets. It assumes no real role, issues no AWS credentials and executes no arbitrary source code.

Changed scenario and scope

Question: the direct function test works, but the API request still fails before useful handler work. Should the execution role receive administrator permissions? No. Compare the service invocation grant and source scope first, then use the integration evidence to identify the failed boundary.

Use the console links below to inspect the function, its role and the integration permission as separate steps. Real cross-account access, organization controls and unsupported policy conditions require current AWS evaluation. Confirm the exact function qualifier and request source in a live investigation before changing a policy.

Practice the supported console workflow

Sources and scope

Reviewed against these official references. The model’s supported scope appears alongside its controls.

How we review explanations