IAM Policy practice questions

Attach the same allow policy to the vendor account’s existing IAM user so the user can call sts:AssumeRole directly into your role.

Why wrong: Even if the vendor user can call sts:AssumeRole, your role still must trust that principal. Without trust, the AssumeRole request is denied.

Replace the AssumeRole call with GetCallerIdentity so the vendor can infer permissions without assuming the role.

Why wrong: GetCallerIdentity does not grant access to the internal resources. The vendor still needs a trusted identity and proper permissions.

Enable MFA on the vendor’s IAM user and require MFA for your role using condition keys in the permissions policy.

Why wrong: MFA requirements affect the authorization flow but do not solve the root cause. The trust policy must first allow the vendor to assume the role.

Create IAM user access keys in account A and attach the UploadRole policy directly to those keys.

Why wrong: Using static access keys increases risk and bypasses role-based trust controls. It also does not leverage the existing role in account B. Attaching account B permissions directly to account A identities is typically not least-privilege for cross-account access.

Add s3:PutObject permissions to the bucket policy in account B for all principals in account A.

Why wrong: Bucket policies can grant access, but granting broadly to account A principals is harder to keep least-privileged. It also does not address that sts:AssumeRole must be authorized for the app to use the intended role. This option ignores the missing trust relationship root cause.

Attach an SCP (service control policy) in AWS Organizations to deny sts:AssumeRole unless the caller uses an MFA device.

Why wrong: An SCP can restrict actions at the organization level, but it won’t fix the current AccessDenied stemming from missing trust. If MFA enforcement is needed, it should be reflected in an appropriate condition in the trust policy, not as the primary missing permission.

Remove the permission boundary from CICDRole so that only the identity policy controls access.

Why wrong: Removing a permission boundary eliminates a critical preventative control that caps the maximum permissions an IAM entity can ever have. Without this guardrail, the effective permissions are solely determined by the identity policy. If the identity policy is misconfigured or becomes overly broad through subsequent updates, there would be no secondary enforcement mechanism to prevent unintended or unauthorized IAM actions, significantly increasing the risk of privilege escalation.

Add an identity-policy deny for iam:CreatePolicy and iam:UpdateRole on all resources.

Why wrong: Identity-policy denies can be incomplete or bypassed indirectly through other actions/permissions or policy changes. They also depend on correct identity policy maintenance over time, whereas permission boundaries provide a centralized maximum cap for the role.

Rely on CloudTrail alerts to stop deployments from performing IAM changes after the fact.

Why wrong: Relying on CloudTrail alerts is a reactive, detective control, not a proactive preventative measure. CloudTrail records API calls and events, providing an audit trail and enabling alerts *after* an action has already occurred. It does not possess the capability to block or stop IAM changes in real-time during authorization. Therefore, this approach would only notify administrators of unauthorized IAM actions after they have been successfully executed, failing to prevent the security incident.

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

Why wrong: Adding kms:Decrypt to an identity policy in Account B only grants the principal *permission to attempt* the action. However, for cross-account access to a KMS Customer Managed Key (CMK), the CMK's key policy in Account A must *also explicitly permit* the Account B principal to use the key. Without this explicit authorization on the resource itself, the request will be denied, as the key policy acts as the ultimate gatekeeper in the two-layer authorization model.

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

Why wrong: Disabling SSE-KMS and switching to SSE-S3 would change the encryption mechanism, not resolve the permissions issue for the existing SSE-KMS encrypted objects. This action would remove the requirement for KMS permissions by using an AWS-managed key (SSE-S3), but it would likely violate any security or compliance requirements mandating the use of a customer-managed CMK. It's a functional change that sidesteps the problem rather than fixing the access control for the specified encryption type.

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

Why wrong: A permissions boundary defines the *maximum* permissions an IAM identity policy can grant to an IAM principal, but it does not grant permissions itself. Furthermore, permissions boundaries do not override resource-based policies like KMS key policies. Even if a permissions boundary allows `kms:*`, the request will still be denied if the KMS key policy in Account A does not explicitly permit the Account B principal to perform `kms:Decrypt` on that specific key.

Attach DeployBoundary to the automation role only, because that automatically forces every created role to inherit the same boundary.

Why wrong: A boundary on the creator role does not automatically propagate to newly created roles. The new role must either be created with the boundary or be blocked unless it includes the approved boundary. Creator boundaries and target-role boundaries are separate controls.

Create an SCP that denies iam:CreateRole and iam:PutRolePermissionsBoundary unless aws:RequestTag equals DeployBoundary.

Why wrong: Request tags are useful for tagging governance, but they do not validate which permissions boundary is attached to the new role. The enforcement must check the permissions boundary parameter or the boundary ARN condition, not a general request tag.

Use AWS Access Analyzer to automatically attach the approved boundary whenever a role is created without one.

Why wrong: Access Analyzer is a detection and analysis service, not an enforcement mechanism that modifies IAM resources. It can help identify overly broad access, but it cannot automatically attach permissions boundaries to IAM roles during creation.

Permission boundaries do not affect permissions for resources created with role chaining; enable role chaining instead to apply the boundary.

Why wrong: Permission boundaries are evaluated to limit the maximum effective permissions for the IAM principal regardless of role chaining. The symptom (being able to perform an action beyond the intended maximum) most commonly indicates that the intended boundary was not applied or was applied incorrectly.

KMS key policies override permission boundaries for S3, so deletion permission comes from the KMS policy; restrict the KMS key policy instead.

Why wrong: S3 bucket deletion authorization is governed by IAM permissions (and, where applicable, S3 bucket policies/ACLs). KMS key policies control access to cryptographic operations for KMS-encrypted data, not whether the caller can delete an S3 bucket.

Permission boundaries apply only to managed policies, not to inline policies; move the overly permissive permissions to a managed policy type to keep it bounded.

Why wrong: Permission boundaries apply to the effective permissions of the principal, regardless of whether the allowed actions come from inline policies or managed policies. If the boundary is correctly attached, both inline and managed policies are constrained by the boundary; moving to a managed policy does not address an incorrect/missing boundary attachment.

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.

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.

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.

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.

Create an IAM user for administrators with AdministratorAccess and require MFA only at the IAM user login.

Why wrong: AdministratorAccess grants too much privilege and still relies on long-lived access keys. MFA at login does not prevent use of existing sessions without MFA constraints.

Attach policies to an IAM user that allow read/write actions and enable MFA in the account, but do not use condition keys in IAM policies.

Why wrong: Enabling MFA at the account level is not the same as enforcing MFA presence for each API call. Without condition keys, sessions may still be used without MFA constraints.

Use a role with the correct actions but enforce MFA only in the application by prompting users for an OTP before every API call.

Why wrong: Client-side enforcement is not reliable and can be bypassed. Security should be enforced at the IAM policy layer using condition keys to control authorization.

In Company B's IAM policy, allow kms:Encrypt on Company A's KMS key ARN, without changing Company A's key policy.

Why wrong: KMS key policies govern access to the key; adding permissions in the caller account alone cannot override a restrictive key policy in the key owner account.

Create a new KMS key in Company B and configure Company A's S3 bucket to use that key for SSE-KMS.

Why wrong: Switching bucket ownership encryption to a partner key changes trust boundaries and operational ownership. It also doesn't directly resolve the original denial and can complicate key administration.

Disable key policy restrictions by setting the KMS key to enabled and removing all policy statements so that encryption automatically works for any principal.

Why wrong: Removing restrictions or effectively allowing all principals defeats security objectives and is not required for cross-account access. Key policies should be explicit and least-privilege.

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.

Add a condition that allows secretsmanager:GetSecretValue only when aws:SourceIp is within 10.0.0.0/8.

Why wrong: Source IP conditions cannot reliably prove that the traffic used the required Interface VPC endpoint. Requests can be translated by NAT gateways, proxies, or load balancers, and the observed Source IP may not uniquely identify the endpoint path.

Require TLS by adding a condition on aws:SecureTransport for the Secrets Manager permission.

Why wrong: aws:SecureTransport enforces that the request uses HTTPS, but it does not restrict which network path was used to reach Secrets Manager. A call could still reach the public endpoint over an unintended route while using TLS.

Add a KMS condition using kms:ViaService=secretsmanager.us-east-1.amazonaws.com instead of restricting Secrets Manager directly.

Why wrong: The kms:ViaService condition affects whether a key can be used via a particular AWS service context, but the question’s requirement is about the network path to the Secrets Manager API. This does not constrain the request to originate from the specified Interface VPC endpoint.

A larger KMS key rotation period

Why wrong: Rotation interval does not determine which principals may use a key.

S3 Transfer Acceleration

Why wrong: Transfer Acceleration does not control KMS key usage.

Remove all IAM permissions from AppProvisioner and require a central security team to create every role manually.

Why wrong: This would certainly reduce risk, but it removes the delegated administration model the team explicitly needs. It is operationally expensive and slows delivery unnecessarily.

Allow developers to keep creating roles, but add a CloudTrail rule that alerts security after a privileged policy is attached.

Why wrong: Alerting after the fact detects bad changes, but it does not prevent a powerful role from being created or used. The requirement is preventive least privilege, not detective monitoring alone.

Move the delegated IAM workflow into a separate VPC and restrict it with security groups and network ACLs.

Why wrong: IAM authorization is not controlled by VPC networking constructs. Security groups and network ACLs do not restrict IAM actions such as role creation or policy attachment.

Make the objects public and rely on difficult-to-guess object names

Why wrong: Security through obscurity is not an access-control strategy.

Copy the objects to a public website bucket

Why wrong: A public website bucket exposes data unnecessarily.

Create an IAM user in the company account and share the access keys

Why wrong: Long-term shared credentials are less secure and harder to govern.

Remove the ABAC condition using aws:PrincipalTag/Project so the policy ignores session tags.

Why wrong: Removing the condition would broaden access and violates the ABAC design that restricts actions to the correct project.

Move the aws:PrincipalTag/Project condition into the trust policy so it applies during the AssumeRole call.

Why wrong: Even if conditions exist in the trust policy, the session tags must be allowed and provided. The failure indicates the tag was not populated.

Add kms:Decrypt permission to the CI role because missing tags are typically caused by KMS authorization failures.

Why wrong: The observed symptom is that the session tag is missing, not that KMS decryption is denied. These are unrelated controls.

Create IAM user access keys in account A and attach the UploadRole policy directly to those keys.

Why wrong: Using static access keys increases risk and bypasses role-based trust controls. It also does not leverage the existing role in account B. Attaching account B permissions directly to account A identities is typically not least-privilege for cross-account access.

Add s3:PutObject permissions to the bucket policy in account B for all principals in account A.

Why wrong: Bucket policies can grant access, but granting broadly to account A principals is harder to keep least-privileged. It also does not address that sts:AssumeRole must be authorized for the app to use the intended role. This option ignores the missing trust relationship root cause.

Attach an SCP (service control policy) in AWS Organizations to deny sts:AssumeRole unless the caller uses an MFA device.

Why wrong: An SCP can restrict actions at the organization level, but it won’t fix the current AccessDenied stemming from missing trust. If MFA enforcement is needed, it should be reflected in an appropriate condition in the trust policy, not as the primary missing permission.

Add kms:Decrypt to the KMS key policy in Account A for the Account B role arn:aws:iam::account-b:role/app-read, and remove kms:Decrypt from the role policy in Account B.

Why wrong: Adding kms:Decrypt to the KMS key policy is a valid approach, but removing kms:Decrypt from the role policy is not required to fix an AccessDenied kms:Decrypt failure. KMS authorization requires both (1) identity policy permission (in Account B) and (2) the KMS key policy permission (in Account A). Removing the role permission can cause the failure to continue or move to a different authorization denial.

Update the IAM role in Account B to use the s3:GetObject permission only, and rely on S3 to authorize KMS decrypt automatically.

Why wrong: S3 authorization to call GetObject does not eliminate the need for KMS permissions to call kms:Decrypt. For SSE-KMS, the GetObject request ultimately requires kms:Decrypt in KMS, which is authorized by both the caller’s IAM permissions and the KMS key policy.

Switch the S3 bucket encryption from SSE-KMS to SSE-S3, keeping all existing IAM and KMS configuration unchanged.

Why wrong: Changing to SSE-S3 avoids KMS decryption entirely, so it could remove the kms:Decrypt failure. However, that is not a targeted fix for the underlying authorization issue and conflicts with the stated requirement of using the existing customer-managed KMS key for SSE-KMS.