Skip to main content
In this lesson we cover IAM — Identity and Access Management — the AWS service that centralizes authentication and authorization across your account. Authentication verifies who a caller is (a user, service, or application). Authorization determines what that authenticated identity is allowed to do (for example, creating an Amazon S3 bucket or terminating an Amazon EC2 instance).
A presentation slide titled "Understanding Authentication and Authorization" showing two rounded cards labeled "01 Authentication" and "02 Authorization" with circular icons and a plus sign between them. The design uses soft gradient icons and a clean, minimalist layout.
  • Authentication: proves the identity of a user or service.
  • Authorization: grants or denies permissions that control actions on AWS resources.
Different people and systems need different access. An administrator may need broad privileges, while a monitoring team should only have read access. IAM gives you a single control plane to manage identities and permissions, which improves security, auditing, and compliance and lets you enforce the principle of least privilege.
A slide titled "Identity and Access Management (IAM)" showing four numbered colored tiles representing: 1) Enhanced Security, 2) Centralized Management, 3) Compliance and Auditing, and 4) Least Privilege Principle. Each tile has a simple white icon illustrating the respective concept.
When granting access, apply least privilege: give teams only the permissions required for their tasks. For example, if a team works only with AWS RDS, grant RDS permissions only — avoid granting S3 or other unrelated access. Key IAM identity types Creating access in AWS
  • IAM user — represents an identity that can authenticate to AWS. Users may have console, programmatic (API/SDK), or both types of access.
  • By default, a new IAM user has no permissions; you must explicitly grant them.
  • Permissions are assigned with IAM policies: JSON documents that describe allowed or denied actions on specific resources.
Use groups to simplify permission management. Attach policies to a group once and all members inherit those permissions. Users can belong to multiple groups and receive the union of those group policies.
The slide titled "IAM – Policy Inheritance" shows user cards for a Dev Group (Smith and Clark) and an Ops Group (Jonas), with a dotted "Audit Group" overlay covering Clark. Each user is shown as a colored circular avatar with a small policy/clipboard icon.
IAM policy basics Policies use JSON and follow a predictable structure. A policy contains the policy language Version and an array of Statement objects. Each statement defines the effect, the action(s), the resource(s), and optional conditions. Example policy that allows listing a bucket and getting objects from a single S3 bucket:
Policy field breakdown Explanation of the example
  • Version: identifies the policy language version (use 2012-10-17).
  • Statement: an array of one or more rules; here there’s a single statement.
  • Effect: "Allow" grants the listed actions.
  • Action: permits s3:ListBucket (list the bucket) and s3:GetObject (retrieve objects).
  • Resource: restricts those actions to the specified bucket and its objects.
This example grants only list and read access for the single bucket; it does not permit deletes or access to other buckets. Policy assignment and evaluation
  • Policies can be attached to users, groups, or roles.
  • Managed policies (AWS-managed or customer-managed) are reusable across identities. Inline policies are embedded directly on a single identity.
  • Policy evaluation rules:
    • Explicit Deny always overrides Allow.
    • If no statement allows an action, the default is Deny.
    • AWS evaluates all applicable policies (identity-based, resource-based, permissions boundaries, SCPs) to determine the final decision.
When studying for the AWS Solutions Architect Associate Certification, focus on IAM fundamentals: authentication vs authorization, users, groups, roles, policies, and the principle of least privilege. Many exam questions hinge on understanding how policies are evaluated and how access is granted or denied.
Always follow the principle of least privilege: grant only the permissions required, and prefer managed policies or role-based access over broad, long-lived credentials.
Links and references

Watch Video