IAM Policy practice questions

Allow only listing and reading with a single statement: Action = ["s3:*"], Resource = ["arn:aws:s3:::prod-reporting/incoming/*"].

Why it fails: This is overly broad because s3:* includes write and delete actions not required for reads. Least privilege requires restricting to s3:GetObject only. While the resource scope is close, wildcard actions expand permissions beyond the stated need.

Allow all S3 reads at the account level: Action = ["s3:GetObject"], Resource = ["arn:aws:s3:::*"].

Why it fails: Using arn:aws:s3:::* is not least privilege and allows access to every bucket in the account. Even though the action is GetObject, the scope is far wider than the required prefix. This would violate the stated requirement to restrict to s3://prod-reporting/incoming/.

Allow bucket listing with a condition that forces the prefix: Action = ["s3:ListBucket"], Resource = ["arn:aws:s3:::prod-reporting"], Condition = {"StringLike": {"s3:prefix": "incoming/*"}}.

Why it fails: ListBucket is a bucket-level permission that governs listing operations (e.g., ListObjectsV2), not object retrieval. Even with a prefix condition, it merely filters which keys appear in the listing; it does not authorize s3:GetObject on the underlying objects. To read an object, the IAM policy must grant s3:GetObject on the object ARN (e.g., arn:aws:s3:::prod-reporting/incoming/*). The s3:prefix condition is not evaluated for GetObject calls, so this statement leaves object reads completely unauthorized and AccessDenied persists.

Add kms:Decrypt to the IAM role attached to the application without changing the key policy.

Why it fails: Granting `kms:Decrypt` to the IAM role addresses only the IAM authorization layer; it does nothing to satisfy the separate KMS key policy condition that constrains decryption. In AWS KMS, an operation is allowed only if both the IAM policy and the key policy (and any grants) permit it—the authorization is intersectional. The key policy here explicitly evaluates the `kms:EncryptionContext` condition, and since the application's decrypt call uses a mismatched context, the request is denied even if the role has `kms:Decrypt`. Adding the IAM permission is therefore ineffective and does not resolve the actual cause, which is the encryption-context mismatch in the API call itself.

Disable the encryption context condition in the KMS key policy to avoid future failures.

Why it fails: Disabling the encryption context condition in the key policy would allow the decrypt call to succeed, but it defeats the purpose of the condition, which is to restrict the KMS key's use to a specific application purpose (`myapp-secrets`). Encryption context conditions in key policies are a security best practice that provides an additional authorization boundary and also helps prevent ciphertext from being decrypted by other principals or workflows that do not know the context. Removing the condition would permit any caller with `kms:Decrypt` permission to decrypt data using this key, broadening the attack surface and violating the original security design; it is a workaround that fixes the symptom by eliminating the control, not by addressing the bug in the application code.

Rotate the KMS key immediately and re-encrypt all secrets with a different key ID.

Why it fails: Rotating the KMS key or re-encrypting secrets with a new key ID is an unnecessary and disruptive remedy because key rotation does not change the encryption context requirements for existing ciphertext. When you rotate a KMS key, AWS KMS retains the old backing key for decryption of previously encrypted data, and the same KMS key ID continues to be used for both encrypt and decrypt operations—so a new key ID would break all references and force you to re-encrypt every secret. More importantly, the decryption failure is caused by the missing or incorrect encryption context in the application's decrypt call, not by the key's age or cryptographic material. Changing keys would add operational overhead and still leave the application's decrypt logic broken for any ciphertext that was created with the correct context, since that context must still be supplied to decrypt successfully.

Only in the S3 bucket policy by granting s3:GetObject, because S3 bucket policy controls decryption.

Why it fails: S3 bucket policies govern S3 control-plane and data-plane operations such as s3:GetObject for retrieving the object, but they have no authority over KMS actions. When an object is encrypted with SSE-KMS, S3 invokes KMS to decrypt the data key on the caller's behalf, and KMS authorizes that call by evaluating the key policy and the caller's IAM policies against the kms:Decrypt action. Granting only s3:GetObject in the bucket policy gives the caller access to the encrypted ciphertext but does not allow KMS to decrypt it, so the GetObject request fails if the role lacks the necessary KMS permissions.

Only in the IAM role identity policy; the KMS key policy does not need changes for SSE-KMS.

Why it fails: For customer-managed keys, a restrictive CMK key policy can deny or omit access. In that case, identity-policy kms:Decrypt permission alone is insufficient because the key policy is also evaluated and must allow the role to use the key for decryption.

By enabling S3 default encryption; KMS permissions are automatically granted to all IAM roles in the account.

Why it fails: Enabling S3 default encryption only configures the encryption applied to newly written objects; it is a write-time bucket setting that does not modify the customer-managed CMK's key policy or grant any IAM principal permissions to call kms:Decrypt. Even if default encryption is enabled, KMS evaluates each decryption request independently against the key policy, so roles attempting to read objects must be separately authorized to use that CMK. Without explicit kms:Decrypt permission in the key policy, or a matching IAM policy that the key policy allows, S3 GetObject requests will fail with an AccessDenied error.

Allow s3:PutObject on arn:aws:s3:::ci-artifacts/* and allow s3:ListBucket on arn:aws:s3:::ci-artifacts without any prefix condition.

Why it fails: This policy grants s3:PutObject on arn:aws:s3:::ci-artifacts/*, which permits writes to the bucket root and to every prefix, not just uploads/, thereby expanding the upload scope far beyond the required path. Additionally, s3:ListBucket is allowed on the bucket ARN with no s3:prefix condition, so the principal can list every object in the entire bucket rather than being restricted to uploads/. Combined, these permissions violate least privilege by giving broad write and read access that the CI pipeline does not need.

Allow s3:GetObject on arn:aws:s3:::ci-artifacts/uploads/* so the pipeline can confirm artifacts exist.

Why it fails: s3:GetObject is a read-only action that retrieves an object's contents or metadata; it grants no ability to perform s3:PutObject, so the pipeline cannot upload artifacts. Even if the intent were to verify artifact existence, GetObject on uploads/* requires knowing the exact object key, which is not the stated requirement. This option therefore completely fails to authorize the write operation needed by the CI pipeline.

Allow s3:PutObject on arn:aws:s3:::ci-artifacts/uploads/* and also allow s3:DeleteObject on arn:aws:s3:::ci-artifacts/uploads/*.

Why it fails: While this option correctly scopes s3:PutObject to the uploads/ prefix, it adds s3:DeleteObject on the same prefix, which is not necessary for uploading artifacts. PutObject already creates or overwrites objects; DeleteObject is a separate destructive action that increases the risk of accidental or malicious removal of build artifacts. Least privilege dictates granting only the minimum actions needed, and the pipeline only needs to write objects and verify them via a scoped ListBucket, not delete them.

Attach an IAM policy in Account B that grants s3:* on the bucket and its objects.

Why it fails: An identity policy in Account B alone cannot authorize access to a bucket in another account. S3 also requires a matching resource policy or equivalent cross-account trust, and broad s3:* is unnecessary for least privilege.

Create an S3 gateway endpoint in Account B so the application can reach the bucket privately.

Why it fails: An S3 gateway endpoint is a networking feature that provides private connectivity from Account B's VPC to S3, but it does not grant any data-plane authorization. The AccessDenied error occurs because the bucket policy and KMS key policy in Account A do not yet permit the external role, not because traffic traverses the public internet. Even with the endpoint configured, S3 will still evaluate the bucket policy and KMS key policy and deny the request if the role lacks s3:GetObject and kms:Decrypt permissions, so this option does not address the root cause.

Add an SCP in Account A that allows the Account B role to bypass KMS encryption checks.

Why it fails: Service control policies (SCPs) are guardrails applied at the AWS Organizations account or OU level that limit the maximum permissions for principals within that account; they can only restrict, never grant, permissions to an external role. An SCP in Account A cannot authorize an Account B role to bypass KMS encryption checks because KMS decisions are always governed by the key policy in Account A, and SCPs do not override that policy. To fix the encryption failure, the Account B role must be explicitly added to the KMS key policy with kms:Decrypt, alongside the bucket policy for s3:GetObject, so this option is both conceptually and technically incorrect.

Use an Organizations service control policy (SCP) to cap the maximum permissions for role creation in each account

Why it fails: SCPs limit what principals in a member account can do, but they are applied at the account/organization level. They are not the most direct control to enforce a per-role permissions ceiling defined by the baseline that applies to each role the teams create.

Rely on KMS key policies to restrict permissions because IAM policies cannot override KMS restrictions

Why it fails: KMS key policies only govern access to a specific category of resources—encryption keys used with AWS Key Management Service—so they cannot cap permissions for actions on EC2, S3, or IAM itself. Even for KMS-sensitive operations, a key policy is a resource-based policy that works together with (and does not supersede) IAM policies; it allows or denies specific KMS API calls but does not establish a maximum permission envelope for the role. Therefore, relying on KMS policies would leave every non-KMS action unconstrained and fail to prevent the privilege escalation that application teams could introduce with broader role policies.

Require multi-factor authentication (MFA) for all role creation requests and deny any request without MFA

Why it fails: MFA strengthens authentication for the person creating the role, but it does not limit the permissions the role can actually exercise after it is created. Permission boundaries specifically enforce a maximum set of allowed actions for the role.

Tag encrypted volumes after creation

Why it fails: Tagging encrypted volumes after creation is purely detective and has no enforcement effect. Tags are metadata labels only; they do not alter resource configuration or trigger any encryption. Tagging merely marks which volumes are already encrypted, so it helps with inventory and visibility but cannot stop unencrypted volumes from being created in the first place.

Enable VPC Flow Logs

Why it fails: VPC Flow Logs capture IP traffic information—source and destination addresses, ports, protocol, and accept/reject status—for network interfaces, not EBS volume properties. They monitor network-level activity, not data-at-rest encryption. Therefore, enabling Flow Logs would neither detect nor prevent the creation of unencrypted EBS volumes, making it irrelevant to this requirement.

Run a daily Lambda function to encrypt unencrypted volumes

Why it fails: This is a reactive remediation pattern that leaves a gap equal to the scheduling interval—up to 24 hours per day if run daily. Converting an unencrypted volume requires snapshotting it, copying/encrypting the snapshot, creating a new encrypted volume, and remounting it, which risks downtime or data loss in a production healthcare system. It also depends on the function having IAM permissions and does not stop the initial noncompliant creation, unlike a preventive SCP.

Add kms:Decrypt to the developer’s IAM policy so KMS can validate the ExternalId during AssumeRole.

Why it fails: Adding kms:Decrypt to the developer's IAM policy cannot influence STS trust policy evaluation because the sts:ExternalId condition is checked by the STS service against the value passed in the AssumeRole request, not against KMS permissions. KMS permissions govern encryption and decryption operations on AWS KMS keys, which are entirely unrelated to the trust relationship between accounts. Even with kms:Decrypt, the missing or mismatched ExternalId in the AssumeRole call will still cause AccessDenied.

Increase the role’s MaxSessionDuration to reduce authentication failures.

Why it fails: MaxSessionDuration only controls the maximum validity period of the temporary credentials after STS successfully issues them; it plays no role in whether the AssumeRole request is authorized at the moment the trust policy is evaluated. Since the ExternalId condition fails, STS denies the request before a session is even created, so increasing the session duration cannot reduce authentication failures.

Remove the ExternalId condition from the trust policy to allow all AssumeRole requests.

Why it fails: Removing the ExternalId condition from the trust policy would let the AssumeRole request pass without the required value, but it would directly violate the security requirement to protect against the confused-deputy problem. This condition is specifically designed to verify that the caller possesses the shared secret known only to the intended external account; deleting it weakens the cross-account trust boundary and leaves the role exposed to malicious third parties.

Add kms:Decrypt permissions to Account B’s IAM user because trust policy failures are KMS related.

Why it fails: This option misattributes the failure. The denial occurs during evaluation of the role's trust policy, specifically the sts:ExternalId condition, which happens in the STS service and before any KMS API is invoked. Adding kms:Decrypt to the IAM user does not alter the trust policy evaluation; IAM permissions are irrelevant when the request never gets past the initial authorization check. Even if the role's permissions include KMS actions, the caller never receives a role session to use them unless AssumeRole succeeds.

Remove the ExternalId condition from the trust policy so any caller can assume the role.

Why it fails: While removing the ExternalId condition would allow Account B's IAM user to assume the role, it does so by eliminating a defensive control that protects against the confused deputy problem. The whole point of the external ID is to ensure the role can only be assumed by a principal that knows the agreed-upon identifier, preventing a third party from misusing the role's permissions. Keeping the condition and supplying b-7f9a is the intended fix, as it resolves the error without reducing the security posture of the trust policy.

Use AssumeRoleWithSAML instead of AssumeRole so ExternalId is not required.

Why it fails: AssumeRoleWithSAML does not bypass trust policy conditions. STS evaluates the same trust policy regardless of which AssumeRole* API is used, so the sts:ExternalId condition still must be satisfied. Moreover, AssumeRoleWithSAML requires a SAML assertion from an IdP, which is not part of the CLI command sequence described. The correct fix remains to provide the missing external ID in the original AssumeRole call, not to switch to a different federation endpoint.

Add a condition requiring "StringEquals": {"aws:PrincipalOrgID": "o-example"} without any MFA condition.

Why it fails: Filtering by aws:PrincipalOrgID controls which identities (via organization) can assume the role, but it does not validate whether MFA was used in the authentication flow. Non-MFA sessions from the same org could still satisfy the trust.

Add a statement that denies sts:AssumeRole when the requested role session name contains the text "dev".

Why it fails: The role session name is supplied by the caller via the RoleSessionName parameter of sts:AssumeRole and can be set to any arbitrary string. It is not an AWS-generated indicator of authentication strength, so denying assume role when it contains "dev" does not verify whether MFA was used. A caller who authenticated without MFA could simply omit "dev" from the session name or use a different label, bypassing the check entirely while still lacking MFA protection.

Require HTTPS by setting a condition on "aws:SecureTransport": "true" in the trust policy.

Why it fails: The aws:SecureTransport condition key in the trust policy only verifies that the AssumeRole API request was sent over HTTPS/TLS. While HTTPS is a good transport security practice, it does not provide any information about whether the caller used MFA; a non-MFA session can easily make HTTPS requests through the AWS CLI, SDK, or console. Therefore, this condition prevents insecure transport but does not enforce the MFA requirement that the policy needs, leaving the role assumable by non-MFA principals.

Edit AppDeployRole’s attached identity policy to add iam:CreateRole again; permission boundaries only apply when permissions are missing.

Why it fails: Permission boundaries are an additional authorization constraint (an upper limit). Even if the role’s identity policy allows an action, IAM will deny it when the permission boundary does not allow the action for the resource.

Remove the permission boundary from the role because permission boundaries are not enforced at runtime.

Why it fails: Removing the permission boundary is not a viable fix because IAM permission boundaries are enforced on every authorization request, not only at role creation. They act as an explicit upper limit on the effective permissions: even if the role's identity-based policy allows iam:CreateRole, the boundary itself will deny the action if it does not explicitly allow it (or if it explicitly denies it), resulting in an AccessDenied error at runtime. Additionally, deleting the boundary eliminates a security control that is likely required by the organization's governance, and it does not follow the principle of least privilege—the proper fix is to scope the boundary to allow iam:CreateRole for only the specific resource ARNs the automation needs, rather than removing the control entirely.

Encrypt the deployment artifacts with KMS so IAM denies become KMS authorization failures.

Why it fails: Encrypting deployment artifacts with KMS does not address the root cause of the failure because the problem is an IAM authorization failure for the iam:CreateRole action, which occurs during the authorization phase of the API call, well before any data plane operation such as KMS decryption is attempted. The role's permission boundary still lacks an allowance for iam:CreateRole, so the call will still be denied regardless of whether the artifacts are encrypted; introducing KMS encryption would merely add a separate permission requirement for the KMS key, not satisfy the boundary. This option is orthogonal to the IAM permissions issue and would not change the outcome of the failed CreateRole request.

The request succeeds because the IAM policy explicitly allows kms:Decrypt

Why it fails: An IAM policy that explicitly allows kms:Decrypt governs what a principal can do within an account, but AWS Organizations SCPs operate as an outer authorization boundary for all principals in a member account. When an SCP contains an explicit Deny that matches kms:Decrypt, that Deny takes precedence over any Allow found in the account's identity-based or resource-based policies. The final authorization decision is effectively 'deny' because the explicit Deny in the SCP cannot be overridden by a permissive IAM statement, regardless of how explicit the IAM allow is.

The request succeeds, but only when using the KMS key policy to allow the user

Why it fails: Whether the KMS key policy allows the user is separate from the Organizations authorization filter. Even if the key policy would allow kms:Decrypt, the SCP’s explicit deny blocks the request at a higher level in the authorization flow.

The request succeeds for read-only actions and fails only for writes

Why it fails: SCP evaluation is based on the exact action string specified in the policy, not on whether the action is conceptually a read or write operation. The SCP in question explicitly denies kms:Decrypt, and that exact action is what the request calls, so the request fails. Treating kms:Decrypt as 'read-only' would not change the outcome because the SCP matches on the Action element value; there is no special handling for read-like or write-like operations. In AWS authorization, every action is denied by default unless an Allow is found that is not contradicted by a Deny, and a Deny in an SCP is decisive regardless of the action's classification.

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

Why it fails: Automatic key rotation for a customer-managed KMS key only creates new backing keys for the same key material's version; it does not modify the key policy or alter how the key is authorized for cross-account use. The AccessDenied error stems from the key policy in account B lacking an explicit statement that permits the instance role from account A to call kms:Decrypt (and kms:CreateGrant). Since rotation adds no new principals or permissions, it cannot resolve the authorization failure, so the volume mount will still fail.

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 it fails: In cross-account KMS authorization, the key policy in the key-owning account is the resource-based policy that KMS evaluates, and it must explicitly include the external principal (e.g., the instance role's ARN or the root of account A). Simply attaching an IAM permissions policy to the instance role in account A does not update that key policy, so the request still fails because the default key policy in account B grants access only to the account root or internal principals. For a valid cross-account call, both the IAM policy in the using account and the key policy in the key-owning account must grant permission; one-sided authorization is insufficient.

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

Why it fails: EBS volume encryption cannot be disabled on an existing encrypted volume; you would have to create an unencrypted volume from a snapshot, which defeats the security requirement and still does not fix the KMS authorization denial. Even if you attempted to temporarily use an unencrypted volume, the root cause is that the key policy in account B does not allow the account A instance role to use the key. Bypassing encryption is a poor security practice and does not address the cross-account KMS policy misconfiguration; the correct fix is to update the key policy to grant kms:Decrypt and kms:CreateGrant to the instance role's principal.

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

Why it fails: Making object names unguessable is not a security boundary—it is security by obscurity. If the bucket policy permits public read (effectively from the Principal '*'), any object in the bucket can be fetched by anyone who obtains or guesses its URL, and those URLs can leak via logs, HTTP referrers, or browser history. There is no way to revoke access for a single partner, enforce least privilege per prefix, or audit who accessed which report.

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

Why it fails: Sharing an IAM user's access keys with a partner creates long-term, shared credentials that live entirely in your own account. This approach fails to attribute actions to specific individuals in the partner organization, complicates key rotation and deprovisioning, and risks exposure if the keys are transmitted or stored insecurely. Even if the keys are only given to one partner, there is no scoping to a particular role or prefix beyond what the IAM user's policy permits, and the partner account gains no self-service control over access.

Copy the objects to a public website bucket

Why it fails: A public website bucket (enabled with static website hosting) turns the bucket into an internet-facing origin where every object is served as anonymous content. This is an all-or-nothing exposure: it makes the reports accessible to any user on the public internet, not just the partner, and offers no support for authentication, IAM principals, or per-object access controls. It also bypasses S3's Block Public Access safeguards and makes the data vulnerable to search engines and automated crawlers.

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

Why it fails: S3 object ACLs are legacy access list controls that govern who can read or write an object at the S3 API level; they do not influence AWS KMS authorization in any way. The AccessDenied error in this scenario is raised by KMS when S3 tries to decrypt the object's envelope key using the customer-managed CMK. Since ACLs cannot grant kms:Decrypt permissions on the CMK, changing them cannot bypass cryptographic authorization, and the partner account still lacks the required KMS access.

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

Why it fails: Creating a new bucket in the partner account and copying the objects is an architectural workaround, not a resolution of the KMS trust misconfiguration. The copy operation would require decrypting each object with the CMK first, then re-encrypting under the partner account's own key, which adds significant bandwidth, cost, and potential data exposure during transfer. It also leaves the original bucket's KMS key policy broken and maintains duplicate data, needlessly complicating the architecture rather than granting the partner role the minimal KMS actions through a policy or grant.

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

Why it fails: Switching the bucket to SSE-S3 would indeed remove the partner's need for KMS permissions because S3 fully manages those encryption keys, but it abandons the customer-managed key entirely. The scenario calls for using a CMK, likely to meet security or compliance requirements; SSE-S3 lacks per-key policies, audit trails, and the ability to rotate or revoke the key independently. Existing objects encrypted under the CMK would have to be rewritten to the new encryption type, and this is a workaround that doesn't fix the underlying trust policy configuration.

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

Why it fails: Making objects public with difficult-to-guess names is security through obscurity, not access control. Any user who obtains the URL can read the object, and object names can leak through logs, browser history, or shared links. S3 public access is not scoped to a principal or prefix; once an object is public, every AWS account and internet user can read it, so the partner's access cannot be limited to a specific role or prefix and least privilege is impossible.

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

Why it fails: Creating an IAM user and sharing access keys gives the partner a permanent, long-lived credential that is shared across all partner staff, destroying individual accountability and audit trails. These keys cannot be rotated automatically, cannot be scoped to a temporary session, and if leaked they become an unrestricted backdoor for any operation the user's policy allows. This approach also violates the recommendation to use IAM roles and temporary credentials for cross-account access.

Copy the objects to a public website bucket

Why it fails: Copying the objects to a public website bucket exposes the reports to the entire internet because S3 static website endpoints serve content anonymously over HTTP and do not evaluate IAM or bucket policies. You would not only grant the partner access but also every user who can discover the URL, and you would have to maintain a duplicate, possibly stale copy. This approach defeats least privilege and is far less secure than a private bucket with a resource-based policy.

Allow secretsmanager:* on all resources in the account.

Why it fails: Granting secretsmanager:* on all resources is an administrative privilege, not a read action: it allows creating, updating, rotating, and deleting every secret in the account. A container retrieving one known secret needs only GetSecretValue, so this wildcard policy needlessly exposes the entire Secrets Manager estate and maximizes the blast radius if the container's credentials are compromised.

Allow secretsmanager:ListSecrets so the service can discover the secret ARN at runtime.

Why it fails: ListSecrets only returns secret metadata (names, ARNs, tags, descriptions); it does not return the secret value, so the container would still need GetSecretValue to read the actual secret. The secret ARN is already configured in the container, so runtime discovery is unnecessary and granting ListSecrets lets the role probe the account for all secret names and metadata, broadening the attack surface without supporting the described read.

Allow secretsmanager:PutSecretValue so the service can retrieve and update the secret value.

Why it fails: PutSecretValue is a write operation that overwrites the secret's encrypted value; it has no role in a read-only retrieval workflow. Granting it would let the container unintentionally corrupt the secret or disrupt dependent applications, while also violating least privilege because the stated requirement only asks to read exactly one secret.

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

Why it fails: A deny-only managed policy attached to an IAM group can block specific named actions, but it cannot impose an upper bound on the permissions that a developer-created role will have. IAM group policies apply only to the users in the group, not to roles created by those users, so the newly created roles are outside the group's deny scope. Deny statements also only reject the exact actions listed, leaving all other permissions available, so this measure fails to enforce an 'approved maximum permissions' ceiling.

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

Why it fails: An AWS Organizations SCP acts as a permission filter at the account or OU level, not as a grant mechanism. It cannot 'grant' the approved Lambda permissions to a specific developer role because SCPs only constrain the maximum allowed permissions for principals in the account; the actual permissions must still come from identity-based policies attached to the role. Additionally, SCPs apply to all principals in scope, not directly to individual roles, so this approach does not cap what a developer-created role can receive and does not address the role-creation escalation path.

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

Why it fails: The choice between inline and managed policies affects lifecycle management and reuse, not the maximum permission scope. Inline policies can still contain broad permissions—including full Lambda access—and they are embedded directly in the role, making them harder to audit than managed policies. A developer could attach an inline policy granting excessive permissions just as easily as a managed policy, so this practice alone does not prevent privilege escalation or enforce a security-approved boundary.

The S3 bucket is configured with default encryption using SSE-S3, which conflicts with SSE-KMS and causes decryption failures.

Why it fails: SSE-S3 and SSE-KMS are both valid encryption options for S3. If the bucket default were SSE-S3, objects would use an S3-managed key and no KMS permissions would be needed. The scenario explicitly states SSE-KMS with a customer-managed key, so the conflict described does not exist. The failure is due to missing kms:Decrypt permission.

The S3 bucket policy does not explicitly allow the IAM role to perform s3:GetObject.

Why it fails: The scenario states the IAM role already has s3:GetObject permission on the bucket. An explicit bucket policy is not required for same-account access when the IAM identity policy allows the action. The AccessDenied error stems from KMS key permissions, not S3 bucket policy. Adding a bucket policy would not resolve the missing kms:Decrypt permission on the customer-managed key.

The EC2 instance's security group does not allow outbound HTTPS traffic to the AWS KMS endpoint.

Why it fails: S3 handles the KMS decryption on behalf of the caller; the EC2 instance does not call KMS directly. Even if the instance cannot reach KMS, S3 performs the decrypt operation server-side. The AccessDenied error indicates an authorization failure, not a network connectivity issue. Security group rules for outbound HTTPS would not change the KMS authorization outcome.

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

Why it fails: 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 it fails: 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 it fails: 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.