Lesson 140 · AWS Learning Path

AWS 140: Lambda permissions and execution roles

Anil Jalela · Published Nov 12, 2025 · 8 min read

Why this lesson matters

Separate the execution role used by function code, the resource policy that permits invocation, and the caller permissions used to configure Lambda.

What you will be able to do

By the end, you can:

• explain lambda permissions and execution roles in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+--------------------------+
|  Event source principal  |
+--------------------------+
             |
             v
+----------------------------+
|  Function resource policy  |
+----------------------------+
              |
              v
+-----------------------------------------+
|  Lambda service assumes execution role  |
+-----------------------------------------+
                    |
                    v
+--------------------------------+
|  Downstream API authorization  |
+--------------------------------+

For Lambda permissions, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Lambda permissions. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Lambda permissions. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.

Architecture decision table

Follow each authorization request separately

There is no single “Lambda permission.” At least four evaluations may occur:

1. A deployment/operator principal calls control-plane actions such as create/update function, attach event source or pass an IAM role. iam:PassRole permits assigning a role to Lambda; it does not grant that operator the role's data permissions.
2. An invoker calls the function. Its identity policy and, for cross-account or AWS-service invocation, the function's resource-based policy must authorize the qualified/unqualified ARN and conditions.
3. Lambda's service principal (lambda.amazonaws.com) assumes the execution role through its trust policy and provides temporary credentials to code.
4. The code calls SQS, DynamoDB, KMS, Secrets Manager or another API. IAM evaluates the execution-role policy together with resource policies, permissions boundaries, session context, VPC endpoint policy, SCP/RCP and explicit denies.

An event source mapping is also an AWS resource that polls SQS/Kinesis/DynamoDB Streams/MSK/MQ using the execution role and then invokes the function. Push services such as S3, SNS and EventBridge commonly need a function resource-policy statement naming the service principal and constraining AWS:SourceArn and, where supported, AWS:SourceAccount to prevent a confused deputy. API Gateway uses a source ARN covering API/stage/method/resource; overly narrow patterns deny valid routes and wildcards that are too broad authorize unrelated routes.

Least privilege and secret boundaries

Build permissions from exact SDK calls and resource ownership. Restrict queue/table/key/secret ARNs, actions and conditions; separate functions with different trust/data needs instead of one shared super-role. CloudWatch Logs permissions are still permissions and log groups need retention/encryption ownership. KMS authorization often needs both IAM and a key policy/grant. VPC networking does not replace IAM, and IAM success does not prove TCP reachability.

Do not place long-lived AWS keys in code or environment variables. The execution role provides rotating credentials through the runtime. Secrets Manager/Parameter Store values require explicit read/decrypt permission and safe caching/rotation. CloudTrail shows management/data events when configured, while function logs show application behavior; use both to distinguish “not invoked” from “invoked but downstream denied.”

Policy changes are eventually reflected across distributed systems. Use bounded retests and preserve original request ID/error. IAM Policy Simulator can help with identity policies but may not reproduce every resource policy, SCP, key grant or service context; the actual denied API and CloudTrail authorization context are stronger evidence.

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open Lambda, Functions, Configuration, Permissions; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws lambda list-functions --query 'Functions[].{Name:FunctionName,Role:Role}' --output table
aws lambda get-policy --function-name replace-with-function-name --output json
aws iam get-role --role-name replace-with-execution-role-name --query 'Role.{Name:RoleName,Trust:AssumeRolePolicyDocument}' --output json

Expected interpretation

The role ARN and function policy reveal different trust directions. AccessDenied must be traced to the exact principal, action, resource, condition, and policy layer.

Practical work

Draw three requests: deploy a function, invoke it from API Gateway, and let its code send to SQS. Write the principal and policy required for each arrow.

For every arrow include action, resource ARN shape, policy owner, trust/resource statement, conditions, explicit-deny layers and CloudTrail/application evidence. Add S3 and cross-account invocation variants and explain SourceArn/SourceAccount. Create a least-privilege execution-policy draft for one exact queue and one KMS-encrypted secret, then supply negative tests for another queue, direct invocation by an unapproved principal, wrong API stage and KMS key disabled. Do not deploy policies.

Diagnose this topic from its own evidence

Decode the exact principal, action, resource and request ID. If no Lambda invocation metric/log exists, inspect caller/service permission and function policy. If the handler logs an AWS SDK AccessDenied, inspect execution-role credentials and downstream IAM/resource/key/endpoint/organization policies. If Lambda cannot assume the role, inspect trust principal and role association. If deployment says iam:PassRole denied, fix the operator's narrow pass-role permission and iam:PassedToService condition - not the execution role.

Test denials intentionally: an allowed API route succeeds, an unlisted stage fails; the function sends to its queue, a second queue fails; secret metadata may be visible while decrypt/value access fails according to the design. Never diagnose by attaching AdministratorAccess. Change one statement, retest, then revert the exercise.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Separate the execution role used by function code, the resource policy that permits invocation, and the caller permissions used to configure Lambda.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Lambda permissions.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Lambda permissions.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid adding AdministratorAccess to the execution role or granting every service permission to invoke the function.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

Pass when the learner correctly maps deployer, invoker, Lambda service, execution role and downstream service to separate requests and policies; explains PassRole, trust policy, resource policy and IAM evaluation with explicit deny; constrains service invocation against confused-deputy risk; and handles KMS/secrets/logging. The evidence must include one success and at least three expected denials with the failed layer identified. Fail if a wildcard administrator role is proposed, network rules are treated as authorization, the deployer is assumed to be the runtime identity, or an invocation policy is confused with downstream data access.

Official sources

• Lambda permissions
• Lambda execution role
• Lambda Developer Guide
• Serverless Lens