Identity and Access Management (IAM) Basics

Identity and Access Management (IAM) is a web service that helps you securely control access to Amazon Web Services (AWS) resources. AWS is a cloud computing platform provided by Amazon that lets you rent virtual servers, storage, and databases. IAM is free to use with any AWS account, and it is the first thing you set up when you create an account.

The core concept is simple: you have a central place to manage users, their passwords, and what they are allowed to do. Before cloud computing, companies managed access by giving each employee a shared username and password for a single server, or they used a physical key to a room with a computer. That worked poorly because if someone left the company, you had to change every password and re-key every lock. IAM solves this by giving you one central dashboard to control everything.

Let us break down the four main components you need to understand for the DVA-C02 exam.

The first component is the IAM User. An IAM User is a person or service that interacts with AWS. Each user has a unique name and a set of credentials, usually a password for the AWS web console or an access key for programmatic access (when a script or application makes requests without a human typing a password). You create a separate IAM User for every person in your organisation who needs to touch AWS. You never share users — each person gets their own. This is important because if you share one username and password, you cannot tell who did what in the audit logs. AWS records every action taken by every IAM User, so having individual users is essential for security auditing.

The second component is the IAM Group. An IAM Group is a collection of IAM Users. Groups make it easy to manage permissions for many people at once. For example, you might create a group called "Developers" and assign permissions that let them launch virtual servers and access logs. Then you add all the developer IAM Users to that group. When a new developer joins, you simply add them to the group, and they automatically get the right permissions. When a developer leaves, you remove them from the group. This is much faster than editing permissions on each user individually. Groups cannot contain other groups — they are flat collections of users only.

The third component is the IAM Policy. An IAM Policy is a document that defines permissions. It is written in a language called JSON (JavaScript Object Notation), which is a text format for storing data. A policy states whether to "Allow" or "Deny" specific actions on specific resources. For example, a policy might say: "Allow the 'ec2:RunInstances' action on all resources." EC2 is the AWS service that provides virtual servers. RunInstances is the action that launches a new server. The policy is then attached to a user, group, or role. Policies can be very granular — you can allow a user to start a server but not stop it, or allow reading a file from a storage bucket but not deleting it.

The fourth component is the IAM Role. An IAM Role is similar to a user in that it has permissions attached, but it is not a permanent identity — it does not have a username or password in the traditional sense. Instead, a role is assumed by someone or something that needs temporary permissions. For example, a virtual server running on EC2 might need to access a database. Instead of hardcoding a username and password into that server’s software (which is a security risk), you attach an IAM Role to the server. The server then automatically retrieves temporary security credentials from AWS and uses them to access the database. Roles are also used to give access to users from other AWS accounts or to allow services like AWS Lambda (a serverless compute service) to interact with other AWS services.

The simplest way to remember the difference between users, groups, roles, and policies is this: Users are identities for people. Groups are containers for users. Policies are permission documents. Roles are temporary identities for services or cross-account access.

IAM also enforces the principle of least privilege. This is a security best practice meaning you give someone only the permissions they absolutely need to do their job — no more, no less. For example, if a developer only needs to read logs, you do not give them permission to delete resources. The exam loves to test this principle.

Finally, IAM is global. Unlike many AWS services that are tied to a specific region (like US East or Europe), IAM settings apply across all regions. You create a user once, and that user can access resources in any region, unless you specifically restrict them.

In summary, IAM is the gatekeeper for your entire AWS account. It lets you create individual users, group them, define precise permissions with policies, and use roles for services. It is the first line of defence and the foundation of AWS security.

Imagine you are a junior developer at a small e-commerce company called "ShopFast". The company uses AWS to host its website, store product images in Amazon S3 (Simple Storage Service — a cloud storage service), and run a database in Amazon RDS (Relational Database Service — a managed database service). You are tasked with setting up a new employee’s access.

First, you log into the AWS Management Console as the root user. The root user is the email address you used to create the AWS account. Every AWS account has exactly one root user, and it has full, unrestricted access to everything. For security reasons, you should never use the root user for daily tasks — only for initial setup and billing emergencies. The first thing you do is create an IAM User for yourself and assign it admin permissions. Then you lock away the root user credentials.

Now, the new employee, Priya, joins as a developer. You open the IAM dashboard in AWS. You click "Add user" and type her name: "Priya". You select "Programmatic access" because she will use the AWS Command Line Interface (CLI) to run scripts, and also "AWS Management Console access" so she can log in to the web interface. You set a temporary password that she will change on first login.

Next, you need to give Priya permissions. Instead of creating a policy from scratch, you go to the "Groups" section and create a group called "Developers". You then attach the AWS managed policy called "AmazonS3FullAccess" which allows full control over S3 buckets. You also attach "AmazonRDSReadOnlyAccess" so she can query the database but not modify it. Then you add Priya to the Developers group. She now has exactly the permissions she needs — that is least privilege in action.

Later, your boss asks you to set up a backup server that automatically copies files from S3 to a second region. You could put the server's access key inside its configuration file, but that is insecure. Instead, you create an IAM Role called "BackupServerRole". You attach a policy to it that allows "s3:GetObject" and "s3:PutObject" on the bucket. You then launch an EC2 instance (virtual server) and attach the role to it. The server automatically gets temporary credentials via an AWS feature called Instance Metadata Service (IMDS) and uses those credentials to perform the backup. You never have to manage a password or key for that server.

Finally, you set up a password policy in IAM that requires passwords to be at least 12 characters long, contain a symbol, and expire every 90 days. You also enable Multi-Factor Authentication (MFA) — an extra layer of security where you need a code from a phone app in addition to your password — for all users who can access the production environment.

What you have done here is pure IAM in practice: creating users, grouping them, attaching policies, using roles for services, and applying security best practices. Every real-world AWS environment follows this pattern.