serverless-application-model: Adding AmazonDynamoDBFullAccess policy doesnt affect role created by SAM

@quarryman So I was unaware that you need to define a Role explicitly for CodeStar. Since you are using CodeStar, the only option is it manage the Role yourself. This is due to CodeStar not being able to create IAM Roles.

Marking this as a bug though. We should be failing if both Role and Policies are being used in the same template.

I was having the same issue - I modified a default CodeStar project using Node/Lambda, but I could not get the Lambda function to access my DynamoDB table. I was able to fix the permission problem by adding the following line to the LambdaExecutionRole in the template.yml file. - arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess

Below is this section of the template.yml file with the line above inserted. This fixed my permission problem and allowed my lambda function to access by DynamoDB table.

LambdaExecutionRole:
    Description: Creating service role in IAM for AWS Lambda
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Sub 'CodeStar-${ProjectId}-Execution${Stage}'
      AssumeRolePolicyDocument:
        Statement:
        - Effect: Allow
          Principal:
            Service: [lambda.amazonaws.com]
          Action: sts:AssumeRole
      Path: /
      ManagedPolicyArns:
        -  arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
        -  arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess
      PermissionsBoundary: !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/CodeStar_${ProjectId}_PermissionsBoundary'

@quarryman This is because you are specifying both a Role and the Policies. If you look at the docs, specifically the description of Policies. It reads: “Names of AWS managed IAM policies or IAM policy documents or SAM Policy Templates that this function needs, which should be appended to the default role for this function. If the Role property is set, this property has no meaning.” SAM does not edit any CloudFormation specific resources, we will only edit, mutate, or modify resources that SAM creates.

The two options here are

1. Manage the Role yourself through the Role you are attaching to the Serverless::Function.
2. Remove the Role and let SAM generate the Role for you.

Unless you have a very specific use case and need to attach your own Role, my recommendation is to allow SAM to generate the Role for you. This will allow SAM to append other policies to the role as well. For example, if you needed to configure a DLQ, SAM would append the correct scoped permissions to the Role for you, but only if you allow SAM to generate it.

@sanathkr I think we should fail on these cases going forward. I have seen this a couple times now and while it is documented, I do not think the experience is very clear.