How should I use these Identity and Access Management practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Identity and Access Management questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Identity and Access Management domain.

SCS-C02 · topic practice

Identity and Access Management practice questions

This domain covers how AWS evaluates every request: IAM users, groups, roles, and policies, plus resource-based policies, permission boundaries, SCPs, and identity federation. You must read policy JSON and predict the effective permission, including explicit denies, trust policies, and cross-account access. Expect scenario questions on least-privilege design and credential handling.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

20 questionsDomain: Identity and Access Management

Practice 10 questions Browse domain →

What the exam tests

What to know about Identity and Access Management

Given a scenario, determine the effective permissions by combining identity policies, resource policies, boundaries, SCPs, and conditions, then choose the least-privilege option. The single most important thing: an explicit Deny always wins, and roles with temporary credentials beat embedded access keys.

Reading IAM identity-based and resource-based policy JSON to determine effective allow or deny

Distinguishing IAM roles and STS AssumeRole from long-term access keys for AWS service access

Applying permissions boundaries, SCPs, and session policies as permission guardrails

Using iam:ChangePassword, iam:GetUser, and MFA conditions for self-service and console access

Watch out for

Common Identity and Access Management exam traps

▸Forgetting that an explicit Deny in any applicable policy overrides every Allow, including administrator access.
▸Assuming a resource-based policy alone grants access without checking the identity's own permissions or account trust.
▸Confusing permissions boundaries with SCPs: boundaries limit identities, SCPs limit accounts in Organizations.

Practice set

Identity and Access Management questions

20 questions · select your answer, then reveal the explanation

Question 1hardmultiple choice

Read the full Identity and Access Management explanation →

An IAM policy includes the following condition: "StringNotEquals": {"aws:SourceArn": "arn:aws:ec2:us-east-1:123456789012:instance/*"}. What is the effect of this condition when attached to an IAM role?

Trap 1: Denies all requests from EC2 instances

The StringNotEquals operator tests whether the condition key's value does not match the specified string. When the source ARN matches the exact pattern in the policy, the condition evaluates to false, so the Deny effect does not apply and the request is not denied. Therefore, requests from EC2 instances that match the specified account and region ARN are unaffected; only non-matching sources — including EC2 instances outside the specified scope — would be denied.

Trap 2: Allows the role to be assumed only by EC2 instances in the…

This option misreads a Deny statement as an Allow effect. StringNotEquals in a Deny statement means that requests are blocked when the source ARN differs from the specified value; it does not create a positive permission that allows role assumption. To restrict assumption to a specific account and region, you would need an explicit Allow statement on sts:AssumeRole with a StringEquals condition, not a Deny statement with StringNotEquals. A standalone Deny cannot grant access, so this explanation is incorrect.

Trap 3: Allows any request that comes from an EC2 instance regardless of…

This option incorrectly assumes the policy allows all EC2 instances from any account. The condition is not a broad EC2-based allow; it is a Deny with a StringNotEquals condition on an ARN that is scoped to a specific account and region. An EC2 instance from a different account or region will have an ARN that does not match the pattern, making the condition true and triggering the Deny. Furthermore, a Deny statement never grants permissions — if there is no explicit allow in the same policy, the request would be implicitly denied by default, so the statement cannot be interpreted as an allow.

Study all Identity and Access Management common traps →

A
Denies all requests from EC2 instances
Why it fails: The StringNotEquals operator tests whether the condition key's value does not match the specified string. When the source ARN matches the exact pattern in the policy, the condition evaluates to false, so the Deny effect does not apply and the request is not denied. Therefore, requests from EC2 instances that match the specified account and region ARN are unaffected; only non-matching sources — including EC2 instances outside the specified scope — would be denied.
B
Allows the role to be assumed only by EC2 instances in the specified account and region
Why it fails: This option misreads a Deny statement as an Allow effect. StringNotEquals in a Deny statement means that requests are blocked when the source ARN differs from the specified value; it does not create a positive permission that allows role assumption. To restrict assumption to a specific account and region, you would need an explicit Allow statement on sts:AssumeRole with a StringEquals condition, not a Deny statement with StringNotEquals. A standalone Deny cannot grant access, so this explanation is incorrect.
C
Denies requests that do not originate from an EC2 instance in the specified account and region
This option correctly recognizes how StringNotEquals works in a Deny statement. The policy sets a condition key (such as ec2:SourceInstanceARN or aws:SourceArn) to a specific ARN pattern that includes a particular account and region. When a request originates from a source whose ARN does not match that pattern — for example, an instance in another account, another region, or a non-EC2 principal — the StringNotEquals condition is true and the Deny effect blocks the request. Conversely, if the source ARN matches the specified pattern, the condition is false and the Deny does not fire, so the request is allowed. This matches the given answer.
D
Allows any request that comes from an EC2 instance regardless of account
Why it fails: This option incorrectly assumes the policy allows all EC2 instances from any account. The condition is not a broad EC2-based allow; it is a Deny with a StringNotEquals condition on an ARN that is scoped to a specific account and region. An EC2 instance from a different account or region will have an ARN that does not match the pattern, making the condition true and triggering the Deny. Furthermore, a Deny statement never grants permissions — if there is no explicit allow in the same policy, the request would be implicitly denied by default, so the statement cannot be interpreted as an allow.

Full breakdown with real-world context →

Question 2easymultiple choice

Read the full Identity and Access Management explanation →

An IAM user receives an 'AccessDenied' error when trying to list objects in an S3 bucket. The user has the following policy attached: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:ListBucket","Resource":"arn:aws:s3:::example-bucket"}]}. What is the most likely reason?

Trap 1: The policy is missing a condition

Conditions are not required.

Trap 2: The policy does not include s3:GetObject

ListBucket is sufficient to list objects; GetObject is for reading objects.

Trap 3: The policy has a syntax error

The policy is valid JSON.

Study all Identity and Access Management common traps →

A
The policy is missing a condition
Why it fails: Conditions are not required.
B
The bucket policy explicitly denies the action
An explicit Deny in a bucket policy overrides the identity-based Allow, because AWS evaluates all applicable policies and any Deny wins. The s3:ListBucket Allow on the bucket ARN is therefore negated by the bucket policy.
C
The policy does not include s3:GetObject
Why it fails: ListBucket is sufficient to list objects; GetObject is for reading objects.
D
The policy has a syntax error
Why it fails: The policy is valid JSON.

Full breakdown with real-world context →

Question 3easymulti select

Read the full Identity and Access Management explanation →

Which TWO are valid ways to authenticate to AWS for API calls? (Choose two.)

Trap 1: SSH key pairs

SSH key pairs are used to authenticate to EC2 instances at the OS level (for example, to log in as ec2-user or ubuntu) or for Git repositories, not to sign AWS API requests. AWS API calls require IAM credentials—either access keys or temporary STS credentials—that are validated by IAM against the account's policies. The presence of a key pair in EC2 does not map to IAM permissions for control-plane operations, so it cannot authenticate an API call.

Trap 2: Database master password

A database master password authenticates to the database engine itself—such as an RDS PostgreSQL or MySQL instance—for data-plane operations like connecting and running SQL queries. It does not authenticate to the AWS Control Plane, nor does it provide any IAM identity or permissions to call AWS service APIs. Even if the password is stored in Secrets Manager, retrieving it only grants database access, not API access.

Trap 3: Root user access keys

Although access keys can be generated for the root user and would technically sign a SigV4 request, AWS strongly prohibits creating or using them because the root account has unrestricted administrative access and cannot be locked down by policies. Using root keys bypasses all IAM security controls, MFA requirements, and auditability, making it an unsafe and effectively invalid way to authenticate for API calls. AWS documentation and the Well-Architected Framework direct you to create an IAM user or role instead, so this option is not considered a valid choice.

Study all Identity and Access Management common traps →

A
SSH key pairs
Why it fails: SSH key pairs are used to authenticate to EC2 instances at the OS level (for example, to log in as ec2-user or ubuntu) or for Git repositories, not to sign AWS API requests. AWS API calls require IAM credentials—either access keys or temporary STS credentials—that are validated by IAM against the account's policies. The presence of a key pair in EC2 does not map to IAM permissions for control-plane operations, so it cannot authenticate an API call.
B
IAM user access keys
IAM user access keys are long-term credentials composed of an access key ID and a secret access key, used to sign AWS API requests using Signature Version 4. These keys uniquely identify the IAM principal and carry whatever permissions are attached to that user's IAM policies, making them a completely valid way to programmatically authenticate to AWS. For security, best practice is to rotate them regularly and prefer temporary credentials when possible.
C
Database master password
Why it fails: A database master password authenticates to the database engine itself—such as an RDS PostgreSQL or MySQL instance—for data-plane operations like connecting and running SQL queries. It does not authenticate to the AWS Control Plane, nor does it provide any IAM identity or permissions to call AWS service APIs. Even if the password is stored in Secrets Manager, retrieving it only grants database access, not API access.
D
Temporary credentials from an IAM role
Temporary credentials are issued by AWS STS through APIs like AssumeRole, GetSessionToken, or the EC2 instance metadata service, and they consist of an access key, secret key, and a session token. These credentials are short-lived (typically 15 minutes to 12 hours) and are automatically scoped by the role's trust policy and permissions, providing a secure and valid means to authenticate API calls. They are the recommended method for workloads running on EC2, ECS, Lambda, or any environment that can assume a role.
E
Root user access keys
Why it fails: Although access keys can be generated for the root user and would technically sign a SigV4 request, AWS strongly prohibits creating or using them because the root account has unrestricted administrative access and cannot be locked down by policies. Using root keys bypasses all IAM security controls, MFA requirements, and auditability, making it an unsafe and effectively invalid way to authenticate for API calls. AWS documentation and the Well-Architected Framework direct you to create an IAM user or role instead, so this option is not considered a valid choice.

Full breakdown with real-world context →

Question 4hardmultiple choice

Read the full Identity and Access Management explanation →

Refer to the exhibit. A security engineer runs the command above. Which of the following is true about the role MyRole?

Network Topology

Trap 1: The role has a resource-based policy attached

An IAM role's trust policy is a resource-based policy, so the role does have a resource-based policy attached. Therefore, this statement is true, but it is not the most specific answer based on the command shown.

Trap 2: The role can be assumed by any IAM user in account 123456789012

The trust policy's Principal is "ec2.amazonaws.com", which is the EC2 service principal, not an AWS account ID or an IAM user ARN. IAM grants sts:AssumeRole only to the exact principal named in the trust policy, so IAM users in account 123456789012 are not authorized by this policy. Even if a user has sts:AssumeRole permissions in their own IAM policy, the role's trust policy will reject their request.

Trap 3: The role can be assumed by any AWS service

The Principal element is explicitly limited to the service principal ec2.amazonaws.com; it does not include other AWS service principals such as lambda.amazonaws.com, s3.amazonaws.com, or ecs-tasks.amazonaws.com. Although a service principal might appear generic, only the listed EC2 service is allowed to assume the role. Therefore, the statement overstates the scope of the trust relationship.

Study all Identity and Access Management common traps →

A
The role has a resource-based policy attached
Why it fails: An IAM role's trust policy is a resource-based policy, so the role does have a resource-based policy attached. Therefore, this statement is true, but it is not the most specific answer based on the command shown.
B
The role can be assumed by any IAM user in account 123456789012
Why it fails: The trust policy's Principal is "ec2.amazonaws.com", which is the EC2 service principal, not an AWS account ID or an IAM user ARN. IAM grants sts:AssumeRole only to the exact principal named in the trust policy, so IAM users in account 123456789012 are not authorized by this policy. Even if a user has sts:AssumeRole permissions in their own IAM policy, the role's trust policy will reject their request.
C
The role can be assumed by any AWS service
Why it fails: The Principal element is explicitly limited to the service principal ec2.amazonaws.com; it does not include other AWS service principals such as lambda.amazonaws.com, s3.amazonaws.com, or ecs-tasks.amazonaws.com. Although a service principal might appear generic, only the listed EC2 service is allowed to assume the role. Therefore, the statement overstates the scope of the trust relationship.
D
The role can be assumed by EC2 instances
The trust policy contains a statement granting sts:AssumeRole when the Principal is ec2.amazonaws.com, so the EC2 service is authorized to obtain temporary credentials for this role. When an EC2 instance is launched with an instance profile that references this role, EC2 calls sts:AssumeRole on behalf of the instance. This matches the exact intent of a service role for EC2.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full Identity and Access Management explanation →

A company has a multi-account AWS Organization with three accounts: Management, Development, and Production. The Security team uses the Management account to manage IAM policies centrally. They have created a service control policy (SCP) named 'RestrictRootAccess' that denies all actions for the root user in all accounts. The SCP is attached to the root organizational unit. The Development account has an IAM role 'DevAdmin' with full administrator access via an IAM policy. The role's trust policy allows the Management account's 'SecurityAudit' role to assume it. A security engineer in the Management account assumes the 'SecurityAudit' role and then tries to assume the 'DevAdmin' role in the Development account. The assumption fails with an 'AccessDenied' error. What is the most likely cause?

Trap 1: The SCP is attached to the root OU and overrides any allow in the…

An SCP attached at the root OU is a guardrail that restricts the maximum permitted IAM actions for principals in member accounts, but it cannot override or negate a resource-based trust policy on a role. Cross-account sts:AssumeRole is governed by the combination of the requesting principal's identity-based permissions and the target role's trust policy; organization-level SCPs do not affect or replace that trust authorization.

Trap 2: The SCP 'RestrictRootAccess' denies the sts:AssumeRole action for…

The SCP named RestrictRootAccess, by its name, restricts the AWS root user's management account privileges—it does not deny sts:AssumeRole for IAM roles. SCPs apply to IAM principals within the account they are attached to, not to accounts outside that OU, and they cannot alter the trust relationship of a role in another member account. The actual failing point remains the trust policy, not this SCP.

Trap 3: The 'SecurityAudit' role requires MFA to assume the 'DevAdmin' role

The scenario does not include any MFA condition in the DevAdmin role's trust policy, nor does it mention an MFA requirement from the SecurityAudit role. MFA would only block assumption if the trust policy contained a condition such as aws:MultiFactorAuthPresent: true, and even then it would be in addition to the required principal allow. The failure stems from the absence of a trust relationship, not from an MFA gate.

Study all Identity and Access Management common traps →

A
The SCP is attached to the root OU and overrides any allow in the member accounts
Why it fails: An SCP attached at the root OU is a guardrail that restricts the maximum permitted IAM actions for principals in member accounts, but it cannot override or negate a resource-based trust policy on a role. Cross-account sts:AssumeRole is governed by the combination of the requesting principal's identity-based permissions and the target role's trust policy; organization-level SCPs do not affect or replace that trust authorization.
B
The trust policy of the 'DevAdmin' role does not grant sts:AssumeRole to the 'SecurityAudit' role
For a cross-account role assumption, the target role's trust policy must explicitly list the ARN or AWS account of the requesting principal as an allowed sts:AssumeRole principal. If the DevAdmin role's trust policy does not name the SecurityAudit role or the member account, the request is denied even if identity-based policies allow the action—because sts:AssumeRole requires an explicit allow in both the identity policy and the trust policy.
C
The SCP 'RestrictRootAccess' denies the sts:AssumeRole action for all principals except root
Why it fails: The SCP named RestrictRootAccess, by its name, restricts the AWS root user's management account privileges—it does not deny sts:AssumeRole for IAM roles. SCPs apply to IAM principals within the account they are attached to, not to accounts outside that OU, and they cannot alter the trust relationship of a role in another member account. The actual failing point remains the trust policy, not this SCP.
D
The 'SecurityAudit' role requires MFA to assume the 'DevAdmin' role
Why it fails: The scenario does not include any MFA condition in the DevAdmin role's trust policy, nor does it mention an MFA requirement from the SecurityAudit role. MFA would only block assumption if the trust policy contained a condition such as aws:MultiFactorAuthPresent: true, and even then it would be in addition to the required principal allow. The failure stems from the absence of a trust relationship, not from an MFA gate.

Full breakdown with real-world context →

Question 6hardmultiple choice

Read the full Identity and Access Management explanation →

A developer is trying to upload an object to an S3 bucket named 'my-bucket' using the AWS CLI. The developer has an IAM user with a policy that includes 's3:PutObject' for 'arn:aws:s3:::my-bucket/*'. However, the upload fails with an 'Access Denied' error. The bucket policy is set to allow all principals from the same AWS account to perform 's3:PutObject'. What is the most likely cause of this failure?

Trap 1: The IAM user is not authorized to perform 's3:PutObject' on the…

Incorrect. The IAM user policy does grant s3:PutObject on the object ARN, so this option is not the cause.

Trap 2: The IAM policy grants 's3:PutObject' only on objects (/*), but the…

Incorrect. s3:PutObject does not require permission on the bucket ARN; the action is always on objects. The error stems from the bucket policy not listing the IAM user.

Trap 3: The bucket 'my-bucket' does not exist in the same region as the CLI…

Incorrect. A region mismatch would yield a NoSuchBucket or redirect error, not an Access Denied.

Study all Identity and Access Management common traps →

A
The IAM user is not authorized to perform 's3:PutObject' on the bucket 'my-bucket'.
Why it fails: Incorrect. The IAM user policy does grant s3:PutObject on the object ARN, so this option is not the cause.
B
The bucket policy denies access because the principal is not explicitly listed.
Correct. The bucket policy likely uses the root principal, which does not cover the IAM user, resulting in an implicit deny.
C
The IAM policy grants 's3:PutObject' only on objects (/*), but the request may also require 's3:PutObject' on the bucket itself for some operations.
Why it fails: Incorrect. s3:PutObject does not require permission on the bucket ARN; the action is always on objects. The error stems from the bucket policy not listing the IAM user.
D
The bucket 'my-bucket' does not exist in the same region as the CLI request.
Why it fails: Incorrect. A region mismatch would yield a NoSuchBucket or redirect error, not an Access Denied.

Full breakdown with real-world context →

Question 7hardmultiple choice

Read the full Identity and Access Management explanation →

An IAM policy is attached to a user. The user is trying to change their own password in the IAM console but receives an 'Access Denied' error. The user has an MFA device configured and is logged in with MFA. Why is the password change failing?

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:ChangePassword",
      "Resource": "*"
    }
  ]
}

Trap 1: The Allow statement for iam:ChangePassword is not sufficient…

The Deny is conditional; if the condition is not met, the Deny does not apply. But the condition is met due to BoolIfExists.

Trap 2: The Deny statement denies all actions unconditionally, so the Allow…

The Deny has a condition; it is not unconditional.

Trap 3: The user does not have permission to change their own password…

The Allow statement allows iam:ChangePassword on all resources, which includes the user's own password.

Study all Identity and Access Management common traps →

A
The Allow statement for iam:ChangePassword is not sufficient because the Deny statement explicitly denies all actions.
Why it fails: The Deny is conditional; if the condition is not met, the Deny does not apply. But the condition is met due to BoolIfExists.
B
The Deny statement uses 'BoolIfExists' which evaluates to true if the condition key is not present. In the IAM console, the 'aws:MultiFactorAuthPresent' key may not be set, causing the Deny to apply even when the user has MFA.
The Deny statement's BoolIfExists condition evaluates true when aws:MultiFactorAuthPresent is absent. The IAM console's ChangePassword call does not populate that key, so the Deny matches and overrides the Allow, producing Access Denied despite the user having authenticated with MFA.
C
The Deny statement denies all actions unconditionally, so the Allow statement cannot override it.
Why it fails: The Deny has a condition; it is not unconditional.
D
The user does not have permission to change their own password because the Allow statement is not specific enough.
Why it fails: The Allow statement allows iam:ChangePassword on all resources, which includes the user's own password.

Full breakdown with real-world context →

Question 8hardmulti select

Read the full Identity and Access Management explanation →

A security engineer is designing a solution to allow an external auditor to access logs in an S3 bucket in the company's AWS account. The auditor does not have an AWS account. The engineer needs to grant read-only access to the specific bucket for a limited time. Which TWO actions should the engineer take? (Choose two.)

Trap 1: Enable S3 Access Analyzer on the bucket to generate findings for…

Access Analyzer only identifies potential access issues; it does not grant access.

Trap 2: Create a cross-account IAM role in the company's account and share…

The auditor does not have an AWS account to assume the role.

Trap 3: Configure the bucket policy to grant access to 'Principal': '*'…

This would make the bucket public; not recommended for sensitive logs.

Study all Identity and Access Management common traps →

A
Enable S3 Access Analyzer on the bucket to generate findings for the auditor.
Why it fails: Access Analyzer only identifies potential access issues; it does not grant access.
B
Create a cross-account IAM role in the company's account and share the role ARN with the auditor.
Why it fails: The auditor does not have an AWS account to assume the role.
C
Use AWS STS to issue temporary credentials that the auditor can use to access the bucket.
AWS STS issues temporary, time-limited credentials via AssumeRole, satisfying the auditor's lack of an AWS account and the limited-time constraint. The auditor receives an access key, secret key and session token, which the S3 bucket policy or IAM role trust policy scopes to read-only access on that specific bucket.
D
Generate a pre-signed URL for each log file the auditor needs to access.
Pre-signed URLs embed the engineer's credentials in a time-limited signature, letting the auditor download individual objects over HTTPS without any AWS account or identity. This satisfies the no-account constraint, but only for named files, so it complements rather than replaces bucket-wide access.
E
Configure the bucket policy to grant access to 'Principal': '*' with a condition that limits access to the auditor's IP address.
Why it fails: This would make the bucket public; not recommended for sensitive logs.

Full breakdown with real-world context →

Question 9mediumdrag order

Read the full Identity and Access Management explanation →

Drag and drop the steps to configure AWS CloudTrail for logging across all regions and accounts in the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Create a CloudTrail trail, then create an S3 bucket, then configure…

A CloudTrail trail requires an existing S3 bucket as the destination for log delivery at the moment of creation. The trail creation API asks for a bucket name and attempts to write a validation log immediately; if the bucket is missing, the trail creation fails because there is no destination to receive the log files. Since no bucket exists in this sequence, the first step is invalid and none of the later steps can be reached.

Trap 2: Create an S3 bucket, then create a CloudTrail trail, then enable…

This is incorrect because enabling log file integrity validation before configuring the trail to apply to all regions is logically out of order. While both settings are independent, the recommended best practice is to set multi-region first, and integrity validation can be enabled anytime after trail creation.

Trap 3: Create an S3 bucket, then create an organization trail, then create…

An organization trail is not a separate resource that you create before a normal CloudTrail trail; it is a standard trail with the `IsOrganizationTrail` attribute set to true by the management account. You must first create the trail resource, then designate it as an organization trail to enable log delivery from all accounts in the AWS organization. Attempting to create an organization trail before the underlying trail exists is impossible because there is no trail resource to configure with the organization-wide flag.

Study all Identity and Access Management common traps →

A
Create an S3 bucket, then create a CloudTrail trail, then configure the trail to apply to all regions, then enable log file integrity validation, then create an organization trail.
This is the correct order because you must first create an S3 bucket to store logs, then create the trail specifying that bucket, apply the trail to all regions to cover all AWS regions, enable integrity validation to ensure log files have not been tampered with, and finally create an organization trail to aggregate logs from all accounts in the organization.
B
Create a CloudTrail trail, then create an S3 bucket, then configure the trail to apply to all regions, then enable log file integrity validation, then create an organization trail.
Why it fails: A CloudTrail trail requires an existing S3 bucket as the destination for log delivery at the moment of creation. The trail creation API asks for a bucket name and attempts to write a validation log immediately; if the bucket is missing, the trail creation fails because there is no destination to receive the log files. Since no bucket exists in this sequence, the first step is invalid and none of the later steps can be reached.
C
Create an S3 bucket, then create a CloudTrail trail, then enable log file integrity validation, then configure the trail to apply to all regions, then create an organization trail.
Why it fails: This is incorrect because enabling log file integrity validation before configuring the trail to apply to all regions is logically out of order. While both settings are independent, the recommended best practice is to set multi-region first, and integrity validation can be enabled anytime after trail creation.
D
Create an S3 bucket, then create an organization trail, then create a CloudTrail trail, then configure the trail to apply to all regions, then enable log file integrity validation.
Why it fails: An organization trail is not a separate resource that you create before a normal CloudTrail trail; it is a standard trail with the `IsOrganizationTrail` attribute set to true by the management account. You must first create the trail resource, then designate it as an organization trail to enable log delivery from all accounts in the AWS organization. Attempting to create an organization trail before the underlying trail exists is impossible because there is no trail resource to configure with the organization-wide flag.

Full breakdown with real-world context →

Question 10mediummatching

Read the full Identity and Access Management explanation →

Match each AWS KMS key type to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Managed by AWS for use with specific services

Managed by customer with full control

Used internally by AWS, not visible to customers

Key store backed by AWS CloudHSM

Trap 1: Customer managed key: AWS creates and manages the key, but you can…

This statement is false for customer managed keys because cloudHSM? No, that's wrong—the real issue is that AWS does not create customer managed keys; you create them. With a customer managed key, you control rotation, deletion, and key policies, while AWS only provides the underlying service. The characteristics described—AWS manages the key while you simply view and audit it—are exactly what defines an AWS managed key, making this option an incorrect description.

Trap 2: AWS managed key: You create, manage, and control the key lifecycle.

This option reverses the actual definition of an AWS managed key: AWS itself provisions and manages the key on behalf of a service, not the customer. You cannot create, rotate, delete, or write key policies for it; AWS does all of that automatically to protect your resources. Controlling lifecycle and policies is the hallmark of a customer managed key, so attributing that control to an AWS managed key is a classic exam trap.

Study all Identity and Access Management common traps →

A
Customer managed key: You create, manage, and control the key lifecycle, including rotation, deletion, and policies.
Customer managed keys are KMS keys that you create and fully own within your AWS account, giving you granular control over the entire lifecycle. You can set rotation schedules, define deletion windows, and attach key policies that determine which principals and services can encrypt or decrypt. This control is what separates them from AWS managed keys, where AWS defines policy and rotation, and from AWS owned keys, which you cannot access at all.
B
AWS managed key: AWS creates and manages the key on your behalf, but you can view it and audit its usage.
An AWS managed key is created by a service to protect resources on your behalf, and AWS handles the key material, automatic annual rotation, and the key policy. You cannot alter the policy or schedule deletion, but you can see the key in the console and audit every cryptographic operation via CloudTrail. That visibility is a key difference from AWS owned keys, which are completely invisible and shared across accounts.
C
AWS owned key: You cannot view or manage the key; it is owned and managed by AWS and used to protect resources in many accounts.
An AWS owned key is a KMS key that resides in a service's own AWS account, not your account, and it is shared across many accounts to protect service-side data. You cannot view these keys in the console, audit their usage, or manage them in any way—there is no customer access. This differs from AWS managed keys, which exist in your account and appear in your audit logs, and from customer managed keys, which you control fully.
D
Custom key store (CloudHSM): Keys are stored in a CloudHSM cluster under your control, providing single-tenant hardware security modules.
A custom key store connects KMS to a CloudHSM cluster that you provision and control, giving you single-tenant hardware security modules for key storage. Unlike regular KMS keys, which are generated and stored in AWS's shared, multi-tenant HSM fleet, the cryptographic material for your keys is created and stored in your own HSMs. This allows you to meet strict compliance or regulatory requirements while still using the KMS API for encryption operations and lifecycle management.
E
Customer managed key: AWS creates and manages the key, but you can view it and audit its usage.
Why it fails: This statement is false for customer managed keys because cloudHSM? No, that's wrong—the real issue is that AWS does not create customer managed keys; you create them. With a customer managed key, you control rotation, deletion, and key policies, while AWS only provides the underlying service. The characteristics described—AWS manages the key while you simply view and audit it—are exactly what defines an AWS managed key, making this option an incorrect description.
F
AWS managed key: You create, manage, and control the key lifecycle.
Why it fails: This option reverses the actual definition of an AWS managed key: AWS itself provisions and manages the key on behalf of a service, not the customer. You cannot create, rotate, delete, or write key policies for it; AWS does all of that automatically to protect your resources. Controlling lifecycle and policies is the hallmark of a customer managed key, so attributing that control to an AWS managed key is a classic exam trap.

Full breakdown with real-world context →

Question 11mediummatching

Read the full Identity and Access Management explanation →

Match each AWS CloudHSM feature to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Hardware security module

Cryptographic token interface standard

Java Cryptography Extension provider

Security standard for cryptographic modules

Trap 1: Multi-tenant: Multiple customers share the same HSM.

AWS CloudHSM is explicitly single-tenant: each HSM is dedicated entirely to one customer and is not shared with any other AWS account. A multi-tenant design would defeat the primary purpose of a hardware security module, which is to create a strong physical and logical boundary around sensitive cryptographic material. CloudHSM's dedicated appliance model ensures that only the owning customer has control and visibility into the HSM, and AWS cannot access or retrieve the customer's keys.

Trap 2: HSM client: CloudHSM provides a software-based HSM emulator.

'HSM client' is not a software emulator; it is the software library that applications use to communicate with the dedicated physical CloudHSM device through standard APIs such as PKCS#11, JCE, or Microsoft CNG. CloudHSM runs on dedicated hardware, not a virtualized or software-based HSM, so there is no emulation involved. The client component simply translates API calls from applications into commands sent over a secure network connection to the physical HSM, and it does not perform any cryptographic operations itself.

Study all Identity and Access Management common traps →

A
Dedicated HSM: Each customer gets exclusive access to a hardware security module.
Each CloudHSM user receives a dedicated physical hardware security module appliance that is exclusively allocated to their AWS account, with no multi-tenant sharing at the hardware layer. The HSM is provisioned inside the customer's VPC via elastic network interfaces, giving the customer direct, single-tenant access to the device. This isolation ensures that cryptographic operations and key material are never co-mingled with another customer's data, satisfying strict security and compliance requirements.
B
FIPS 140-2 Level 3: CloudHSM is validated to FIPS 140-2 Level 3.
AWS CloudHSM is a hardware security module that has been validated under the FIPS 140-2 Level 3 standard, the highest level commonly available for commercial HSM services. This validation covers the cryptographic module's physical security, including tamper-evident coatings, tamper-responsive mechanisms, and zeroization of keys upon attempted penetration. Because the module is FIPS 140-2 Level 3 compliant, it is suitable for regulated workloads such as PCI DSS, HIPAA, and U.S. government systems requiring validated cryptography.
C
Automatic replication: CloudHSM automatically replicates keys across multiple HSMs in a cluster.
When you create an AWS CloudHSM cluster, the service automatically replicates all keys, certificates, and cryptographic objects across every HSM in that cluster, ensuring that no single HSM failure results in data loss or service interruption. This replication is managed at the cluster level and is transparent to applications, so a client can use any HSM in the cluster to perform operations on the same key material. Automatic replication also supports high availability and load balancing, because multiple HSMs can service requests while maintaining a consistent cryptographic state.
D
Multi-tenant: Multiple customers share the same HSM.
Why it fails: AWS CloudHSM is explicitly single-tenant: each HSM is dedicated entirely to one customer and is not shared with any other AWS account. A multi-tenant design would defeat the primary purpose of a hardware security module, which is to create a strong physical and logical boundary around sensitive cryptographic material. CloudHSM's dedicated appliance model ensures that only the owning customer has control and visibility into the HSM, and AWS cannot access or retrieve the customer's keys.
E
HSM client: CloudHSM provides a software-based HSM emulator.
Why it fails: 'HSM client' is not a software emulator; it is the software library that applications use to communicate with the dedicated physical CloudHSM device through standard APIs such as PKCS#11, JCE, or Microsoft CNG. CloudHSM runs on dedicated hardware, not a virtualized or software-based HSM, so there is no emulation involved. The client component simply translates API calls from applications into commands sent over a secure network connection to the physical HSM, and it does not perform any cryptographic operations itself.

Full breakdown with real-world context →

Question 12hardmultiple choice

Read the full Identity and Access Management explanation →

A security engineer notices that an IAM user has permissions that are not explicitly granted through any policy. The engineer suspects that the user might have inherited permissions from a group or role. Which IAM feature should the engineer use to identify the source of these permissions?

Trap 1: IAM Roles Anywhere

IAM Roles Anywhere allows workloads outside AWS to assume IAM roles, but it does not help trace the source of permissions for an IAM user.

Trap 2: CloudTrail Insights

CloudTrail Insights analyzes CloudTrail events for unusual activity, not permission sources.

Trap 3: IAM Access Analyzer

IAM Access Analyzer is used to identify unintended access to resources by analyzing resource-based policies, not to trace the source of user permissions.

Study all Identity and Access Management common traps →

A
IAM Roles Anywhere
Why it fails: IAM Roles Anywhere allows workloads outside AWS to assume IAM roles, but it does not help trace the source of permissions for an IAM user.
B
IAM Policy Simulator
The IAM Policy Simulator evaluates the effective permissions for a principal and shows which policies allow or deny each action, revealing whether access originates from a group or role attachment rather than a directly attached policy.
C
CloudTrail Insights
Why it fails: CloudTrail Insights analyzes CloudTrail events for unusual activity, not permission sources.
D
IAM Access Analyzer
Why it fails: IAM Access Analyzer is used to identify unintended access to resources by analyzing resource-based policies, not to trace the source of user permissions.

Full breakdown with real-world context →

Question 13hardmultiple choice

Read the full Identity and Access Management explanation →

An organization wants to enforce that all IAM users use MFA. The security team creates an IAM policy that denies all actions unless MFA is present. However, some users report they cannot even change their own password to enable MFA. What should the security team do to resolve this?

Trap 1: Add a statement that allows all actions when MFA is present.

Adding an allow statement for all actions when MFA is present does not solve the bootstrap problem: users without an MFA device cannot perform any self-service action, including enabling MFA, because the condition on the allow will not match their unauthenticated-MFA session. Moreover, an allow with a condition only grants access when the condition is true; any other existing allow statement that lacks the MFA condition would continue to grant access without MFA, so the policy does not reliably enforce the requirement.

Trap 2: Assign the policy only after users have enabled MFA.

Applying the MFA-required policy only after a user has enrolled MFA is operationally impractical because the user needs access to IAM actions such as iam:CreateVirtualMFADevice and iam:EnableMFADevice before the policy is attached, yet the policy is supposed to be the thing that enforces MFA adherence. In practice, unprivileged users would not be able to enroll at all unless an administrator manually grants temporary permissions, and those temporary grants bypass the security goal during the interim period. Therefore, a self-service exception is necessary.

Trap 3: Remove the MFA condition from the policy.

Removing the MFA condition from the policy eliminates the only mechanism that blocks unauthenticated-MFA requests; the policy would then allow every listed action regardless of whether the caller passed a multi-factor challenge. This directly contradicts the organization's requirement and turns the policy into a standard permissions policy, while users could still voluntarily enable MFA but would never be required to use it.

Study all Identity and Access Management common traps →

A
Add a statement that allows all actions when MFA is present.
Why it fails: Adding an allow statement for all actions when MFA is present does not solve the bootstrap problem: users without an MFA device cannot perform any self-service action, including enabling MFA, because the condition on the allow will not match their unauthenticated-MFA session. Moreover, an allow with a condition only grants access when the condition is true; any other existing allow statement that lacks the MFA condition would continue to grant access without MFA, so the policy does not reliably enforce the requirement.
B
Add an exception statement that allows iam:ChangePassword without MFA.
Creating an explicit exception for iam:ChangePassword as a Deny policy with the condition aws:MultiFactorAuthPresent=false lets a user authenticate with only a password and rotate that password, after which they can self-enroll an MFA device and then all subsequent actions will require MFA. This small exception is considered safe because password changes do not expose the user's other permissions, and it closes the classic bootstrap gap that would otherwise lock users out before they can set up MFA.
C
Assign the policy only after users have enabled MFA.
Why it fails: Applying the MFA-required policy only after a user has enrolled MFA is operationally impractical because the user needs access to IAM actions such as iam:CreateVirtualMFADevice and iam:EnableMFADevice before the policy is attached, yet the policy is supposed to be the thing that enforces MFA adherence. In practice, unprivileged users would not be able to enroll at all unless an administrator manually grants temporary permissions, and those temporary grants bypass the security goal during the interim period. Therefore, a self-service exception is necessary.
D
Remove the MFA condition from the policy.
Why it fails: Removing the MFA condition from the policy eliminates the only mechanism that blocks unauthenticated-MFA requests; the policy would then allow every listed action regardless of whether the caller passed a multi-factor challenge. This directly contradicts the organization's requirement and turns the policy into a standard permissions policy, while users could still voluntarily enable MFA but would never be required to use it.

Full breakdown with real-world context →

Question 14hardmulti select

Read the full Identity and Access Management explanation →

Which THREE are valid ways to grant cross-account access to an S3 bucket? (Choose three.)

Trap 1: Use an IAM user in the source account with access keys.

Using an IAM user in the source account with access keys is not a cross-account access method; it simply identifies the requester as that user within the source account. For the user to reach a bucket in another account, the target bucket policy must explicitly trust that source IAM user ARN, and the source user's own identity policy must also permit the action. This approach relies on long-lived access keys and sharing credentials, which violates security best practices and is not one of the accepted cross-account patterns.

Trap 2: Set the bucket ACL to grant full control to the other account.

Bucket ACLs are a legacy access-control mechanism that predates bucket policies, and they are not a recommended way to grant cross-account access. An ACL can technically grant FULL_CONTROL to another account, but it offers no support for conditions, granular actions, or principals beyond the account-level grant. Modern AWS environments often disable ACLs through S3 Object Ownership settings, and cross-account access should be handled with resource-based policies or access points for security and auditability.

Study all Identity and Access Management common traps →

A
Use an IAM user in the source account with access keys.
Why it fails: Using an IAM user in the source account with access keys is not a cross-account access method; it simply identifies the requester as that user within the source account. For the user to reach a bucket in another account, the target bucket policy must explicitly trust that source IAM user ARN, and the source user's own identity policy must also permit the action. This approach relies on long-lived access keys and sharing credentials, which violates security best practices and is not one of the accepted cross-account patterns.
B
Create an IAM role in the target account and allow the source account to assume it.
This is the canonical cross-account access pattern: the target account creates an IAM role with a trust policy that names the source account as a principal allowed to assume it, and an attached permissions policy defines the maximum actions the role can perform. A user in the source account calls sts:AssumeRole and receives temporary credentials scoped to that role, eliminating the need to share long-lived access keys. Because the trust relationship is explicit and the session is temporary, this is a secure and commonly used pattern for granting access to resources in another account.
C
Use an S3 access point with a policy that allows cross-account access.
An S3 access point is a dedicated endpoint for a bucket that has its own access point policy, which can grant access to principals in a different account. When a request arrives via the access point, the access point policy is evaluated alongside the underlying bucket policy, and the bucket policy can restrict access to requests that come through the access point using aws:SourceAccount or aws:SourceArn conditions. This allows you to grant cross-account access to a specific subset of data without changing the bucket's primary policy, and it is a valid method in this context.
D
Create a bucket policy that grants access to the other account's root user.
Creating a bucket policy that grants access to the other account's root user is a valid resource-based cross-account technique. The bucket policy can list the target account's root ARN as the principal and define specific actions such as s3:GetObject or s3:PutObject for that account. For this to work end-to-end, an IAM principal in the target account must also have matching identity-based permissions from its own account, and the bucket policy must not conflict with any explicit deny. This makes bucket policies a simple but effective way to allow cross-account access to S3 resources.
E
Set the bucket ACL to grant full control to the other account.
Why it fails: Bucket ACLs are a legacy access-control mechanism that predates bucket policies, and they are not a recommended way to grant cross-account access. An ACL can technically grant FULL_CONTROL to another account, but it offers no support for conditions, granular actions, or principals beyond the account-level grant. Modern AWS environments often disable ACLs through S3 Object Ownership settings, and cross-account access should be handled with resource-based policies or access points for security and auditability.

Full breakdown with real-world context →

Question 15hardmultiple choice

Read the full Identity and Access Management explanation →

A security engineer is designing a cross-account access solution. An IAM role in Account A needs to be assumed by users from Account B. Which two components are required?

Trap 1: Permissions boundary on the role to limit permissions

Permissions boundaries only cap the maximum permissions an IAM entity can have; they never grant access or establish a cross-account relationship. In this scenario, attaching a permissions boundary to the role in Account A would at best restrict what the role can do after it is assumed, but the boundary alone does not give Account B's principal any path to call sts:AssumeRole. Cross-account trust requires the role's trust policy and an identity policy in Account B, so a boundary is optional hardening, not the enabling control.

Trap 2: Service control policy in Account A allowing AssumeRole

An SCP in Account A applies only to principals in AWS Organizations under Account A and can only filter away permissions; it cannot grant an external account the ability to call sts:AssumeRole. Since the request originates from Account B, Account A's SCP never evaluates the initiating principal's permissions, and an SCP that 'allows' AssumeRole does not create the required trust relationship between the accounts. The correct design relies on the role's trust policy for the external principal and a permissions policy in Account B.

Trap 3: Resource-based policy on the role allowing cross-account access

IAM roles do not accept a standard resource-based policy attached directly to the role for granting cross-account access; the role's trust policy is the resource-based policy that specifies which principals are allowed to assume it. Creating a separate 'resource-based policy on the role' is an invalid pattern because the only way to authorize an external principal is through the role's trust relationship, combined with the caller's sts:AssumeRole permission. Other services use resource-based policies, but role assumption relies on the trust policy mechanism.

Study all Identity and Access Management common traps →

A
Permissions boundary on the role to limit permissions
Why it fails: Permissions boundaries only cap the maximum permissions an IAM entity can have; they never grant access or establish a cross-account relationship. In this scenario, attaching a permissions boundary to the role in Account A would at best restrict what the role can do after it is assumed, but the boundary alone does not give Account B's principal any path to call sts:AssumeRole. Cross-account trust requires the role's trust policy and an identity policy in Account B, so a boundary is optional hardening, not the enabling control.
B
Service control policy in Account A allowing AssumeRole
Why it fails: An SCP in Account A applies only to principals in AWS Organizations under Account A and can only filter away permissions; it cannot grant an external account the ability to call sts:AssumeRole. Since the request originates from Account B, Account A's SCP never evaluates the initiating principal's permissions, and an SCP that 'allows' AssumeRole does not create the required trust relationship between the accounts. The correct design relies on the role's trust policy for the external principal and a permissions policy in Account B.
C
Trust policy allowing Account B to assume the role, and IAM policy in Account B allowing sts:AssumeRole
The role in Account A must have a trust policy whose Principal is Account B's account ID (or a role/user in Account B) and whose Action is sts:AssumeRole, establishing that Account B is authorized to enter the role. Separately, Account B must attach an IAM identity policy to the user or role that will perform the assumption, granting sts:AssumeRole with a Resource condition or the role ARN as the resource. This two-part pattern is the standard cross-account role access: the trust policy answers 'who may assume' and the caller's identity policy answers 'may this principal initiate it'.
D
Resource-based policy on the role allowing cross-account access
Why it fails: IAM roles do not accept a standard resource-based policy attached directly to the role for granting cross-account access; the role's trust policy is the resource-based policy that specifies which principals are allowed to assume it. Creating a separate 'resource-based policy on the role' is an invalid pattern because the only way to authorize an external principal is through the role's trust relationship, combined with the caller's sts:AssumeRole permission. Other services use resource-based policies, but role assumption relies on the trust policy mechanism.

Full breakdown with real-world context →

Question 16easymultiple choice

Read the full Identity and Access Management explanation →

An IAM user needs to rotate their own access keys. Which IAM policy action should be allowed?

Trap 1: iam:DeleteAccessKey

Wrong. iam:DeleteAccessKey permanently removes the specified access key from the IAM user, and if used too early it can immediately break any workloads still using the old key. In a rotation workflow, deletion is the final cleanup step after UpdateAccessKey has deactivated the old key and a new key has been verified, so DeleteAccessKey alone cannot perform the rotation.

Trap 2: iam:CreateAccessKey

Wrong. iam:CreateAccessKey only provisions a fresh access key; it does not touch the existing key, so the old key would continue to issue valid AWS Signature Version 4 requests. Rotation is not complete until the old key is unusable; having only CreateAccessKey in a policy lets a user proliferate keys but never safely retire one.

Trap 3: iam:ChangePassword

Wrong. iam:ChangePassword governs the user's password for the AWS Management Console sign-in, not programmatic credentials. Access key rotation involves creating a new key pair, deactivating the old key, and removing the old key; changing a password has no effect on any access key's validity or lifecycle.

Study all Identity and Access Management common traps →

A
iam:DeleteAccessKey
Why it fails: Wrong. iam:DeleteAccessKey permanently removes the specified access key from the IAM user, and if used too early it can immediately break any workloads still using the old key. In a rotation workflow, deletion is the final cleanup step after UpdateAccessKey has deactivated the old key and a new key has been verified, so DeleteAccessKey alone cannot perform the rotation.
B
iam:UpdateAccessKey
Correct. iam:UpdateAccessKey lets an IAM user flip the Status of an access key between Active and Inactive, and that deactivation step is what makes rotation safe: you can switch to the new key, disable the old one, verify no breakage, and then delete it. Without this action, the old key would remain usable alongside the new one, defeating the purpose of rotation.
C
iam:CreateAccessKey
Why it fails: Wrong. iam:CreateAccessKey only provisions a fresh access key; it does not touch the existing key, so the old key would continue to issue valid AWS Signature Version 4 requests. Rotation is not complete until the old key is unusable; having only CreateAccessKey in a policy lets a user proliferate keys but never safely retire one.
D
iam:ChangePassword
Why it fails: Wrong. iam:ChangePassword governs the user's password for the AWS Management Console sign-in, not programmatic credentials. Access key rotation involves creating a new key pair, deactivating the old key, and removing the old key; changing a password has no effect on any access key's validity or lifecycle.

Full breakdown with real-world context →

Question 17hardmultiple choice

Read the full Identity and Access Management explanation →

A security engineer notices that an IAM role for an EC2 instance has a policy that allows s3:PutObject on a bucket. However, the application reports access denied when trying to upload. The bucket policy does not explicitly deny access. What is a likely cause?

Trap 1: The bucket policy denies access

Incorrect. The bucket policy does not explicitly deny access as stated in the question. An explicit deny would override, but the scenario says no explicit deny.

Trap 2: The instance profile is not attached to the EC2 instance

Incorrect. If the instance profile were not attached, the role would not be available to the EC2 instance, but the role is attached and has the policy.

Trap 3: The role's policy does not include s3:PutObject

Incorrect. The role policy does include s3:PutObject, so this is not the issue.

Study all Identity and Access Management common traps →

A
The bucket policy denies access
Why it fails: Incorrect. The bucket policy does not explicitly deny access as stated in the question. An explicit deny would override, but the scenario says no explicit deny.
B
The instance profile is not attached to the EC2 instance
Why it fails: Incorrect. If the instance profile were not attached, the role would not be available to the EC2 instance, but the role is attached and has the policy.
C
The role's policy does not include s3:PutObject
Why it fails: Incorrect. The role policy does include s3:PutObject, so this is not the issue.
D
The policy condition key does not match the request context
Identity-based policies and bucket policies are evaluated together, and a condition such as s3:prefix or aws:SourceVpce that does not match the actual request context causes an implicit deny. The explicit Allow never applies, producing Access Denied despite no Deny statement.

Full breakdown with real-world context →

Question 18hardmultiple choice

Read the full Identity and Access Management explanation →

A security engineer needs to ensure that an IAM role can be assumed only from a specific VPC. Which IAM policy condition key should be used?

Trap 1: aws:RequestedRegion

This condition key restricts the AWS region from which a request can be made, not the VPC.

Trap 2: aws:VpcSourceIp

This is not a valid AWS IAM condition key.

Trap 3: aws:SourceIp

This condition key restricts the source IP address, which is not the same as VPC.

Study all Identity and Access Management common traps →

A
aws:RequestedRegion
Why it fails: This condition key restricts the AWS region from which a request can be made, not the VPC.
B
aws:VpcSourceIp
Why it fails: This is not a valid AWS IAM condition key.
C
aws:SourceVpc
The aws:SourceVpc condition key evaluates the VPC endpoint through which the request arrives, restricting role assumption to traffic originating from the specified VPC. This precisely matches the stem's requirement to limit assumption to one VPC.
D
aws:SourceIp
Why it fails: This condition key restricts the source IP address, which is not the same as VPC.

Full breakdown with real-world context →

Question 19easymulti select

Read the full Identity and Access Management explanation →

Which TWO of the following are valid IAM policy condition keys? (Choose TWO.)

Trap 1: aws:RequestedService

aws:RequestedService is not an AWS IAM condition key; AWS does not define this key in its global condition key list. The service is already encoded in the action namespace (for example, s3: in s3:GetObject), so a separate condition key for service name would be redundant. Using a nonexistent key in a policy will cause the policy to fail evaluation or be rejected.

Trap 2: aws:PrincipalService

aws:PrincipalService is not a valid IAM condition key because the principal element already defines who is making the request, and AWS uses keys like aws:PrincipalArn, aws:PrincipalAccount, and aws:PrincipalOrgID to express principal attributes. There is no need for a key that identifies a service principal; service principals are matched via the principal element in resource-based policies.

Trap 3: aws:SourceArn

aws:SourceArn is a real global condition key, but it is only valid in specific contexts where the request is triggered by another AWS service, such as an S3 event or a cross-service call. It is not a general-purpose condition key for typical user or role identities, which is why it cannot be considered a universally valid IAM condition key in all policies.

Study all Identity and Access Management common traps →

A
aws:RequestedRegion
aws:RequestedRegion is a documented global condition key that lets you allow or deny access based on the AWS Region in the request context, such as the Region of the resource being created. It is commonly used in service control policies to enforce regional boundaries or to deny operations in specific Regions, and it is supported by a broad range of AWS services.
B
aws:RequestedService
Why it fails: aws:RequestedService is not an AWS IAM condition key; AWS does not define this key in its global condition key list. The service is already encoded in the action namespace (for example, s3: in s3:GetObject), so a separate condition key for service name would be redundant. Using a nonexistent key in a policy will cause the policy to fail evaluation or be rejected.
C
aws:SourceIp
aws:SourceIp is a valid global condition key that restricts access based on the source IP address of the requester, commonly used to allow requests only from corporate or VPC CIDR ranges. Note that it only works for requests with an IP address and is often paired with aws:SourceVpc for network-level controls.
D
aws:PrincipalService
Why it fails: aws:PrincipalService is not a valid IAM condition key because the principal element already defines who is making the request, and AWS uses keys like aws:PrincipalArn, aws:PrincipalAccount, and aws:PrincipalOrgID to express principal attributes. There is no need for a key that identifies a service principal; service principals are matched via the principal element in resource-based policies.
E
aws:SourceArn
Why it fails: aws:SourceArn is a real global condition key, but it is only valid in specific contexts where the request is triggered by another AWS service, such as an S3 event or a cross-service call. It is not a general-purpose condition key for typical user or role identities, which is why it cannot be considered a universally valid IAM condition key in all policies.

Full breakdown with real-world context →

Question 20hardmultiple choice

Read the full Identity and Access Management explanation →

A security engineer attaches this policy to an IAM user. The user tries to download an object from the bucket from an IP address 10.1.0.5. What will happen?

Exhibit

Refer to the exhibit. IAM policy JSON:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/16"
        }
      }
    }
  ]
}

Trap 1: The user will be allowed access because the policy allows…

Although the policy contains an Allow for s3:GetObject, that permission is gated by a required condition. IAM evaluates the condition before applying the Allow; if the condition is not satisfied, the Allow statement is skipped and provides no permission. Since no other statement in the policy grants the action, the request falls through to the implicit deny. Thus, the user is not allowed simply because the action appears in an Allow statement.

Trap 2: The policy is invalid and will cause an error

The policy is not invalid from an IAM policy perspective; it uses correct JSON syntax and includes recognized elements such as Effect, Action, Resource, and Condition. A condition operator or key that is properly formatted is a valid part of a policy, even if the value does not match the request context. The IP mismatch is a runtime evaluation outcome, not a policy validation error. Therefore, the IAM service will accept the policy and enforce it, not return an error.

Trap 3: The user will be denied access because there is an explicit deny

The user is not denied because of an explicit deny; the policy does not contain any statement with Effect set to Deny. The denial in this scenario is an implicit deny, which occurs automatically when no applicable Allow grants the requested action. An explicit deny would take precedence over all allows, but no such statement exists here. The cause of the denial is simply that the conditional Allow does not apply because the condition fails.

Study all Identity and Access Management common traps →

A
The user will be denied access because the condition does not match
In IAM, an Allow statement only grants access if all of its conditions evaluate to true. Here, the condition requires the request to originate from a permitted IP address range, but the user's request comes from an IP outside that range. Because the condition does not match, the Allow never becomes effective, and the default implicit deny applies. As a result, the user is denied access even though no explicit Deny exists.
B
The user will be allowed access because the policy allows s3:GetObject
Why it fails: Although the policy contains an Allow for s3:GetObject, that permission is gated by a required condition. IAM evaluates the condition before applying the Allow; if the condition is not satisfied, the Allow statement is skipped and provides no permission. Since no other statement in the policy grants the action, the request falls through to the implicit deny. Thus, the user is not allowed simply because the action appears in an Allow statement.
C
The policy is invalid and will cause an error
Why it fails: The policy is not invalid from an IAM policy perspective; it uses correct JSON syntax and includes recognized elements such as Effect, Action, Resource, and Condition. A condition operator or key that is properly formatted is a valid part of a policy, even if the value does not match the request context. The IP mismatch is a runtime evaluation outcome, not a policy validation error. Therefore, the IAM service will accept the policy and enforce it, not return an error.
D
The user will be denied access because there is an explicit deny
Why it fails: The user is not denied because of an explicit deny; the policy does not contain any statement with Effect set to Deny. The denial in this scenario is an implicit deny, which occurs automatically when no applicable Allow grants the requested action. An explicit deny would take precedence over all allows, but no such statement exists here. The cause of the denial is simply that the conditional Allow does not apply because the condition fails.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Identity and Access Management sessions

Start a Identity and Access Management only practice session

Every question in these sessions is drawn from the Identity and Access Management domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Identity and Access Management questions →Mixed SCS-C02 session

Frequently asked questions

What does the SCS-C02 exam test about Identity and Access Management?: Given a scenario, determine the effective permissions by combining identity policies, resource policies, boundaries, SCPs, and conditions, then choose the least-privilege option. The single most important thing: an explicit Deny always wins, and roles with temporary credentials beat embedded access keys.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Identity and Access Management questions in a focused session?: Yes — the session launcher on this page draws every question from the Identity and Access Management domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other SCS-C02 topics?: Use the topic links above to move to related areas, or go back to the SCS-C02 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the SCS-C02 exam covers. They are not copied from any real exam or dump site.

Identity and Access Management only

10 questions 20 questions 30 questions 50 questions

Mixed SCS-C02 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All SCS-C02 questions Identity and Access Management domain overview SCS-C02 exam guide

Exam traps to avoid

▸Forgetting that an explicit Deny in any applicable policy overrides every Allow, including administrator access.
▸Assuming a resource-based policy alone grants access without checking the identity's own permissions or account trust.
▸Confusing permissions boundaries with SCPs: boundaries limit identities, SCPs limit accounts in Organizations.

Identity and Access Management practice questions

What to know about Identity and Access Management

Common Identity and Access Management exam traps

Identity and Access Management questions

An IAM policy includes the following condition: "StringNotEquals": {"aws:SourceArn": "arn:aws:ec2:us-east-1:123456789012:instance/*"}. What is the effect of this condition when attached to an IAM role?

An IAM user receives an 'AccessDenied' error when trying to list objects in an S3 bucket. The user has the following policy attached: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:ListBucket","Resource":"arn:aws:s3:::example-bucket"}]}. What is the most likely reason?

Which TWO are valid ways to authenticate to AWS for API calls? (Choose two.)

Refer to the exhibit. A security engineer runs the command above. Which of the following is true about the role MyRole?

An IAM policy is attached to a user. The user is trying to change their own password in the IAM console but receives an 'Access Denied' error. The user has an MFA device configured and is logged in with MFA. Why is the password change failing?

Exhibit

Drag and drop the steps to configure AWS CloudTrail for logging across all regions and accounts in the correct order.

Match each AWS KMS key type to its description.

Match each AWS CloudHSM feature to its description.

A security engineer notices that an IAM user has permissions that are not explicitly granted through any policy. The engineer suspects that the user might have inherited permissions from a group or role. Which IAM feature should the engineer use to identify the source of these permissions?

An organization wants to enforce that all IAM users use MFA. The security team creates an IAM policy that denies all actions unless MFA is present. However, some users report they cannot even change their own password to enable MFA. What should the security team do to resolve this?

Which THREE are valid ways to grant cross-account access to an S3 bucket? (Choose three.)

A security engineer is designing a cross-account access solution. An IAM role in Account A needs to be assumed by users from Account B. Which two components are required?

An IAM user needs to rotate their own access keys. Which IAM policy action should be allowed?

A security engineer notices that an IAM role for an EC2 instance has a policy that allows s3:PutObject on a bucket. However, the application reports access denied when trying to upload. The bucket policy does not explicitly deny access. What is a likely cause?

A security engineer needs to ensure that an IAM role can be assumed only from a specific VPC. Which IAM policy condition key should be used?

Which TWO of the following are valid IAM policy condition keys? (Choose TWO.)

A security engineer attaches this policy to an IAM user. The user tries to download an object from the bucket from an IP address 10.1.0.5. What will happen?

Exhibit

Track your progress over time

Start a Identity and Access Management only practice session

Related SCS-C02 topic practice pages

Threat Detection and Incident Response practice questions