You already know that policies are the documents that define permissions in AWS. But there are two ways to apply them, depending on where you attach them: to an identity or to a resource. Understanding the difference will help you read and write permissions correctly, and solve the classic mystery of “why isn’t this permission working?”

An IAM policy is a JSON document. Its central piece is the statement, which answers:

• Effect: Allow (permit) or Deny (deny).
• Action: what can be done (s3:GetObject = read S3 objects).
• Resource: on which resource (identified by its ARN, the unique identifier of any resource in AWS).

This policy says: “Allow the action read objects on the objects in the informes-2026 bucket.” Don’t worry about memorizing the syntax; the important thing is to understand the concept.

They are attached to an identity: a user, a group, or a role. They answer the question:

“What can THIS identity do?”

Example: You attach a policy to the user María that says “she can read from the informes-2026 bucket.” The permission travels with María: wherever she acts, she can read that bucket.

This is the most common way. When you grant permissions to your users and roles, you normally use identity-based policies.

They are attached to the resource itself: an S3 bucket, an SQS queue, a Lambda function… They answer the question:

“Who can access THIS resource?”

Example: You attach a policy to the informes-2026 bucket that says “the partner company’s account can read my objects.” The permission travels with the bucket: it defines who can enter it.

You already saw an example in Chapter 5: S3 bucket policies are resource-based policies.

Building Analogy:

• An identity-based policy is like what your employee card can open. You carry it with you; it defines which doors you can enter.
• A resource-based policy is like the list of authorized people posted on the door of a specific room. It defines who can enter that particular room.

Sometimes, to enter a room, both must match: your card must allow you to open that door and your name must be on the room’s list.

The star case for resource-based policies is cross-account access: when someone from another AWS account needs to access something of yours, the resource-based policy is what allows it, because it applies to the resource regardless of which account the accessor comes from.

When someone tries to do something, AWS evaluates all applicable policies (identity and resource-based) with these rules, in this order:

1. By default, everything is denied. If nothing allows it, it’s denied.
2. An explicit Allow grants the permission (it can come from the identity or resource policy).
3. An explicit Deny ALWAYS wins. If any policy says “deny,” it’s denied, even if another says “allow.”

Mental rule: “Deny beats Allow, and without Allow there is no permission.” This rule solves almost all AWS permission mysteries.

Typical mystery example: “I gave María permission to read the bucket, but she can’t.” Possible causes: there’s an explicit Deny somewhere (which wins), or the resource policy (bucket) doesn’t include her, or the Allow is missing from her identity. Knowing the evaluation logic, you know where to look.

To finish, two ways to organize policies (not to be confused with identity/resource):

• Managed: reusable policies you attach to multiple identities. AWS offers many predefined ones (like AmazonS3ReadOnlyAccess), and you can create your own. Recommended because they’re reusable and easy to maintain.
• Inline: policies written directly inside a single identity. Useful for very specific permissions for a single user or role.

• A policy defines permissions with Effect (allow/deny), Action (what), and Resource (on what, via ARN).
• Identity-based: attached to a user/group/role → “what can this identity do?” It’s the most common.
• Resource-based: attached to the resource (bucket, queue…) → “who can access this resource?” Key for cross-account access.
• Evaluation logic: everything denied by default, an Allow grants, and an explicit Deny always wins.
• “Deny beats Allow, and without Allow there is no permission” solves most doubts.

In the next subchapter we’ll look at two pillars of access security: multi-factor authentication (MFA) and temporary credentials (STS).