Resource-Based Policies vs Identity Policies

Identity-based policies are JSON policy documents attached to an IAM entity: a user, group, or role. They define what actions that entity is allowed or denied on which AWS resources. For example, an IAM policy attached to a developer role might allow s3:GetObject on a specific bucket. The policy says: "This role can read objects from this bucket." The policy is evaluated when the entity makes a request. The key characteristic is that the policy is tied to the identity, not the resource. Identity-based policies can be managed (created and attached by you) or inline (embedded directly in the user/group/role). The default is an implicit deny: if no policy explicitly allows an action, it is denied. An explicit deny in any policy overrides any allow.

Resource-based policies are JSON policy documents attached directly to an AWS resource, such as an S3 bucket, SQS queue, SNS topic, Lambda function, or KMS key. They specify which principals (AWS accounts, IAM users, roles, or federated users) can perform what actions on that resource. For example, an S3 bucket policy might grant s3:GetObject to an IAM role in another account. The policy says: "This bucket allows that role to read its objects." Resource-based policies are evaluated when the resource receives a request. They allow cross-account access without needing to create IAM roles. The resource owner controls access directly. Resource-based policies can also include conditions based on source IP, VPC, or time.

When an IAM principal makes a request to an AWS service, the authorization engine evaluates all applicable policies. The evaluation logic is: 1. If there is an explicit deny in any policy (identity-based or resource-based), the request is denied. 2. If there is an explicit allow in either the identity-based policy or the resource-based policy (or both), the request is allowed. 3. If neither policy explicitly allows the action, the default is an implicit deny.

This is often summarized as "allow by default" combined with "deny overrides." However, the default is actually deny; an allow must exist somewhere. The key point is that an allow from either the identity policy OR the resource policy is sufficient. This is crucial for cross-account access: the resource-based policy can allow a principal from another account, even if that principal's own identity policy does not explicitly allow the action (though the principal's identity policy must not deny it).

There are two primary ways to grant cross-account access: - Resource-based policy: Attach a policy to the resource that specifies the external principal. This is simpler and does not require the external account to create a role. Example: S3 bucket policy granting s3:GetObject to an IAM user in another account. - Role-based access: The resource owner creates an IAM role that the external principal can assume. The external principal's identity policy must allow sts:AssumeRole. This is more flexible but requires the external account to manage role assumption.

The exam frequently asks which method to use for a given scenario. Resource-based policies are preferred when the resource service supports them (S3, SQS, SNS, Lambda, KMS, etc.) and you want to grant access to many users across accounts without managing roles. Role-based access is required when the resource does not support resource-based policies (e.g., EC2, RDS) or when you need fine-grained control over session permissions.

Not all AWS services support resource-based policies. Common services that do: - Amazon S3 – bucket policies - Amazon SQS – queue policies - Amazon SNS – topic policies - AWS Lambda – function policies (resource-based) - AWS KMS – key policies - Amazon S3 Glacier – vault policies - Amazon API Gateway – resource policies - AWS Secrets Manager – secret policies (resource-based) - Amazon ECR – repository policies

Services that do NOT support resource-based policies (require role-based access):

Both identity-based and resource-based policies use the same JSON structure with the following elements: - Version – policy language version, always "2012-10-17" - Statement – array of statements, each containing: - Effect – "Allow" or "Deny" - Action – one or more AWS actions (e.g., "s3:GetObject") - Resource – ARN of the resource (in identity policies) or "*" (in resource policies, where the resource is implicit) - Principal – only in resource-based policies; specifies who is allowed/denied (e.g., "AWS": "arn:aws:iam::123456789012:user/Alice") - Condition – optional conditions

The Principal element is exclusive to resource-based policies. It specifies the entity that is allowed or denied access. Values can be: - "AWS" – an IAM user, role, or AWS account (e.g., "arn:aws:iam::123456789012:root" for the entire account) - "Service" – an AWS service (e.g., "lambda.amazonaws.com") - "Federated" – a federated identity provider - "*" – everyone (anonymous access)

In identity-based policies, the principal is implicit (the entity the policy is attached to).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/CrossAccountRole"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

The AWS authorization engine evaluates policies in the following order: 1. Identity-based policies (user, group, role) 2. Resource-based policies 3. IAM permissions boundaries 4. Organizations service control policies (SCPs) 5. Session policies (for assumed roles)

If any policy explicitly denies the action, the request is denied. Otherwise, if any policy explicitly allows the action, the request is allowed. If no policy explicitly allows, the request is implicitly denied.

Permissions boundaries are an advanced feature that sets the maximum permissions an identity-based policy can grant. They are not resource-based policies. They are attached to an IAM user or role and define the maximum set of actions that the entity can perform, even if its identity policy allows more. The exam may test the interaction between boundaries and resource-based policies: a resource-based policy cannot grant permissions that exceed the boundary of the principal's role.

SCPs are used in AWS Organizations to set permission guardrails for accounts. They are not resource-based policies; they are identity-based policies applied at the organization level. SCPs restrict what actions the account's IAM entities can do, but they do not grant permissions. Resource-based policies are still evaluated after SCPs.

A large enterprise has multiple AWS accounts: a central data lake account and several analytics accounts. The data lake team wants to allow analysts in the analytics accounts to read specific prefixes in an S3 bucket. The simplest solution is to attach a bucket policy (resource-based) to the data lake bucket that grants s3:GetObject to the IAM roles in the analytics accounts. This avoids the need for the analytics accounts to assume a role in the data lake account, reducing complexity. The bucket policy includes a condition to restrict access to specific VPC endpoints for security. Misconfiguration often occurs when the principal ARN is incorrect (e.g., using the account ID instead of the role ARN) or when the bucket policy does not include the s3:ListBucket action for the prefix, causing "Access Denied" errors when listing objects. Performance is not an issue because S3 bucket policies are evaluated at request time with minimal overhead.

A company uses S3 to store images and a Lambda function to generate thumbnails. The S3 bucket is configured to trigger the Lambda function on new object creation. To allow S3 to invoke the Lambda function, the company attaches a resource-based policy to the Lambda function (also called a function policy) that grants lambda:InvokeFunction to the S3 service principal (s3.amazonaws.com). This is more secure than making the Lambda function public. A common mistake is forgetting to add the condition that restricts invocation to the specific bucket ARN, which could allow any S3 bucket in the same account to invoke the function. The function policy also includes the source account ID to prevent cross-account abuse. At scale, with thousands of invocations per second, the Lambda resource policy evaluation adds negligible latency.

A microservices architecture spans two AWS accounts: Account A runs a producer service, and Account B runs a consumer service. The producer sends messages to an SQS queue in Account B. To allow Account A to send messages, Account B attaches a queue policy (resource-based) that grants sqs:SendMessage to the IAM role used by the producer in Account A. The queue policy also includes a condition to restrict the source IP range. The producer's IAM role does not need to explicitly allow sqs:SendMessage in its identity policy; the queue policy alone is sufficient. However, if the producer's identity policy has an explicit deny on sqs:SendMessage, the request will fail. A common pitfall is not including the sqs:SendMessage action in the queue policy, leading to "Access Denied" errors. For high-throughput queues (thousands of messages per second), the queue policy evaluation is a minor overhead.