- Signing in (root vs IAM users)
- Creating IAM users and granting console access
- Demonstrating the default-deny model
- Granting permissions (managed policies vs inline policies)
- Using groups to simplify permission management
- Creating and using roles (including sts:AssumeRole)
Never use the root user for daily operations. Keep root credentials secured, enable MFA, and only use root for account-level tasks that cannot be performed otherwise.
Signing in: root user vs IAM user
To sign in to the AWS Console go to aws.amazon.com/console and choose “Sign in to the Console”. There are two primary sign-in types:| Account type | Sign-in credentials | Typical use case |
|---|---|---|
| Root user | Email used to register the AWS account + root password (and MFA if enabled) | Account-wide management, billing, and actions that require root only |
| IAM user | Username and password created in IAM (or programmatic keys) | Daily operations with scoped permissions |
Opening IAM
Open the IAM console from the AWS Console search bar or from Recently visited services.
Create an IAM user
Navigate to IAM → Users → Add users. Provide a username and enable AWS Management Console access. You can let AWS auto-generate a password or set a custom one; optionally require the user to set a new password at first sign-in.
sanjeev and enable console access with a custom password. You can also skip attaching permissions at creation and assign them later.
- Add user to a group (user inherits group’s policies)
- Copy permissions from an existing user
- Attach policies directly to the user (inline or managed)
Signing in as an IAM user
From the Console sign-in, choose “IAM user” and provide the AWS account ID or alias, the IAM username, and the password. You can obtain the account ID from the root session → account dropdown.
Demonstrate default-deny: try to create an S3 bucket
IAM follows a default-deny security model: unless a permission is explicitly allowed, it is denied. For example, a user without s3:CreateBucket will fail when attempting to create an S3 bucket.
Grant permissions (must do this as root or an admin)
Sign back in as root (or as an admin user) to grant permissions. Open the user in IAM → Permissions → Add permissions. You can attach AWS managed policies (pre-built by AWS) or create custom policies.
Follow the principle of least privilege: prefer specific managed policies or custom policies over AdministratorAccess. Grant only the permissions required for the task and enable MFA for privileged accounts.
Use groups to simplify permission management
When multiple users need the same permissions, assign those permissions to a group rather than attaching policies to each user individually. Users inherit group policies automatically, and membership can be changed quickly.
admin, attach AdministratorAccess to it, and add your admin users to the group. The user Permissions tab will show the policy as “Attached from group admin.”
Read-only / monitoring group
Create amonitoring group for users who only need read-only access. Attach the managed policy ReadOnlyAccess to this group — it allows list and read operations (actions that start with Get, List, Describe, Search).
user1 and sanjeev to the monitoring group. Permissions are additive: a user can belong to multiple groups and will inherit the union of all group permissions.
admin and leave them only in monitoring, they will be prevented from destructive actions like s3:DeleteBucket:
Roles: temporary permissions and cross-entity access
Roles provide temporary credentials and are used for:- Short-lived elevation for a user (auditors, engineers with limited time-bound tasks)
- Service principals (EC2, Lambda, ECS tasks) needing AWS access
- Cross-account access where identities from another AWS account assume a role
- AWS service (for service principals like EC2)
- Another AWS account (for cross-account access)
- This AWS account (to allow IAM users/roles in your account to assume it)
AmazonS3FullAccess to the role.
AmazonS3FullAccess conceptually looks like:
S3FullAccess) and create it.
Restrict who can assume the role
A created role does not automatically let every user assume it. Two things must be in place:- The role’s trust policy must trust the principal (account, user, or role) that will assume it.
- The principal must have an IAM policy that allows the sts:AssumeRole action on the role resource ARN.
AssumeS3Access and attach it to the user or group that should be able to assume the role.
Assume the role (console)
To switch into the role from the console use the role’s “Switch role” link. The URL or link pre-fills the account and role name so the user can switch into the role and receive its permissions temporarily.
Summary
- Root user: Full account access. Protect it — enable MFA and avoid using it for daily tasks.
- IAM user: Starts with no permissions (default-deny); you must explicitly grant permissions via policies.
- Managed policies: Pre-built by AWS and useful for common roles (AdministratorAccess, AmazonS3FullAccess, ReadOnlyAccess).
- Groups: Attach policies to groups to manage many users at once — users inherit group permissions.
- Roles: Provide temporary credentials for short-term tasks or service-to-service access. To allow role assumption, grant sts:AssumeRole to specific principals and ensure the role’s trust policy trusts them.