IAM Policy practice questions

Rely only on their IAM managed policies and instruct developers to self-check against internal guidelines.

Why wrong: Guidelines and self-checks are not enforceable controls. Developers could accidentally (or intentionally) attach policies that exceed the intended maximum permissions.

Use a service control policy (SCP) that applies only to the developers’ IAM users in the account.

Why wrong: SCPs are evaluated at the organization/account level and constrain allowed API actions for principal types across affected accounts/OUs. They are not the most direct tool for capping an individual principal’s maximum effective permissions in the way permission boundaries do (and SCPs are not designed for per-identity “maximum permission” limits).

Use a KMS key policy to restrict IAM actions, because IAM actions can be controlled with KMS.

Why wrong: KMS key policies govern cryptographic key usage (for example, Encrypt/Decrypt) and do not control whether a principal is authorized to grant or perform IAM permissions. KMS does not function as an IAM permissions cap mechanism.

Allow s3:PutObject on arn:aws:s3:::build-artifacts-prod/* and allow s3:ListBucket on arn:aws:s3:::build-artifacts-prod with no condition.

Why wrong: This is too permissive because PutObject is scoped to the entire bucket (arn:aws:s3:::build-artifacts-prod/*), allowing uploads outside teamA/. It also allows ListBucket for the full bucket without any s3:prefix condition, so the pipeline could list other prefixes.

Allow s3:PutObject on arn:aws:s3:::build-artifacts-prod/teamA/* and allow s3:GetBucketLocation on arn:aws:s3:::build-artifacts-prod/teamA/.

Why wrong: GetBucketLocation is not required to satisfy the listed controls (upload only to teamA/ and list only within teamA/). Additionally, scoping GetBucketLocation to a prefix is not the right control for restricting ListBucket results; the missing piece is the constrained s3:ListBucket permission with an s3:prefix condition.

Allow s3:* on arn:aws:s3:::build-artifacts-prod/teamA/* and allow s3:ListAllMyBuckets for easier auditing.

Why wrong: s3:* is broader than needed and can grant permissions such as DeleteObject or other read/write capabilities beyond what is required. ListAllMyBuckets is unrelated to preventing access to other prefixes within the target bucket and expands exposure outside the intended control boundary.

Add conditions sts:ExternalId = <value> only; do not include any MFA requirement because MFA can be enforced by the IAM role session policy.

Why wrong: Adding sts:ExternalId satisfies the external ID requirement, but MFA is not enforced by that setting. MFA must be validated at AssumeRole time using trust policy conditions (for example, aws:MultiFactorAuthPresent = true). Otherwise, a caller could satisfy the external ID and still avoid MFA.

Add conditions for aws:PrincipalTag:Department = Engineering and sts:ExternalId = <value>; omit MFA because MFA is optional for AssumeRole.

Why wrong: Principal tags are not guaranteed to exist for every caller and are not a reliable mechanism for enforcing an explicit MFA requirement. Omitting aws:MultiFactorAuthPresent fails the stated security requirement that the session be MFA-authenticated.

Add conditions aws:SecureTransport = true and sts:ExternalId = <value>; rely on IAM permissions in account C to require MFA.

Why wrong: aws:SecureTransport enforces TLS usage for API calls, not MFA. Also, caller-side IAM permissions cannot ensure that the STS trust evaluation validates MFA at AssumeRole time; MFA must be checked via trust conditions such as aws:MultiFactorAuthPresent.

Add a permission boundary to the developer role that points to ApprovedAppBoundary.

Why wrong: That only constrains the developer role itself; it does not force new roles to use the approved boundary.

Use an S3 bucket policy to block policy documents that grant AdministratorAccess.

Why wrong: S3 bucket policies do not control IAM role creation or IAM policy attachment.

Require team members to use STS session policies when they create new roles.

Why wrong: Session policies only limit temporary sessions and do not force a permissions boundary on newly created roles.

Update only the consumer role identity policy because identity policies always override key policies.

Why wrong: Identity policies do not override a restrictive KMS key policy. KMS evaluates key policy authorization for customer-managed keys in addition to (and in practice as the gate for) identity-based permissions.

Enable default encryption on SQS so that KMS permissions are no longer required.

Why wrong: SQS encryption settings do not remove the authorization requirement for decrypting with a CMK. If messages are encrypted using a CMK, kms:Decrypt must still be allowed.

Create an S3 bucket policy statement allowing kms:Decrypt because the messages are stored in S3.

Why wrong: SQS message decryption authorization is evaluated by KMS using the CMK key policy (and possible grants). S3 bucket policies are unrelated to KMS authorization for SQS decryption.

Create an IAM user for each developer and keep the existing broad permissions, rotating keys every 90 days.

Why wrong: Long-lived IAM user access contradicts temporary credentials requirements. Rotating keys reduces exposure but does not prevent repeated leakage or enforce least privilege at scale.

Attach a policy that allows ecs:* and autoscaling:* and rely on developers to self-review that no IAM statements are added to their roles.

Why wrong: Self-review is not an enforceable control. Without a permission boundary or explicit deny, developers could add iam:* permissions and violate the security requirement.

Create a single shared IAM role with full administrator permissions so developers can troubleshoot faster when deployments fail.

Why wrong: Administrator permissions violate least-privilege and allow IAM changes. A shared role also makes accountability weaker and increases blast radius of mistakes.

Update the IAM role in account B to include kms:Encrypt and kms:GenerateDataKey; then kms:Decrypt will start working automatically.

Why wrong: kms:Encrypt and kms:GenerateDataKey do not grant kms:Decrypt authorization. The error indicates that the KMS key policy is denying the decrypt call, so the fix must adjust KMS key policy (and/or grants), not add unrelated IAM KMS actions.

Disable key policy for the CMK by switching to S3-managed encryption, because KMS key policies are always enforced regardless of grants.

Why wrong: Switching encryption types changes the encryption configuration and does not address the underlying requirement for authorization to use the specific CMK. Additionally, KMS key policy is not a concept that can be “disabled” for a CMK; the correct fix is to modify the CMK key policy (and/or create appropriate grants).

Create an SCP in account A that allows kms:Decrypt for all accounts, avoiding changes to the key policy.

Why wrong: Service Control Policies (SCPs) are organization-level guardrails. Even if an SCP allows kms:Decrypt, KMS can still deny the call if the CMK’s key policy does not allow it. SCPs also do not replace the CMK key policy requirement for cross-account authorization.

Require the vendor to use the same MFA device serial number as your internal administrators in the trust policy.

Why wrong: Trust policies can check conditions related to MFA in some contexts, but matching your internal MFA device serial to an external vendor is impractical and not the primary confused-deputy mitigation. External ID was designed specifically for this cross-account vendor role assumption pattern.

Remove the role’s permissions policy and rely only on the S3 bucket policy to validate the caller.

Why wrong: Relying solely on the bucket policy does not address the confused-deputy risk in role assumption. Also, a missing permissions policy may break legitimate access. External ID is the relevant trust policy mitigation for limiting which assumers can obtain credentials.

Allow sts:AssumeRole from the vendor account root principal without restricting to the vendor’s specific IAM role.

Why wrong: Allowing root principal broadly increases risk and does not mitigate confused-deputy attacks. The trust policy should be as specific as possible, and External ID provides a targeted protection against attackers misusing the vendor’s access.

Add an IAM policy statement allowing s3:GetObject for the bucket that stores the encrypted data.

Why wrong: S3 permissions determine whether the encrypted ciphertext can be retrieved. They do not grant cryptographic authorization to call kms:Decrypt on the KMS key.

Enable a CloudFront distribution for the KMS key alias.

Why wrong: CloudFront settings and distribution behavior do not affect KMS key policy evaluation for kms:Decrypt.

Create a VPC gateway endpoint for KMS to route decryption requests privately.

Why wrong: Private networking can affect connectivity, but it cannot replace authorization. Without key-policy permission, KMS will still deny kms:Decrypt with AccessDenied.

Keep s3:ListBucket allowed on arn:aws:s3:::customer-data, but restrict s3:GetObject to arn:aws:s3:::customer-data/exports/acme/*.

Why wrong: Restricting GetObject prevents reads outside the prefix, but allowing ListBucket on the whole bucket still lets the role enumerate object keys (for other tenants), which violates the tenant-isolation requirement.

Allow s3:ListBucket only on arn:aws:s3:::customer-data/exports/acme/* and allow s3:GetObject on arn:aws:s3:::customer-data/*.

Why wrong: s3:ListBucket does not accept an object-style ARN as its resource. It must be granted on the bucket ARN. The GetObject scope in this option is overly broad and would allow reads outside exports/acme/.

Add a Deny statement for s3:GetObject outside arn:aws:s3:::customer-data/exports/acme/*, but keep s3:ListBucket unrestricted on arn:aws:s3:::customer-data.

Why wrong: Even if GetObject is blocked for other tenants, unrestricted ListBucket still exposes object keys and folder names for other tenants, which is disallowed by the security requirement.

Use CloudWatch Logs metric filters on application logs to infer which principals changed trust policies.

Why wrong: CloudWatch metric filters cannot capture AWS management API calls for IAM changes unless explicitly logged by the application.

Rely on GuardDuty alerts to provide the full request parameters for every IAM policy change.

Why wrong: GuardDuty focuses on threat detection and does not provide comprehensive, authoritative audit trails for every IAM change.

Enable AWS Config only and store periodic snapshots without CloudTrail management events.

Why wrong: AWS Config records configuration state changes, but CloudTrail is the primary service for detailed API action audit logging.

Enable KMS automatic key rotation for the customer-managed key in account B.

Why wrong: Key rotation is unrelated to authorization failures. The problem is that the key policy in account B is not allowing the cross-account principal to use kms:Decrypt for the key.

Attach the key policy as an IAM permissions policy to the instance role in account A only; key policies are not evaluated cross-account.

Why wrong: KMS key policies are evaluated on the key itself. Without updating the key policy in account B, cross-account calls will still be denied even if IAM permissions exist in account A.

Disable encryption on the EBS volume until authorization is fixed, then re-enable encryption after mount.

Why wrong: Disabling encryption violates security requirements and does not address why KMS authorization fails. Encrypted volumes and snapshots require correct KMS policies to be usable.

Use an IAM user in Account B and hard-code the narrower S3 path in its access key policy.

Why wrong: This reintroduces long-term credentials and defeats the purpose of using STS assumed-role access. It also creates a separate identity instead of reusing the central deployment role.

Add a bucket ACL that grants write access only to the TeamA pipeline session name.

Why wrong: S3 ACLs cannot evaluate STS session names or enforce per-session restrictions. They are also a poor fit for least-privilege automation because they are coarse and difficult to manage safely at scale.

Attach a permissions boundary to the central role so every pipeline session inherits the narrower prefix automatically.

Why wrong: A permissions boundary limits the maximum permissions of an IAM principal, but it does not let different callers apply different temporary restrictions when they assume the same role. The boundary would apply to the role itself, not dynamically to one TeamA session versus other pipeline sessions.

Keep the root principal and add an aws:PrincipalTag condition in the trust policy to require the tag acct-b-prod-7788.

Why wrong: Principal tags can help with authorization, but they do not ensure that only one exact role in Account B can call STS. Any principal that can supply the tag might still satisfy the condition. This does not provide the required caller-specific trust boundary.

Attach a permission boundary to the role in Account A so that only PipelineExecRole can use it.

Why wrong: Permission boundaries limit the maximum permissions a role can have after it is assumed, but they do not control who is trusted to assume the role. The trust policy, not the permission boundary, determines which external principal can call sts:AssumeRole.

Add an SCP in Account B that allows sts:AssumeRole only for PipelineExecRole.

Why wrong: An SCP can constrain identities in Account B, but it cannot by itself grant trust on the role in Account A. The trust policy in Account A must still explicitly allow the correct principal and should include the external ID condition for secure cross-account access.

Replace SSE-KMS with S3 object ACLs so the partner account can bypass KMS authorization.

Why wrong: ACLs control S3 object access, not KMS cryptographic authorization. The error is coming from KMS decrypt operations, so ACL changes would not solve it.

Create a new bucket in the partner account and copy the objects there to avoid cross-account encryption.

Why wrong: Moving the data would avoid the immediate trust problem, but it is an architectural workaround, not the required fix. It adds duplication, cost, and operational complexity without addressing the KMS sharing requirement.

Switch the bucket to SSE-S3 so the partner role no longer needs KMS permissions.

Why wrong: SSE-S3 removes customer-managed key control, which may violate security or compliance requirements. The scenario requires safe use of the customer-managed KMS key, not eliminating it.

Place the developers in an IAM group with a deny-only managed policy attached.

Why wrong: A group policy can help with access management, but it does not cap the maximum permissions a created role can receive.

Use an AWS Organizations SCP to grant only the approved Lambda permissions directly to the developer roles.

Why wrong: An SCP can restrict permissions, but it does not grant permissions to a role. The role still needs identity-based permissions.

Create the roles with inline policies only, because inline policies are always safer than managed policies.

Why wrong: Inline policies are not automatically safer. They can still contain excessive permissions and do not enforce a maximum boundary.

Re-enable object ACLs and manage access by setting object-level ACLs for each team's prefix.

Why wrong: This reintroduces ACL management complexity and conflicts with the requirement to avoid ACLs. It also makes permissions harder to audit and easier to misconfigure.

Split the bucket into one bucket per team and keep using a single shared bucket policy for all of them.

Why wrong: Separate buckets can work, but they multiply operational overhead and still require policy management across many buckets. The question asks for a better redesign of the access model, not just more buckets.

Make the bucket public and issue presigned URLs for team access so IAM policies are no longer needed.

Why wrong: Presigned URLs are useful for temporary access, but making the bucket public violates the security requirement. Public access would also expose the bucket beyond the intended internal teams.

Add kms:Decrypt permissions to the identity policy in account B only, without modifying the CMK key policy in account A.

Why wrong: Identity permissions alone are often insufficient when cross-account KMS access is involved. KMS key policies control whether principals can use the key.

Disable SSE-KMS on the S3 bucket so objects use SSE-S3 instead, eliminating the need for KMS permissions.

Why wrong: This removes KMS-based control rather than correcting permissions. It also may violate the requirement to use the customer-managed CMK.

Attach a broad permissions boundary to the account B role allowing all kms:* actions to override the key policy.

Why wrong: Permissions boundaries are a control on identity policies, not a way to override a KMS key policy. Broad kms:* permissions would still be blocked if the key policy denies.

In Company A role trust policy, allow sts:AssumeRole for principal "arn:aws:iam::<company-b-account-id>:root" with no sts:ExternalId condition.

Why wrong: Allowing the entire Company B account root is broader than necessary, and omitting the sts:ExternalId condition does not provide confused-deputy protection.

In the trust policy, allow iam:PassRole for the Company B principal and include an sts:ExternalId condition.

Why wrong: Trust policies for role assumption use sts:AssumeRole. iam:PassRole is unrelated to establishing temporary credentials via STS AssumeRole.

In Company A, grant Company B access using an IAM permissions policy attached to RoleInA instead of using a trust policy.

Why wrong: Cross-account role assumption requires a trust policy that allows sts:AssumeRole. Identity permission policies alone do not permit assuming the role.

Update the developer’s IAM policy to allow kms:Decrypt on the CMK alias ARN so the request bypasses the SCP.

Why wrong: An SCP Deny at the Organizations level overrides IAM allows. IAM changes cannot neutralize an SCP explicit Deny.

Add a KMS key policy statement that allows the developer role to decrypt the CMK.

Why wrong: KMS key policies can grant authorization to principals, but they cannot override an SCP explicit Deny. Organizations evaluation blocks the request before the KMS key policy authorization is applied.

Attach a permissions boundary that grants kms:Decrypt so the SCP becomes irrelevant.

Why wrong: Permission boundaries do not override SCP Deny effects. The SCP explicit deny still blocks the action regardless of permission boundaries.