IAM

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.

AWS Identity Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

AWS Identity Services Cheat Sheet

AWS Identity and Security Services

IAM – Identity & Access Management

  • securely control access to AWS services and resources
  • helps create and manage user identities and grant permissions for those users to access AWS resources
  • helps create groups for multiple users with similar permissions
  • not appropriate for application authentication
  • is Global and does not need to be migrated to a different region
  • helps define Policies,
    • in JSON format
    • all permissions are implicitly denied by default
    • most restrictive policy wins
  • IAM Role
    • helps grants and delegate access to users and services without the need of creating permanent credentials
    • IAM users or AWS services can assume a role to obtain temporary security credentials that can be used to make AWS API calls
    • needs Trust policy to define who and Permission policy to define what the user or service can access
    • used with Security Token Service (STS), a lightweight web service that provides temporary, limited privilege credentials for IAM users or for authenticated federated users
    • IAM role scenarios
      • Service access for e.g. EC2 to access S3 or DynamoDB
      • Cross Account access for users
        • with user within the same account
        • with user within an AWS account owned the same owner
        • with user from a Third Party AWS account with External ID for enhanced security
      • Identity Providers & Federation
        • AssumeRoleWithWebIdentity – Web Identity Federation, where the user can be authenticated using external authentication Identity providers like Amazon, Google or any OpenId IdP
        • AssumeRoleWithSAML – Identity Provider using SAML 2.0, where the user can be authenticated using on premises Active Directory, Open Ldap or any SAML 2.0 compliant IdP
        • AssumeRole (recommended) or GetFederationToken – For other Identity Providers, use Identity Broker to authenticate and provide temporary Credentials
  • IAM MFA (Multi-Factor Authentication)
    • AWS supports FIDO2 passkeys, virtual MFA devices (authenticator apps), and hardware MFA tokens
    • SMS MFA has been discontinued – use FIDO2 passkeys or virtual/hardware MFA devices instead
    • AWS enforces MFA for root users across all account types (rolled out 2024-2025)
    • FIDO2 passkeys use public key cryptography for phishing-resistant authentication
    • Up to 8 MFA devices can be registered per IAM user
  • IAM Best Practices
    • Do not use Root account for anything other than billing
    • Create Individual IAM users
    • Use groups to assign permissions to IAM users
    • Grant least privilege
    • Use IAM roles for applications on EC2
    • Delegate using roles instead of sharing credentials
    • Rotate credentials regularly
    • Use Policy conditions for increased granularity
    • Use CloudTrail to keep a history of activity
    • Enforce a strong IAM password policy for IAM users
    • Remove all unused users and credentials
    • Enable MFA for all users, especially root accounts – use FIDO2 passkeys for strongest protection
    • Use IAM Access Analyzer to identify unused access and overly permissive policies
  • Increased IAM Quotas (May 2026)
    • Roles per account: up to 10,000
    • Managed policies per account: up to 10,000
    • Role trust policy size: up to 8,192 characters

IAM Roles Anywhere

  • enables workloads running outside of AWS (on-premises, hybrid, multi-cloud) to access AWS resources using temporary credentials
  • eliminates the need for long-term AWS access keys for external workloads
  • uses X.509 certificates from your Certificate Authority (CA) for authentication
  • integrates with existing enterprise PKI infrastructure
  • key components:
    • Trust Anchor – establishes trust between IAM Roles Anywhere and your CA
    • Profile – specifies the IAM roles and session policies
    • Credential Helper – tool that runs on the workload to obtain temporary credentials
  • supports workloads on-premises, in containers, or in other cloud providers
  • uses the same IAM policies and roles as AWS workloads for consistent access control

IAM Access Analyzer

  • helps identify resources shared with external entities and validate IAM policies
  • provides External Access Analysis – identifies resources accessible from outside your account or organization
  • provides Unused Access Analysis – continuously monitors for:
    • Unused IAM roles
    • Unused access keys for IAM users
    • Unused passwords for IAM users
    • Unused services and actions for active roles/users
  • supports Custom Policy Checks – validates policies before deployment against best practices
  • generates policy recommendations based on access activity (least privilege)
  • integrates with AWS Security Hub for centralized findings
  • zone of trust can be set at account or organization level

AWS Organizations

  • is an account management service that enables consolidating multiple AWS accounts into an organization that can be centrally managed.
  • include consolidated billing and account management capabilities that enable one to better meet the budgetary, security, and compliance needs of your business.
  • As an administrator of an organization, new accounts can be created in an organization and invite existing accounts to join the organization.
  • enables you to
    • Automate AWS account creation and management, and provision resources with AWS CloudFormation Stacksets.
    • Maintain a secure environment with policies and management of AWS security services
    • Govern access to AWS services, resources, and regions
    • Centrally manage policies across multiple AWS accounts
    • Audit your environment for compliance
    • View and manage costs with consolidated billing
    • Configure AWS services across multiple accounts
  • supports Service Control Policies – SCPs
    • offer central control over the maximum available permissions for all of the accounts in your organization, ensuring member accounts stay within the organization’s access control guidelines.
    • are available only in an organization that has all features enabled, and aren’t available if the organization has enabled only the consolidated billing features.
    • are NOT sufficient for granting access to the accounts in the organization.
    • defines a guardrail for what actions accounts within the organization root or OU can do, but IAM policies need to be attached to the users and roles in the organization’s accounts to grant permissions to them.
    • Effective permissions are the logical intersection between what is allowed by the SCP and what is allowed by the IAM and resource-based policies.
    • with an SCP attached to member accounts, identity-based and resource-based policies grant permissions to entities only if those policies and the SCP allow the action
    • don’t affect users or roles in the management account. They affect only the member accounts in your organization.
  • supports Resource Control Policies (RCPs) – launched Nov 2024
    • a new authorization policy type that sets the maximum available permissions on resources within the organization
    • complement SCPs – SCPs control what principals can do, RCPs control what can be done on resources
    • help centrally restrict external access to AWS resources at scale (establish data perimeters)
    • don’t affect resources in the management account – only affect resources in member accounts
    • work alongside SCPs to provide comprehensive authorization guardrails
    • supported by AWS Control Tower for managed preventive controls
  • supports Declarative Policies – launched Dec 2024 at re:Invent
    • a new management policy type that declares and enforces desired configuration for AWS services at scale
    • different from SCPs/RCPs – declarative policies enforce service configurations, not just permissions
    • configuration is always maintained even when the service adds new features or APIs
    • simplifies governance by defining durable intent for baseline service configurations

AWS Directory Services

  • gives applications in AWS access to Active Directory services
  • different from SAML + AD, where the access is granted to AWS services through Temporary Credentials
  • AWS Managed Microsoft AD
    • fully managed Microsoft Active Directory powered by Windows Server
    • available in Standard and Enterprise editions
    • supports self-service API-driven edition upgrades (Standard to Enterprise) – Oct 2025
    • supports dual-stack networking (IPv4 and IPv6) – Sep 2025
    • includes Directory Service Data API for built-in object management (users, groups, attributes) – Sep 2024
    • Hybrid Edition (Aug 2025) – extends your existing self-managed AD domain to AWS Managed Microsoft AD
      • automatically handles replication between on-premises AD and AWS
      • preserves existing identity and access infrastructure
      • simplifies migration of AD-dependent workloads to AWS
      • supports extending domains from on-premises, AWS, or multi-cloud
  • Simple AD
    • least expensive but does not support Microsoft AD advanced features
    • provides a Samba 4 Microsoft Active Directory compatible standalone directory service on AWS
    • No single point of Authentication or Authorization, as a separate copy is maintained
    • trust relationships cannot be setup between Simple AD and other Active Directory domains
    • Don’t use it, if the requirement is to leverage access and control through centralized authentication service
  • AD Connector
    • acts just as an hosted proxy service for instances in AWS to connect to on-premises Active Directory
    • enables consistent enforcement of existing security policies, such as password expiration, password history, and account lockouts, whether users are accessing resources on-premises or in the AWS cloud
    • needs VPN connectivity (or Direct Connect)
    • integrates with existing RADIUS-based MFA solutions to enabled multi-factor authentication
    • does not cache data which might lead to latency
  • Read-only Domain Controllers (RODCs)
    • works out as a Read-only Active Directory
    • holds a copy of the Active Directory Domain Service (AD DS) database and respond to authentication requests
    • they cannot be written to and are typically deployed in locations where physical security cannot be guaranteed
    • helps maintain a single point to authentication & authorization controls, however needs to be synced
  • Writable Domain Controllers
    • are expensive to setup
    • operate in a multi-master model; changes can be made on any writable server in the forest, and those changes are replicated to servers throughout the entire forest

AWS IAM Identity Center (formerly AWS Single Sign-On)

  • is the recommended service for managing workforce access to AWS accounts and applications (formerly known as AWS SSO, renamed July 2022)
  • provides centralized SSO access to all AWS accounts and cloud applications
  • helps manage access and permissions to commonly used third-party software as a service (SaaS) applications, AWS-integrated applications as well as custom applications that support SAML 2.0.
  • includes a user portal where end-users can find and access all their assigned AWS accounts, cloud applications, and custom applications in one place.
  • supports connecting external identity providers (Okta, Microsoft Entra ID, Ping Identity) or using built-in directory
  • Trusted Identity Propagation
    • enables administrators to grant permissions based on user attributes (user ID, group associations) across AWS service boundaries
    • eliminates the need for service-specific identity mapping
    • supports services like Amazon Redshift, Amazon Q Business, Amazon EMR, and more
  • Multi-Region Replication (Feb 2026)
    • replicate identity configurations across multiple AWS Regions
    • provides active access portal endpoints in multiple Regions for improved availability
    • available for organization instances connected to external identity providers
    • currently available in 17 enabled-by-default commercial AWS Regions
  • supports customer managed policies and permission boundaries in permission sets

Amazon Cognito

  • Amazon Cognito provides authentication, authorization, and user management for the web and mobile apps.
  • Users can sign in directly with a username and password, or through a third party such as Facebook, Amazon, Google, or Apple.
  • Cognito has two main components.
    • User pools are user directories that provide sign-up and sign-in options for the app users.
    • Identity pools enable you to grant the users access to other AWS services.
  • Feature Tiers (Nov 2024) – User pools now offer three tiers:
    • Lite – basic authentication features (existing user pools default to this)
    • Essentials – includes Managed Login, passwordless authentication (passkeys, email, SMS), access token customization, password reuse prevention (new user pools default to this)
    • Plus – adds advanced security features including adaptive authentication, threat protection, and compromised credentials detection
  • Managed Login (Nov 2024) – fully managed, hosted sign-in/sign-up experience with rich branding customization
  • Passwordless Authentication (Nov 2024)
    • supports passkeys (FIDO standards, public key cryptography) for phishing-resistant sign-in
    • supports email and SMS one-time passwords
    • available in the Essentials tier
  • Refresh Token Rotation (Apr 2025) – enables automatic rotation of OAuth 2.0 refresh tokens for improved security
  • Client Secret Management (Feb 2026) – custom client secrets, on-demand rotation, up to two active secrets per app client
  • Multi-Region Replication (2026) – replicate user pools across Regions for business continuity and reduced latency
  • Customer-Managed Keys – full control over data encryption at rest using your own KMS keys
  • Cognito Sync – Note: AWS recommends using AWS AppSync instead of Cognito Sync for new implementations. AppSync provides similar data synchronization with additional real-time and offline capabilities.

Amazon Verified Permissions

  • a fully managed, fine-grained authorization service for applications (GA 2023)
  • uses Cedar, an open-source policy language purpose-built for authorization
  • externalizes authorization logic from application code for consistent access control
  • supports both Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC)
  • key components:
    • Policy Store – container for Cedar policies, logically isolated from other stores
    • Policies and Templates – define who can do what on which resources
    • Schema – defines entity types, actions, and their relationships
    • Authorization Requests – real-time evaluation of user access against policies
  • integrates natively with Amazon Cognito for identity context
  • aligns with Zero Trust principles – least privilege and continuous verification
  • supports multi-tenant authorization with multiple identity providers
  • enables security teams to audit and analyze application-level access centrally

IAM Federation – Identity Providers & SSO

~ Last updated on : ~ jayendrapatil ~ 29 Comments

IAM Role – Identity Providers and Federation

📋 2025-2026 Key Updates:

  • IAM Identity Center (formerly AWS SSO) is the recommended service for centralized workforce access management across AWS accounts and applications.
  • Amazon Cognito introduced feature tiers (Lite, Essentials, Plus), Managed Login, and passwordless authentication with passkeys (November 2024).
  • IAM Roles Anywhere enables temporary credentials for hybrid/on-premises/multi-cloud workloads using X.509 certificates.
  • IAM Outbound Identity Federation (November 2025) allows AWS workloads to access external services using short-lived JWTs via the GetWebIdentityToken API.
  • STS Global Endpoint Regionalization (April 2025) — requests to sts.amazonaws.com are now automatically served in the same Region as your workloads.
  • Identity Provider can be used to grant external user identity permissions to AWS resources without having to be created within your AWS account.
  • External user identities can be authenticated either through the organization’s authentication system or through a well-known identity provider such as Amazon, Google, etc.
  • Identity providers help keep the AWS account secure without having the need to distribute or embed long-term credentials in the application.
  • To use an IdP, an IAM identity provider entity can be created to establish a trust relationship between the AWS account and the IdP.
  • IAM supports IdPs that are compatible with OpenID Connect (OIDC) or SAML 2.0 (Security Assertion Markup Language 2.0)
  • AWS recommends using IAM Identity Center for centralized access management when federating workforce users, and Amazon Cognito for customer-facing application authentication.

Web Identity Federation without Cognito

IAM Web Identity Federation

  1. Mobile or Web Application needs to be configured with the IdP which gives each application a unique ID or client ID (also called audience)
  2. Create an Identity Provider entity for OIDC compatible IdP in IAM.
  3. Create an IAM role and define the
    1. Trust policy – specify the IdP (like Amazon) as the Principal (the trusted entity), and include a Condition that matches the IdP assigned app ID
    2. Permission policy – specify the permissions the application can assume
  4. Application calls the sign-in interface for the IdP to login
  5. IdP authenticates the user and returns an authentication token (OAuth access token or OIDC ID token) with information about the user to the application
  6. Application then makes an unsigned call to the STS service with the AssumeRoleWithWebIdentity action to request temporary security credentials.
  7. Application passes the IdP’s authentication token along with the Amazon Resource Name (ARN) for the IAM role created for that IdP.
  8. AWS verifies that the token is trusted and valid and if so, returns temporary security credentials (access key, secret access key, session token, expiry time) to the application that has the permissions for the role that you name in the request.
  9. STS response also includes metadata about the user from the IdP, such as the unique user ID that the IdP associates with the user.
  10. Application makes signed requests to AWS using the Temporary credentials
  11. User ID information from the identity provider can distinguish users in the app for e.g., objects can be put into S3 folders that include the user ID as prefixes or suffixes. This lets you create access control policies that lock the folder so only the user with that ID can access it.
  12. Application can cache the temporary security credentials and refresh them before their expiry accordingly. Temporary credentials, by default, are good for an hour.

Interactive Website provides a very good way to understand the flow

Note: For most scenarios, AWS recommends using Amazon Cognito instead of directly calling AssumeRoleWithWebIdentity. Cognito acts as an identity broker and provides additional capabilities including anonymous access, data synchronization, and simplified token management.

Mobile or Web Identity Federation with Cognito

  • Amazon Cognito as the identity broker is recommended for almost all web identity federation scenarios
  • Cognito is easy to use and provides additional capabilities like anonymous (unauthenticated) access
  • Cognito supports anonymous users, MFA and also helps synchronizing user data across devices and providers
  • Cognito consists of two main components:
    • User Pools — User directory with sign-up/sign-in, MFA, federation to external IdPs, and OAuth 2.0/OIDC flows
    • Identity Pools (Federated Identities) — Provides temporary AWS credentials to access AWS services directly

Web Identify Federation using Cognito

Amazon Cognito Updates (2024-2025)

  • Feature Tiers (November 2024) — Cognito now offers three pricing tiers:
    • Lite — Basic authentication with password-based login, social federation, and SAML/OIDC
    • Essentials — Adds Managed Login, passwordless authentication (passkeys, email OTP, SMS OTP), email MFA, choice-based sign-in, and access token customization
    • Plus — Adds advanced security features (adaptive authentication, compromised credentials detection), activity logging, and customizable managed login branding
  • Managed Login — Pre-built, customizable hosted sign-in/sign-up pages with a no-code visual editor, eliminating the need to build custom authentication UIs
  • Passwordless Authentication — Supports passkeys (FIDO2/WebAuthn), email OTP, and SMS OTP for phishing-resistant, low-friction sign-in
  • Machine-to-Machine (M2M) Authorization — OAuth 2.0 client credentials grants for service-to-service authentication

SAML 2.0-based Federation

  • AWS supports identity federation with SAML 2.0 (Security Assertion Markup Language 2.0), an open standard used by many identity providers (IdPs).
  • SAML 2.0 based federation feature enables federated single sign-on (SSO), so users can log into the AWS Management Console or call the AWS APIs without having to create an IAM user for everyone in the organization
  • SAML helps simplify the process of configuring federation with AWS by using the IdP’s service instead of writing custom identity proxy code.
  • This is useful in organizations that have integrated their identity systems (such as Windows Active Directory or OpenLDAP) with software that can produce SAML assertions to provide information about user identity and permissions (such as Active Directory Federation Services or Shibboleth)
  • Note: For new deployments, AWS recommends IAM Identity Center (formerly AWS SSO) as the preferred approach for workforce federation, as it simplifies multi-account access management and eliminates per-account federation configuration.

SAML based Federation

  1. Create a SAML provider entity in AWS using the SAML metadata document provided by the Organizations IdP to establish a “trust” between your AWS account and the IdP
  2. SAML metadata document includes the issuer name, a creation date, an expiration date, and keys that AWS can use to validate authentication responses (assertions) from your organization.
  3. Create IAM roles which define
    1. Trust policy with the SAML provider as the principal, which establishes a trust relationship between the organization and AWS
    2. Permission policy establishes what users from the organization are allowed to do in AWS
  4. SAML trust is completed by configuring the Organization’s IdP with information about AWS and the role(s) that you want the federated users to use. This is referred to as configuring relying party trust between your IdP and AWS
  5. Application calls the sign-in interface for the Organization IdP to login
  6. IdP authenticates the user and generates a SAML authentication response which includes assertions that identify the user and include attributes about the user
  7. Application then makes an unsigned call to the STS service with the AssumeRoleWithSAML action to request temporary security credentials.
  8. Application passes the ARN of the SAML provider, the ARN of the role to assume, the SAML assertion about the current user returned by IdP, and the time for which the credentials should be valid. An optional IAM Policy parameter can be provided to further restrict the permissions to the user
  9. AWS verifies that the SAML assertion is trusted and valid and if so, returns temporary security credentials (access key, secret access key, session token, expiry time) to the application that has the permissions for the role named in the request.
  10. STS response also includes metadata about the user from the IdP, such as the unique user ID that the IdP associates with the user.
  11. Using the Temporary credentials, the application makes signed requests to AWS to access the services
  12. Application can cache the temporary security credentials and refresh them before their expiry accordingly. Temporary credentials, by default, are good for an hour.

AWS Console SSO with SAML

  • SAML 2.0 based federation can also be used to grant access to the federated users to the AWS Management console.
  • This requires the use of the AWS SSO endpoint instead of directly calling the AssumeRoleWithSAML API.
  • The endpoint calls the API for the user and returns a URL that automatically redirects the user’s browser to the AWS Management Console.
  • AWS supports Regional SAML endpoints for failover, allowing you to configure multiple sign-in endpoints for improved federation resiliency.

SAML based SSO to AWS Console

  1. User browses the organization’s portal and selects the option to go to the AWS Management Console.
  2. Portal performs the function of the identity provider (IdP) that handles the exchange of trust between the organization and AWS.
  3. Portal verifies the user’s identity in the organization.
  4. Portal generates a SAML authentication response that includes assertions that identify the user and include attributes about the user.
  5. Portal sends this response to the client browser.
  6. Client browser is redirected to the AWS SSO endpoint and posts the SAML assertion.
  7. AWS SSO endpoint handles the call for the AssumeRoleWithSAML API action on the user’s behalf and requests temporary security credentials from STS and creates a console sign-in URL that uses those credentials.
  8. AWS sends the sign-in URL back to the client as a redirect.
  9. Client browser is redirected to the AWS Management Console. If the SAML authentication response includes attributes that map to multiple IAM roles, the user is first prompted to select the role to use for access to the console.

Custom Identity Broker Federation

Custom Identity broker Federation

  • If the Organization doesn’t support SAML-compatible IdP, a Custom Identity Broker can be used to provide the access.
  • Custom Identity Broker should perform the following steps
    • Verify that the user is authenticated by the local identity system.
    • Call the AWS STS AssumeRole (recommended) or GetFederationToken (by default, has an expiration period of 36 hours) APIs to obtain temporary security credentials for the user.
    • Temporary credentials limit the permissions a user has to the AWS resource
    • Call an AWS federation endpoint and supply the temporary security credentials to get a sign-in token.
    • Construct a URL for the console that includes the token.
    • URL that the federation endpoint provides is valid for 15 minutes after it is created.
    • Give the URL to the user or invoke the URL on the user’s behalf.

IAM Identity Center (formerly AWS SSO)

  • IAM Identity Center is the recommended AWS service for managing workforce access to multiple AWS accounts and applications.
  • Renamed from AWS Single Sign-On (AWS SSO) in July 2022.
  • Provides a single place to create or connect workforce users and centrally manage their access across all AWS accounts and applications.
  • Key features:
    • Centralized Access Management — Manage access to multiple AWS accounts in AWS Organizations from a single interface
    • Permission Sets — Define collections of IAM policies that determine what a user can do in an AWS account; supports customer managed policies and permission boundaries
    • Identity Source Flexibility — Use the built-in Identity Center directory, connect to Active Directory, or federate with external SAML 2.0/SCIM-compatible IdPs (Okta, Azure AD/Entra ID, Google Workspace, etc.)
    • Single Sign-On — Users authenticate once and access all assigned AWS accounts and applications without re-authenticating
    • Application Assignments — Assign access to SAML 2.0 applications and AWS-managed applications (Amazon Q Developer, etc.)
    • Multi-Region Support — Supports multi-Region replication for enhanced resiliency
    • Delegated Administration — Allows a member account to be designated as the delegated administrator for IAM Identity Center
  • IAM Identity Center eliminates the need to configure federation separately for each AWS account and simplifies permission management at scale.
  • When to use IAM Identity Center vs. direct SAML federation:
    • Use IAM Identity Center for centralized workforce access across multiple AWS accounts
    • Use direct IAM SAML federation for legacy applications or when IAM Identity Center is not available in your Region

IAM Roles Anywhere

  • IAM Roles Anywhere enables workloads running outside of AWS (on-premises, hybrid, multi-cloud) to obtain temporary AWS security credentials using X.509 certificates.
  • Extends the short-term credential model beyond the cloud, eliminating the need for long-term access keys for on-premises workloads.
  • Key components:
    • Trust Anchor — Represents the certificate authority (CA) that issues certificates to your workloads. Can be AWS Private CA or an external CA.
    • Profile — Specifies the IAM roles that can be assumed and optional session policies to further restrict permissions
    • X.509 Certificate — Issued to workloads by the trusted CA, used to authenticate and request temporary credentials
  • How it works:
    1. Register your CA as a Trust Anchor in IAM Roles Anywhere
    2. Create a Profile mapping to one or more IAM roles
    3. Workloads present their X.509 certificate to IAM Roles Anywhere
    4. IAM Roles Anywhere validates the certificate against the Trust Anchor
    5. If valid, temporary AWS credentials are returned (similar to AssumeRole)
  • Use cases:
    • On-premises servers accessing AWS services (S3, KMS, DynamoDB)
    • CI/CD pipelines running outside AWS (Azure DevOps, Jenkins)
    • Multi-cloud workloads that need AWS resource access
    • Kubernetes clusters outside AWS accessing AWS APIs
  • Supports workload identity mapping using certificate Subject (CN, FQDN) or SPIFFE-based identifiers

IAM Outbound Identity Federation (November 2025)

  • IAM Outbound Identity Federation enables AWS workloads to securely access external services without storing long-term credentials.
  • AWS workloads can request short-lived JSON Web Tokens (JWTs) from AWS STS by calling the GetWebIdentityToken API.
  • External services trust the AWS-issued JWT instead of requiring stored API keys or secrets.
  • Key features:
    • JWTs are cryptographically signed and short-lived
    • Uses IAM policies to control who can request tokens and what claims they contain
    • CloudTrail logs every token issuance event for audit
    • Supports passing session tags as claims for attribute-based access control (ABAC) at the external service
  • Must be explicitly enabled for your AWS account using the EnableOutboundWebIdentityFederation API.
  • Note: JWTs from GetWebIdentityToken cannot be used for OIDC federation back into AWS (via AssumeRoleWithWebIdentity). They are strictly for outbound access.

AWS STS Updates (2025)

  • Global Endpoint Regionalization (April 2025) — STS requests to the global endpoint (sts.amazonaws.com) are now automatically served in the same AWS Region as your workloads, improving resiliency and reducing latency. Previously, all global endpoint requests were routed through US East (N. Virginia).
  • SDK Default Changes (July 2025) — AWS SDKs are updating defaults: STS service endpoint will default to regional, and retry strategy will default to standard.
  • Session Tags — STS supports up to 50 session tags with AssumeRole, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity, enabling fine-grained ABAC across federated workloads. Tags can represent project, environment, or cost-center metadata.
  • AWS recommends using Regional STS endpoints whenever possible, especially for workloads outside AWS or in opt-in Regions, for improved resilience.

Federation Summary

Federation Type STS API Use Case Recommended Approach
Web Identity (without Cognito) AssumeRoleWithWebIdentity Mobile/web apps with social IdPs Use Cognito instead
Web Identity (with Cognito) Cognito Identity Pools (calls STS internally) Mobile/web apps needing AWS access ✅ Recommended for apps
SAML 2.0 Federation AssumeRoleWithSAML Enterprise SSO, API access Use IAM Identity Center for new deployments
Custom Identity Broker AssumeRole / GetFederationToken Non-SAML enterprise IdPs Use IAM Identity Center if possible
IAM Identity Center Managed by service Multi-account workforce access ✅ Recommended for workforce
IAM Roles Anywhere X.509 certificate exchange On-premises/hybrid/multi-cloud workloads ✅ Recommended for external workloads
Outbound Federation GetWebIdentityToken AWS workloads accessing external services ✅ New (2025)

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. A photo-sharing service stores pictures in Amazon Simple Storage Service (S3) and allows application sign-in using an OpenID Connect-compatible identity provider. Which AWS Security Token Service approach to temporary access should you use for the Amazon S3 operations?
    1. SAML-based Identity Federation
    2. Cross-Account Access
    3. AWS IAM users
    4. Web Identity Federation
  2. Which technique can be used to integrate AWS IAM (Identity and Access Management) with an on-premise LDAP (Lightweight Directory Access Protocol) directory service?
    1. Use an IAM policy that references the LDAP account identifiers and the AWS credentials.
    2. Use SAML (Security Assertion Markup Language) to enable single sign-on between AWS and LDAP
    3. Use AWS Security Token Service from an identity broker to issue short-lived AWS credentials. (Refer Link)
    4. Use IAM roles to automatically rotate the IAM credentials when LDAP credentials are updated.
    5. Use the LDAP credentials to restrict a group of users from launching specific EC2 instance types.
  3. You are designing a photo sharing mobile app the application will store all pictures in a single Amazon S3 bucket. Users will upload pictures from their mobile device directly to Amazon S3 and will be able to view and download their own pictures directly from Amazon S3. You want to configure security to handle potentially millions of users in the most secure manner possible. What should your server-side application do when a new user registers on the photo-sharing mobile application? [PROFESSIONAL]
    1. Create a set of long-term credentials using AWS Security Token Service with appropriate permissions Store these credentials in the mobile app and use them to access Amazon S3.
    2. Record the user’s Information in Amazon RDS and create a role in IAM with appropriate permissions. When the user uses their mobile app create temporary credentials using the AWS Security Token Service ‘AssumeRole’ function. Store these credentials in the mobile app’s memory and use them to access Amazon S3. Generate new credentials the next time the user runs the mobile app.
    3. Record the user’s Information in Amazon DynamoDB. When the user uses their mobile app create temporary credentials using AWS Security Token Service with appropriate permissions. Store these credentials in the mobile app’s memory and use them to access Amazon S3 Generate new credentials the next time the user runs the mobile app.
    4. Create IAM user. Assign appropriate permissions to the IAM user Generate an access key and secret key for the IAM user, store them in the mobile app and use these credentials to access Amazon S3.
    5. Create an IAM user. Update the bucket policy with appropriate permissions for the IAM user Generate an access Key and secret Key for the IAM user, store them In the mobile app and use these credentials to access Amazon S3.
  4. Your company has recently extended its datacenter into a VPC on AWS to add burst computing capacity as needed Members of your Network Operations Center need to be able to go to the AWS Management Console and administer Amazon EC2 instances as necessary. You don’t want to create new IAM users for each NOC member and make those users sign in again to the AWS Management Console. Which option below will meet the needs for your NOC members? [PROFESSIONAL]
    1. Use OAuth 2.0 to retrieve temporary AWS security credentials to enable your NOC members to sign in to the AWS Management Console.
    2. Use Web Identity Federation to retrieve AWS temporary security credentials to enable your NOC members to sign in to the AWS Management Console.
    3. Use your on-premises SAML 2.O-compliant identity provider (IDP) to grant the NOC members federated access to the AWS Management Console via the AWS single sign-on (SSO) endpoint.
    4. Use your on-premises SAML 2.0-compliant identity provider (IDP) to retrieve temporary security credentials to enable NOC members to sign in to the AWS Management Console
  1. A corporate web application is deployed within an Amazon Virtual Private Cloud (VPC) and is connected to the corporate data center via an iPsec VPN. The application must authenticate against the on-premises LDAP server. After authentication, each logged-in user can only access an Amazon Simple Storage Space (S3) keyspace specific to that user. Which two approaches can satisfy these objectives? (Choose 2 answers) [PROFESSIONAL]
    1. Develop an identity broker that authenticates against IAM security Token service to assume a IAM role in order to get temporary AWS security credentials. The application calls the identity broker to get AWS temporary security credentials with access to the appropriate S3 bucket. (Needs to authenticate against LDAP and not IAM)
    2. The application authenticates against LDAP and retrieves the name of an IAM role associated with the user. The application then calls the IAM Security Token Service to assume that IAM role. The application can use the temporary credentials to access the appropriate S3 bucket. (Authenticates with LDAP and calls the AssumeRole)
    3. Develop an identity broker that authenticates against LDAP and then calls IAM Security Token Service to get IAM federated user credentials The application calls the identity broker to get IAM federated user credentials with access to the appropriate S3 bucket. (Custom Identity broker implementation, with authentication with LDAP and using federated token)
    4. The application authenticates against LDAP the application then calls the AWS identity and Access Management (IAM) Security Token service to log in to IAM using the LDAP credentials the application can use the IAM temporary credentials to access the appropriate S3 bucket. (Can’t login to IAM using LDAP credentials)
    5. The application authenticates against IAM Security Token Service using the LDAP credentials the application uses those temporary AWS security credentials to access the appropriate S3 bucket. (Need to authenticate with LDAP)
  2. Company B is launching a new game app for mobile devices. Users will log into the game using their existing social media account to streamline data capture. Company B would like to directly save player data and scoring information from the mobile app to a DynamoDB table named Score Data When a user saves their game the progress data will be stored to the Game state S3 bucket. what is the best approach for storing data to DynamoDB and S3? [PROFESSIONAL]
    1. Use an EC2 Instance that is launched with an EC2 role providing access to the Score Data DynamoDB table and the GameState S3 bucket that communicates with the mobile app via web services.
    2. Use temporary security credentials that assume a role providing access to the Score Data DynamoDB table and the Game State S3 bucket using web identity federation
    3. Use Login with Amazon allowing users to sign in with an Amazon account providing the mobile app with access to the Score Data DynamoDB table and the Game State S3 bucket.
    4. Use an IAM user with access credentials assigned a role providing access to the Score Data DynamoDB table and the Game State S3 bucket for distribution with the mobile app.
  3. A user has created a mobile application which makes calls to DynamoDB to fetch certain data. The application is using the DynamoDB SDK and root account access/secret access key to connect to DynamoDB from mobile. Which of the below mentioned statements is true with respect to the best practice for security in this scenario?
    1. User should create a separate IAM user for each mobile application and provide DynamoDB access with it
    2. User should create an IAM role with DynamoDB and EC2 access. Attach the role with EC2 and route all calls from the mobile through EC2
    3. The application should use an IAM role with web identity federation which validates calls to DynamoDB with identity providers, such as Google, Amazon, and Facebook
    4. Create an IAM Role with DynamoDB access and attach it with the mobile application
  4. You are managing the AWS account of a big organization. The organization has more than 1000+ employees and they want to provide access to the various services to most of the employees. Which of the below mentioned options is the best possible solution in this case?
    1. The user should create a separate IAM user for each employee and provide access to them as per the policy
    2. The user should create an IAM role and attach STS with the role. The user should attach that role to the EC2 instance and setup AWS authentication on that server
    3. The user should create IAM groups as per the organization’s departments and add each user to the group for better access control
    4. Attach an IAM role with the organization’s authentication service to authorize each user for various AWS services
  5. Your fortune 500 company has under taken a TCO analysis evaluating the use of Amazon S3 versus acquiring more hardware The outcome was that all employees would be granted access to use Amazon S3 for storage of their personal documents. Which of the following will you need to consider so you can set up a solution that incorporates single sign-on from your corporate AD or LDAP directory and restricts access for each user to a designated user folder in a bucket? (Choose 3 Answers) [PROFESSIONAL]
    1. Setting up a federation proxy or identity provider
    2. Using AWS Security Token Service to generate temporary tokens
    3. Tagging each folder in the bucket
    4. Configuring IAM role
    5. Setting up a matching IAM user for every user in your corporate directory that needs access to a folder in the bucket
  6. An AWS customer is deploying a web application that is composed of a front-end running on Amazon EC2 and of confidential data that is stored on Amazon S3. The customer security policy that all access operations to this sensitive data must be authenticated and authorized by a centralized access management system that is operated by a separate security team. In addition, the web application team that owns and administers the EC2 web front-end instances is prohibited from having any ability to access the data that circumvents this centralized access management system. Which of the following configurations will support these requirements? [PROFESSIONAL]
    1. Encrypt the data on Amazon S3 using a CloudHSM that is operated by the separate security team. Configure the web application to integrate with the CloudHSM for decrypting approved data access operations for trusted end-users. (S3 doesn’t integrate directly with CloudHSM, also there is no centralized access management system control)
    2. Configure the web application to authenticate end-users against the centralized access management system. Have the web application provision trusted users STS tokens entitling the download of approved data directly from Amazon S3 (Controlled access and admins cannot access the data as it needs authentication)
    3. Have the separate security team create and IAM role that is entitled to access the data on Amazon S3. Have the web application team provision their instances with this role while denying their IAM users access to the data on Amazon S3 (Web team would have access to the data)
    4. Configure the web application to authenticate end-users against the centralized access management system using SAML. Have the end-users authenticate to IAM using their SAML token and download the approved data directly from S3. (not the way SAML auth works and not sure if the centralized access management system is SAML complaint)
  7. What is web identity federation?
    1. Use of an identity provider like Google or Facebook to become an AWS IAM User.
    2. Use of an identity provider like Google or Facebook to exchange for temporary AWS security credentials.
    3. Use of AWS IAM User tokens to log in as a Google or Facebook user.
    4. Use of AWS STS Tokens to log in as a Google or Facebook user.
  8. Games-R-Us is launching a new game app for mobile devices. Users will log into the game using their existing Facebook account and the game will record player data and scoring information directly to a DynamoDB table. What is the most secure approach for signing requests to the DynamoDB API?
    1. Create an IAM user with access credentials that are distributed with the mobile app to sign the requests
    2. Distribute the AWS root account access credentials with the mobile app to sign the requests
    3. Request temporary security credentials using web identity federation to sign the requests
    4. Establish cross account access between the mobile app and the DynamoDB table to sign the requests
  9. You are building a mobile app for consumers to post cat pictures online. You will be storing the images in AWS S3. You want to run the system very cheaply and simply. Which one of these options allows you to build a photo sharing application without needing to worry about scaling expensive uploads processes, authentication/authorization and so forth?
    1. Build the application out using AWS Cognito and web identity federation to allow users to log in using Facebook or Google Accounts. Once they are logged in, the secret token passed to that user is used to directly access resources on AWS, like AWS S3. (Amazon Cognito is a superset of the functionality provided by web identity federation. Refer link)
    2. Use JWT or SAML compliant systems to build authorization policies. Users log in with a username and password, and are given a token they can use indefinitely to make calls against the photo infrastructure.
    3. Use AWS API Gateway with a constantly rotating API Key to allow access from the client-side. Construct a custom build of the SDK and include S3 access in it.
    4. Create an AWS oAuth Service Domain and grant public signup and access to the domain. During setup, add at least one major social media site as a trusted Identity Provider for users.
  10. The Marketing Director in your company asked you to create a mobile app that lets users post sightings of good deeds known as random acts of kindness in 80-character summaries. You decided to write the application in JavaScript so that it would run on the broadest range of phones, browsers, and tablets. Your application should provide access to Amazon DynamoDB to store the good deed summaries. Initial testing of a prototype shows that there aren’t large spikes in usage. Which option provides the most cost-effective and scalable architecture for this application? [PROFESSIONAL]
    1. Provide the JavaScript client with temporary credentials from the Security Token Service using a Token Vending Machine (TVM) on an EC2 instance to provide signed credentials mapped to an Amazon Identity and Access Management (IAM) user allowing DynamoDB puts and S3 gets. You serve your mobile application out of an S3 bucket enabled as a web site. Your client updates DynamoDB. (Single EC2 instance not a scalable architecture)
    2. Register the application with a Web Identity Provider like Amazon, Google, or Facebook, create an IAM role for that provider, and set up permissions for the IAM role to allow S3 gets and DynamoDB puts. You serve your mobile application out of an S3 bucket enabled as a web site. Your client updates DynamoDB. (Can work with JavaScript SDK, is scalable and cost effective)
    3. Provide the JavaScript client with temporary credentials from the Security Token Service using a Token Vending Machine (TVM) to provide signed credentials mapped to an IAM user allowing DynamoDB puts. You serve your mobile application out of Apache EC2 instances that are load-balanced and autoscaled. Your EC2 instances are configured with an IAM role that allows DynamoDB puts. Your server updates DynamoDB. (Is Scalable but Not cost effective)
    4. Register the JavaScript application with a Web Identity Provider like Amazon, Google, or Facebook, create an IAM role for that provider, and set up permissions for the IAM role to allow DynamoDB puts. You serve your mobile application out of Apache EC2 instances that are load-balanced and autoscaled. Your EC2 instances are configured with an IAM role that allows DynamoDB puts. Your server updates DynamoDB. (Is Scalable but Not cost effective)

New Practice Questions (2024-2026 Updates)

  1. A company wants to provide its workforce with single sign-on access to multiple AWS accounts in their AWS Organization. They want centralized permission management and the ability to assign access from a single interface. Which AWS service should they use?
    1. AWS Cognito User Pools
    2. IAM SAML federation with each account
    3. IAM Identity Center (formerly AWS SSO)
    4. Custom Identity Broker with AssumeRole

    Explanation: IAM Identity Center is the recommended service for centralized workforce access management across multiple AWS accounts. It provides single sign-on, centralized permission sets, and eliminates per-account federation configuration.

  2. An organization has on-premises servers that need to access Amazon S3 and AWS KMS. They want to avoid using long-term IAM access keys. Which solution provides temporary credentials for on-premises workloads?
    1. Configure SAML federation for the servers
    2. Use Amazon Cognito Identity Pools
    3. Use IAM Roles Anywhere with X.509 certificates from the organization’s CA
    4. Create an identity broker that calls GetFederationToken

    Explanation: IAM Roles Anywhere is designed specifically for workloads outside AWS that need temporary credentials. Workloads authenticate using X.509 certificates issued by a trusted CA, and receive temporary AWS credentials.

  3. A mobile application needs to authenticate users with social identity providers (Google, Facebook, Apple) and provide them access to application data stored in DynamoDB. The application also needs to support unauthenticated guest access. Which is the recommended approach? (Choose 2)
    1. Create IAM users for each social provider
    2. Use Amazon Cognito User Pools for authentication with social identity federation
    3. Use Amazon Cognito Identity Pools to provide temporary AWS credentials for DynamoDB access
    4. Use AssumeRoleWithWebIdentity directly from the mobile app
    5. Use IAM Identity Center for social provider federation

    Explanation: Cognito User Pools handle authentication with social IdPs, and Cognito Identity Pools provide temporary AWS credentials. Together they support both authenticated and unauthenticated (guest) access.

  4. An AWS Lambda function needs to call an external SaaS API that supports OIDC-based authentication. The company wants to avoid storing long-term API keys in AWS Secrets Manager. Which approach should they use?
    1. Use web identity federation with AssumeRoleWithWebIdentity
    2. Store the API key in the Lambda environment variable with encryption
    3. Use IAM Outbound Identity Federation to obtain a short-lived JWT for the external service
    4. Use Amazon Cognito to authenticate the Lambda function

    Explanation: IAM Outbound Identity Federation (launched November 2025) allows AWS workloads to call GetWebIdentityToken to obtain short-lived JWTs for authenticating with external services, eliminating the need to store long-term credentials.

  5. A company is setting up SAML 2.0 federation for console access. They want to improve resiliency in case of a Regional outage. What should they configure?
    1. Set up IAM Identity Center in multiple accounts
    2. Configure their IdP and AWS federation to support multiple Regional SAML sign-in endpoints
    3. Use GetFederationToken as a backup to AssumeRoleWithSAML
    4. Deploy a custom identity broker in multiple Availability Zones

    Explanation: AWS supports Regional SAML endpoints for failover. Configuring the IdP to use multiple Regional endpoints provides enhanced resilience for federated console access.

  6. Which of the following correctly describes the STS global endpoint behavior as of April 2025?
    1. All global endpoint requests are served from US East (N. Virginia) for consistency
    2. Global endpoint requests are automatically served in the same AWS Region as the workload for improved resiliency
    3. The global endpoint has been deprecated in favor of Regional endpoints
    4. Global endpoint requests are load-balanced across all available Regions

    Explanation: As of April 2025, AWS STS global endpoint requests are automatically served in the same Region as the workload. Previously, all requests went to US East (N. Virginia). AWS still recommends using Regional endpoints whenever possible.

References

AWS Identity & Security Services Cheat Sheet

~ Last updated on : ~ jayendrapatil ~ 9 Comments

AWS Identity & Security Services Cheat Sheet

AWS Identity and Security Services

📌 Last Updated: June 2026 — Includes AWS Security Hub reimagined (re:Invent 2025), AWS Security Agent (GA March 2026), mandatory MFA enforcement for all root users, GuardDuty Extended Threat Detection, and IAM Identity Center multi-Region replication.

AWS Identity Services Cheat Sheet

AWS Security Services Cheat Sheet

AWS Identity & Security Services Overview

AWS Security, Identity, and Compliance services provide a comprehensive set of tools to help protect data, accounts, and workloads. These services are organized into the following categories:

Identity and Access Management

  • AWS Identity and Access Management (IAM) – Securely manage access to AWS services and resources using users, groups, roles, and policies
  • AWS IAM Identity Center (formerly AWS SSO) – Centrally manage SSO access to multiple AWS accounts and business applications
    • Now supports multi-Region replication (Feb 2026) for high availability
    • Supports IPv6 dual-stack endpoints
  • Amazon Cognito – Customer identity and access management (CIAM) for web and mobile apps
    • Now supports passwordless authentication with passkeys (FIDO2/WebAuthn), email OTP, and SMS OTP (Nov 2024)
    • New feature tiers: Essentials and Plus (Nov 2024)
    • Managed Login for pre-built authentication UIs
  • Amazon Verified Permissions – Scalable, fine-grained authorization using Cedar policy language for custom applications
  • AWS Resource Access Manager (RAM) – Securely share AWS resources across accounts and within AWS Organizations
  • AWS Directory Service – Managed Microsoft Active Directory in the AWS Cloud

Detection and Response

  • Amazon GuardDuty – Intelligent threat detection that continuously monitors for malicious activity
    • Extended Threat Detection (re:Invent 2024) – AI/ML-powered attack sequence identification across multiple data sources
    • Now covers EC2, ECS, EKS, S3, and IAM attack sequences
    • Custom entity lists for domain-based threat intelligence (Sept 2025)
  • Amazon Detective – Analyze, investigate, and identify root cause of security findings using ML and graph theory
  • Amazon Inspector – Automated vulnerability management for EC2 instances and container images in ECR
  • AWS Security Hub – Cloud security posture management (CSPM) and unified security operations
    • Reimagined at re:Invent 2025 – Unifies GuardDuty, Inspector, and other services into a single experience
    • Near real-time analytics and risk prioritization (GA Dec 2025)
    • Extended Plan (GA Feb 2026) – Full-stack enterprise security with 21 curated partner solutions across 9 categories
    • Expanding to multicloud environments
  • AWS Security Agent (GA March 2026) – AI-powered frontier agent for proactive application security
    • Automated security reviews tailored to organizational requirements
    • On-demand context-aware penetration testing
    • Full repository code scanning (Preview May 2026)
    • Operates like a human penetration tester – identifies, exploits, and validates vulnerabilities

Data Protection

Network and Application Protection

  • AWS WAF – Web application firewall to protect against common web exploits and bots
  • AWS Shield – Managed DDoS protection (Standard and Advanced tiers)
  • AWS Network Firewall – Managed network firewall for VPC with stateful inspection and IPS
  • AWS Firewall Manager – Centrally configure and manage firewall rules across accounts in AWS Organizations

Security Data Management and Compliance

  • Amazon Security Lake – Centralize security data from AWS, SaaS, on-premises using OCSF standard
    • Achieved FedRAMP High and Moderate authorization (April 2025)
  • AWS Audit Manager – Continuously audit AWS usage for risk and compliance assessment
  • AWS Artifact – On-demand access to AWS security and compliance reports

Key Updates (2024-2026)

  • MFA Enforcement (2024-2025) – AWS now mandates MFA for all root users across all account types. Prevents over 99% of password-related attacks.
  • AWS Security Hub Reimagined (re:Invent 2025) – Completely redesigned to unify security services into a single experience with near real-time analytics and AI-driven risk prioritization.
  • AWS Security Agent (GA March 2026) – First AI-powered frontier agent for autonomous application security testing and code scanning.
  • GuardDuty Extended Threat Detection (re:Invent 2024) – AI/ML attack sequence identification now covers EC2, ECS, EKS workloads.
  • IAM Identity Center Multi-Region (Feb 2026) – Replicate identity center configuration across multiple AWS Regions for high availability.
  • Amazon Cognito Passwordless (Nov 2024) – Native passkey support with FIDO2/WebAuthn, email OTP, and SMS OTP authentication.
  • Centralized Root Access Management (Nov 2024) – Centrally manage root credentials and perform privileged tasks across AWS Organizations member accounts.
  • Agentic AI Security Framework (2025) – New Agentic AI Security Scoping Matrix for securing autonomous AI systems.

AWS Certification Relevance

  • Solutions Architect (Associate/Professional) – IAM, VPC security, encryption, Security Hub, GuardDuty
  • Security Specialty – All services in depth, including Security Lake, Detective, Macie, Inspector
  • SysOps Administrator – Security Hub, Config, GuardDuty, IAM best practices
  • Developer Associate – Cognito, IAM roles, KMS, Secrets Manager
  • DevOps Professional – Security automation, Inspector, Security Hub integrations