SOA-C02 Reliability and Business Continuity 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.

• ✓

  Identify the bucket and account, then write the policy with correct principal and actions, then save the policy, then test access.

  Why this is correct

  Correct order ensures the policy is scoped properly: you must first identify the exact S3 bucket ARN and the AWS account that owns it, since a bucket policy's Resource element must reference that ARN and the Principal often specifies the account. Next, write the policy statements with explicit action permissions (e.g., s3:GetObject) and principals, then attach or save the policy to the bucket via the S3 console or PutBucketPolicy API. Finally, test access using IAM Access Analyzer, the S3 console's policy simulator, or an actual request to confirm the intended effect. Skipping any step risks misconfiguration or a policy that is not evaluated.

• ✗

  Write the policy with correct principal and actions, then identify the bucket and account, then save the policy, then test access.

  Why it's wrong here

  This sequence is incorrect because writing the policy before identifying the bucket and account leaves you without the essential context needed for the Resource and Principal fields; a bucket policy must include the bucket's Amazon Resource Name (ARN) and often the account ID to grant or restrict access correctly. If you draft the policy first, you may reference an incorrect ARN or omit the account-based principal, leading to a malformed policy that cannot be saved or that grants unintended access. Even if you later correct the policy, you would have to rewrite it, making this order inefficient and error-prone. The bucket identity is a prerequisite, not an afterthought, in policy construction.

• ✗

  Identify the bucket and account, then write the policy with correct principal and actions, then test access, then save the policy.

  Why it's wrong here

  This ordering is invalid because saving the policy is what makes it active for evaluation; testing the policy before saving will test any previously attached policy or, if no policy exists, the bucket's default private permissions, not the policy you just wrote. Since S3 only evaluates bucket policies that are attached and persisted to the bucket, an unsaved policy never influences requests, so your test would produce misleading results. You must first save the policy through the PutBucketPolicy operation or console, and then verify access with a test to see the new policy's effect. Reversing these steps means you are validating an imaginary policy, not the one actually enforced.

• ✗

  Identify the bucket and account, then save the policy, then write the policy with correct principal and actions, then test access.

  Why it's wrong here

  This sequence is wrong because saving the policy before writing its statements will overwrite the current bucket policy with an empty or incomplete policy, which typically removes all existing permissions or applies a default deny-all effect. After saving a blank policy, writing the policy afterward does not automatically persist it—you would need to save again or use a procedure like PutBucketPolicy with the JSON document in one step. The correct approach is to compose the complete policy JSON first, then save it atomically, ensuring the bucket always has a well-formed, intended policy. Saving first not only fails to record the eventual policy but can also disrupt live access until the second save.

Go deeper

Related to this question