Identity and Access Management practice questions

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:ListBucket","Resource":"arn:aws:s3:::my-bucket"}]}

Why wrong: Granting s3:ListBucket against the bucket ARN only permits the user to enumerate object keys and metadata, not to retrieve the bodies of any objects. This action is evaluated at the bucket level, while the actual data resides at the object level. To satisfy read-only access, an object-level action such as s3:GetObject on arn:aws:s3:::my-bucket/* is required, so this policy alone fails to meet the requirement.

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:*","Resource":"*"}]}

Why wrong: This policy grants s3:* for every resource, which includes administrative and destructive actions such as s3:DeleteObject, s3:PutBucketPolicy, and s3:PutObject. It goes far beyond read-only access and violates the principle of least privilege. With wildcards on both the action and the resource, the user could modify, delete, or reconfigure any S3 bucket in the account, not just the intended one.

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:PutObject","Resource":"arn:aws:s3:::my-bucket/*"}]}

Why wrong: s3:PutObject allows the user to upload or overwrite objects in the bucket, which is write access rather than read access. Even though the resource ARN correctly points to objects under my-bucket, the action is the opposite of what is needed for a read-only policy. A read-only policy must grant s3:GetObject on the object ARN, not s3:PutObject, which would let the user create new versions or replace existing object content.

Denies all requests from EC2 instances

Why wrong: 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.

Allows the role to be assumed only by EC2 instances in the specified account and region

Why wrong: 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.

Allows any request that comes from an EC2 instance regardless of account

Why wrong: 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.

An OIDC identity provider

Why wrong: An OIDC identity provider is not a valid replacement for this scenario because AD and AD FS use SAML 2.0, not OpenID Connect's JWT-based flow. OIDC in IAM is meant for web identity federation with providers such as Amazon Cognito, Google, or GitHub, and it uses sts:AssumeRoleWithWebIdentity, not sts:AssumeRoleWithSAML. Creating an OIDC provider would not match the SAML protocol used by the corporate Active Directory. Even though OIDC is a modern federation protocol, AWS treats it as a separate integration path, so it cannot provide the same SAML assertion processing this workload requires.

An IAM user for each Active Directory user

Why wrong: Creating an IAM user for each Active Directory user is the antithesis of federation; it duplicates the entire corporate directory inside AWS and forces you to manage rotation, MFA, and disablement of long-term credentials for every identity. IAM has quotas on the number of users, and every user would need unique programmatic credentials or passwords, which creates significant operational overhead and a wider secret-management surface. Federation is meant to let users log in to the AWS Management Console and API using their existing AD credentials and receive short-lived role-based credentials. Doing it manually with IAM users sacrifices the single-sign-on and centralized lifecycle benefits of the SAML role-based approach.

A federation role type

Why wrong: IAM does not have a distinct role type called a 'federation role'; all IAM roles are the same set of permission and trust policy documents, and the label is only a trust policy template in the AWS console. In the role creation wizard, choices such as 'SAML 2.0 federation' merely pre-populate the trust policy with a placeholder for a SAML provider ARN, not with a different kind of role. If you need SAML access, you still create a regular IAM role, set its permissions using IAM policies, and put the SAML provider ARN in the trust policy. Selecting a 'federation role type' is therefore an invalid mental model and would not alter the actual IAM role behavior.

Allows all actions only when using HTTPS

Why wrong: The statement's Effect is Deny, not Allow, so it can never grant access to any action, even one made over HTTPS. A policy with this effect merely creates a restriction that blocks non-HTTPS calls; authorizing HTTPS requests requires a separate, explicit Allow statement. Conflating the Deny with an Allow is a common misunderstanding, but an IAM policy cannot implicitly allow an action when it is written as a Deny. This option incorrectly describes the statement as a positive authorization when it is purely a prohibition.

Enforces HTTPS for S3 bucket policies only

Why wrong: This is an IAM identity-based policy, not an S3 bucket policy, and the aws:SecureTransport condition key can be used across all AWS services and policy types. When you attach this policy to an IAM user or role, it enforces HTTPS for every service that identity calls, including EC2, Lambda, DynamoDB, and others, not just S3. S3 bucket policies are resource-based and scope the condition to a specific bucket, but this policy is not scoped to S3 resources. Therefore, it does not apply exclusively to S3 bucket policies.

Blocks all actions for a specific AWS service

Why wrong: This policy does not target any one AWS service; it uses a wildcard in the Action clause (e.g., 'Action':'*') and a wildcard Resource, so it applies to all services, all resources, and all operations. A service-specific block would require actions to be namespaced to that service (e.g., 's3:PutObject' or 'ec2:*'), and the resource to be restricted accordingly. Since the policy is not limited to a service namespace, it denies non-HTTPS requests across every service rather than only one. This option incorrectly narrows the scope of what is actually a broad, account-wide restriction.

A resource-based policy on the EC2 instance

Why wrong: EC2 instances are compute resources, not IAM principals, and they do not support resource-based policies. Resource-based policies can be attached to services such as S3 buckets, SNS topics, or KMS keys, but EC2 has no policy attachment point. To grant permissions to workloads running on an instance, you must use an IAM role through an instance profile.

An IAM user with access keys stored on the instance

Why wrong: Storing an IAM user's access keys on an EC2 instance is insecure because the keys are long-lived and remain valid indefinitely unless manually rotated. If the instance is compromised, an attacker can exfiltrate the keys and use them from anywhere. This also requires distributing secret material to every instance and managing key lifecycle, which is operationally fragile compared to the automatic, short-lived credentials provided by an instance profile.

An IAM group

Why wrong: IAM groups are administrative containers used to organize IAM users and attach policies to multiple users at once. Groups are not IAM principals and cannot be assigned to an EC2 instance or assumed by the EC2 service. The only valid way to grant permissions directly to an EC2 instance is through an IAM role embedded in an instance profile.

Contact AWS Support to undo the deletion

Why wrong: Calling AWS Support cannot restore a deleted IAM user: the DeleteUser API permanently removes the user object, including its path, permissions boundary, group memberships, and all attached inline or managed policies, and AWS retains no recoverable copy of that principal. Support engineers have no internal mechanism to reverse this operation; they will only advise you to recreate the user manually.

Use the AWS IAM console to undelete the user

Why wrong: The IAM console provides no undelete or recycle-bin feature. Once a user is deleted via the console, CLI, or API, the user object is immediately gone from the account, and the console only lets you create a brand-new IAM user—it cannot reconstruct the original user object, its ARN-based unique ID, or any of its embedded credentials.

Restore the user from a backup of IAM

Why wrong: IAM has no native backup/restore capability; unlike services such as DynamoDB or S3, there is no API to snapshot a user or to roll back a user to a previous state. Even if you exported CloudFormation templates or AWS Config rules that describe the user, those are infrastructure-as-code definitions, not backups of the live user object, and applying them would still create a fresh user rather than restoring the deleted one.

Change the instance type of an RDS database

Why wrong: Changing an RDS instance type is a database lifecycle operation executed by the Amazon RDS service through the ModifyDBInstance API or the RDS console. IAM never performs such modifications; it only controls whether an identity is authorized to call rds:ModifyDBInstance by evaluating permissions policies. Thus, while IAM can gate the request, the actual instance type change is an RDS action, not an IAM action.

Create a CloudFront distribution

Why wrong: Creating a CloudFront distribution is performed through the Amazon CloudFront service using the CreateDistribution API or the console, which handles edge locations, cache behaviors, and origin configuration. IAM does not contain a native action to create distributions; it only grants or denies the cloudfront:CreateDistribution permission to a user or role. Therefore, provisioning a distribution is a CloudFront operation, not an action performed using AWS IAM.

Configure a VPC peering connection

Why wrong: Configuring a VPC peering connection is a networking task owned by Amazon VPC, implemented through the ec2:CreateVpcPeeringConnection API and VPC console, followed by route table updates. IAM is not the service that creates the peering link; at most, an IAM policy can authorize a user to call the VPC API. Since the peering connection and its routing are managed by VPC and not by IAM, this is not an action performed using AWS IAM.

Permission boundaries must be used

Why wrong: Permission boundaries are an optional IAM feature that sets the maximum permissions an entity can receive, but they are not a required part of IAM design. You only need them if you have a delegation model or want to cap privileges for specific roles or users. Standard IAM design can be fully functional without using permission boundaries, so they cannot be a mandatory design factor.

Service control policies (SCPs) must allow the action

Why wrong: Service control policies apply only within AWS Organizations to set account-wide guardrails, and they never grant permissions by themselves. When designing cross-account access via a resource-based policy, the presence or absence of an SCP is not a design consideration because SCPs can only deny or restrict already-granted permissions. Additionally, many AWS accounts exist outside an organization, so SCPs cannot be a universal factor in IAM design.

SSH key pairs

Why wrong: 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.

Database master password

Why wrong: 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.

Root user access keys

Why wrong: 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.

The role has a resource-based policy attached

Why wrong: 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.

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

Why wrong: 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.

The role can be assumed by any AWS service

Why wrong: 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.

The SCP is attached to the root OU and overrides any allow in the member accounts

Why wrong: 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.

The SCP 'RestrictRootAccess' denies the sts:AssumeRole action for all principals except root

Why wrong: 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.

The 'SecurityAudit' role requires MFA to assume the 'DevAdmin' role

Why wrong: 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.

The IAM user is not authorized to perform 's3:PutObject' on the bucket 'my-bucket'.

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

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 wrong: 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.

The bucket 'my-bucket' does not exist in the same region as the CLI request.

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

The trust policy for the role must be defined in Account A.

Why wrong: The trust policy is a resource-based policy that is attached to the IAM role in Account B, the account that owns the role. It cannot be defined in Account A because Account A does not own the role resource; resource-based policies must be created in the account where the resource resides. The trust policy in Account B specifies which principals, such as the IAM users in Account A, are allowed to assume that role.

The S3 bucket policy must grant access to the IAM users in Account A.

Why wrong: When a user in Account A assumes a role in Account B, the resulting session uses the role's identity and permissions, not the user's original IAM identity. Therefore, the S3 bucket policy in Account B should grant the role ARN (e.g., arn:aws:iam::AccountB:role/CrossAccountRole) as the Principal, not the individual IAM user ARNs. If the bucket policy only references the users, the assumed-role session will be denied because the role is the principal making the request.

The IAM users in Account A must have cross-account permissions on the S3 bucket in Account B.

Why wrong: The IAM users in Account A do not access the S3 bucket directly; they assume the role in Account B, and that role carries the S3 permissions via its attached identity policy. The role's permissions are the sole determinant of access to the bucket for the assumed-role session. Consequently, the users do not need any cross-account S3 bucket permissions—only the sts:AssumeRole permission on their own policy.

Create a CMK, then perform manual key rotation, then enable automatic key rotation, then update applications to use the new key, then verify decryption.

Why wrong: This sequence reverses the intended control-plane actions. Manual key rotation in KMS means creating a brand-new CMK (or new key material) and reassigning aliases, whereas automatic rotation changes the backing key of the same CMK while preserving the key ID. If you manually rotate first, you are working with a new CMK before you have set up automatic rotation on the original one, so your automatic rotation enablement either targets the wrong key or is applied after you have already committed to a new key identity. Enabling automatic rotation should immediately follow CMK creation so the original key's backing material rotates annually; manual rotation should only be considered later if immediate re-keying is required, not as a precursor to the automatic-rotation setting.

Enable automatic key rotation, then create a CMK, then perform manual key rotation, then update applications, then verify decryption.

Why wrong: Automatic key rotation cannot be enabled before the CMK exists because the EnableKeyRotation API call requires an existing KeyId or AliasName to identify the target key. Without a CMK, there is no rotating key material, no alias to reference, and no IAM/Key Policy context for the rotation permission. The very first step must be creating a customer-managed key (or importing key material if applicable), and only then can you configure rotation policies such as automatic annual rotation. Additionally, this option omits the prerequisite of establishing a rooted KMS key policy that allows the account to manage rotation, so the order is not only operationally impossible but also lacks the required access-control setup before rotation settings are applied.

Create a CMK, then enable automatic key rotation, then update applications to use the new key, then perform manual key rotation, then verify decryption.

Why wrong: This is incorrect because you should perform manual key rotation before updating applications. Manual rotation creates a new key that applications will use; updating applications before manual rotation means they would still reference the old key.

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 wrong: 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.

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 wrong: 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.

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 wrong: 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.

Customer managed key: AWS creates and manages the key, but you can view it and audit its usage.

Why wrong: 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.

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

Why wrong: 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.

Multi-tenant: Multiple customers share the same HSM.

Why wrong: This option is incorrect because 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.

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

Why wrong: This option is incorrect because '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.

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"iam:*AccessKey*","Resource":"arn:aws:iam::*:user/*"}]}

Why wrong: This policy grants Allow on the ARN arn:aws:iam::*:user/*, which matches the resource path for every IAM user in every account. The wildcard in the user name segment means the principal can create, update, or delete access keys for any user, not just themselves. That clearly violates the requirement to manage only the caller's own keys, so it is too permissive.

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"iam:*AccessKey*","Resource":"*"}]}

Why wrong: A Deny effect with Resource '*' applies to all IAM access key management actions for every resource, including the caller's own user. Even if another policy grants access, an explicit Deny always overrides, so this policy blocks the user from managing any access keys. Since the intent is to allow self-management, this statement is fundamentally counterproductive.

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"iam:*AccessKey*","Resource":"*"}]}

Why wrong: Resource '*' at the IAM service level is equivalent to allowing access to all IAM users and all IAM resources, not just the caller's own user. This statement therefore lets the user manage access keys for every account's users, just like the wildcard user/* case but with even broader scope. It does not incorporate any condition or variable to bind the action to the authenticated identity, so it fails the least-privilege requirement.

aws:SourceIp

Why wrong: The aws:SourceIp condition key evaluates the source IP address of the requesting client, typically used to restrict access to requests originating from trusted IP ranges. It cannot determine whether the principal's account belongs to a specific AWS organization, because IP addresses are not associated with organizational membership. Thus, while it provides network-level control, it does not enforce cross-account organizational boundaries.

aws:MultiFactorAuthPresent

Why wrong: The aws:MultiFactorAuthPresent condition key is a boolean that checks whether the principal authenticated with a valid multi-factor authentication token. It ensures that the requester used MFA, but it provides no information about which AWS account or organization the principal belongs to. Therefore, it cannot be used to restrict cross-account access to principals from a specific organization; it only verifies the authentication strength.

aws:SourceVpce

Why wrong: The aws:SourceVpce condition key checks the ID of the VPC endpoint from which the request originates, restricting access to traffic that traverses a specific VPC endpoint. It is a networking-based condition that controls the network path, not the identity or organizational affiliation of the principal. Consequently, it cannot ensure that the principal's account is in a particular AWS organization, as requests could come from any account through that endpoint.

The user has not attached a security group to the instance.

Why wrong: A security group is a resource-level configuration, not an IAM permission. When a user launches an instance without explicitly selecting a security group, AWS automatically assigns the default security group of the VPC, so the launch can proceed without an IAM denial. IAM authorization for RunInstances does not require a security group to be attached; rather, the user would need ec2:AuthorizeSecurityGroupIngress or related permissions only if they were modifying rules as part of the launch. Therefore, omitting a security group cannot produce the IAM 'not authorized' error described in the scenario.

The IAM policy does not include ec2:RunInstances for us-east-1.

Why wrong: If the IAM policy truly lacked ec2:RunInstances or did not cover us-east-1, the error would be a straightforward 'not authorized to perform: ec2:RunInstances' without reference to a condition key. In the scenario, the policy does include the action and region; instead, the denial occurs because the Condition block in the policy requires ec2:InstanceType to equal 't2.micro', and the requested type does not match. The user is effectively authorized for the API call in the region, but the request context fails the condition, leading to a final deny. Thus, this option misdiagnoses the problem as an absent action when the action is present but conditionally restricted.

The user's account has reached the EC2 instance limit.

Why wrong: Reaching the EC2 instance limit, such as the default On-Demand instances quota per region, results in an error like 'InstanceLimitExceeded' or 'LimitExceeded,' which is a service quota issue, not an IAM policy evaluation failure. Service limits apply to the AWS account regardless of what IAM policies allow, and they are fixed by requesting a quota increase from the Service Quotas console. The reported error for the user would specifically mention 'not authorized' or 'denied,' indicating the IAM authorization engine rejected the request due to the policy condition, not because the account had exhausted its resources. Consequently, this explanation is incorrect because a quota limit would not produce an IAM authorization error.