AWS IAM Best Practices and Least Privilege – SAP-C02 Study Guide

Purpose of This Lesson

AWS Identity and Access Management (IAM) best practices focus on reducing the exposure created by long-lived credentials, limiting permissions, protecting privileged identities, and continuously reviewing access. These practices apply to both human users and workloads, whether an organization operates one AWS account or a large multi-account environment.

Key Concepts

Prefer Federation and Temporary Credentials for Human Users

Human users should generally access AWS through federation with an external identity provider or AWS IAM Identity Center rather than by creating individual long-term IAM user credentials.

Federation allows users to authenticate with an existing corporate identity system and receive temporary AWS credentials through AWS Security Token Service (AWS STS). Benefits include:

• Centralized identity lifecycle management
• Easier integration with corporate authentication and MFA
• Reduced use of long-term passwords and access keys
• Faster revocation when an employee changes role or leaves the organization
• Better support for centralized access across multiple AWS accounts

IAM users may still exist in established environments, but new designs should normally favor federated access and IAM Identity Center.

Use IAM Roles for Workloads

Applications, scripts, and AWS services should use IAM roles and temporary credentials instead of storing access keys in source code, configuration files, or deployment artifacts.

Common role-based patterns include:

• An EC2 instance assumes an instance profile role.
• A Lambda function executes using its function execution role.
• An ECS task receives permissions through a task role.
• A user or external identity assumes a role for access to an AWS account.
• A CI/CD system assumes a narrowly scoped deployment role.

Temporary credentials are issued through AWS STS and expire automatically. This limits the useful lifetime of credentials if they are exposed.

Require Multi-Factor Authentication

MFA should be enabled for the root user, privileged identities, and other accounts where appropriate. MFA provides an additional authentication factor beyond a password or access key.

For privileged access, consider requiring MFA in IAM policies with a condition such as aws:MultiFactorAuthPresent. The exact policy design must account for whether the request is made through the AWS Management Console or programmatic APIs.

Protect the Root User

The AWS account root user has extensive privileges and should not be used for routine administration. Recommended controls include:

• Use a strong, unique root password.
• Enable MFA, preferably a phishing-resistant option where supported.
• Store root credentials securely with tightly controlled access.
• Avoid creating root access keys.
• Use the root user only for tasks that specifically require it.
• Monitor and alert on root-user activity.

Routine administration should be performed through named identities with appropriate roles and permissions.

Rotate Long-Term Access Keys When They Are Necessary

Long-term access keys should be avoided whenever roles or federation can satisfy the requirement. Some legacy tools, external systems, or integration constraints may still require them.

When long-term credentials are unavoidable:

• Rotate them regularly.
• Store them in a suitable secrets-management system rather than application code.
• Restrict their permissions.
• Monitor their use.
• Remove inactive or unused keys promptly.

Rotation reduces the period during which a compromised key can be abused, but it does not replace least privilege or secret protection.

Give Administrators Named Accounts

Each administrator should use an individual identity rather than sharing an administrative IAM user. Named access improves accountability, enables individual audit trails, and makes access removal more precise.

Administrative access should normally be granted through roles, federation, or IAM Identity Center permission sets, with MFA and tightly controlled permissions.

Apply Least Privilege

Grant only the permissions required for a user, role, or workload to perform its intended function. Least privilege should be applied to:

• IAM actions
• Resources
• Regions
• APIs and operations
• Conditions such as source IP, tags, encryption requirements, or MFA state
• The duration of access

Avoid granting broad permissions such as Action: "*" or Resource: "*" unless the use case genuinely requires them and the access is carefully controlled.

Start with AWS Managed Policies, Then Refine

AWS managed policies are useful when establishing access quickly because they cover common job functions and services. However, they may grant broader permissions than a specific workload or user requires, and their contents can change as AWS updates them.

For mature environments, create and maintain customer managed policies or inline policies that reflect the actual access requirements. Policy refinement should be based on observed usage, documented responsibilities, and testing.

Use IAM Access Analyzer

IAM Access Analyzer helps improve permissions and identify unintended access. Relevant capabilities include:

• Generating policy recommendations from observed access activity
• Identifying resources accessible from outside an account or organization
• Validating IAM policies for security and functional issues
• Reviewing public and cross-account resource access

Access Analyzer is an aid to least privilege, not a substitute for architectural review. An action that has not appeared in recent activity may still be required during a rare operational event.

Remove Unused Access

Regularly review and remove unused:

• IAM users
• Roles
• Groups
• Policies
• Access keys
• Permissions and trust relationships

Unused identities and credentials increase the attack surface and make audits more difficult. Access reviews should include both identity permissions and resource policies, since effective access can result from either side.

Use Policy Conditions for Additional Restrictions

IAM policy conditions can narrow when or how a permission is usable. Examples include restricting access based on:

• Source IP address or network range
• MFA presence
• Requested AWS Region
• Principal tags or resource tags
• VPC endpoint context
• Secure transport using TLS
• Encryption requirements
• Specific requested service or resource attributes

Conditions should complement, not replace, explicit action and resource restrictions. Be careful with network-based conditions when users or applications may access AWS through proxies, NAT gateways, or changing addresses.

Establish Guardrails Across Multiple Accounts

Multi-account environments require centralized governance. AWS Organizations can group and manage accounts, while AWS Control Tower can help establish a governed landing zone with account provisioning, preventive controls, and detective controls.

Different mechanisms address different layers of control:

• Service control policies (SCPs): Organization-level maximum permission boundaries for accounts and organizational units. SCPs do not grant permissions; they limit the maximum permissions that IAM policies can grant.
• IAM permissions boundaries: Maximum permissions for a specific IAM user or role within an account. They are useful when delegating permission-management responsibilities.
• Identity policies: Permissions attached to users, groups, or roles.
• Resource policies: Permissions attached to resources such as S3 buckets, KMS keys, or SQS queues.

A permission is effective only when all applicable controls allow it. A permissions boundary can prevent a delegated administrator from creating a role that exceeds an approved permission ceiling.

Exam-Relevant Takeaways

• Prefer IAM Identity Center or federation for human access and issue temporary credentials.
• Use IAM roles and STS temporary credentials for workloads; do not embed access keys in applications.
• Protect the root user with MFA and avoid using it for daily operations.
• Use individual administrator identities to preserve accountability.
• Rotate long-term access keys when they cannot be eliminated.
• AWS managed policies are a useful starting point, but customer managed policies usually provide tighter least privilege.
• Use IAM Access Analyzer to identify external access, validate policies, and help generate policies from activity.
• Conditions can constrain access by factors such as source IP, MFA, tags, encryption, and network context.
• Use AWS Organizations, Control Tower, SCPs, and permissions boundaries for multi-account governance.
• A permissions boundary limits the maximum permissions for a user or role; it does not grant permissions by itself.

Architecture Decision Guide

Requirement	Preferred approach	Important consideration
Employees need access to multiple AWS accounts	IAM Identity Center with federation	Centralize identity and use permission sets rather than creating many IAM users
EC2, Lambda, ECS, or other AWS workload needs API access	IAM role with temporary credentials	Avoid static access keys in code, images, and configuration
Legacy integration requires an access key	Restricted long-term access key with rotation	Store it securely, monitor use, and plan migration to role-based access
Emergency or privileged administrative access	Federated or assumed role with MFA	Use named identities and tightly control session duration and permissions
A team may create roles but must not exceed approved access	IAM permissions boundary	The boundary limits maximum permissions; an identity policy is still required
Organization-wide restriction across accounts	SCP through AWS Organizations	SCPs limit permissions but do not grant access
Need to identify public or cross-account access	IAM Access Analyzer	Review findings and confirm that intended sharing is documented
Need to refine broad permissions	Access Analyzer policy generation plus testing	Activity-based recommendations may miss infrequent but valid operations
Access should be allowed only from a corporate network	IAM condition using source network context	Validate behavior through NAT, proxies, VPNs, and VPC endpoints

Common Exam Traps

• Confusing federation with IAM user creation: Federation is intended to reduce dependence on individual long-term IAM users.
• Using access keys for EC2 or Lambda: AWS workloads should normally obtain temporary credentials through roles.
• Assuming MFA alone creates least privilege: MFA strengthens authentication but does not restrict what an identity can do.
• Treating the root user as an administrator account: The root user is reserved for tasks that require root credentials and should not be used routinely.
• Assuming AWS managed policies are always least privilege: They are convenient but may be broader than necessary.
• Assuming Access Analyzer automatically fixes permissions: It provides findings, validation, and recommendations; engineers must review and implement changes.
• Confusing permissions boundaries with granted permissions: A boundary is a ceiling, not an authorization grant.
• Confusing SCPs with IAM policies: SCPs restrict the maximum permissions available to accounts or organizational units but do not grant permissions.
• Overusing source-IP conditions: AWS requests may originate through NAT, proxies, VPNs, or service infrastructure, so a simplistic IP restriction can break valid access.
• Deleting an apparently unused permission without validation: Low-frequency operational paths may not appear in recent activity.

Real-World Engineer Notes

• Build identity around a central provider and automate joiner, mover, and leaver workflows.
• Separate production access from non-production access, and require stronger approval or MFA for production operations.
• Use short-lived sessions and limit role session duration where practical.
• Monitor CloudTrail for root-user activity, unusual role assumptions, access-key use, policy changes, and changes to trust relationships.
• Treat IAM policy and role trust-policy changes as production changes requiring review.
• Test permissions with representative workflows before removing actions identified as unused.
• Document intentional public and cross-account access so security findings can be triaged quickly.
• Use permissions boundaries when delegating IAM administration to development or platform teams.
• Combine identity policies, resource policies, SCPs, boundaries, and conditions deliberately; an allow in one policy does not override an explicit deny or an organizational restriction.

Quick Reference Summary

• Human users: federation or IAM Identity Center + temporary credentials.
• Workloads: IAM roles + STS temporary credentials.
• Privileged identities: MFA, named access, and limited permissions.
• Root user: MFA, secure storage, no routine use, no root access keys.
• Long-term keys: avoid where possible; rotate and protect when required.
• Permissions: start broad only when necessary, then reduce to least privilege.
• Analysis: IAM Access Analyzer for policy validation, external-access findings, and recommendations.
• Governance: Organizations and Control Tower for multi-account controls; SCPs and boundaries for permission ceilings.
• Hygiene: remove unused users, roles, policies, permissions, and credentials.

Flashcards

1. Q: What should be preferred for human access to AWS?

A: Federation with an identity provider or IAM Identity Center using temporary credentials.

1. Q: How should an EC2 instance access AWS APIs?

A: Through an IAM role attached using an instance profile, which provides temporary credentials.

1. Q: Why are temporary credentials safer than long-term access keys?

A: They expire automatically, limiting the useful lifetime of exposed credentials.

1. Q: What is the recommended use of the root user?

A: Only for tasks that specifically require root credentials; it should not be used for daily administration.

1. Q: Which authentication control should protect root and privileged access?

A: Multi-factor authentication.

1. Q: What is least privilege?

A: Granting only the permissions required for an identity or workload to perform its intended tasks.

1. Q: What is a drawback of AWS managed policies?

A: They may grant more permissions than a particular workload or user requires.

1. Q: What can IAM Access Analyzer help identify?

A: Public or cross-account access, policy validation issues, and policy recommendations based on access activity.

1. Q: What does an IAM permissions boundary do?

A: It defines the maximum permissions an IAM user or role can receive; it does not grant permissions itself.

1. Q: What is the role of an SCP?

A: It limits the maximum permissions available to accounts or organizational units in AWS Organizations; it does not grant permissions.

1. Q: Give two examples of IAM policy conditions.

A: Requiring MFA and restricting requests to a particular source IP range. Other examples include tag, Region, encryption, and TLS conditions.

1. Q: Why should administrators use separate named accounts?

A: Named identities improve accountability, auditing, and precise access revocation.

Practice Questions

Question 1

A company is designing a new multi-account AWS environment. Employees currently authenticate through the corporate identity provider. The security team wants centralized access management, MFA support, and temporary credentials without creating separate IAM users in every account.

Which solution best meets these requirements?

A. Create an IAM user in each account and distribute access keys.
B. Configure IAM Identity Center with federation to the corporate identity provider.
C. Share the root credentials through a password manager.
D. Create one administrator IAM user in the management account.

Correct answer: B

Explanation: IAM Identity Center integrated with federation provides centralized user access and temporary credentials across AWS accounts. The other options rely on shared or long-term credentials and reduce accountability.

Question 2

An application running on Amazon EC2 needs to read objects from one S3 bucket. A developer proposes storing an IAM access key in the application configuration file.

What is the best architectural response?

A. Store the access key in the EC2 user data script.
B. Encrypt the access key with a KMS key and keep it in the application AMI.
C. Attach an IAM role to the EC2 instance with only the required S3 permissions.
D. Use the root user access key and rotate it weekly.

Correct answer: C

Explanation: An EC2 instance profile role provides temporary credentials without embedding long-term credentials in the application. The role should allow only the required S3 actions and bucket resources.

Question 3

A platform team is allowed to create IAM roles for application teams. The organization wants to ensure that no role created by the platform team can grant access to billing data, even if the platform team accidentally attaches an overly broad identity policy.

Which control best addresses this requirement within the AWS account?

A. Attach an IAM permissions boundary to roles created by the platform team.
B. Enable MFA for the platform team.
C. Use an AWS managed policy for administrator access.
D. Configure an S3 lifecycle policy on the billing data bucket.

Correct answer: A

Explanation: A permissions boundary defines the maximum permissions that a role can have. It limits the effect of overly broad identity policies, although the boundary itself does not grant access.

Question 4

An organization uses AWS Organizations. Security requires that no account in the production organizational unit be able to disable CloudTrail, regardless of the IAM policies attached inside those accounts.

Which control is most appropriate?

A. An IAM permissions boundary attached to every developer role.
B. An SCP denying the relevant CloudTrail actions for the production organizational unit.
C. An AWS managed read-only policy in each production account.
D. An IAM condition requiring a corporate source IP address.

Correct answer: B

Explanation: An SCP can impose an organization-level restriction across accounts in an organizational unit. It does not grant permissions, but an explicit deny in the SCP prevents the restricted actions even if identity policies allow them.

Question 5

A security team wants to discover unintended public and cross-account access to AWS resources and obtain recommendations for reducing permissions based on observed API activity.

Which AWS service should the team use?

A. AWS Trusted Advisor only
B. AWS IAM Access Analyzer
C. AWS Config only
D. Amazon Inspector

Correct answer: B

Explanation: IAM Access Analyzer is designed to identify external access, validate IAM policies, and help generate least-privilege policies from observed access activity. Other services may support security or compliance operations but do not provide this IAM-focused capability.