SOA-C02 Deployment, Provisioning, and Automation 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.

• ✓

  The IAM role assumed by the Elastic Beanstalk environment

  Why this is correct

  The Elastic Beanstalk environment uses an IAM service role to interact with other AWS services. To read the artifact from S3, that role must have s3:GetObject permission on the artifact bucket. Denial often indicates the role lacks these permissions.

• ✗

  The IAM role used by CodeBuild

  Why it's wrong here

  The CodeBuild IAM role is scoped to the build phase: it grants permissions to pull source code, execute build commands, and push build artifacts to the pipeline's artifact S3 bucket. During deployment, Elastic Beanstalk retrieves the artifact from S3 using its own environment's service role, not the CodeBuild role. An 'Access Denied' error when reading the artifact therefore points to the Elastic Beanstalk role missing s3:GetObject, not to the CodeBuild role's policies. Even if the CodeBuild role were misconfigured, it would fail at the build stage, not during the deploy action.

• ✗

  Whether the artifact bucket is in the same region as the pipeline

  Why it's wrong here

  The artifact bucket can reside in a different AWS Region from the pipeline as long as the pipeline's service role and the Elastic Beanstalk environment role have cross-region permissions (e.g., s3:GetObject on the bucket ARN). A region mismatch alone would not produce an 'Access Denied' error; it would instead cause a different symptom like a 'Cannot access S3 object' timeout or an S3 bucket not found error. The error here is an authorization failure, meaning the request reached S3 but the principal lacked the required permission. Thus, the root cause is the Elastic Beanstalk environment's IAM role, not the bucket's region.

• ✗

  The S3 bucket policy for the artifact bucket

  Why it's wrong here

  The artifact bucket is managed by AWS CodePipeline, and its bucket policy typically allows access to the pipeline's service role. However, the error arises from the Elastic Beanstalk role lacking permissions, not from an overly restrictive bucket policy.