IAM Roles and Policies

An IAM role has permissions, just like a user — but nobody "logs in" to a role permanently. Instead, an identity (a person, an AWS service, or an application) assumes the role temporarily and receives short-lived, automatically-expiring credentials for the duration of that session.

This is exactly the gap Lesson 2 left open for workloads. Some concrete examples:

• An application running on an EC2 server that needs to read from an S3 bucket is given a role — not access keys hardcoded into its configuration. The EC2 service assumes that role on the application's behalf.
• A Lambda function that writes logs is given a role with just enough permission to write to the specific log destination it needs.
• An administrator who normally works with limited permissions can assume a more privileged role temporarily, only when a specific elevated task actually requires it — rather than holding that elevated access permanently.

In every case, the credentials involved are temporary. If they leak, they stop being useful on their own relatively quickly — a meaningfully smaller risk than a long-lived access key sitting in a config file indefinitely.

Whether it's attached to a user, a group, or a role, a policy is what actually defines permissions. A policy is a JSON document that states which actions are allowed or denied, and on which resources.

Here's a small, safe example — granting read-only access to objects inside one specific, fictional training bucket:

IAM evaluates every applicable policy for a request, and the result follows one important rule: an explicit Deny always overrides an Allow, no matter how many other policies grant the permission. If one policy grants access to a resource and a separate policy explicitly denies it, the request is denied.

This lesson only introduces the concept — full policy evaluation order involves more nuance than fits here — but the practical habit worth taking away is: an explicit Deny is a deliberate, strong statement, not a suggestion that other policies can talk their way around.

Below is a policy you will see referenced in real-world AWS discussions constantly — and it's included here specifically so you can recognize and avoid it, not copy it.

Effect "Allow" grants the permission. Action "s3:GetObject" allows only reading an object's contents — not listing the bucket, not writing, not deleting. Resource narrows this to one specific, fictional bucket (quarrydev-training-bucket) rather than every bucket in the account. Change any one of these three lines and the meaning of the whole policy changes.

This policy allows every action on every resource in the account — effectively administrator-level access. It is shown here only so you can recognize it and understand why it's dangerous: it violates least privilege completely, and if the identity holding it is ever compromised, the attacker inherits full account access, not just the narrow slice that identity actually needed to do its job.