Cross-Account Access with IAM Roles Quiz Quiz

Enhance your understanding of cross-account access using IAM roles with this quiz. Evaluate your knowledge of permissions, trust policies, role assumption, and secure practices for granting access across different cloud accounts.

1. Role Assumption Basics

   Which statement best describes how cross-account access is typically established using IAM roles in cloud environments?

   1. Roles are shared between accounts using public URLs.
   2. An IAM user in Account A assumes a role in Account B based on trust policies.
   3. An IAM role in Account A directly logs into Account B with a password.
   4. Account B users copy their credentials to Account A for access.

   Explanation: Cross-account access usually involves an IAM user from one account assuming a role in another account, as defined by trust policies that grant such permission. Directly logging in with a role or exchanging passwords is not a secure or supported way to establish access. Sharing roles through public URLs would expose sensitive permissions and is not a recommended or feasible method.

2. Trust Policy Purpose

   What is the main purpose of the trust policy attached to an IAM role when enabling cross-account access?

   1. It specifies which external accounts or entities are permitted to assume the role.
   2. It defines the billing information for role usage.
   3. It logs all actions performed by the role.
   4. It sets password requirements for users of the role.

   Explanation: The trust policy determines which accounts or entities can assume the role, forming the basis of secure cross-account access. While billing, password policies, and activity logging are important, they are managed elsewhere and not the primary function of a trust policy. Therefore, only the first option correctly explains the purpose of a trust policy.

3. Permissions in Practice

   If Account A wants users to list storage buckets in Account B using a role, where should the necessary permissions be defined?

   1. On the storage buckets' metadata directly.
   2. In the role’s policy in Account B granting listing access.
   3. In a password policy shared between accounts.
   4. In Account A’s user policy providing access to Account B resources.

   Explanation: Permissions for resources should be defined within the role's policy in Account B, granting the ability to list storage buckets. Assigning permissions in Account A's user policy will not extend to Account B's resources. Modifying bucket metadata alone won't grant cross-account access, and password policies are unrelated to resource permissions.

4. AssumeRole API Purpose

   What is the primary function of the AssumeRole API in the context of cross-account access?

   1. To permanently assign a user's permissions to a different account.
   2. To obtain temporary security credentials for a role in another account.
   3. To synchronize user passwords across accounts.
   4. To create new storage buckets in another account.

   Explanation: The AssumeRole API is used to request temporary credentials to access resources as a specified role in a different account. It does not permanently assign permissions, create storage buckets, or synchronize passwords between accounts. The other options describe unrelated or incorrect actions.

5. Required Permissions for Role Assumption

   What permission must an IAM user have in order to assume a role for cross-account access?

   1. Permission to call the AssumeRole action on the role's resource.
   2. Permission to change the trust policy in the other account.
   3. Permission to edit password policies in the source account.
   4. Permission to create users in the destination account.

   Explanation: The user must have permission to invoke the AssumeRole action specifically on the role’s resource to assume a role. Creating users or editing trust and password policies are different administrative activities and not prerequisites for assuming roles between accounts.

6. Role Session Duration

   How long do the temporary credentials obtained from assuming a cross-account role typically remain valid unless otherwise specified?

   1. One year
   2. One hour
   3. Permanently
   4. Five minutes

   Explanation: Temporary credentials from role assumption default to being valid for one hour, although the duration can sometimes be customized up to a maximum set by the role. Credentials do not last for a year, are never permanent, and five minutes would be uncommonly short and not the default.

7. Best Practice for Access Restriction

   When setting up a cross-account IAM role, what is a recommended best practice regarding permissions?

   1. Grant only the minimum set of permissions required for tasks.
   2. Allow all actions for simplicity.
   3. Use the same access key for all roles.
   4. Enable password reuse across accounts.

   Explanation: Applying the principle of least privilege by granting only necessary permissions reduces security risks from over-privileged access. Allowing all actions introduces vulnerabilities, password reuse is insecure, and sharing access keys across roles undermines auditability and security.

8. Verifying Role Assumption

   If a user in Account A is unable to assume a role in Account B, what should you check first?

   1. If the role name matches the user name.
   2. That the storage bucket name is unique.
   3. Whether the user’s email is identical in both accounts.
   4. The role's trust policy in Account B includes Account A.

   Explanation: The trust policy must explicitly allow Account A (or its users) to assume the role; otherwise, access is blocked. User email addresses, storage bucket names, and role-name/user-name matches do not fundamentally determine cross-account role access rights.

9. Limiting Role Sessions

   Which option would best help limit the risks associated with cross-account role sessions?

   1. Require multi-factor authentication (MFA) before assuming the role.
   2. Disable time-based restrictions on credentials.
   3. Share the temporary credentials with multiple users.
   4. Allow anonymous users to assume the role.

   Explanation: Requiring MFA adds an extra layer of security to role assumption, verifying the user's identity. Disabling time restrictions increases risk, while anonymous use or sharing credentials weakens accountability and access control, making these poor choices for limiting risks.

10. Secure Credential Handling

    When a user receives temporary credentials by assuming a cross-account IAM role, what is the secure way to use them?

    1. Convert the credentials to a password for other accounts.
    2. Use the credentials only for authorized tasks during their validity period.
    3. Store the credentials in a public document for convenience.
    4. Forward the credentials by email for reuse.

    Explanation: Temporary credentials should be used exclusively for the allowed tasks and only while they are valid. Publishing, converting, or sharing the credentials undermines security and opens the account to unauthorized or malicious access. Keeping credentials private and task-specific is the secure and intended practice.