Core Services
IAM — Users, Roles, and Policies
AWS Identity and Access Management (IAM) is the central security service that orchestrates authentication and authorization across the entire cloud environment. It matters because it implements the principle of least privilege, ensuring that every service or user possesses only the minimum necessary permissions to perform their specific tasks. You reach for IAM whenever you need to secure resources, manage access for developers, or enable service-to-service communication.
Understanding IAM Users and Identity
An IAM User represents a distinct person or application that interacts with AWS. Think of an IAM user as a digital identity that needs long-term credentials to prove who they are. When you create a user, you are establishing an entity that can hold security credentials like access keys or console passwords. However, simply creating a user does not grant them any ability to perform actions; by default, all AWS accounts adhere to a 'deny by default' posture. You must explicitly attach permissions to the user, either directly or via groups, to enable activity. This granular control is essential because it prevents accidental over-provisioning. Users are best suited for human operators who need consistent, long-term access, but for automated services, we prefer using temporary security tokens provided by roles, which limits the blast radius if credentials are leaked.
{
"UserName": "cloud_admin",
"Path": "/staff/",
"Tags": [{"Key": "Role", "Value": "Administrator"}]
# This represents the identity object definition
}The Anatomy of IAM Policies
Policies are the JSON documents that define 'what' an identity is allowed to do. AWS evaluates these policies using a specific logic: if there is an explicit deny, it overrides all allows, and if no explicit allow is found, the default is to deny. A policy consists of statements including Effect (Allow/Deny), Action (the API call, e.g., s3:ListBucket), and Resource (the specific ARN). The power of policies lies in their ability to use wildcards and conditions, allowing you to define access based on time, IP address, or even whether a request uses encryption. By decoupling the identity from the permission, you can update a single policy and have that change propagate to all identities attached to it, making global security posture adjustments incredibly efficient and auditable.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::my-secure-bucket/*"]
}]
# Defines the permission scope for the identity
}IAM Roles: The Power of Delegation
An IAM Role is a temporary identity that does not have long-term credentials like passwords or keys associated with it. Instead, roles are assumed by entities that need temporary access to perform actions. This is the foundation of secure AWS architecture because it eliminates the need to store secret keys on servers or in application code. When an entity assumes a role, AWS provides it with temporary security tokens that expire automatically. This is vastly superior to long-term user credentials because, even if the temporary credentials are compromised, they become useless after a short window of time. Roles are the standard for service-to-service communication, such as allowing an EC2 instance to read from a database without hardcoding any sensitive security keys inside the instance itself.
{
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}]
}
# Defines which service can adopt this identity
}Trust Relationships and Policy Evaluation
A Trust Relationship is the critical component that defines who or what is permitted to assume a specific role. While a permission policy defines what an identity can do, the Trust Policy defines the 'who.' It acts as a gatekeeper. By inspecting the Principal element in the trust policy, AWS determines if the requesting entity has the right to assume the identity in question. This separation allows for cross-account access: you can allow a user in a completely different AWS account to assume a role in your current account by explicitly listing their account ID in the trust policy. This enables secure, audited collaboration across complex environments without sharing physical credentials, strictly adhering to the principle of least privilege through controlled, temporary delegation of rights.
{
"Principal": {"AWS": "arn:aws:iam::123456789012:root"},
"Action": "sts:AssumeRole"
# Determines who is trusted to trigger this role
}Implementing Least Privilege Architecture
Implementing least privilege means constantly reviewing and shrinking the permissions granted to every entity. Because AWS adds new services and API calls regularly, a static 'AdministratorAccess' policy is a major security risk. Instead, you should use managed policies for common tasks but transition toward customer-managed policies that contain only the specific API calls required for the job. Use the IAM Access Analyzer to identify unused permissions, and always prefer roles over users for compute workloads. By enforcing MFA for human users and using IAM roles for services, you minimize the risk surface. Security in the cloud is an iterative process; you must start with a base deny-everything posture and only layer on permissions that are explicitly required for the application to function correctly in production.
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "false"}}
# Enforces MFA for all actions globally
}Key points
- AWS follows an implicit deny by default for all actions.
- IAM Users should be reserved for human operators needing console or CLI access.
- IAM Roles provide temporary credentials, making them safer than static user keys.
- Policies are JSON documents that define explicit allows and denies.
- An explicit deny in any policy overrides any other allow present.
- Trust policies determine which entities are allowed to assume a role.
- Least privilege is achieved by granting only the minimum necessary permissions.
- The Principle of Least Privilege reduces the blast radius of potential security incidents.
Common mistakes
- Mistake: Granting 'AdministratorAccess' to every IAM user. Why it's wrong: This violates the Principle of Least Privilege and creates a massive security risk if a user's credentials are compromised. Fix: Define custom IAM policies that grant only the specific actions required for the user's role.
- Mistake: Attaching IAM Policies directly to users. Why it's wrong: This makes managing permissions at scale difficult as the number of users grows. Fix: Attach policies to IAM Groups and add users to those groups to manage permissions centrally.
- Mistake: Sharing IAM User credentials between multiple individuals. Why it's wrong: It makes auditing impossible and violates compliance standards. Fix: Create individual IAM users for each person or use AWS IAM Identity Center (SSO).
- Mistake: Misunderstanding that an IAM Role is for users. Why it's wrong: IAM Roles are intended for temporary security credentials for services (like EC2) or cross-account access, not for permanent user login. Fix: Use IAM Users for human authentication and IAM Roles for service and task-based authorization.
- Mistake: Using Inline Policies for everything. Why it's wrong: Inline policies cannot be reused across multiple entities, leading to duplication and management overhead. Fix: Use Managed Policies (AWS managed or Customer managed) to ensure consistency and easier updates.
Interview questions
What is an AWS IAM User, and when should it be used?
An AWS IAM User is an identity created within an AWS account that represents a person or service that interacts with AWS resources. You should use IAM Users primarily for long-term programmatic access using access keys or for individuals who need to log in to the AWS Management Console. However, AWS best practice now emphasizes using AWS IAM Identity Center instead of long-term IAM user credentials, reserving IAM users mainly for specific application-based needs.
Can you explain the purpose of an IAM Role and how it differs from an IAM User?
An IAM Role is an identity that does not have long-term credentials like a password or access key. Instead, it is intended to be assumed by anyone who needs it, providing temporary security credentials. The primary difference is that a user is a permanent identity, whereas a role is a set of permissions that can be assumed. For example, you attach a role to an EC2 instance so that applications running on that instance gain temporary permissions without requiring you to store permanent credentials inside your code.
What are IAM Policies and how do they function within the AWS security model?
IAM Policies are JSON documents that define permissions, specifying what actions are allowed or denied on specific AWS resources. When a user or role makes a request, AWS evaluates these policies based on the principle of least privilege. A policy structure includes elements like Effect (Allow/Deny), Action (e.g., s3:ListBucket), and Resource (the ARN of the target). If no explicit 'Allow' is found, access is denied by default, ensuring a secure-by-default posture.
Compare using IAM User access keys versus IAM Roles for EC2 instances. Why is one preferred over the other?
Using IAM User access keys on an EC2 instance is a significant security risk because it requires hardcoding credentials, which can be leaked or stolen. In contrast, using an IAM Role is the preferred approach because AWS automatically rotates the temporary security credentials for the instance. Roles eliminate the need for manual key management and provide a much smaller attack surface, adhering to the security best practice of never storing static credentials in your application environment.
Explain the concept of an IAM Policy 'Deny' and how it interacts with an 'Allow' statement in complex policy evaluations.
In AWS, the policy evaluation logic follows a strict order: by default, all requests are denied. If an explicit 'Allow' is found in any policy, access is granted. However, if an explicit 'Deny' exists in any applicable policy—whether it is an Identity-based policy, a Resource-based policy, or a Service Control Policy (SCP)—it will override any 'Allow' statement. This is known as an 'Explicit Deny,' and it is the highest-priority rule in the evaluation process.
How would you implement a cross-account access strategy using IAM Roles?
To implement cross-account access, you create an IAM Role in the 'target' account (the one containing the resource) and define a 'Trust Policy' that permits the 'source' account to assume it. The source account then grants its users the 'sts:AssumeRole' permission to trigger the switch. The structure of the trust policy looks like this: {"Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::SourceAccountID:root"}, "Action": "sts:AssumeRole"}. This creates a secure, temporary bridge between accounts without requiring shared credentials.
Check yourself
1. An application running on an EC2 instance needs to read objects from an S3 bucket. What is the most secure way to grant this access?
- A.Create an IAM User with S3 read access and store the access keys in the application code.
- B.Attach an IAM Role with an S3 read policy to the EC2 instance.
- C.Add an S3 bucket policy that allows the public to read all objects.
- D.Modify the S3 bucket's Access Control List (ACL) to grant the EC2 instance's IP address access.
Show answer
B. Attach an IAM Role with an S3 read policy to the EC2 instance.
Attaching an IAM Role is the most secure method because it provides temporary, automatically rotated credentials. Storing keys in code is a major security risk. Public access is insecure, and IP-based ACLs are not a robust mechanism for AWS service authorization.
2. A developer needs to temporarily access a resource in a different AWS account. Which IAM feature should be used?
- A.IAM Group
- B.IAM User with cross-account permissions
- C.IAM Role
- D.IAM Policy versioning
Show answer
C. IAM Role
IAM Roles are designed for cross-account access through a mechanism called 'Role Assumption'. Groups are for organizing users, users are for persistent identity, and policy versioning tracks changes to permissions, none of which facilitate cross-account trust.
3. What is the result of an explicit 'Deny' statement in an IAM policy?
- A.It is ignored if an 'Allow' statement exists for the same action.
- B.It always takes precedence over any 'Allow' statement.
- C.It only denies access if no 'Allow' statement is found.
- D.It results in an error in the policy simulator.
Show answer
B. It always takes precedence over any 'Allow' statement.
In the AWS policy evaluation logic, an explicit Deny always overrides an Allow. Options ignoring the Deny or making it secondary are incorrect because security-focused Deny statements are absolute.
4. How does the 'Principle of Least Privilege' apply to IAM policy design?
- A.Providing users with access to only the resources necessary to perform their specific tasks.
- B.Granting broad administrative access and limiting it only when a user violates policy.
- C.Restricting all users to only the AWS Management Console access.
- D.Removing all IAM policies to ensure no one can make mistakes.
Show answer
A. Providing users with access to only the resources necessary to perform their specific tasks.
Least privilege means granting only the minimum permissions required. Broad access is the opposite of the principle. Restricting only to console access is arbitrary, and removing all policies prevents any productive work.
5. What happens when an IAM user is deleted?
- A.All resources created by the user are automatically deleted.
- B.The user's password is saved for 30 days for recovery purposes.
- C.The user loses all access to the AWS account immediately.
- D.The user's associated IAM Role permissions are automatically revoked.
Show answer
C. The user loses all access to the AWS account immediately.
Deleting an IAM user immediately revokes their authentication and authorization credentials. Resources are independent of user existence, passwords are not kept, and roles are distinct entities that are not bound to the lifespan of a specific user.