Become an AWS pro by understanding IAM, learning to write policies, and configuring access. Get hands-on with realistic examples, developed by AWS Solution Certified Architects. No setup, no cleanup, no hassle.

A Practical Guide to AWS IAM by Tamás Sallai_468 x 60 .png

This course is about how AWS IAM works and how to write policies to control access in an AWS account. In this course, you will learn how AWS APIs work, explore different parts of the requests made to the APIs and elaborates on how access is determined. Additionally, you will dive into how to configure access inside AWS by describing the policy structure and the 5 policy types AWS supports.

Further, you will become familiar with how the elements in the request and the policies fit together. You will also determine whether the operation is allowed or denied by demonstrating through several step-by-step realistic examples that show exactly how IAM evaluates access, thus providing templates for how to apply these protections to AWS environments.

Lastly, this course offers you some practical tips on how to secure an account both as an administrator and as a developer. It explains the best practices and the usual pitfalls of AWS security.

AWS Security Fundamentals: A Practical Guide to AWS IAM

In the S3 bucket example, either the identity- or the resource-based policy is enough to give access. This is the case for most resource types, but there are exceptions. An **IAM role's trust policy** needs to allow the action explicitly, it's not enough that the identity policy allows it.

## How can resource policy allow an operation?
The resource policy can allow an operation in two ways. It can allow the user explicitly, such as `"Principal": "<iam>/user"`. In this case, the operation is allowed and there is no need for an identity policy. This is how it works for less strict resources.

The other way is to allow the *account* in the form of `"Principal": "arn:aws:iam::<accountid>:root"`. This delegates access control to the identity policies to decide. If a trust policy does not allow either the requesting identity or the account then the request is denied.

This is how the policy evaluation flow looks like for these resources:


In the S3 bucket example, either the identity- or the resource-based policy is enough to give access. This is the case for most resource types, but there are exceptions. An **IAM role's trust policy** needs to allow the action explicitly, it's not enough that the identity policy allows it.

# How can resource policy allow an operation?
The resource policy can allow an operation in two ways. It can allow the user explicitly, such as `"Principal": "<iam>/user"`. In this case, the operation is allowed and there is no need for an identity policy. This is how it works for less strict resources.

The other way is to allow the *account* in the form of `"Principal": "arn:aws:iam::<accountid>:root"`. This delegates access control to the identity policies to decide. If a trust policy does not allow either the requesting identity or the account then the request is denied.

This is how the policy evaluation flow looks like for these resources:


Learn about some restricted resources in which IAM role’s trust policy is required to allow actions explicitly.

Introduction

Access Control Basics

User Management using IAM

IAM Policies

Request Evaluation Flow and Examples

Role Management Using Identity and Access Management (IAM)

How to Secure an AWS Account

Conclusion

Appendix

Restricted resources

How can resource policy allow an operation?