AWS IAM Best Practices

This lesson reviews core AWS Identity and Access Management best practices that are important for the AWS Certified Solutions Architect – Professional SAP-C02 exam.

IAM is foundational to almost every AWS architecture. On the exam, IAM often appears inside larger scenario-based questions involving security, governance, automation, hybrid access, application permissions, cross-account access, and operational control. The key theme is simple: grant the minimum permissions required, avoid long-term shared credentials, and continuously monitor and refine access.

Key Concepts

Protect the AWS Account Root User

The AWS account root user has full administrative control over the entire AWS account. It should not be used for day-to-day operations.

The root user should be reserved only for tasks that specifically require root-level access, such as certain account-level billing, support, or account recovery actions.

For exam purposes, remember this pattern:

• Do not use the root user for normal administration.
• Do not create or use root access keys.
• Enable MFA on the root user.
• Store root credentials securely.
• Use IAM users, IAM roles, federation, or AWS IAM Identity Center for normal access.

The root account is too powerful to be treated like a normal administrator account.

Create Individual Identities Instead of Sharing Accounts

Each person who needs access to AWS should have their own identity. Shared user accounts are a security and audit problem because they make it difficult to determine who performed a specific action.

In a real AWS environment, this matters because CloudTrail logs API activity. If multiple people use the same IAM user, the logs only show that shared IAM user, not the individual person behind the action.

For the SAP-C02 exam, shared credentials are almost always the wrong answer.

Use Groups to Assign Permissions to IAM Users

IAM groups are used to organize IAM users and assign permissions consistently. Instead of attaching policies directly to every user, you attach policies to a group and then add users to that group.

For example:

IAM Group	Attached Policy Purpose
BillingAdmins	Billing and cost management permissions
ReadOnlyUsers	Read-only AWS console access
EC2Operators	Limited EC2 operational permissions
SecurityAuditors	Security visibility and audit permissions

This makes permissions easier to manage and reduces configuration drift.

Apply Least Privilege

Least privilege means granting only the permissions required to perform a specific job or function.

This is one of the most important IAM concepts for the SAP-C02 exam.

Instead of giving broad access such as:

"Action": "*",
"Resource": "*"

you should scope permissions down to the specific services, actions, resources, and conditions required.

Least privilege can include:

• Limiting actions, such as allowing s3:GetObject but not s3:DeleteObject
• Limiting resources, such as only allowing access to a specific S3 bucket
• Adding conditions, such as source IP restrictions
• Using separate roles for separate workloads
• Reviewing and removing unused permissions over time

Start with AWS Managed Policies When Appropriate

AWS managed policies are prebuilt policies created and maintained by AWS. They are useful when an organization is starting out or when the permission set aligns with a common job function.

Examples include policies for read-only access, billing access, or administrative access.

However, AWS managed policies are not editable. They may also be broader than required for mature environments.

For the exam, AWS managed policies can be acceptable for simple or standardized access needs, but customer managed policies are usually preferred when precise least-privilege control is required.

Use Customer Managed Policies Instead of Inline Policies

Customer managed policies are standalone IAM policies created and managed within your AWS account. They can be attached to multiple IAM users, groups, or roles.

Inline policies are embedded directly into a single IAM identity. They are tightly coupled to that user, group, or role.

For most real-world and exam scenarios, customer managed policies are preferred because they are reusable, easier to audit, and easier to maintain.

Policy Type	Best Use Case	Key Limitation
AWS managed policy	Quick start or common job role	Cannot be edited
Customer managed policy	Reusable least-privilege permissions	Must be maintained by your organization
Inline policy	One-off tightly coupled permission	Harder to reuse and manage

Review IAM Permissions Regularly

IAM permissions should not be “set and forget.” Over time, users may change roles, applications may change, and unused permissions may remain in place.

Regular access reviews help identify:

• Overly broad permissions
• Unused IAM users
• Unused access keys
• Stale roles
• Inline policies that should be converted to managed policies
• Permissions that no longer align with job responsibilities

For SAP-C02, this maps to governance, security operations, and continuous improvement.

Configure a Strong Password Policy

For IAM users that authenticate using passwords, the AWS account should enforce a strong password policy.

A strong password policy can include requirements such as:

• Minimum password length
• Complexity requirements
• Password expiration
• Password reuse prevention
• Administrative reset controls

In modern enterprise designs, direct IAM user password access should often be minimized in favor of federation or IAM Identity Center, but password policy still matters when IAM users exist.

Enable Multi-Factor Authentication

MFA adds a second authentication factor beyond the password. This is a core AWS security best practice.

MFA should be enabled for:

• The AWS root user
• Privileged IAM users
• Administrative roles
• Any identity with sensitive permissions

On the exam, if an answer choice includes enabling MFA for privileged access, it is often part of the correct security design.

Use IAM Roles for Applications Running on EC2

Applications running on EC2 should use IAM roles instead of embedded access keys.

The correct pattern is:

1. Create an IAM role with the required permissions.
2. Attach the role to the EC2 instance through an instance profile.
3. The application retrieves temporary credentials automatically from the instance metadata service.
4. The application uses those temporary credentials to call AWS services.

This avoids storing long-term credentials on the instance.

For example, if an EC2 instance needs to read from an S3 bucket, attach an IAM role that allows the required S3 actions instead of storing access keys in a configuration file or application code.

Use Roles to Delegate Permissions

IAM roles are also used to delegate access. Unlike IAM users, roles are assumed temporarily by trusted entities.

Roles are commonly used for:

• EC2 instances accessing S3, DynamoDB, CloudWatch, or other AWS services
• Lambda functions accessing AWS resources
• Cross-account access
• Federated users
• AWS services performing actions on your behalf
• Temporary elevated access

For SAP-C02, roles are usually the preferred answer when something needs AWS permissions without relying on long-term static credentials.

Do Not Share Access Keys

Access keys consist of an access key ID and a secret access key. They are used for programmatic access to AWS.

Sharing access keys is dangerous because anyone with those credentials can perform any action allowed by the permissions attached to that IAM identity.

Access keys should not be:

• Shared between users
• Embedded in application code
• Stored in public repositories
• Hardcoded in scripts
• Placed in AMIs or container images
• Reused across applications

If credentials are exposed, they should be disabled or deleted immediately and replaced with a safer access method.

Rotate Credentials Regularly

Long-term credentials should be rotated regularly to reduce the risk of credential exposure.

This applies to:

• IAM user passwords
• Access keys
• Application credentials
• Other long-lived secrets

However, the better design is often to avoid long-term credentials entirely by using IAM roles and temporary security credentials.

Remove Unnecessary Credentials

Unused credentials are a security risk. If an IAM user, access key, password, or role is no longer required, it should be removed or disabled.

This is especially important for:

• Former employees
• Old automation accounts
• Legacy scripts
• Decommissioned applications
• Unused access keys
• Stale test accounts

For the exam, unnecessary active credentials usually indicate a poor security posture.

Use IAM Policy Conditions for Additional Security

IAM policy conditions allow you to add context-based restrictions to a permission.

For example, a policy can allow access only if the request comes from a specific corporate IP range.

Common IAM condition use cases include:

Condition Type	Example Use Case
Source IP	Allow console/API access only from corporate public IP ranges
MFA present	Require MFA before allowing sensitive actions
Requested region	Restrict actions to approved AWS Regions
Resource tags	Allow access only to resources with specific tags
Principal tags	Implement attribute-based access control
VPC endpoint	Require access through a private endpoint

IAM conditions are important for advanced security architecture because they allow permissions to be narrowed beyond simple allow or deny statements.

Monitor Activity in the AWS Account

AWS environments should be continuously monitored and audited.

The most important service for IAM activity auditing is AWS CloudTrail. CloudTrail records API calls made in the account, including who made the request, when it occurred, the source IP, and the AWS service involved.

Monitoring is important for:

• Security investigations
• Compliance
• Detecting unauthorized activity
• Reviewing administrative actions
• Identifying suspicious API calls
• Confirming whether credentials are being used

For SAP-C02, monitoring and auditing are often part of the best answer when the scenario involves governance, security, or incident response.

Exam-Relevant Takeaways

IAM best practices are frequently tested indirectly. The exam may not simply ask, “What is an IAM best practice?” Instead, it may describe an application, migration, security concern, or operational issue and expect you to choose the safest AWS-native identity design.

Remember these points:

• Never use the root account for daily administration.
• Do not create or use root access keys.
• Enable MFA, especially for root and privileged access.
• Avoid shared IAM users.
• Use groups to manage IAM user permissions.
• Use roles for AWS services and applications.
• Prefer temporary credentials over long-term access keys.
• Use least privilege.
• Use customer managed policies for reusable, controlled permissions.
• Avoid inline policies unless there is a specific one-to-one reason.
• Use IAM policy conditions for additional restrictions.
• Rotate and remove old credentials.
• Monitor AWS account activity with CloudTrail.

The most exam-friendly answer is usually the one that reduces static credentials, improves auditability, applies least privilege, and uses AWS-native identity controls.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
EC2 instance needs to read from S3	IAM role attached to EC2 instance profile	Provides temporary credentials without hardcoding access keys
Multiple users need the same permissions	IAM group with attached policy	Easier permission management and consistency
Organization needs reusable custom permissions	Customer managed policy	Reusable, auditable, and easier to maintain than inline policies
User needs one-off permission tightly bound to a single identity	Inline policy	Can be used for strict one-to-one permissions, but usually not preferred
New AWS environment needs quick baseline permissions	AWS managed policies	Useful starting point for common job functions
Production environment requires strict least privilege	Customer managed policies	Allows precise control over actions, resources, and conditions
Need to restrict access to corporate network	IAM policy condition using source IP	Adds context-based access control
Need to track who performed AWS actions	Individual identities plus CloudTrail	Provides accountability and auditability
Application requires AWS API access	IAM role	Avoids long-term static credentials
Access key is no longer used	Disable or delete the access key	Reduces credential exposure risk

Common Exam Traps

Trap: Using Access Keys on EC2 Instead of IAM Roles

If an EC2 instance needs access to another AWS service, do not store access keys on the instance. Use an IAM role attached to the instance.

Access keys on EC2 are usually the wrong exam answer.

Trap: Sharing IAM Users

Shared accounts reduce accountability. AWS expects individual identities so actions can be audited properly.

If multiple administrators need access, create separate identities and assign permissions through groups, roles, or federation.

Trap: Using the Root User for Administration

The root user should not be used for normal AWS management. Any answer suggesting routine root usage is likely incorrect.

Trap: Overusing AdministratorAccess

Granting full administrator access is rarely the correct answer unless the scenario specifically requires it. The exam favors least privilege.

Trap: Choosing Inline Policies for Reusable Permissions

Inline policies are directly embedded in one identity. If permissions need to be reused or centrally managed, customer managed policies are a better choice.

Trap: Forgetting Credential Rotation and Cleanup

Old access keys, unused IAM users, and stale credentials are security risks. The exam may include scenarios where credentials need to be rotated, removed, or replaced with roles.

Trap: Ignoring Monitoring

Security design is not complete without logging and monitoring. CloudTrail is essential for auditing IAM and AWS API activity.

Real-World Engineer Notes

In real environments, IAM becomes one of the most important operational control planes in AWS. A poor IAM design creates security risk, audit gaps, operational confusion, and unnecessary escalation work.

From an infrastructure engineering perspective, the biggest issue is usually credential sprawl. Teams may create IAM users for scripts, vendors, applications, administrators, CI/CD tools, and legacy integrations. Over time, nobody knows which access keys are still required. That creates risk during audits and incident response.

A more mature design uses IAM roles wherever possible. EC2, Lambda, ECS tasks, EKS workloads, and AWS services should use role-based access instead of long-term credentials. This reduces the need to rotate secrets manually and makes access easier to govern.

For human access, many organizations should avoid managing large numbers of standalone IAM users. Federation through an identity provider or AWS IAM Identity Center is usually cleaner because it allows centralized access control, MFA enforcement, and better offboarding.

IAM policy reviews should also be part of normal operations. When an engineer changes teams, when an application is retired, or when a vendor engagement ends, related permissions should be reviewed. This is similar to disabling old AD service accounts or cleaning up stale admin group memberships in a traditional infrastructure environment.

CloudTrail should be enabled and retained appropriately. During troubleshooting or incident response, CloudTrail may be the only way to confirm whether a user, role, access key, or service performed a specific AWS API action.

Quick Reference Summary

IAM best practices focus on secure identity management, least privilege, and avoiding long-term credentials.

Use the root account only when absolutely necessary. Enable MFA and protect root credentials.

Create individual identities instead of shared accounts.

Use IAM groups to manage permissions for users.

Use IAM roles for EC2 instances, AWS services, applications, cross-account access, and temporary delegated access.

Prefer customer managed policies over inline policies for reusable permissions.

Use AWS managed policies as a starting point when appropriate, but refine permissions for least privilege.

Do not embed or share access keys.

Rotate credentials and remove unused credentials.

Use IAM policy conditions to add context-based restrictions.

Monitor all AWS account activity with CloudTrail and related security tooling.

Flashcards

Q: Why should the AWS root user not be used for daily administration?
A: The root user has unrestricted account-level access. Daily tasks should be performed using IAM users, roles, federation, or IAM Identity Center with least-privilege permissions.

Q: What should you do with AWS account root access keys?
A: Avoid creating them. If they exist and are not required, remove them. Root access keys are highly sensitive and should not be used for normal operations.

Q: What is the best way to assign the same permissions to multiple IAM users?
A: Create an IAM group, attach the required policy to the group, and add users to the group.

Q: What does least privilege mean in IAM?
A: Granting only the permissions required to perform a specific job or task, and nothing more.

Q: When should you use an IAM role for an EC2 instance?
A: When the EC2 instance or an application running on it needs access to AWS services such as S3, DynamoDB, or CloudWatch.

Q: Why are IAM roles preferred over access keys for applications running on AWS services?
A: IAM roles provide temporary credentials automatically and avoid storing long-term credentials in code, configuration files, or on servers.

Q: What is an AWS managed policy?
A: A policy created and maintained by AWS for common permission sets or job functions. It cannot be edited by the customer.

Q: What is a customer managed policy?
A: A reusable IAM policy created and managed by the customer within their AWS account.

Q: Why are customer managed policies generally preferred over inline policies?
A: They are reusable, easier to audit, and easier to manage centrally.

Q: What is an inline policy?
A: A policy embedded directly into a single IAM user, group, or role.

Q: What is an example of an IAM policy condition?
A: Allowing access only from a specific source IP range, requiring MFA, or limiting actions to specific AWS Regions.

Q: Why should access keys be rotated?
A: Rotation reduces the risk of long-term credential exposure and limits the impact if credentials are compromised.

Q: What should be done with unused IAM credentials?
A: They should be disabled or deleted to reduce security risk.

Q: Which AWS service is commonly used to audit IAM and AWS API activity?
A: AWS CloudTrail.

Q: What is the main risk of shared IAM users?
A: They reduce accountability because actions cannot be reliably traced back to an individual person.

Practice Questions

Question 1:
An application running on an Amazon EC2 instance needs to read objects from an Amazon S3 bucket. The development team suggests storing an IAM user’s access key and secret access key in a local configuration file on the instance. What is the best solution?

A. Store the access keys in the application configuration file and restrict file permissions
B. Store the access keys in an encrypted EBS volume
C. Attach an IAM role with the required S3 permissions to the EC2 instance
D. Use the AWS account root user access keys because they have full access

Correct Answer:
C. Attach an IAM role with the required S3 permissions to the EC2 instance

Explanation:
Applications running on EC2 should use IAM roles through instance profiles. This provides temporary credentials and avoids storing long-term access keys on the server.

---

Question 2:
A company has several IAM users who need the same billing-related permissions. The company wants a manageable way to assign and update those permissions. What should the solutions architect recommend?

A. Attach the same inline policy to each IAM user
B. Create an IAM group, attach the billing policy to the group, and add the users to the group
C. Share one IAM user account among the billing administrators
D. Use the AWS root account for billing tasks

Correct Answer:
B. Create an IAM group, attach the billing policy to the group, and add the users to the group

Explanation:
IAM groups simplify permission management for users with the same job function. Shared accounts and root account usage are not best practices.

---

Question 3:
A security review finds several old IAM access keys that have not been used in months. What is the best action?

A. Leave them active in case they are needed later
B. Attach AdministratorAccess to the associated IAM users
C. Disable or delete the unused access keys after validating they are no longer required
D. Copy the keys into a shared password vault for future use

Correct Answer:
C. Disable or delete the unused access keys after validating they are no longer required

Explanation:
Unused credentials increase security risk. They should be removed when no longer needed.

---

Question 4:
A company wants to allow certain administrative actions only when users connect from the corporate office public IP range. Which IAM feature should be used?

A. IAM groups
B. IAM policy conditions
C. AWS managed policies only
D. Inline policies attached to the root account

Correct Answer:
B. IAM policy conditions

Explanation:
IAM policy conditions can restrict access based on contextual attributes such as source IP address, MFA status, requested Region, or resource tags.

---

Question 5:
A company wants to create a reusable least-privilege policy that can be attached to multiple IAM roles. Which policy type is most appropriate?

A. Root policy
B. Inline policy
C. Customer managed policy
D. Access key policy

Correct Answer:
C. Customer managed policy

Explanation:
Customer managed policies are standalone policies created by the customer. They can be reused across multiple IAM users, groups, and roles.