SAA-C03 Design Secure Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

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

  Why it's wrong here

  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.

• ✓

  Update DeployBoundary to allow iam:CreateRole for only the required resource ARNs, following least privilege.

  Why this is correct

  IAM permission boundaries define the maximum set of permissions the role can use. To permit iam:CreateRole, the DeployBoundary must explicitly allow iam:CreateRole (and scope it to the required resources). The attached identity policy alone is not sufficient when the boundary is more restrictive.

• ✗

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

  Why it's wrong here

  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's wrong here

  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.

Go deeper

Related to this question