The first thing we should talk about is execution policies. These policies are attached to a service-linked role and define what AWS resources can be accessed by that role. The policy itself follows the same syntax as an IAM policy and works the same way. When creating a Lambda function, you're given a choice of attaching an existing IAM role or creating a new one. You can always modify the configuration to use a different role after creating the function, if you like.

When attaching a role to a Lambda function, we are defining exactly what AWS resources the function code has access to while it is running. To see an example of an execution policy, we need to create a role.

To create an execution role, perform the following steps:

1. Log in to your AWS account and head over to the IAM console.
2. Click on Roles | Create role.
3. Now, we need to choose which service will be using the role. Choose Lambda and click Next. 

In the background, this sets up a trust relationship that gives the Lambda service permission to use the role. This relationship is reflected in a trust policy document, represented in JSON, where a Principal is explicitly allowed to perform an action. The policy document for that relationship will look similar to the following code, and you will be able to find it in the role configuration after creating the role:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "lambda.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
  }]
}

4. Next, we need to grant the role some permissions so that our Lambda function will be able to access AWS resources during execution. You can update these permissions any time without a new deployment of the function. Depending on the resources you want to grant your function access to, there might be a predefined managed policy that you can use. For example, if your function needs to call an endpoint in the API gateway, you might use the AmazonAPIGatewayInvokeFullAccess policy. On the other hand, since you might have very specific requirements for the policy, you can create your own and provide the JSON yourself. The following is an example of an execution policy document that would allow you to read records from a DynamoDB stream and also write log output to CloudWatch Logs. Choose a policy to use and click Next:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "dynamodb:DescribeStream",
      "dynamodb:GetRecords",
      "dynamodb:GetShardIterator",
      "dynamodb:ListStreams",
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:PutLogEvents"
    ],
    "Resource": "*"
  }]
}

This is an IAM policy document that can be attached to a role. It states what API actions (for example, GetRecords in DynamoDB) the role is allowed or not allowed to perform, and which resources it is allowed to perform the actions against.

The preceding access control policy document states that the role attached to the function can list and read DynamoDB streams, as well as also set up a location in CloudWatch Logs to write log output into. This would be a suitable policy to attach if you were reading records from a DynamoDB stream event source mapping.

5. Optionally, you can tag your role with a key-value pair. Let's skip this and click Next.
6. Lastly, name your role and click Create role.

This will create a role that you can attach to a new or existing Lambda function. The next section will explain how we grant invocation permissions to other AWS resources so that they can trigger functions.