IAM

IAM Roles vs Policies vs Users – Complete Guide

~ Last updated on : ~ Kiro Agent

AWS IAM Roles vs Policies vs Users – Complete Guide

AWS Identity and Access Management (IAM) is the foundation of security in AWS. Understanding the differences between IAM Users, IAM Roles, and IAM Policies is critical for both real-world AWS security and AWS certification exams. This guide provides a comprehensive comparison of these three core IAM components, explains how they work together, and covers best practices for 2025-2026.

IAM — How Users, Roles & Policies Work Together
AWS Account
IAM User
Long-term credentials
(Access Key / Password)
IAM Role
Temporary credentials
(AssumeRole → STS)
IAM Group
Collection of Users
(attach policies to group)
↓ All get permissions from ↓
Identity Policy
Attached to User/Role/Group
Resource Policy
Attached to S3/SQS/KMS
Permission Boundary
Max permissions cap
SCP
Organization guardrail

IAM Overview – The Big Picture

IAM controls who (authentication) can do what (authorization) on which resources in your AWS account. Every single AWS API call passes through IAM for evaluation before reaching the target service.

The three core building blocks are:

  • IAM Users – Identities representing people or applications with long-term credentials
  • IAM Roles – Identities with temporary credentials that can be assumed by trusted entities
  • IAM Policies – JSON documents that define permissions (allow/deny actions on resources)
Component What It Is Credentials Primary Use Case
IAM User An identity (person or app) Long-term (password, access keys) Legacy human access, service accounts
IAM Role An assumable identity Temporary (STS tokens, 1-12 hrs) Services, cross-account, federation
IAM Policy A permissions document N/A (attached to identities/resources) Define what actions are allowed/denied

IAM Users

What Are IAM Users?

An IAM User is an identity within your AWS account that represents a person or application. Each IAM user has:

  • A unique name within the AWS account
  • Long-term credentials – either a password (for console access) or access keys (for programmatic access)
  • A unique ARN – e.g., arn:aws:iam::123456789012:user/jayendra

IAM User Credentials

Credential Type Usage Rotation
Password AWS Console sign-in Configurable via password policy
Access Key ID + Secret Access Key CLI, SDK, API calls Manual (max 2 active keys per user)
MFA Device Additional authentication factor Virtual (TOTP) or hardware

When to Use IAM Users

  • Third-party integrations that cannot use IAM roles or OIDC federation
  • Break-glass emergency access when federation is unavailable
  • Very small teams (1-2 people) without AWS Organizations
⚠️ Best Practice (2025-2026): AWS strongly recommends using IAM Identity Center (formerly AWS SSO) instead of IAM users for human access. IAM Identity Center provides temporary credentials, centralized management, and integrates with external identity providers (Okta, Entra ID, Google Workspace). Reserve IAM users for legacy workloads and specific programmatic use cases.

IAM Groups

IAM Groups are collections of IAM users that simplify permission management:

  • Attach policies to a group; all users in the group inherit those permissions
  • A user can belong to up to 10 groups
  • Groups cannot be nested (no group within a group)
  • Groups are not identities – they cannot be referenced in resource-based policies or assume roles

IAM Roles

What Are IAM Roles?

An IAM Role is an identity with specific permissions that can be assumed by trusted entities. Unlike users, roles do not have long-term credentials. When an entity assumes a role, AWS STS (Security Token Service) provides temporary security credentials consisting of:

  • Access Key ID
  • Secret Access Key
  • Session Token
  • Expiration timestamp (default 1 hour, configurable 15 min to 12 hours)

Role Components

Component Purpose Example
Trust Policy Defines WHO can assume the role EC2 service, another account, OIDC provider
Permissions Policy Defines WHAT the role can do Read S3, write DynamoDB
Permission Boundary Sets maximum permissions ceiling Restrict to specific services only
Session Duration How long credentials are valid 1 hour (default), max 12 hours

Trust Policy Example

This trust policy allows the EC2 service to assume this role, enabling EC2 instances to use the role’s permissions.

Types of IAM Roles

Role Type Trusted Entity Use Case
Service Role AWS Service (EC2, Lambda, ECS) EC2 instance accessing S3, Lambda accessing DynamoDB
Cross-Account Role Another AWS account Account A accessing resources in Account B
Federation Role Identity Provider (SAML/OIDC) Corporate SSO users accessing AWS
Service-Linked Role Specific AWS service Pre-defined by AWS, cannot modify permissions

Cross-Account Access with Roles

Cross-account roles enable secure access between AWS accounts without sharing long-term credentials:

  1. Account B (resource owner) creates a role with a trust policy allowing Account A
  2. Account A (requester) grants its users/roles permission to call sts:AssumeRole on Account B’s role
  3. User in Account A calls AssumeRole and receives temporary credentials for Account B

Role Chaining

Role chaining occurs when a role assumes another role. Key limitations:

  • Maximum session duration is limited to 1 hour (regardless of role’s max session setting)
  • CloudTrail logs each AssumeRole call in the chain
  • The final role’s permissions apply (not a union of all roles in the chain)

IAM Roles Anywhere

Launched in 2022 and enhanced through 2025, IAM Roles Anywhere extends IAM roles to workloads outside AWS using X.509 certificates. On-premises servers, IoT devices, and other non-AWS workloads can obtain temporary AWS credentials without long-term access keys.

IAM Policies

What Are IAM Policies?

IAM Policies are JSON documents that define permissions. They specify which actions are allowed or denied on which resources under what conditions. Policies do not grant access on their own – they must be attached to an identity (user, group, role) or a resource.

Policy Structure

Policy Elements

Element Required Description
Version Yes Always use “2012-10-17” (current version)
Statement Yes Array of permission statements
Sid No Statement identifier (optional description)
Effect Yes Allow or Deny
Principal Resource policies only Who the policy applies to
Action Yes API actions (e.g., s3:GetObject)
Resource Yes ARN of resources the policy applies to
Condition No When the policy is in effect

Types of IAM Policies

Identity-Based Policies vs Resource-Based Policies

Aspect Identity-Based Policies Resource-Based Policies
Attached to Users, Groups, Roles Resources (S3 bucket, SQS queue, KMS key)
Principal element Not used (implied by attachment) Required (specifies who gets access)
Cross-account Requires role assumption Can grant access directly to another account
Types Managed and Inline Inline only (embedded in resource)
Examples AmazonS3ReadOnlyAccess S3 Bucket Policy, SQS Queue Policy, KMS Key Policy
💡 Key Difference for Cross-Account Access: With resource-based policies, the principal retains permissions from their original account (no need to give up permissions). With IAM roles, the assuming entity temporarily gives up their original permissions and takes on only the role’s permissions.

AWS Managed vs Customer Managed vs Inline Policies

Type Created By Reusable Versioning Use When
AWS Managed AWS Yes (across accounts) Yes (AWS updates) Standard permissions for common use cases
Customer Managed You Yes (within account) Yes (up to 5 versions) Custom, reusable permissions specific to your org
Inline You No (1:1 with identity) No Strict 1:1 relationship, deleted with identity

Permission Boundaries

A permission boundary is an advanced feature that sets the maximum permissions an IAM entity (user or role) can have. It acts as a guardrail:

  • The effective permissions = intersection of identity-based policies AND permission boundary
  • Even if an identity-based policy grants s3:*, if the permission boundary only allows s3:GetObject, the effective permission is only s3:GetObject
  • Used for delegation – allow developers to create roles but only within defined boundaries
  • Permission boundaries do NOT grant permissions on their own

Service Control Policies (SCPs)

SCPs are organization-level policies in AWS Organizations that set permission guardrails across all accounts:

  • Apply to all IAM users and roles in member accounts (including root user for service actions)
  • Do NOT grant permissions – they only restrict what’s allowed
  • Effective permissions = SCP ∩ Identity-based policies ∩ Permission boundaries
  • Can be attached at Organization root, OU, or account level
  • Do NOT affect the management account
  • As of 2025, SCPs support the full IAM policy language including conditions in Allow statements and NotAction

Resource Control Policies (RCPs)

Introduced in 2024, Resource Control Policies (RCPs) complement SCPs by controlling access to resources rather than identities:

  • Restrict which principals (including external accounts) can access resources in your organization
  • Applied at Organization root, OU, or account level
  • Complement SCPs (identity guardrails) with resource-level guardrails

IAM Policy Evaluation Logic

When an AWS API call is made, IAM evaluates all applicable policies in a specific order:

  1. Explicit Deny – If ANY policy explicitly denies the action → DENIED (always wins)
  2. Resource Control Policies (RCPs) – Organization-level resource guardrails
  3. Service Control Policies (SCPs) – Organization-level identity guardrails
  4. Resource-Based Policies – If the resource policy allows the caller → may ALLOW (same account)
  5. Permission Boundaries – Must allow the action for it to proceed
  6. Session Policies – If using assumed role with session policy, must allow
  7. Identity-Based Policies – Must explicitly allow the action
💡 Key Rule: By default, all requests are implicitly denied. An explicit Allow is required (from the appropriate policy type), and an explicit Deny always overrides any Allow.

Same-Account vs Cross-Account Evaluation

Scenario Requirements
Same account Either identity-based OR resource-based policy can grant access
Cross-account BOTH the identity-based policy (in caller’s account) AND resource-based policy (in resource’s account) must allow access

How Users, Roles, and Policies Work Together

Visual Hierarchy

Common Patterns

Pattern 1: EC2 Instance Accessing S3

  1. Create an IAM Role with a trust policy for ec2.amazonaws.com
  2. Attach an identity-based policy granting S3 permissions to the role
  3. Attach the role to the EC2 instance (Instance Profile)
  4. Application on EC2 uses temporary credentials automatically via instance metadata

Pattern 2: Lambda Function Accessing DynamoDB

  1. Create an IAM Role with a trust policy for lambda.amazonaws.com
  2. Attach policies granting DynamoDB access
  3. Assign the role as the Lambda execution role
  4. Lambda automatically assumes the role on each invocation

Pattern 3: Cross-Account S3 Access

  1. Option A (Role-based): Create a role in Account B, trust Account A, grant S3 access
  2. Option B (Resource-based): Add a bucket policy in Account B allowing Account A’s principal

Pattern 4: Developer Permission Delegation

  1. Admin creates a permission boundary policy (e.g., only allow S3 and DynamoDB actions)
  2. Admin grants developer permission to create roles WITH the permission boundary
  3. Developer creates roles freely, but those roles can never exceed the boundary’s permissions

Best Practices (2025-2026)

1. Use IAM Identity Center for Human Access

  • Replace IAM users with IAM Identity Center (formerly AWS SSO)
  • Connect your existing IdP (Okta, Entra ID, Google Workspace)
  • Provides temporary credentials with automatic token refresh
  • Single sign-on to all AWS accounts and applications
  • No additional AWS charge for IAM Identity Center

2. Enforce Least Privilege

  • Start with minimal permissions and add as needed
  • Use IAM Access Analyzer to generate policies based on actual usage (CloudTrail)
  • Review and remove unused permissions regularly
  • Use last accessed information to identify unused services
  • Prefer specific actions over wildcards (s3:GetObject not s3:*)

3. Require MFA

  • Enable MFA for all IAM users (especially those with console access)
  • Use policy conditions to require MFA for sensitive operations: "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  • Prefer FIDO2/WebAuthn security keys over TOTP virtual MFA

4. Use Roles Over Users

  • EC2 instances → use Instance Profiles (IAM Roles)
  • Lambda functions → use Execution Roles
  • Cross-account access → use IAM Roles with AssumeRole
  • On-premises workloads → use IAM Roles Anywhere
  • CI/CD pipelines → use OIDC federation (GitHub Actions, GitLab)

5. Implement Guardrails at Scale

  • Use SCPs to prevent dangerous actions organization-wide (e.g., deny leaving organization, deny disabling CloudTrail)
  • Use Permission Boundaries for delegation (developers creating their own roles)
  • Use RCPs to restrict external access to your resources
  • Tag-based access control (ABAC) for scalable permissions management

6. Monitor and Audit

  • Enable CloudTrail in all accounts and regions
  • Use IAM Access Analyzer to detect external and unused access
  • Review IAM credential reports regularly
  • Set up alerts for root account usage

When to Use Each – Decision Guide

Scenario Use Why
Human accessing AWS Console IAM Identity Center Centralized, temporary credentials, SSO
EC2 instance needs AWS API access IAM Role (Instance Profile) Temporary credentials, auto-rotated
Lambda function accessing DynamoDB IAM Role (Execution Role) Service role, no static credentials
Account A accessing Account B resources IAM Role (Cross-Account) Secure delegation without sharing keys
Third-party SaaS needing AWS access IAM Role (External ID) Prevents confused deputy, no shared secrets
CI/CD pipeline (GitHub Actions) IAM Role (OIDC Federation) No stored AWS secrets in CI system
On-premises server accessing S3 IAM Roles Anywhere X.509 certs, temporary credentials
Restricting max permissions for developers Permission Boundary Delegation without privilege escalation
Organization-wide security guardrails SCPs Prevent dangerous actions across all accounts
Allow external account to access S3 bucket Resource-Based Policy Principal retains own permissions
Emergency break-glass access IAM User (with MFA) When federation/SSO is unavailable

AWS Certification Exam Tips

🎯 Exam Tips for SAA-C03, SAP-C02, SCS-C02, DVA-C02:

  • Explicit Deny always wins – No matter what allows exist, a single deny overrides everything
  • Roles for services, users for legacy – If the question mentions EC2/Lambda needing access, the answer involves a role, not access keys
  • Cross-account = role OR resource policy – Know when each is appropriate. Resource-based policies let the caller keep their original permissions
  • Permission boundaries don’t grant permissions – They only restrict. Effective = identity policy ∩ boundary
  • SCPs don’t affect management account – Common exam trick question
  • External ID prevents confused deputy – Required for third-party cross-account access
  • Role chaining limits session to 1 hour – Even if role’s max is 12 hours
  • Groups are NOT identities – Cannot be principal in a resource policy, cannot assume roles
  • IAM is global – Not region-specific (but STS endpoints can be regional)
  • AssumeRoleWithWebIdentity vs AssumeRoleWithSAML – Web identity for OIDC (Cognito, GitHub), SAML for enterprise IdPs

IAM Roles vs Policies vs Users – Practice Questions

Question 1

A company wants its EC2 instances to securely access objects in an S3 bucket without storing credentials on the instances. What is the recommended approach?

  1. Create an IAM user, generate access keys, and store them in environment variables on the EC2 instance
  2. Create an IAM role with S3 permissions and associate it with the EC2 instance via an instance profile
  3. Add a bucket policy allowing all EC2 instances in the VPC to access the bucket
  4. Enable public access on the S3 bucket for the specific objects needed
Show Answer

Answer: B –

Explanation: IAM roles attached to EC2 instances (via instance profiles) provide temporary credentials that are automatically rotated. This eliminates the need to store long-term credentials. Option A uses long-term credentials which is a security risk. Option C is not how bucket policies work (VPC endpoint policies could restrict, but not via bucket policy to EC2). Option D removes security entirely.

Question 2

An organization uses AWS Organizations with multiple accounts. They want to ensure NO user in any member account can disable CloudTrail, regardless of their IAM permissions. What should they implement?

  1. An IAM policy attached to all users denying cloudtrail:StopLogging
  2. A permission boundary on all roles denying cloudtrail:StopLogging
  3. A Service Control Policy (SCP) denying cloudtrail:StopLogging on member accounts
  4. A resource-based policy on the CloudTrail trail denying StopLogging
Show Answer

Answer: C –

Explanation: SCPs provide organization-wide guardrails that cannot be overridden by any IAM policy within member accounts. Option A requires attaching to every user and can be removed by admins. Option B requires applying to every role and doesn’t cover users. Option D is not supported by CloudTrail. Only SCPs provide mandatory, centralized enforcement across accounts.

Question 3

A developer in Account A (111111111111) needs to access a DynamoDB table in Account B (222222222222). The solution must NOT require the developer to give up their Account A permissions while accessing Account B’s table. What approach should be used?

  1. Create a cross-account IAM role in Account B and have the developer assume it
  2. Create an IAM user in Account B for the developer with DynamoDB permissions
  3. Add a resource-based policy on the DynamoDB table granting access to Account A’s developer
  4. Use VPC peering between the accounts to access DynamoDB
Show Answer

Answer: C –

Explanation: Resource-based policies allow cross-account access while the principal retains their original account permissions. When you assume a role (Option A), you temporarily give up your original permissions and can only use the assumed role’s permissions. DynamoDB does not support resource-based policies directly, but this question tests the concept. In practice, for DynamoDB cross-account, you would use a role. However, for the exam concept being tested: resource-based policies = keep original permissions; role assumption = adopt role’s permissions only.

Note: In real-world scenarios, DynamoDB does NOT support resource-based policies, so cross-account IAM roles would be the correct approach for DynamoDB specifically. This question tests conceptual understanding of the difference between roles and resource-based policies.

Question 4

A company wants to allow its development team to create IAM roles for their Lambda functions, but ensure those roles can never have more permissions than a predefined set (S3 and DynamoDB access only). What should the security team implement?

  1. An SCP restricting the development account to S3 and DynamoDB only
  2. A permission boundary policy that allows only S3 and DynamoDB actions, required when developers create roles
  3. AWS managed policies that only include S3 and DynamoDB permissions
  4. Inline policies on each developer’s IAM user restricting role creation
Show Answer

Answer: B –

Explanation: Permission boundaries are designed for this exact delegation pattern. The security team creates a permission boundary policy allowing only S3 and DynamoDB. They then grant developers permission to create roles only if those roles have this permission boundary attached (using iam:PermissionsBoundary condition key). This ensures developers can self-service while preventing privilege escalation. Option A would restrict the entire account, not just developer-created roles. Options C and D don’t prevent developers from attaching broader policies.

Question 5

A company’s security policy requires that all API calls from IAM users must use Multi-Factor Authentication (MFA). They want users who haven’t authenticated with MFA to only be able to manage their own MFA device. Which policy approach achieves this?

  1. Attach a deny policy that denies all actions except MFA management unless aws:MultiFactorAuthPresent is true
  2. Remove all permissions from users and only grant them through roles that require MFA to assume
  3. Use an SCP to deny all actions unless MFA is present
  4. Configure the AWS account password policy to require MFA
Show Answer

Answer: A –

Explanation: The standard pattern uses a policy with two statements: (1) Allow MFA self-management actions always, and (2) Deny all other actions with a condition "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}. This forces users to set up and authenticate with MFA before they can perform any other actions. Option B works but is overly complex. Option C would affect all principals including service roles which don’t use MFA. Option D only enforces MFA at console sign-in, not for API/CLI calls.

Related Posts

Related Posts

References

AWS IAM Best Practices – Least Privilege & MFA

~ Last updated on : ~ jayendrapatil ~ 10 Comments

AWS IAM Best Practices

📋 Content Update Notice (June 2026)

This post has been significantly updated to align with the latest AWS IAM security best practices. Key changes include: use of AWS IAM Identity Center for centralized workforce access, mandatory MFA enforcement for all root users (completed June 2025), support for passkeys (FIDO2) as phishing-resistant MFA, IAM Roles Anywhere for external workloads, Resource Control Policies (RCPs) for resource-level guardrails, enhanced IAM Access Analyzer capabilities including unused access analysis and guided revocation, and centralized root access management in AWS Organizations.

AWS recommends the following AWS Identity and Access Management service – IAM Best Practices to secure AWS resources

Root Account – Protect & Minimize Root User Usage

  • Do not use the AWS Root account which has full access to all the AWS resources and services including the Billing information.
  • Permissions associated with the AWS Root account cannot be restricted.
  • Do not generate the access keys, if not required.
  • If already generated and not needed, delete the access keys.
  • If access keys are needed, rotate (change) the access key regularly.
  • Never share the Root account credentials or access keys, instead create IAM users or Roles to grant granular access.
  • Enable AWS multifactor authentication (MFA) on the AWS account — AWS now enforces MFA for all root users across all account types (as of June 2025).
  • Use phishing-resistant MFA methods such as passkeys or FIDO2 security keys for root account protection.
  • Use centralized root access management in AWS Organizations to monitor, remove, and prevent recovery of long-term root credentials across member accounts.
  • Root users must register MFA within 35 days of first sign-in attempt if not already enabled.

Use Federation with IAM Identity Center for Human Users

  • Don’t use the AWS root account credentials to access AWS, and don’t share the credentials with anyone else.
  • Use AWS IAM Identity Center (formerly AWS SSO) for centralized access management to provide workforce access to AWS accounts using temporary credentials.
  • Use an identity provider (IdP) for federated access to AWS accounts by assuming IAM roles, which provide temporary credentials.
  • IAM Identity Center supports integration with external identity providers (Okta, Azure AD, Google Workspace, etc.) or its own built-in identity store.
  • Create individual IAM users only for specific legacy use cases that cannot use federation (e.g., third-party tools, CodeCommit SSH access, Amazon Keyspaces).
  • For scenarios requiring IAM users with programmatic access, use long-term credentials only when temporary credentials via roles are not feasible.

Groups – Use groups to assign permissions to IAM users

  • Instead of defining permissions for individual IAM users, create groups and define the relevant permissions for each group as per the job function, and then associate IAM users to those groups.
  • Users in an IAM group inherit the permissions assigned to the group and a User can belong to multiple groups.
  • It is much easier to add new users, remove users and modify the permissions of a group of users.

Permission – Apply Least-Privilege Permissions

  • IAM user, by default, is created with no permissions.
  • Users should be granted LEAST PRIVILEGE as required to perform a task.
  • Starting with minimal permissions and adding to the permissions as required to perform the job function is far better than granting all access and trying to then tighten it down.
  • Get started with AWS managed policies for common use cases and move toward least-privilege with customer managed policies specific to your use cases.
  • Use IAM Access Analyzer policy generation to generate fine-grained policies based on actual access activity logged in CloudTrail.
  • Use IAM last accessed information to identify and remove unused permissions, policies, and credentials.

Passwords – Enforce strong password policy for users

  • Enforce users to create strong passwords and enforce them to rotate their passwords periodically.
  • Enable a strong password policy to define password requirements forcing users to create passwords with requirements like at least one capital letter, one number, and how frequently it should be rotated.

MFA – Require MFA for All Users

  • Enable MultiFactor Authentication (MFA) for all IAM users, especially those with privileged access to sensitive resources or APIs.
  • AWS now enforces MFA for root users across all account types — Organizations management accounts (May 2024), standalone accounts (June 2024), and all remaining root users (June 2025).
  • Use phishing-resistant MFA such as passkeys and FIDO2 security keys wherever possible.
  • Passkeys (supported since June 2024) use public key cryptography for strong, phishing-resistant authentication that works across devices.
  • AWS supports up to 8 MFA devices per root and IAM user.
  • Synced passkeys allow users to access their FIDO sign-in credentials across multiple devices without re-enrolling each device.
  • MFA prevents over 99% of password-related attacks.
  • If using IAM Identity Center, configure MFA capabilities within Identity Center when using its built-in identity store or AD Connector.

Role – Use Temporary Credentials with IAM Roles

  • Use roles for workloads instead of creating IAM users and hardcoding the credentials which can compromise the access and are also hard to rotate.
  • Roles have specific permissions and do not have a permanent set of credentials.
  • Roles provide a way to access AWS by relying on dynamically generated & automatically rotated temporary security credentials.
  • For workloads running on AWS compute services (EC2, Lambda, ECS), IAM roles deliver temporary credentials automatically.
  • For workloads running outside AWS, use:
    • IAM Roles Anywhere — obtain temporary credentials using X.509 certificates from your PKI (credentials valid up to 12 hours).
    • AssumeRoleWithSAML — using SAML assertions from an external IdP.
    • AssumeRoleWithWebIdentity — using JWT from an OIDC-compatible IdP.
    • AWS IoT Core — using Mutual TLS (MTLS) authentication for IoT devices.
  • Additional options for hybrid workloads: ECS Anywhere, EKS Hybrid Nodes, and Systems Manager Hybrid Activations all deliver temporary credentials to external compute resources.

Sharing – Delegate using roles

  • Allow users from same AWS account, another AWS account, or externally authenticated users (either through any corporate authentication service or through Google, Facebook etc) to use IAM roles to specify the permissions which can then be assumed by them.
  • A role can be defined that specifies what permissions the IAM users in the other account are allowed, and from which AWS accounts the IAM users are allowed to assume the role.

Rotation – Update Access Keys When Needed

  • Where possible, rely on temporary credentials instead of creating long-term credentials such as access keys.
  • For scenarios requiring IAM users with programmatic access and long-term credentials, update access keys when needed (e.g., when an employee leaves).
  • Use IAM access last used information to update and remove access keys safely.
  • Access keys allow creation of 2 active keys at the same time for a user. These can be used to rotate the keys.

Track & Review – Regularly Remove Unused Credentials

  • Remove IAM users, roles, permissions, policies, and credentials (passwords and access keys) that are not needed.
  • Use the IAM Credential report that lists all IAM users in the account and the status of their various credentials, including passwords, access keys, and MFA devices and usage patterns.
  • Use IAM last accessed information to identify users, roles, and permissions no longer needed.
  • Passwords and access keys that have not been used recently might be good candidates for removal.
  • Use IAM Access Analyzer unused access analysis to continuously identify unused roles, access keys, passwords, and unused service/action-level permissions across your organization.

Conditions – Use policy conditions for extra security

  • Define conditions under which IAM policies allow access to a resource.
  • Conditions would help provide finer access control to the AWS services and resources for e.g. access limited to a specific IP range, requiring TLS for all requests, allowing only encrypted requests for uploads to S3 buckets, or restricting access to specific AWS services like CloudFormation.

Auditing – Monitor activity in the AWS account

  • Enable logging features provided through CloudTrail, S3, CloudFront in AWS to determine the actions users have taken in the account and the resources that were used.
  • Log files show the time and date of actions, the source IP for an action, which actions failed due to inadequate permissions, and more.

Use IAM Access Analyzer

  • IAM Access Analyzer provides multiple capabilities to help achieve least privilege:
  • External access analysis — identifies resources shared with external principals and generates findings for public and cross-account access.
  • Unused access analysis — continuously identifies unused IAM roles, unused access keys, unused passwords, and unused service/action-level permissions across your organization (paid feature).
  • Policy generation — generates fine-grained least-privilege policies based on actual access activity captured in CloudTrail logs.
  • Policy validation — provides 100+ policy checks and actionable recommendations to ensure policies adhere to IAM best practices.
  • Custom policy checks — CheckNoNewAccess and CheckAccessNotGranted APIs to verify policies don’t grant unintended access.
  • Guided revocation — provides guidance to revoke unused permissions, with quick links to delete unused roles, access keys, and passwords.
  • Integrates with AWS Security Hub for centralized unused access findings.

Use Permissions Boundaries

  • Use IAM Permissions Boundaries to delegate permissions management within an account.
  • IAM permissions boundaries help set the maximum permissions that you delegate and that an identity-based policy can grant to an IAM role.
  • A permissions boundary does not grant permissions on its own.

Establish Permissions Guardrails Across Multiple Accounts

  • Use AWS Organizations to separate workloads using multiple accounts.
  • Use Service Control Policies (SCPs) to establish permissions guardrails controlling access for all IAM principals (roles and users) across accounts.
  • Use Resource Control Policies (RCPs) (launched November 2024) to establish permissions guardrails controlling access to AWS resources across your organization.
    • RCPs set the maximum available permissions on resources at the organization, OU, or account level.
    • RCPs complement SCPs — SCPs restrict what principals can do, RCPs restrict what can be done to resources.
    • RCPs help establish data perimeters by restricting external access to resources at scale.
  • SCPs and RCPs do not grant permissions — you must still attach identity-based or resource-based policies to grant access.

Use AWS Managed Policies and Move Toward Least Privilege

  • Start with AWS managed policies that grant permissions for common use cases and job functions.
  • AWS managed policies may not grant least-privilege for specific use cases as they are designed for all AWS customers.
  • Reduce permissions further by defining customer managed policies specific to your use cases.
  • Use AWS managed policies for job functions (e.g., ViewOnlyAccess, SystemAdministrator, DatabaseAdministrator) as starting points.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your organization is preparing for a security assessment of your use of AWS. In preparation for this assessment, which two IAM best practices should you consider implementing? Choose 2 answers
    1. Create individual IAM users for everyone in your organization (May not be needed as can use IAM Identity Center with federation)
    2. Configure MFA on the root account and for privileged IAM users
    3. Assign IAM users and groups configured with policies granting least privilege access
    4. Ensure all users have been assigned and are frequently rotating a password, access ID/secret key, and X.509 certificate (Must be assigned only if using console or through command line)
  2. What are the recommended best practices for IAM? (Choose 3 answers)
    1. Grant least privilege
    2. Use the AWS account(root) for regular user
    3. Use Mutli-Factor Authentication (MFA)
    4. Store access key/private key in git
    5. Rotate credentials regularly
  3. Which of the below mentioned options is not a best practice to securely manage the AWS access credentials?
    1. Enable MFA for privileged users
    2. Create individual IAM users
    3. Keep rotating your secure access credentials at regular intervals
    4. Create strong access key and secret access key and attach to the root account
  4. Your CTO is very worried about the security of your AWS account. How best can you prevent hackers from completely hijacking your account?
    1. Use short but complex password on the root account and any administrators.
    2. Use AWS IAM Geo-Lock and disallow anyone from logging in except for in your city.
    3. Use MFA on all users and accounts, especially on the root account. (For increased security, it is recommend to configure MFA to help protect AWS resources. AWS now enforces MFA for all root users.)
    4. Don’t write down or remember the root account password after creating the AWS account.
  5. Fill the blanks: ____ helps us track AWS API calls and transitions, ____ helps to understand what resources we have now, and ____ allows auditing credentials and logins.
    1. AWS Config, CloudTrail, IAM Credential Reports
    2. CloudTrail, IAM Credential Reports, AWS Config
    3. CloudTrail, AWS Config, IAM Credential Reports
    4. AWS Config, IAM Credential Reports, CloudTrail
  6. A company wants to ensure that its workforce users access AWS accounts using temporary credentials and centralized access management. Which AWS service should they use? [Updated 2026]
    1. AWS Directory Service
    2. AWS IAM Identity Center
    3. Amazon Cognito
    4. AWS Certificate Manager
  7. An organization needs to provide temporary AWS credentials to workloads running on-premises that cannot use IAM Identity Center. Which service should they use? [Updated 2026]
    1. AWS STS AssumeRole
    2. IAM User access keys
    3. IAM Roles Anywhere
    4. AWS Secrets Manager
  8. Which IAM Access Analyzer capability helps identify unused IAM roles, access keys, and permissions across an AWS Organization? [Updated 2026]
    1. External access analysis
    2. Policy validation
    3. Unused access analysis
    4. Policy generation
  9. Which AWS Organizations policy type was introduced in November 2024 to centrally restrict access to AWS resources across an organization? [Updated 2026]
    1. Service Control Policies (SCPs)
    2. Tag Policies
    3. Backup Policies
    4. Resource Control Policies (RCPs)
  10. Which MFA method does AWS recommend as the most secure, phishing-resistant option for protecting AWS accounts? [Updated 2026]
    1. Virtual MFA device (authenticator app)
    2. SMS text message codes
    3. Hardware TOTP token
    4. Passkeys and FIDO2 security keys

References

IAM Roles vs Resource-Based Policies – Comparison

~ Last updated on : ~ jayendrapatil ~ 5 Comments

AWS IAM Roles vs Resource-Based Policies

AWS allows granting cross-account access to AWS resources, which can be done using IAM Roles or Resource-Based Policies. Understanding the differences between these two mechanisms is critical for designing secure, multi-account architectures.

Cross-Account Access Methods

  • AWS provides four primary ways to grant cross-account access using resource-based policies:
    • Method 1: Grant access to a specific IAM role using the Principal element (most granular, but role deletion breaks access)
    • Method 2: Grant access to an entire account using the Principal element (delegates access control to the other account)
    • Method 3: Grant access to a specific IAM role using the aws:PrincipalArn condition key (balanced approach — survives role recreation)
    • Method 4: Grant access to an entire AWS Organizations organization using aws:PrincipalOrgId condition key
  • AWS recommends using IAM roles with temporary credentials for cross-account access instead of IAM users with long-term credentials (access keys).

IAM Roles

  • Roles can be created to act as a proxy to allow users or services to access resources.
  • Roles support
    • trust policy which helps determine who can access the resources and
    • permission policy which helps to determine what they can access.
  • Users who assume a role temporarily give up their own permissions and instead take on the permissions of the role. The original user permissions are restored when the user exits or stops using the role.
  • Roles can be used to provide access to almost all the AWS resources.
  • Permissions provided to the User through the Role can be further restricted per user by passing an optional session policy to the STS request. This session policy cannot be used to elevate privileges beyond what the assumed role is allowed to access.
  • When a role ARN is specified in a resource-based policy’s Principal element, AWS maps it to the role’s unique ID. If the role is deleted and recreated with the same name, the new role will have a different unique ID and will not have access — this is an intentional security feature.
  • Using the aws:PrincipalArn condition key in resource-based policies (instead of specifying the role in the Principal element) allows access to survive role recreation, as the condition compares by ARN string rather than unique ID.

IAM Roles Anywhere

  • IAM Roles Anywhere extends the short-term credential model beyond the cloud, allowing on-premises and multi-cloud workloads to authenticate using X.509 certificates issued by your existing PKI (Public Key Infrastructure).
  • Eliminates the need for long-term access keys for on-premises workloads.
  • Supports credentials valid for up to 12 hours (extended from the original shorter duration).
  • Integrates with enterprise PKI so non-AWS workloads can use the same IAM policies and roles as AWS workloads.
  • Use cases include on-premises Kubernetes clusters, CI/CD pipelines running outside AWS, and hybrid cloud environments.

Confused Deputy Prevention

  • The confused deputy problem is a security issue where a less-privileged entity coerces a more-privileged service to perform actions on its behalf.
  • AWS recommends using the following global condition context keys in role trust policies and resource-based policies:
    • aws:SourceArn — restrict to a specific resource ARN (most effective)
    • aws:SourceAccount — restrict to a specific AWS account
    • aws:SourceOrgID — restrict to an AWS Organizations organization
    • aws:SourceOrgPaths — restrict to specific organizational units
  • These condition keys should always be used when granting service principals access to your resources.

Resource-based Policies

  • Resource-based policy allows you to attach a policy directly to the resource you want to share, instead of using a role as a proxy.
  • Resource-based policy specifies the Principal, in the form of a list of AWS account ID numbers, IAM role ARNs, or IAM user ARNs, that can access that resource and what actions they can perform.
  • Using cross-account access with a resource-based policy, the User still works in the trusted account and does not have to give up their permissions in place of the role permissions.
  • Users can work on the resources from both accounts at the same time and this can be useful for scenarios e.g. copying objects from one bucket to the other bucket in a different AWS account.
  • For same-account access, policy evaluation requires either the identity-based policy or the resource-based policy (but not both) to allow the request. For cross-account access, both an identity-based policy in the principal’s account and the resource-based policy on the resource must allow the request.
  • Resources that support resource-based policies include (but are not limited to):
    • Amazon S3 — Bucket policies for bucket and object access
    • Amazon SNS (Simple Notification Service)
    • Amazon SQS (Simple Queue Service)
    • Amazon S3 Glacier — Vault access policies
    • AWS Lambda — Function policies
    • AWS KMS — Key policies (required for KMS, every key must have one)
    • Amazon DynamoDB — Table, index, and stream policies (added 2024)
    • AWS Secrets Manager — Secret resource policies
    • Amazon EventBridge — Event bus policies
    • AWS Backup — Vault access policies
    • Amazon ECR — Repository policies
    • AWS CodeArtifact — Domain and repository policies
    • Amazon Bedrock AgentCore — Runtime and endpoint policies
  • Resource-based policies need the trusted account to create users with permissions to be able to access the resources from the trusted account.
  • Only permissions equivalent to, or less than, the permissions granted to your account by the resource owning account can be delegated.

Resource Control Policies (RCPs)

  • Resource Control Policies (RCPs) are a new type of authorization policy in AWS Organizations, launched at re:Invent 2024.
  • RCPs provide central control over the maximum available permissions on AWS resources across your entire organization.
  • RCPs complement Service Control Policies (SCPs):
    • SCPs — set maximum permissions for IAM principals (users and roles)
    • RCPs — set maximum permissions for AWS resources
  • RCPs help establish a data perimeter by centrally restricting external access to your resources at scale.
  • Supported services include: Amazon S3, AWS STS, AWS KMS, Amazon SQS, AWS Secrets Manager, Amazon Cognito, and Amazon CloudWatch Logs (expanding).
  • RCPs are applied organization-wide through AWS Organizations and can be attached to the organization root, OUs, or individual accounts.
  • AWS Sign-in now supports both resource-based policies and RCPs for the AWS Management Console, enabling restriction of console sign-in to expected networks.

AWS Resource Access Manager (RAM)

  • AWS RAM enables you to share resources with other AWS accounts or within your AWS Organization without using resource-based policies directly.
  • RAM eliminates the need to provision and manage duplicate resources in every account.
  • When sharing a resource, the receiving account’s IAM policies and permissions apply to the shared resource.
  • Supported resources include: VPC subnets, Transit Gateway, Route 53 Resolver rules, License Manager configurations, Aurora DB clusters, and many more.
  • RAM integrates with AWS Organizations to enable sharing without requiring individual account acceptance.

IAM Roles vs Resource-Based Policies – Key Differences

  • Permission Delegation: With IAM roles, the user gives up their original permissions and takes on role permissions. With resource-based policies, the user retains their original permissions.
  • Simultaneous Access: Resource-based policies allow users to work with resources in both accounts simultaneously. Roles do not.
  • Coverage: IAM roles can provide access to almost all AWS resources. Resource-based policies are limited to services that support them.
  • Session Policies: IAM roles support session policies for further restricting permissions. Resource-based policies do not support this concept.
  • Policy Evaluation: For cross-account access via roles, only the role’s identity-based policy determines effective permissions. For cross-account access via resource-based policies, both the caller’s identity-based policy and the resource policy must allow the action.

Best Practices for Cross-Account Access

  • Use IAM roles with temporary credentials instead of IAM users with long-term access keys.
  • Use the aws:PrincipalArn condition key in resource-based policies for a balance of security and availability.
  • Use the aws:PrincipalOrgId condition key to restrict access to your AWS Organization.
  • Use External ID in trust policies when granting access to third parties to prevent confused deputy attacks.
  • Implement the principle of least privilege in all cross-account policies.
  • Use RCPs to enforce organization-wide data perimeters on resources.
  • Regularly audit cross-account access using IAM Access Analyzer.
  • Consider using IAM Identity Center (formerly AWS SSO) with permission sets for centralized multi-account access management.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. What are the two permission types used by AWS?
    1. Resource-based and Product-based
    2. Product-based and Service-based
    3. Service-based
    4. User-based and Resource-based
  2. What’s the policy used for cross-account access? (Choose 2)
    1. Trust policy
    2. Permissions Policy
    3. Key policy
  3. A company has two AWS accounts – Account A and Account B. Account A has an S3 bucket that Account B needs to access. The security team wants to ensure that if the IAM role in Account B is accidentally deleted and recreated, access is maintained. Which approach should be used in the bucket policy?
    1. Specify the IAM role ARN in the Principal element
    2. Specify the account number in the Principal element with an aws:PrincipalArn condition
    3. Specify the account number in the Principal element without any condition
    4. Use a service control policy
  4. An organization wants to centrally restrict external access to their AWS resources across all accounts. Which policy type should they use?
    1. Service Control Policies (SCPs)
    2. Identity-based policies
    3. Resource Control Policies (RCPs)
    4. Permission boundaries
  5. A developer needs to copy objects from an S3 bucket in Account A to an S3 bucket in Account B, and needs to access both buckets simultaneously. Which cross-account access method should be used?
    1. IAM Role in Account A
    2. IAM Role in Account B
    3. Resource-based policy on the S3 bucket in Account A
    4. AWS Resource Access Manager
  6. Which condition keys should be used to prevent the confused deputy problem when granting a service principal access to your resources? (Choose 2)
    1. aws:SourceArn
    2. aws:SourceAccount
    3. aws:PrincipalOrgId
    4. aws:RequestedRegion
  7. An on-premises server needs to access AWS resources using temporary credentials without managing long-term access keys. Which service should be used?
    1. AWS STS AssumeRole
    2. IAM User with MFA
    3. IAM Roles Anywhere
    4. AWS Directory Service

References

AWS IAM Access Management

IAM Access Policies
~ Last updated on : ~ jayendrapatil ~ 16 Comments

IAM Access Management

  • IAM Access Management is all about Permissions and Policies.
  • Permission help define who has access & what actions can they perform.
  • IAM Policy helps to fine-tune the permissions granted to the policy owner
  • IAM Policy is a document that formally states one or more permissions.
  • Most restrictive Policy always wins
  • IAM Policy is defined in the JSON (JavaScript Object Notation) format

IAM policy basically states “Principal A is allowed or denied (Effect) to perform Action B on Resource C given Conditions D are satisfied”

IAM Access Policies

  • An Entity can be associated with Multiple Policies and a Policy can have multiple statements where each statement in a policy refers to a single permission.
  • If the policy includes multiple statements, a logical OR is applied across the statements at evaluation time. Similarly, if multiple policies are applicable to a request, a logical OR is applied across the policies at evaluation time.
  • Principal can either be specified within the Policy for Resource based policies while for Identity based policies the principal is the user, group, or role to which the policy is attached.

IAM Policy Types

  • AWS supports nine types of policies: identity-based policies, resource-based policies, VPC endpoint policies, permissions boundaries, AWS Organizations service control policies (SCPs), AWS Organizations resource control policies (RCPs), access control lists (ACLs), AWS RAM resource shares, and session policies.
  • IAM policies define permissions for an action regardless of the method used to perform the operation (Console, CLI, or API).

Identity-Based vs Resource-Based Permissions

Identity-based, or IAM permissions

  • Identity-based or IAM permissions are attached to an IAM user, group, or role and specify what the user, group, or role can do.
  • User, group, or the role itself acts as a Principal.
  • IAM permissions can be applied to almost all the AWS services.
  • IAM Policies can either be inline or managed (AWS or Customer).
  • IAM Policy’s current version is 2012-10-17.

Resource-based permissions

  • Resource-based permissions are attached to a resource for e.g. S3, SNS
  • Resource-based permissions specify both who has access to the resource (Principal) and what actions they can perform on it (Actions)
  • Resource-based policies are inline only, not managed.
  • Resource-based permissions are supported only by some AWS services
  • Resource-based policies can be defined with version 2012-10-17 or 2008-10-17
  • Within the same account, if either the identity-based policy or the resource-based policy allows the request and the other doesn’t, the request is still allowed (union of permissions).

VPC Endpoint Policies

  • VPC endpoint policies are resource-based policies attached to a VPC endpoint to control which principals can use the endpoint and which resources can be accessed through it.
  • VPC endpoint policies act as an additional access boundary scoped to traffic that traverses the endpoint.
  • VPC endpoint policies do not override or replace identity-based policies or resource-based policies.
  • If no custom endpoint policy is attached, AWS attaches a default policy that allows full access.

Session Policies

  • Session policies are advanced inline policies passed as a parameter when programmatically creating a temporary session for a role or federated user.
  • Session policies limit the permissions that the role or user’s identity-based policies grant to the session.
  • The resulting session’s permissions are the intersection of the identity-based policies and the session policies.
  • Session policies do not grant permissions on their own; they can only restrict.
  • Can be passed using AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, or GetFederationToken API operations.
  • You can pass up to 10 managed session policies using the PolicyArns parameter.

Access Control Lists (ACLs)

  • ACLs control which principals in other accounts can access the resource to which the ACL is attached.
  • ACLs cannot be used to control access for a principal within the same account.
  • ACLs are the only policy type that does not use the JSON policy document format.
  • Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs.

Managed Policies and Inline Policies

  • Managed policies
    • Managed policies are Standalone policies that can be attached to multiple users, groups, and roles in an AWS account.
    • Managed policies apply only to identities (users, groups, and roles) but not to resources.
    • Managed policies allow reusability
    • Managed policy changes are implemented as versions (limited to 5), a new change to the existing policy creates a new version which is useful to compare the changes and revert back, if needed
    • Managed policies have their own ARN
    • Two types of managed policies:
      • AWS managed policies
        • Managed policies that are created and managed by AWS.
        • AWS maintains and can upgrade these policies for e.g. if a new service is introduced, the changes automatically effect all the existing principals attached to the policy
        • AWS takes care of not breaking the policies for e.g. adding a restriction or removal of permission
        • AWS managed policies cannot be modified
      • Customer managed policies
        • Managed policies are standalone and custom policies created and administered by you.
        • Customer managed policies allow more precise control over the policies than when using AWS managed policies.
  • Inline policies
    • Inline policies are created and managed by you, and are embedded directly into a single user, group, or role.
    • Deletion of the Entity (User, Group or Role) or Resource deletes the In-Line policy as well

ABAC – Attribute-Based Access Control

  • ABAC – Attribute-based access control is an authorization strategy that defines permissions based on attributes called tags.
  • ABAC policies can be designed to allow operations when the principal’s tag matches the resource tag.
  • ABAC is helpful in environments that are growing rapidly and help with situations where policy management becomes cumbersome.
  • ABAC policies are easier to manage as different policies for different job functions need not be created.
  • Complements RBAC for granular permissions, with RBAC allowing access to only specific resources and ABAC can allow actions on all resources, but only if the resource tag matches the principal’s tag.
  • ABAC can help use employee attributes from the corporate directory with federation where attributes are applied to their resulting principal.
  • Amazon S3 now supports ABAC for general purpose buckets (launched Nov 2025), allowing tag-based access control on S3 resources directly.
  • ABAC support continues to expand across AWS services including OpenSearch Serverless, SageMaker Lakehouse, RDS, and Aurora.

IAM Permissions Boundaries

  • Permissions boundary allows using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity.
  • Permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.
  • Permissions boundary supports both the AWS-managed policy and the customer-managed policy to set the boundary for an IAM entity.
  • Permissions boundary can be applied to an IAM entity (user or role) but is not supported for IAM Group.
  • Permissions boundary does not grant permissions on its own.
  • If a resource-based policy specifies a role session or user in the principal element, an explicit allow in the permission boundary is not required. However, if the resource-based policy specifies the role ARN, a permission boundary allow is required.
  • An explicit deny in the permissions boundary always takes effect regardless of other policies.

Service Control Policies (SCPs)

  • Service Control Policies (SCPs) are AWS Organizations policies that define the maximum permissions for IAM users and IAM roles within accounts in an organization or organizational unit (OU).
  • SCPs limit permissions that identity-based policies or resource-based policies grant to entities within the account.
  • SCPs do not grant permissions on their own; they only restrict.
  • SCPs affect all IAM users and roles in the member accounts, including the account root user.
  • SCPs do not affect the management account.
  • SCPs now support full IAM policy language (announced Sep 2025), including conditions, individual resource ARNs, and the NotAction element with Allow statements.
  • An explicit deny in an SCP overrides any allow in identity-based or resource-based policies.

Resource Control Policies (RCPs)

  • Resource Control Policies (RCPs) are a new authorization policy type in AWS Organizations launched at re:Invent 2024 (November 2024).
  • RCPs provide centralized preventative controls on AWS resources across the organization.
  • RCPs set the maximum available permissions for resources in member accounts, complementing SCPs which control permissions for principals.
  • RCPs help restrict external access to resources at scale and implement data perimeters.
  • RCPs do not grant permissions on their own.
  • RCPs affect resources in member accounts only, not the management account.
  • RCPs apply regardless of whether the principals belong to the organization.
  • At launch, RCPs support: Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager.
  • RCPs work alongside SCPs to provide comprehensive permission guardrails: SCPs control what principals can do, RCPs control what can be done to resources.
  • An explicit deny in an RCP overrides allows in other policies.

Declarative Policies

  • Declarative policies are a new AWS Organizations capability launched at re:Invent 2024 (December 2024).
  • Declarative policies allow centrally declaring and enforcing desired configuration for a given AWS service at scale across an organization.
  • Once attached, the configuration is always maintained even when services add new APIs or features.
  • Declarative policies are designed to prevent actions that are non-compliant with the policy.
  • Unlike SCPs which require predicting and denying specific API calls, declarative policies express the desired end state.
  • Can be attached to organization root, OUs, or individual accounts.
  • Supported for EC2, VPC, and other services at launch.
  • Example: A declarative policy can disallow public sharing of AMIs organization-wide.

IAM Access Analyzer

  • IAM Access Analyzer helps identify resources that are shared with external entities and validates policies for best practices.
  • IAM Access Analyzer provides multiple types of analysis:
    • External Access Analysis – Identifies resources shared with external principals outside the zone of trust (organization or account).
    • Internal Access Analysis (launched June 2025) – Identifies who within the organization has access to critical resources, providing 360-degree visibility.
    • Unused Access Analysis (launched re:Invent 2023) – Identifies unused roles, unused access keys, unused console passwords, and unused service/action-level permissions.
  • IAM Access Analyzer supports Custom Policy Checks using automated reasoning:
    • Check Access Not Granted – Verifies policies don’t grant access to specific critical actions.
    • Check No Public Access (July 2024) – Determines if a resource policy grants public access to a specified resource type.
    • Check No New Access – Compares updated policy against reference to ensure no new access is granted.
    • Custom policy checks can be integrated into CI/CD pipelines for proactive policy validation.
  • Guided Revocation (June 2024) – Provides actionable recommendations to revoke unused permissions, including refined policy suggestions tailored to actual access activity.
  • Policy Generation – Reviews CloudTrail logs and generates IAM policies based on actual access activity for a specified time frame.
  • Policy Validation – Provides over 100 policy checks including security warnings, errors, general warnings, and best practice suggestions.
  • Unused access analysis is a paid feature, charged per IAM role or user per month.
  • Unused access analysis scope can be customized (Jan 2025) to exclude specific accounts, roles, or users using account IDs or tags.

IAM Policy Simulator

  • IAM Policy Simulator helps test and troubleshoot IAM and resource-based policies
  • IAM Policy Simulator can help test the following ways:-
    • Test IAM based policies. If multiple policies are attached, you can test all the policies or select individual policies to test. You can test which actions are allowed or denied by the selected policies for specific resources.
    • Test Resource based policies. However, Resource-based policies cannot be tested standalone and have to be attached to the Resource
    • Test new IAM policies that are not yet attached to a user, group, or role by typing or copying them into the simulator. These are used only in the simulation and are not saved.
    • Test the policies with selected services, actions, and resources
    • Simulate real-world scenarios by providing context keys, such as an IP address or date, that are included in Condition elements in the policies being tested.
    • Identify which specific statement in a policy results in allowing or denying access to a particular resource or action.
  • IAM Policy Simulator does not make an actual AWS service request and hence does not make unwanted changes to the AWS live environment
  • IAM Policy Simulator just reports the result Allowed or Denied
  • IAM Policy Simulator allows you to modify the policy and test. These changes are not propagated to the actual policies attached to the entities
  • Policy Simulator results can differ from the live AWS environment; always verify against the live environment.
  • Policy Simulator can also be accessed programmatically using SimulateCustomPolicy and SimulatePrincipalPolicy API operations.

IAM Policy Evaluation

When determining if permission is allowed, AWS evaluates all applicable policy types in the following order:

IAM Permission Policy Evaluation

Updated Policy Evaluation Logic (Single Account)

  1. Default Deny – Decision starts with Deny. All permissions are implicitly denied by default.
  2. Explicit Deny Check – IAM checks all applicable policies for an explicit deny. An explicit deny in ANY policy overrides everything and access is denied.
  3. SCPs – If the account is in an AWS Organization with SCPs enabled, the action must be allowed (not denied) by the SCP. If the SCP doesn’t allow it, access is denied.
  4. RCPs – If Resource Control Policies are enabled, they are evaluated. If the RCP denies access to the resource, access is denied.
  5. Resource-Based Policies – If the resource has a resource-based policy that allows the principal, this can grant access (within the same account, union of identity-based and resource-based).
  6. Identity-Based Policies – The identity-based policies attached to the principal are evaluated for an explicit allow.
  7. Permissions Boundaries – If a permissions boundary is set, the action must be allowed by both the identity-based policy AND the permissions boundary.
  8. Session Policies – For federated users or assumed roles with session policies, the session policy further restricts permissions.

Key Evaluation Rules

  • Explicit Deny – An explicit deny in any policy always wins. It overrides any allow.
  • Explicit Allow – Permission must be explicitly allowed. For granting the User any permission, the permission must be explicitly allowed by applicable policy types.
  • Implicit Deny – If neither an explicit deny nor explicit allow policy exists, it reverts to the default: implicit deny.
  • Same Account Union – Within the same account, identity-based and resource-based policies form a union. Either one allowing is sufficient (unless explicitly denied).
  • Cross-Account Intersection – For cross-account access, both the identity-based policy in the source account AND the resource-based policy on the target resource must allow the action.

IAM Policy Variables

  • Policy variables provide a feature to specify placeholders in a policy.
  • When the policy is evaluated, the policy variables are replaced with values that come from the request itself
  • Policy variables allow a single policy to be applied to a group of users to control access for e.g. all user having access to S3 bucket folder with their name only
  • Policy variable is marked using a $ prefix followed by a pair of curly braces ({ }). Inside the ${ } characters, with the name of the value from the request that you want to use in the policy
  • Policy variables work only with policies defined with Version 2012-10-17
  • Policy variables can only be used in the Resource element and in string comparisons in the Condition element
  • Policy variables include variables like aws:username, aws:userid, aws:SourceIp, aws:CurrentTime etc.
  • Context key names are NOT case-sensitive. For example, including aws:SourceIP context key is equivalent to testing for AWS:SourceIp. However, context key values may be case-sensitive depending on the condition operator used.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. IAM’s Policy Evaluation Logic always starts with a default ____________ for every request, except for those that use the AWS account’s root security credentials b
    1. Permit
    2. Deny
    3. Cancel
  2. An organization has created 10 IAM users. The organization wants each of the IAM users to have access to a separate DynamoDB table. All the users are added to the same group and the organization wants to setup a group level policy for this. How can the organization achieve this?
    1. Define the group policy and add a condition which allows the access based on the IAM name
    2. Create a DynamoDB table with the same name as the IAM user name and define the policy rule which grants access based on the DynamoDB ARN using a variable
    3. Create a separate DynamoDB database for each user and configure a policy in the group based on the DB variable
    4. It is not possible to have a group level policy which allows different IAM users to different DynamoDB Tables
  3. An organization has setup multiple IAM users. The organization wants that each IAM user accesses the IAM console only within the organization and not from outside. How can it achieve this?
    1. Create an IAM policy with the security group and use that security group for AWS console login
    2. Create an IAM policy with a condition which denies access when the IP address range is not from the organization
    3. Configure the EC2 instance security group which allows traffic only from the organization’s IP range
    4. Create an IAM policy with VPC and allow a secure gateway between the organization and AWS Console
  4. Can I attach more than one policy to a particular entity?
    1. Yes always
    2. Only if within GovCloud
    3. No
    4. Only if within VPC
  5. A __________ is a document that provides a formal statement of one or more permissions.
    1. policy
    2. permission
    3. Role
    4. resource
  6. A __________ is the concept of allowing (or disallowing) an entity such as a user, group, or role some type of access to one or more resources.
    1. user
    2. AWS Account
    3. resource
    4. permission
  7. True or False: When using IAM to control access to your RDS resources, the key names that can be used are case sensitive. For example, aws:CurrentTime is NOT equivalent to AWS:currenttime.
    1. TRUE
    2. FALSE (Context key names are NOT case-sensitive. aws:CurrentTime IS equivalent to AWS:currenttime. However, context key values may be case-sensitive depending on the condition operator. Refer IAM Condition documentation)
  8. A user has set an IAM policy where it allows all requests if a request from IP 10.10.10.1/32. Another policy allows all the requests between 5 PM to 7 PM. What will happen when a user is requesting access from IP 10.10.10.1/32 at 6 PM?
    1. IAM will throw an error for policy conflict
    2. It is not possible to set a policy based on the time or IP
    3. It will deny access
    4. It will allow access
  9. Which of the following are correct statements with policy evaluation logic in AWS Identity and Access Management? Choose 2 answers.
    1. By default, all requests are denied
    2. An explicit allow overrides an explicit deny
    3. An explicit allow overrides default deny
    4. An explicit deny does not override an explicit allow
    5. By default, all request are allowed
  10. A web design company currently runs several FTP servers that their 250 customers use to upload and download large graphic files. They wish to move this system to AWS to make it more scalable, but they wish to maintain customer privacy and keep costs to a minimum. What AWS architecture would you recommend? [PROFESSIONAL]
    1. Ask their customers to use an S3 client instead of an FTP client. Create a single S3 bucket. Create an IAM user for each customer. Put the IAM Users in a Group that has an IAM policy that permits access to subdirectories within the bucket via use of the ‘username’ Policy variable.
    2. Create a single S3 bucket with Reduced Redundancy Storage turned on and ask their customers to use an S3 client instead of an FTP client. Create a bucket for each customer with a Bucket Policy that permits access only to that one customer. (Creating bucket for each user is not a scalable model, also 100 buckets are a limit earlier without extending which has since changed link)
    3. Create an auto-scaling group of FTP servers with a scaling policy to automatically scale-in when minimum network traffic on the auto-scaling group is below a given threshold. Load a central list of ftp users from S3 as part of the user Data startup script on each Instance (Expensive)
    4. Create a single S3 bucket with Requester Pays turned on and ask their customers to use an S3 client instead of an FTP client. Create a bucket tor each customer with a Bucket Policy that permits access only to that one customer. (Creating bucket for each user is not a scalable model, also 100 buckets are a limit earlier without extending which has since changed link)

New Practice Questions – Updated 2025

  1. Which AWS Organizations policy type is used to centrally restrict external access to AWS resources across an organization?
    1. Service Control Policy (SCP)
    2. Resource Control Policy (RCP)
    3. Permissions Boundary
    4. Declarative Policy

    RCPs provide centralized preventative controls on AWS resources, restricting external access at scale. SCPs control what principals can do, while RCPs control what can be done to resources.

  2. A security team wants to ensure that no AMIs can be publicly shared across their entire AWS Organization, even when new APIs are added. Which policy type should they use?
    1. Service Control Policy (SCP)
    2. Resource Control Policy (RCP)
    3. Declarative Policy
    4. Identity-based Policy

    Declarative policies express desired end state and are maintained even when services add new APIs or features, making them ideal for enforcing configurations like disallowing public AMI sharing.

  3. Which IAM Access Analyzer feature uses automated reasoning to detect policies that grant public access to a resource before deployment?
    1. External Access Analysis
    2. Unused Access Analysis
    3. Custom Policy Checks – Check No Public Access
    4. Policy Generation

    Custom Policy Checks (including Check No Public Access, launched July 2024) use automated reasoning and can be integrated into CI/CD pipelines for proactive policy validation.

  4. In the IAM policy evaluation logic, what is the relationship between identity-based policies and resource-based policies within the same account?
    1. Both must allow the action (intersection)
    2. Either one allowing is sufficient (union)
    3. Resource-based policy always takes precedence
    4. Identity-based policy always takes precedence

    Within the same account, identity-based and resource-based policies form a union. If either one allows the request, access is granted (unless explicitly denied by any policy).

  5. How many policy types does AWS currently support? (Select the correct answer)
    1. 5
    2. 6
    3. 7
    4. 9 (identity-based, resource-based, VPC endpoint policies, permissions boundaries, SCPs, RCPs, ACLs, RAM resource shares, and session policies)
  6. What is the key difference between SCPs and RCPs in AWS Organizations?
    1. SCPs apply to resources while RCPs apply to principals
    2. SCPs control maximum permissions for principals while RCPs control maximum permissions for resources
    3. RCPs can grant permissions while SCPs cannot
    4. SCPs apply only to the management account while RCPs apply to member accounts

    SCPs define maximum permissions for IAM users and roles (principals), while RCPs define maximum permissions for resources. Neither grants permissions. Both apply to member accounts only.

  7. A security administrator wants to identify IAM roles that have permissions to access S3 but haven’t used those permissions in 90 days. Which feature should they use?
    1. IAM Access Analyzer – External Access Analysis
    2. IAM Access Analyzer – Unused Access Analysis
    3. IAM Access Analyzer – Custom Policy Checks
    4. IAM Policy Simulator

    Unused Access Analysis identifies unused roles, unused access keys, unused passwords, and unused service/action-level permissions by analyzing CloudTrail activity.

Google Cloud Identity Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Identity & Access Management – IAM

  • administrators authorize who can take what action on which resources
  • IAM Member (Principal) can be a Google Account (for end users), a service account (for apps and virtual machines), a Google group, a Google Workspace or Cloud Identity domain, or a workforce/workload identity that can access a resource.
  • IAM Role is a collection of permissions granted to authenticated members.
  • supports 3 kinds of roles
    • Basic roles (formerly called Primitive roles) – broad level of access (Owner, Editor, Viewer)
    • Predefined roles – finer-grained granular access control
    • Custom roles – tailored permissions when predefined roles don’t meet the needs.
  • Best practice is to use Predefined over basic roles
  • IAM Policy binds one or more members to a role.
  • IAM policy can be set at any level in the resource hierarchy: organization level, folder level, the project level, or the resource level.
  • IAM Policy inheritance is transitive and resources inherit the policies of all of their parent resources.
  • Effective policy for a resource is the union of the policy set on that resource and the policies inherited from higher up in the hierarchy.
  • Service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.
  • Access Scopes are the legacy method of specifying permissions for the instance for default service accounts
  • Best practice is to set the full cloud-platform access scope on the instance, then securely limit the service account’s access using IAM roles.
  • Delegate responsibility with groups (instead of individual users) and service accounts (for server-to-server interactions)

IAM Conditions

  • IAM Conditions allow granting resource access to identities (members) only if configured conditions are met.
  • Conditions are specified in role bindings of a resource’s IAM policy.
  • Conditions support attributes like date/time, resource type, resource name, IP address, and more.
  • Useful for temporary access, restricting access to specific resources, or limiting access based on device attributes.

IAM Deny Policies

  • IAM Deny Policies (GA) allow defining deny rules that prevent certain principals from using certain permissions, regardless of the roles they’re granted.
  • Deny policies act as guardrails and take precedence over allow policies.
  • Can be attached at the organization, folder, or project level.
  • Useful for centralizing management of administrative privileges and building defense in depth with Organization Policies.
  • Deny policies use the IAM v2 permission format (SERVICE_FQDN/RESOURCE.ACTION).

Workload Identity Federation

  • Workload Identity Federation allows external workloads (AWS, Azure, on-premises) to access Google Cloud resources without using service account keys.
  • Eliminates the maintenance and security burden associated with service account keys.
  • Uses identity pools and providers to map external identities to Google Cloud IAM.
  • Supports OIDC and SAML 2.0 protocols.
  • Recommended for GKE workloads — Workload Identity Federation for GKE enables pods to authenticate to Google Cloud services directly.

Privileged Access Manager (PAM)

  • Privileged Access Manager (PAM) is a Google Cloud native, managed solution for just-in-time temporary privilege elevation.
  • Enables on-demand, time-bound access to sensitive resources instead of always-on privileges.
  • Supports approval workflows — requesters can seek approval from designated approvers before access is granted.
  • Requesters can schedule grant requests up to seven days in advance (e.g., for maintenance windows or on-call shifts).
  • Provides audit logs to track who had access to what and when.
  • IAM recommender can remediate excessive permissions for Google groups by transitioning to PAM entitlements (Preview, 2026).

Principal Access Boundary Policies

  • Principal Access Boundary (PAB) Policies restrict which resources a principal is eligible to access.
  • By default, principals are eligible to access any Google Cloud resource (if they have the permission).
  • PAB policies define rules specifying which resources a set of principals can access — any resource not included is blocked.
  • Works alongside allow policies and deny policies for defense in depth.
  • Managed at the organization level with the Principal Access Boundary Admin role.

Agent Identity (GA – April 2026)

  • Agent Identity provides a first-class, strongly attested, cryptographic identity for AI agents — distinct from human identities or generic service accounts.
  • Based on the SPIFFE standard, tied to the lifecycle of the resource hosting the agent.
  • Enables agents to securely authenticate to MCP servers, cloud resources, endpoints, and other agents.
  • Supports acting on the agent’s own behalf or on behalf of an end user.
  • More secure than service accounts as the identity is per-agent and lifecycle-managed.
  • Agent Identity auth manager (Preview) helps authenticate agents to third-party services using OAuth or API keys.

Cloud Identity

  • Cloud Identity is an Identity as a Service (IDaaS) solution that helps centrally manage the users and groups.
  • configured to federate identities between Google and other identity providers, such as Active Directory and Microsoft Entra ID (formerly Azure Active Directory)
  • Cloud Identity and Google Workspace support Security Assertion Markup Language (SAML) 2.0 for single sign-on with authentication performed by an external identity provider (IdP)
  • With SAML, Cloud Identity or Google Workspace acts as a service provider that trusts the SAML IdP to verify a user’s identity on its behalf.
  • Google Cloud Directory Sync – GCDS implements the synchronization process between external IdP

Workforce Identity Federation

  • Workforce Identity Federation extends Google Cloud’s identity capabilities to support syncless, attribute-based single sign-on for human users.
  • Eliminates the need to synchronize user identities from an external IdP to Google-managed identities (no GCDS needed).
  • Supports multiple identity protocols: OpenID Connect (OIDC) and SAML 2.0.
  • Supports multiple IdPs per identity pool including Okta, Ping Identity, ADFS, and Microsoft Entra ID.
  • Over 95% of Google Cloud products now support Workforce Identity Federation.
  • Provides fine-grained, user-level access control without requiring users to have Google Accounts.

Cloud Billing

  • Google Cloud Billing defines billing accounts linked to Google Cloud Projects to determine who pays for a given set of Google Cloud resources.
  • To move the project to a different billing account, you must be a billing administrator and the project owner.
  • To link a project to a billing account, you must be a Billing Account Administrator or Billing Account User on the billing account OR Project Billing Manager on the project
  • Cloud Billing budgets can be created to monitor all of the Google Cloud charges in one place and configure alerts
  • supports BigQuery export with detailed Google Cloud billing data (such as usage, cost estimates, and pricing data) automatically throughout the day to a specified BigQuery dataset
  • Google Cloud billing data is not added retroactively to BigQuery, so the data before export is enabled will not be visible.

FinOps Hub

  • FinOps Hub centralizes all cost optimization activities in one place, highlighting inefficiencies and providing actionable recommendations.
  • Uses Cloud Billing to retrieve cost data and various Google Cloud cost recommenders for optimization and utilization metrics.
  • FinOps Hub 2.0 (announced at Cloud Next 2025) focuses on bringing utilization insights on resources to the forefront to identify potential waste.
  • Enables collaboration between business professionals and development teams to drive cost optimization.

Cost Anomaly Detection (GA – 2025)

  • Cost Anomaly Detection uses AI to identify spending patterns based on historical and seasonal trends, forecasting expected daily spend per project.
  • Continuously monitors actual spend every hour and detects deviations.
  • Anomaly alerts are enabled by default for every customer across all projects.
  • Supports customizable thresholds for cost impact amount and percent of deviation.
  • Provides automated alerts/notifications and allows feedback to improve accuracy.

CUD Analysis (GA – June 2026)

  • CUD Analysis provides a unified interface to examine both spend-based and resource-based Committed Use Discounts (CUDs).
  • Helps understand savings, track how effectively commitments are used, and download data for offline analysis.
  • Supports the new spend-based CUD model with direct discounted pricing (replacing the previous credit-based model).

AI Cost Summary Agent (Preview – April 2026)

  • AI Cost Summary Agent analyzes AI costs and provides insights into AI-related spend.
  • Focuses on spending related to Gemini usage, including Gemini API and Vertex AI.
  • Available as a widget on the Billing Overview page.

Spend Caps (Private Preview – 2026)

  • Spend Caps allow administrators to set budget limits at the project level that are automatically enforced.
  • If a project reaches the limit, Google Cloud issues a warning and then pauses API traffic.
  • Addresses the limitation of budgets which only alert but don’t enforce spending limits.

Related Posts