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.

• ✓

  Allow s3:PutObject on arn:aws:s3:::ci-artifacts/uploads/* and allow s3:ListBucket on arn:aws:s3:::ci-artifacts with a condition that restricts s3:prefix to uploads/.

  Why this is correct

  This scopes object writes to only the uploads/ prefix (resource-level restriction for s3:PutObject) and scopes object listing to only that same prefix by restricting the ListBucket request via the s3:prefix condition key (bucket-level authorization for s3:ListBucket).

• ✗

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

  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.

  When this WOULD be correct

  This option would be correct if the requirement was to allow the pipeline to upload artifacts to any location under the bucket and list all objects (e.g., for general bucket management). For example, a CI pipeline that needs to upload build outputs to various folders and verify the entire bucket contents.

• ✗

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

  Why it's wrong here

  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.

  When this WOULD be correct

  A scenario where the pipeline needs to download or read the content of uploaded artifacts (e.g., for validation or processing) would require s3:GetObject on the upload path.

• ✗

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

  Why it's wrong here

  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.

  When this WOULD be correct

  This option would be correct if the pipeline also needed to delete old or failed uploads from the uploads/ prefix to manage storage or clean up after a failed build.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question