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.

• ✗

  Create an IAM user in the company account for the auditing firm and email the access key and secret key to the firm's security contact.

  Why it's wrong here

  Creating an IAM user with access keys issues long-term credentials, which the requirement explicitly forbids. Emailing keys increases exposure risk and makes rotation and revocation harder. This option also does not limit the blast radius well because the keys can be used until deleted or rotated.

• ✓

  Create an IAM role in the company account with a trust policy that allows the auditing firm's AWS account to assume it, and attach a policy granting s3:GetObject on the specific object prefix.

  Why this is correct

  Cross-account access without long-term credentials is achieved with an IAM role that the external account assumes. Scoping the role policy to s3:GetObject on a specific prefix limits the blast radius if the external account is compromised. This is the standard AWS pattern for temporary cross-account access and meets the read-only requirement.

• ✗

  Attach an S3 bucket policy that grants s3:GetObject to the auditing firm's IAM user ARN, and disable S3 Block Public Access to allow the cross-account policy to work.

  Why it's wrong here

  S3 Block Public Access does not need to be disabled for cross-account access to a non-public bucket. Granting access to an IAM user ARN in another account is possible, but it is less clean than role assumption and can be brittle if the firm changes users. This option also introduces an unnecessary and risky change to public access settings.

• ✗

  Make the S3 bucket public and share the object URLs with the auditing firm so no AWS credentials are needed.

  Why it's wrong here

  A public bucket exposes the objects to anyone with the URL, not just the auditing firm, and violates the least privilege and blast radius requirements. It also cannot be scoped to a specific external account. This approach removes credential management but at an unacceptable security cost and does not meet the read-only scoped access goal.

• ✓

  Require the auditing firm to call sts:AssumeRole and use the resulting temporary credentials, and set a maximum session duration and an external ID in the trust policy.

  Why this is correct

  Using sts:AssumeRole provides temporary credentials that expire, which avoids long-term secrets. Setting a maximum session duration limits how long a compromised session is usable, and an external ID protects against the confused deputy problem. This complements the role creation step and satisfies the temporary access and blast radius goals.

Go deeper

Related to this question