AWS IAM – Identity & Access Management

1. What IAM is — Users and Groups

IAM (Identity and Access Management) is the service that decides who is who and who may do what in your AWS account. It is a Global service — you create a user once and it works in every Region (see Getting Started with AWS).

When you open an AWS account, AWS creates a root account for you by default. It holds absolute power over everything, and the rule is that it should not be used and should not be shared. Instead, you create an IAM User for each real person in your organization, and collect those users into Groups.

Two rules about groups that questions like to probe:

• Groups only contain users, not other groups — there is no group nesting.
• A user does not have to belong to a group, and a user can belong to multiple groups at once.

Real-world example

In the diagram on the slide: Alice, Bob and Charles are in the Developers group; David and Edward are in Operations; Alice and David are simultaneously in the Audit Team group; and Fred belongs to no group at all. Fred is still a perfectly valid IAM user — his permissions simply have to be attached to him directly.

2. Permissions and policies

Permissions in IAM come from policies: JSON documents you assign to a user or to a group, spelling out exactly which actions that identity may and may not take.

The governing rule when you write policies on AWS is the least privilege principle: do not give a user more permissions than they actually need.

A sample policy, granting read-only visibility into EC2, Elastic Load Balancing and a handful of CloudWatch APIs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "elasticloadbalancing:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:ListMetrics",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

Note the Describe* wildcards: this policy lets the holder look at resources without changing anything, which is the classic shape of a read-only role.

Policy inheritance

Policies can be attached in two places, and that is where “inheritance” comes from:

• Attach a policy to a group, and every user in that group picks it up. Because a user may sit in several groups, they accumulate the permissions of all of them — Alice in both Developers and Audit Team gets both sets.
• Attach a policy directly to a single user, and it is called an inline policy. That is how someone like Fred, who belongs to no group, gets permissions at all.

The practical takeaway: prefer group policies, because they scale with headcount; keep inline policies for the genuine one-off.

3. The structure of an IAM policy

Every IAM policy is built from the same fields. The exam expects you to read one and say what it does.

At the document level:

• Version — the policy language version. Always include 2012-10-17.
• Id — an identifier for the policy (optional).
• Statement — one or more individual statements (required).

Inside each statement:

• Sid — an identifier for that statement (optional).
• Effect — whether the statement allows or denies access: Allow or Deny.
• Principal — the account, user or role the policy applies to.
• Action — the list of actions the statement allows or denies.
• Resource — the list of resources those actions apply to.
• Condition — conditions under which the statement is in effect (optional).

Exam tip

Version, Effect, Action and Resource are the fields you will see in almost every policy question; Sid, Id and Condition are optional and can be absent. Version is a date string that identifies the policy language, not the date you wrote the document — do not read 2012-10-17 as an expiry.

4. Password policy

Strong passwords mean a more secure account, so AWS lets you define an account-wide password policy. The controls it offers:

• Set a minimum password length.
• Require specific character types: uppercase letters, lowercase letters, numbers, and non-alphanumeric characters.
• Allow all IAM users to change their own passwords.
• Require users to change their password after some time — password expiration.
• Prevent password re-use.

5. Multi Factor Authentication (MFA)

Your users can reach the account and can potentially change configuration or delete resources, so both the root account and your IAM users are worth protecting with more than a password.

MFA = a password you know + a security device you own. The main benefit follows directly from that definition: if the password is stolen or guessed, the account is still not compromised, because the attacker does not hold the device.

MFA device options on AWS

Device	Notes
Virtual MFA device	Google Authenticator or Authy, both phone-only; one phone can hold the tokens of several accounts
Universal 2nd Factor (U2F) Security Key	YubiKey by Yubico, a third-party device; one key can cover several root and IAM users
Hardware Key Fob MFA Device	A third-party fob, from Gemalto
Hardware Key Fob MFA Device for AWS GovCloud (US)	A third-party fob, from SurePassID

Exam tip

Two details separate the options in question stems: a virtual MFA device such as Authy can hold multiple tokens on one phone, while a single U2F security key can serve multiple root and IAM users. And when a stem mentions GovCloud (US), the hardware key fob comes from SurePassID, not Gemalto.

6. Three ways to access AWS

There are exactly three entry points, and each is protected differently:

Access method	Protected by
AWS Management Console	Password + MFA
AWS Command Line Interface (CLI)	Access keys
AWS Software Developer Kit (SDK), for code	Access keys

Access keys themselves are generated through the AWS Console, and users manage their own access keys. Treat them exactly like a password: they are secret, and you do not share them. The mental mapping is simple:

• Access Key ID is roughly the username — for example AKIASK4E37PV4983d6C.
• Secret Access Key is roughly the password — for example AZPN3zojWozWCndIjhB0Unh8239a1bzbzO5fqqkZq.

(Those two are the deck’s deliberately fake samples; never publish real ones.)

Exam tip

Console access is protected by a password and MFA; programmatic access (CLI and SDK) is protected by access keys. If a question describes a script or an application authenticating, the answer involves access keys or — better, as section 9 shows — an IAM role, never a console password.

7. The AWS CLI

The AWS CLI is a tool that lets you interact with AWS services by typing commands into your command-line shell. What matters about it:

• It gives you direct access to the public APIs of AWS services.
• You can write scripts with it to manage your resources.
• It is open source, at https://github.com/aws/aws-cli.
• It is an alternative to the AWS Management Console — anything you can click, you can generally type.

8. The AWS SDK

The AWS Software Development Kit is the same capability, but shaped for code rather than a shell:

• It is a set of language-specific APIs — libraries you pull into your project.
• It lets you access and manage AWS services programmatically.
• It is embedded inside your application, rather than run as a separate command.

The SDK families the deck lists:

• SDKs: JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++.
• Mobile SDKs: Android, iOS and others.
• IoT Device SDKs: Embedded C, Arduino and others.

One connecting fact worth remembering: the AWS CLI is itself built on the AWS SDK for Python.

9. IAM Roles for services

Some AWS services need to perform actions on your behalf — an EC2 instance that has to read from a bucket, for instance. You cannot give a service a password, so instead you grant permissions to the service through an IAM Role.

The pattern is: create a role, attach the policies it needs, and assign that role to the service, which then acts with exactly those permissions.

Common roles:

• EC2 Instance Roles
• Lambda Function Roles
• Roles for CloudFormation

Real-world example

An EC2 instance (a virtual server) needs to call an AWS API. Rather than copying your access keys onto the box — where anyone who gets shell access can read them — you attach an EC2 Instance Role. The instance receives permission to access AWS, and nothing secret is stored on disk.

10. IAM’s two security tools

IAM ships two auditing tools, and the exam distinguishes them purely by scope:

Tool	Scope	What it shows
IAM Credentials Report	Account-level	Lists all the account’s users and the status of their various credentials
IAM Access Advisor	User-level	Which services a user has been granted access to, and the last time each of those services was actually used

Access Advisor is the one you use to tighten things up: if a user was granted access to a service and has never touched it, that is a permission you can revise away.

Exam tip

Remember the scope pairing. Credentials Report = account-level, all users, credential status. Access Advisor = user-level, which services were actually used and when. A stem asking “which users still have unused permissions” points at Access Advisor; one asking “give me the status of every credential in the account” points at the Credentials Report.

11. Guidelines and best practices

The deck closes the section with a checklist that doubles as an answer key for a lot of “which of these is the recommended practice” questions:

• Don’t use the root account except for the initial AWS account setup.
• One physical user = one AWS user. No shared logins.
• Assign users to groups and assign permissions to groups, rather than to individuals.
• Create a strong password policy.
• Use and enforce MFA.
• Create and use Roles to give permissions to AWS services.
• Use Access Keys for programmatic access (CLI and SDK).
• Audit permissions with the IAM Credentials Report and IAM Access Advisor.
• Never share IAM users or access keys.

Quick recap

Concept	What to remember for the exam
IAM	Global service; a user works across all Regions
Root account	Created by default; do not use it beyond account setup, never share it
Users	Mapped to a physical person; has a password for the AWS Console
Groups	Contain users only — no nested groups; a user may be in several, or none
Policies	JSON documents describing permissions for users or groups; apply least privilege
Policy fields	Version (always 2012-10-17), Id, Statement; per statement Sid, Effect, Principal, Action, Resource, Condition
Roles	Permissions for EC2 instances and other AWS services, not for people
Security	MFA + password policy; MFA = password you know + device you own
MFA devices	Virtual (Google Authenticator, Authy), U2F key (YubiKey), hardware key fob (Gemalto; SurePassID for GovCloud US)
AWS CLI	Manage AWS from the command line; open source; built on the Python SDK
AWS SDK	Manage AWS from a programming language, embedded in your application
Access Keys	Access AWS via CLI or SDK; Access Key ID ≈ username, Secret Access Key ≈ password
Audit	IAM Credentials Report (account-level), IAM Access Advisor (user-level)