# Execution role

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/execution-role

## Quick definition

An execution role is a security identity that you attach to a computing service, like a serverless function or a virtual machine, to grant it specific permissions. Instead of hardcoding passwords or keys, the service assumes this role to access other services securely. It follows the principle of least privilege, giving only the access needed for the task.

## Simple meaning

Imagine you are the manager of a large office building. You have many employees who need to do different jobs. The cleaning crew needs keys to the supply closets, but not to the server room. The IT technician needs keys to the server room, but not to the supply closets. Instead of giving every employee a master key that opens every door, you give each employee a special keycard that unlocks only the doors they need for their work. That keycard is like an execution role.

In the world of cloud computing, an execution role works the same way. When you have a program running on a cloud service, such as AWS Lambda or an EC2 instance, that program often needs to talk to other services, like reading files from an S3 bucket or writing logs to CloudWatch. Without an execution role, you would have to put a set of login credentials (like a username and password) directly inside your code. That is risky because if someone gets access to your code, they can steal those credentials and do anything with them.

An execution role solves this problem. You create a role with only the permissions needed for your program, such as read-only access to a specific S3 bucket. Then you attach that role to the service running your code. When the code needs to access the bucket, it does not use stored credentials. Instead, it asks the cloud provider, “I have this role. Can I read that file?” The provider checks the role’s permissions and, if allowed, grants access. This way, you never have to manage or expose secrets in your code. The role is temporary and automatically rotated, making your applications much more secure.

This concept is fundamental to the shared responsibility model in cloud computing. You are responsible for configuring these roles correctly to ensure your resources are protected. Execution roles help you follow the security principle of least privilege, meaning you grant only the minimum permissions necessary for a task, and nothing more.

## Technical definition

An execution role is an AWS Identity and Access Management (IAM) role that a service, such as AWS Lambda, Amazon EC2, or AWS Fargate, assumes to perform actions on your behalf. It is a fundamental component of the AWS security model, enabling secure, credential-less access between services. The role is defined by a trust policy and a permissions policy.

When you create an execution role for AWS Lambda, you first define a trust policy that specifies which service principal (e.g., lambda.amazonaws.com) is allowed to assume the role. This is a JSON document that states something like: “Allow the Lambda service to assume this role.” Without this trust policy, no service can use the role, even if the permissions policy grants extensive rights.

Next, you attach a permissions policy (or multiple policies) to the role. These policies define the specific actions the role is allowed to perform on which resources. For example, a permissions policy might grant s3:GetObject on the bucket “my-app-data” and logs:PutLogEvents on a CloudWatch log group. The policies follow the AWS IAM policy language, which supports conditions, resource ARNs, and effect (Allow or Deny).

The process of assuming a role happens through the AWS Security Token Service (STS). When the Lambda function is invoked, the Lambda service calls the AssumeRole API on behalf of that function. STS returns temporary, limited-privilege credentials consisting of an access key ID, secret access key, and a session token. These credentials are valid for a configurable duration, typically up to the function’s timeout. The Lambda runtime environment automatically refreshes these credentials for long-running invocations.

In practice, the execution role is attached to the Lambda function at the time of creation or update. You specify the role’s Amazon Resource Name (ARN) in the function configuration. When the function code runs, the AWS SDK (e.g., boto3 for Python) automatically retrieves these temporary credentials from the local environment variables and metadata. The developer does not need to call AssumeRole manually in their code; the SDK handles it transparently.

For Amazon EC2, the concept is very similar but the implementation differs slightly. You create an IAM role and attach it to an EC2 instance profile. The instance profile is a container that passes the role to the instance. When the EC2 instance starts, the AWS credential provider chain inside the instance queries the instance metadata service (IMDS) to obtain temporary credentials associated with the role. Applications running on the instance can then use these credentials to access other AWS services.

A crucial aspect of execution roles is that they follow the principle of least privilege. Best practice is to grant only the actions and resources required for the function or instance to operate. Overly permissive roles are a common security risk. Execution roles are region-specific but can be assumed across accounts if the trust policy includes a cross-account principal.

Execution roles are also central to AWS services like Amazon ECS, AWS Fargate, AWS Step Functions, and Amazon API Gateway. Each service has its own trust policy requirements. For example, an ECS task execution role must allow ecs-tasks.amazonaws.com to assume it, and it needs permissions to pull container images from Amazon ECR and write logs to CloudWatch.

the execution role is a secure, scalable, and auditable way to grant permissions to AWS services. It eliminates the need for long-term credentials, reduces the risk of credential leakage, and integrates with AWS CloudTrail for full auditability of every API call made by the role.

## Real-life example

Think of a large hotel. The hotel has many departments: housekeeping, maintenance, front desk, and room service. Each department has employees who need access to different parts of the hotel. The housekeeper needs a key card that opens all guest rooms and the linen closet, but not the main office or the kitchen. The maintenance worker needs a key card that opens the boiler room, the electrical panels, and the rooftop, but not the guest rooms. The front desk clerk needs access to the reservation system and the office, but not the supply closets.

Now, instead of giving each employee a master key that opens every door in the hotel, the hotel manager creates special key cards for each role. A housekeeper’s key card is programmed to open only the doors that the housekeeping team needs. When a housekeeper arrives for their shift, they go to the security office and receive a temporary key card that works only for that day. They do not need to remember a password or carry a physical master key that could be copied. At the end of the shift, the key card expires and cannot be used again.

This is exactly how an execution role works in the cloud. The hotel manager is like the cloud administrator who creates IAM roles. The key card is like the temporary credentials issued by AWS STS. The doors are like the AWS services and resources, such as S3 buckets or DynamoDB tables. The housekeeper’s role is like an execution role attached to an AWS Lambda function. The function needs to read data from an S3 bucket, so the execution role grants s3:GetObject permission on that bucket. The function does not have a stored password; it simply assumes the role and gets temporary credentials. Those credentials are valid only for the duration of the function execution, just like the hotel key card expires at the end of the shift.

If the housekeeper tried to open the kitchen door, the key card would beep and refuse, because the card is not programmed for that door. Similarly, if a compromised Lambda function tries to delete data from an RDS database, the execution role will deny that action because the permissions policy does not allow it. This analogy shows how execution roles enforce strict boundaries and keep your cloud environment secure.

## Why it matters

Execution roles matter because they are the cornerstone of secure cloud architecture. In traditional on-premises environments, applications often use long-term credentials like database passwords or API keys stored in configuration files. These credentials can be stolen, leaked, or misused. In cloud environments, the scale and automation make credential management even more critical. Execution roles solve this by providing temporary, automatically rotated credentials that are scoped to the exact permissions needed.

For IT professionals, understanding execution roles is essential for building compliant and secure systems. Many regulatory frameworks, such as PCI DSS, HIPAA, and SOC 2, require strict access controls and the principle of least privilege. Using execution roles helps meet these requirements because you can define precisely which actions a service can perform, and you can audit every action via CloudTrail.

Execution roles also simplify operations. When you need to update permissions, you update the role, not the application code. For example, if a Lambda function needs read access to a new S3 bucket, you simply add that permission to the role. All functions using that role immediately gain the new access. No code changes, no redeployment, no risk of exposing credentials in a code repository.

execution roles enable cross-service automation. For instance, an AWS Step Functions workflow can use an execution role to invoke a Lambda function, which then reads from S3 and writes to DynamoDB, all without any hardcoded secrets. This makes your infrastructure more resilient and auditable.

Finally, execution roles are a key part of the shared responsibility model. AWS is responsible for the security of the cloud, but you are responsible for security in the cloud. Misconfiguring execution roles, such as granting overly broad permissions or forgetting to restrict access to specific resources, is a common cause of data breaches. Therefore, every IT professional working with AWS must master the creation and management of execution roles.

## Why it matters in exams

Execution roles are a core topic across multiple AWS certification exams, including the AWS Certified Solutions Architect – Associate (SAA-C03), AWS Certified Developer – Associate (DVA-C02), and AWS Certified SysOps Administrator – Associate (SOA-C02). For the Solutions Architect exam, you will encounter execution roles in the context of designing secure architectures, specifically in the domain of “Design Secure Architectures” which accounts for 30% of the exam. You need to know when to use an execution role versus an IAM user or access key, and how to apply the principle of least privilege.

In the Developer Associate exam, execution roles are heavily tested in the “Security” domain, especially around AWS Lambda and API Gateway. You may be asked to identify the correct way to grant a Lambda function access to an S3 bucket or a DynamoDB table. The exam often includes questions where you must choose between using an execution role, an IAM user, or resource-based policies. Understanding the difference between an execution role (used by a service) and a resource-based policy (used by the resource itself) is critical.

For the SysOps Administrator exam, execution roles are part of the “Monitoring, Logging, and Remediation” and “Security and Compliance” domains. You may be asked about troubleshooting permission issues, such as why a Lambda function cannot write to CloudWatch Logs, which is almost always due to a missing permission in the execution role. You must know how to attach the necessary policies, including the AWS managed policy AWSLambdaBasicExecutionRole for CloudWatch Logs.

The AWS Certified Security – Specialty (SCS-C02) exam goes deeper into execution roles, covering cross-account roles, role chaining, and the use of conditions in trust policies. You may encounter scenarios where you need to allow an EC2 instance in one account to access an S3 bucket in another account using an execution role with a trust policy that specifies the external account.

the AWS Certified Machine Learning – Specialty exam tests execution roles in the context of Amazon SageMaker, where a SageMaker notebook instance or training job needs an execution role to access training data in S3.

Question types vary. You might see multiple-choice questions like: “A developer wants to allow an AWS Lambda function to read objects from an S3 bucket. What is the MOST secure way to grant this access?” The correct answer is to create an IAM execution role with an S3 read policy and attach it to the function. Incorrect options often include storing access keys in environment variables or using an IAM user with long-term credentials.

You may also see scenario-based questions where you are given a CloudTrail log showing a denied API call, and you must identify the missing permission in the execution role. For example, if a Lambda function’s execution role is missing the ec2:DescribeInstances permission, the function will fail when trying to list EC2 instances. Understanding how to read IAM policy documents and map them to required permissions is a key skill for exam success.

## How it appears in exam questions

Execution role questions typically appear in three main patterns: scenario-based, configuration-based, and troubleshooting-based. Understanding these patterns will help you quickly identify what the question is asking.

Scenario-based questions: You are given a use case, such as an AWS Lambda function that needs to read data from an S3 bucket and write logs to CloudWatch. The question asks you to choose the correct architecture to meet the security and operational requirements. The correct answer will involve creating an IAM execution role with an S3 read policy and a CloudWatch logs write policy, then attaching that role to the Lambda function. Distractors might include using an IAM user with access keys stored in the Lambda environment variables, or using a resource-based policy on the S3 bucket alone without a role. You must recognize that the Lambda function needs its own identity (the execution role) to make calls on your behalf.

Configuration-based questions: These questions show a partial JSON policy document and ask you to identify what is missing or incorrect. For instance, you might see a trust policy that allows “ec2.amazonaws.com” to assume a role, but the question states the role is for a Lambda function. The error is that the service principal should be “lambda.amazonaws.com” not “ec2.amazonaws.com”. Another variation shows a permissions policy that grants “s3:ListBucket” on a specific bucket ARN, but the question asks for permission to get objects, so the action should be “s3:GetObject”. Pay close attention to the actions, resource ARNs, and conditions in the policy.

Troubleshooting-based questions: These present an error message, such as “AccessDeniedException” when a Lambda function tries to write to DynamoDB. The question asks you to identify the root cause. The answer options might include: missing execution role permissions, incorrect region, wrong resource ARN, or a bucket policy blocking access. The correct answer is almost always that the execution role does not include the necessary DynamoDB permissions. You should check if the role has the dynamodb:PutItem action on the correct table. Sometimes the error is more subtle, like the Lambda function’s execution role has the permissions, but the function itself is not configured to use that role. In that case, the question might ask you to verify the function’s configuration.

Another common pattern involves cross-account access. A question might describe an application running in Account A that needs to read data from an S3 bucket in Account B. You must configure an execution role in Account A with a trust policy that allows the Lambda service to assume it, and also configure a bucket policy in Account B that grants access to the execution role’s ARN. The exam may ask you to choose which two steps are required.

Finally, you may see questions about the difference between an execution role and a service-linked role. Service-linked roles are predefined by AWS and are used for specific services like Amazon RDS or Amazon EC2 Auto Scaling. Execution roles are custom roles you create for your own workloads. The exam might ask you when to use one versus the other.

To prepare, practice reading IAM policy documents and identifying which services and actions are allowed. Use the AWS Policy Generator tool to create sample policies. Review the AWS Well-Architected Framework’s Security Pillar for best practices on least privilege.

## Example scenario

A company called PhotoShare runs a web application where users upload photos. The application uses AWS Lambda to automatically resize each uploaded image and store it in a different S3 bucket. When a user uploads a photo to the “uploads” bucket, an S3 event triggers a Lambda function. The Lambda function needs to read the original image from the uploads bucket, resize it, and write the resized image to the “resized” bucket. It also needs to log each operation to CloudWatch Logs for monitoring.

To achieve this securely, the developer creates an IAM execution role for the Lambda function. The role has a trust policy that allows the Lambda service to assume it. The role also has two permissions policies attached. The first policy grants s3:GetObject on the “uploads” bucket ARN, but only for objects (not listing the bucket). The second policy grants s3:PutObject on the “resized” bucket ARN. A third policy (or inline policy) grants logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents on a specific CloudWatch log group ARN.

The developer then configures the Lambda function to use this execution role by specifying its ARN. Inside the Lambda function code, the developer uses the AWS SDK for Python (boto3). The SDK automatically retrieves temporary credentials from the execution role. The code creates an S3 client using boto3.client(‘s3’) and then calls get_object on the uploads bucket and put_object on the resized bucket. The developer does not need to supply any access keys or secrets. The entire access is managed through the role.

Now, suppose a security auditor reviews the setup. The auditor checks that the execution role follows the principle of least privilege. The role only allows read access to the uploads bucket and write access to the resized bucket. It does not allow delete actions on either bucket. It does not allow access to any other S3 buckets. If the Lambda function is compromised, the attacker can only read from the uploads bucket and write to the resized bucket. They cannot delete user photos or access other sensitive data. The auditor is satisfied.

However, if the developer had accidentally attached the AWS managed policy “AmazonS3FullAccess” to the role, the Lambda function would have full control over all S3 buckets in the account. That would be a security risk. This example shows the importance of granting only the necessary permissions in the execution role.

## Common mistakes

- **Mistake:** Attaching an AWS managed policy like AdministratorAccess to an execution role instead of a custom scoped policy.
  - Why it is wrong: This grants the Lambda function full administrative access to all AWS resources in the account, violating the principle of least privilege. If the function is compromised, an attacker can perform any action, including deleting resources or creating new IAM users.
  - Fix: Create a custom IAM policy that includes only the specific actions and resources required for the function's task. For example, instead of full S3 access, grant only s3:GetObject on the specific bucket ARN.
- **Mistake:** Forgetting to attach the AWSLambdaBasicExecutionRole managed policy or equivalent permissions for CloudWatch Logs.
  - Why it is wrong: Without permission to write logs to CloudWatch, the Lambda function will fail silently or produce errors when trying to log. This makes debugging very difficult and can cause monitoring gaps.
  - Fix: Always include a policy that grants logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents on the relevant log group. The AWS managed policy AWSLambdaBasicExecutionRole covers this.
- **Mistake:** Using an IAM user's access keys inside a Lambda function instead of an execution role.
  - Why it is wrong: Access keys are long-term credentials that never expire unless manually rotated. If the keys are stored in the function's environment variables or code, they can be leaked through logs or version control. Also, rotating keys requires updating every function that uses them.
  - Fix: Create an IAM execution role with the necessary permissions and attach it to the Lambda function. The SDK will automatically handle temporary credentials via the role.
- **Mistake:** Configuring the trust policy incorrectly, such as allowing the wrong service principal.
  - Why it is wrong: If the trust policy specifies 'ec2.amazonaws.com' instead of 'lambda.amazonaws.com', the Lambda function will not be able to assume the role. The AssumeRole API call will fail, resulting in an AccessDenied error.
  - Fix: Ensure the trust policy has the correct service principal. For Lambda, use 'lambda.amazonaws.com'. For EC2, use 'ec2.amazonaws.com'. Always double-check the service's documentation.
- **Mistake:** Granting permissions on a wildcard resource (*) when a specific resource ARN is appropriate.
  - Why it is wrong: Using a wildcard in the Resource field allows the role to access all resources of that type in the account. For example, 's3:GetObject' on '* /*' grants read access to every object in every bucket. This is overly permissive.
  - Fix: Specify the exact resource ARN, such as 'arn:aws:s3:::my-bucket/*'. Use conditions like 'aws:ResourceAccount' if needed to restrict further.

## Exam trap

{"trap":"The exam presents a scenario where an AWS Lambda function must access a DynamoDB table in the same account. The answer choices include using an IAM execution role with DynamoDB permissions, using an IAM user with access keys stored in AWS Secrets Manager, or using a resource-based policy on the DynamoDB table. The trap is that many learners choose the resource-based policy because they know DynamoDB supports such policies.","why_learners_choose_it":"Learners often confuse resource-based policies (like S3 bucket policies) with identity-based policies (like IAM roles). They may think that any AWS service that supports resource-based policies can grant access directly to a Lambda function without a role. DynamoDB does support resource-based policies (called table policies), but Lambda functions do not have a principal ARN that can be used in a resource-based policy unless you specify the function's execution role ARN. The simpler and standard approach is to use an execution role.","how_to_avoid_it":"Remember that for most AWS services that act as principals (like Lambda, EC2, ECS), you should use an execution role. Resource-based policies are typically used to grant cross-account access or to allow other AWS services to access your resources. In this scenario, the Lambda function itself needs an identity (the execution role) to make API calls. So the correct answer is to create an execution role with dynamodb:PutItem (or GetItem) and attach it to the Lambda function. Resource-based policies are not the primary mechanism for granting access to a service within the same account."}

## Commonly confused with

- **Execution role vs IAM role (general):** An IAM role is a broader concept that can be assumed by any entity, including users, applications, and AWS services. An execution role is a specific type of IAM role that is designed to be assumed by an AWS service, such as Lambda or EC2, to perform actions on your behalf. The key difference is the trust policy: an execution role has a trust policy that allows a service principal to assume it, whereas a general IAM role might be assumed by a user or a federated identity. (Example: An execution role for Lambda has a trust policy that allows lambda.amazonaws.com to assume it. A general IAM role for a user might have a trust policy that allows an IAM user in another account to assume it for cross-account access.)
- **Execution role vs Service-linked role:** A service-linked role is a predefined IAM role that is directly linked to an AWS service, such as Amazon RDS or Amazon EC2 Auto Scaling. The service defines the permissions and the trust policy, and you cannot modify them directly. In contrast, an execution role is created and fully managed by you. You define the permissions and the trust policy. Service-linked roles are used by AWS services to perform AWS-managed actions, while execution roles are used for your custom workloads. (Example: Amazon RDS uses a service-linked role named AWSServiceRoleForRDS to access other services like EC2 and S3 on your behalf. You do not create this role. For your custom Lambda function, you create an execution role with specific S3 read permissions.)
- **Execution role vs IAM user:** An IAM user is a long-term identity representing a person or application with permanent credentials (access key ID and secret access key). An execution role is a temporary identity that does not have any long-term credentials. Instead, it is assumed to obtain temporary credentials via STS. Using IAM users for services is discouraged because it requires managing and rotating keys, and they cannot be easily scoped to single service invocations. (Example: A developer who needs to interact with AWS CLI uses an IAM user with access keys. An AWS Lambda function that needs to read an S3 bucket uses an execution role with temporary credentials that expire after the function runs.)

## Step-by-step breakdown

1. **Identify the service that needs permissions.** — First, determine which AWS service will perform actions on your behalf. Common examples are AWS Lambda, Amazon EC2, AWS Fargate, or AWS Step Functions. Each service has a unique service principal used in the trust policy.
2. **Create an IAM role in the IAM console or CLI.** — Navigate to the IAM service and choose 'Roles' then 'Create role'. Select the trusted entity type as 'AWS service'. Then choose the use case, for example, 'Lambda'. This automatically generates the correct trust policy for that service.
3. **Define the trust policy.** — The trust policy specifies which service principal is allowed to assume the role. For Lambda, the policy includes 'Service': 'lambda.amazonaws.com'. This step is critical; if the trust policy is wrong, the service cannot assume the role.
4. **Attach permissions policies.** — Attach one or more IAM policies that define the actions and resources the role can access. Use managed policies for common permissions (e.g., AWSLambdaBasicExecutionRole for CloudWatch logs) or create custom policies for fine-grained control. Follow the principle of least privilege.
5. **Name the role and review.** — Give the role a meaningful name, such as 'my-lambda-execution-role'. Add tags if needed for organization. Review the trust policy and permissions policies to ensure they are correct.
6. **Attach the role to the service.** — For AWS Lambda, you specify the execution role ARN when creating or updating the function. For EC2, you attach the role to an instance profile and then associate the instance profile with the instance. This step links the identity to the resource.
7. **Test and monitor.** — Invoke the service and verify it can access the required resources. Check CloudWatch Logs for any errors, and use CloudTrail to audit the API calls made by the role. If access is denied, review the permissions policies and trust policy.

## Practical mini-lesson

In the real world, managing execution roles is a daily task for cloud engineers. You will frequently create roles for new Lambda functions, update permissions as requirements change, and troubleshoot permission errors. A solid understanding of IAM policies and trust relationships is essential.

Let's walk through a practical example. Suppose you are building a data pipeline. A Lambda function every hour reads a CSV file from an S3 bucket, processes it, and writes results to a DynamoDB table. You create an execution role named 'data-pipeline-role'. You attach a policy that allows s3:GetObject on the specific bucket and dynamodb:BatchWriteItem on the specific table. You also attach the AWSLambdaBasicExecutionRole for CloudWatch logs.

Now, imagine you need to update the pipeline to also read from a second S3 bucket. Instead of modifying the Lambda code or redeploying, you simply edit the execution role's policy to add the new bucket ARN. The change takes effect immediately. This is a huge operational advantage.

What can go wrong? One common issue is hitting the IAM role trust policy size limit. IAM roles have a maximum policy size of 10,240 characters for the trust policy and 5,120 characters per managed policy. If you attach too many policies, you may exceed the limit. Use multiple custom policies or inline policies sparingly.

Another issue is eventual consistency. When you update a role's permissions, there is a short delay (a few seconds) before the new permissions are fully propagated. If your Lambda function runs immediately after a policy change, it might still see old cached permissions. In practice, this is rarely a problem, but for critical systems, you may need to add retry logic.

Cross-account execution roles add complexity. If a Lambda function in Account A needs to read an S3 bucket in Account B, you must create an execution role in Account A with a trust policy that allows lambda.amazonaws.com to assume it, and then create a bucket policy in Account B that grants access to the execution role's ARN. You also need to ensure that the IAM user who creates the role has the iam:PassRole permission for that role. This is a common source of errors in production.

Professionals should also understand the difference between using an execution role and using resource-based policies. For example, S3 supports bucket policies that can grant access to a Lambda function’s execution role directly. However, this is only needed for cross-account access. For same-account access, simply grant permissions in the execution role.

Finally, always use the principle of least privilege. Start with minimal permissions and add only what is needed. Use IAM Access Analyzer to review and validate your policies. Use conditions like 'aws:SourceArn' in trust policies to prevent the confused deputy problem. For example, in a cross-account scenario, you can add a condition that restricts the role to be assumed only when the request comes from a specific S3 bucket ARN.

## Memory tip

Think of an execution role as a 'service keycard', it gives a specific AWS service the exact access it needs, nothing more, and it expires automatically.

## FAQ

**Can I use the same execution role for multiple Lambda functions?**

Yes, you can attach the same execution role to multiple Lambda functions. This is useful when multiple functions need the same set of permissions. However, ensure that each function only gets the permissions it actually needs, to avoid over-privileging.

**What happens if I don't assign an execution role to a Lambda function?**

If you do not assign an execution role, the Lambda function will have no permissions to access any AWS resources. It will fail with an access denied error when trying to call any AWS API. The only way to avoid this is to use an execution role.

**Do execution roles expire?**

The role itself does not expire, but the temporary credentials obtained when assuming the role do. For Lambda, these credentials are valid for up to the function's timeout (max 15 minutes). The SDK automatically handles refreshing credentials for longer invocations.

**Can I use an execution role to access resources in another AWS account?**

Yes, this is called cross-account access. You create an execution role in one account with a trust policy that allows the service principal from the other account (or a role in that account) to assume it. Then you also configure a resource-based policy on the target resource (e.g., S3 bucket policy) that grants access to the cross-account role.

**What is the difference between an execution role and a task role in Amazon ECS?**

An execution role is used by the ECS container agent to pull container images and write logs to CloudWatch. A task role is used by the application running inside the container to access other AWS services. They are separate roles with different trust policies.

**How do I troubleshoot an 'AccessDenied' error from a Lambda function?**

Check the execution role's permissions policy to ensure it includes the necessary actions and resources. Also verify the trust policy allows the Lambda service. Use CloudTrail to see which API call was denied and by which role. Finally, check if there are any service control policies (SCPs) or resource-based policies that might be blocking the request.

## Summary

An execution role is a foundational security construct in AWS that allows services like Lambda and EC2 to securely access other AWS resources without hardcoded credentials. It is an IAM role with a trust policy that permits a specific service to assume it, and a permissions policy that defines what actions the role can perform. The role returns temporary credentials through AWS STS, which are automatically refreshed by the SDK, eliminating the need to manage long-term secrets.

Execution roles are critical for implementing the principle of least privilege, because you can grant only the specific permissions required for a task. They simplify operations by allowing permission updates without code changes, and they enable full auditability via CloudTrail. For IT professionals, mastering execution roles is essential for building secure, scalable, and maintainable cloud architectures.

In AWS certification exams, execution roles appear in scenario, configuration, and troubleshooting questions across multiple exams, including Solutions Architect, Developer, SysOps, and Security. The most common exam trap is confusing execution roles with resource-based policies or IAM users. To succeed, focus on understanding the relationship between the trust policy and permissions policy, and always apply least privilege. Remember that execution roles are your service's identity in the cloud, and they are the safest way to grant permissions to your applications.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/execution-role