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 EC2 instance profile does not have an IAM policy granting s3:GetObject on the application version

  Why this is correct

  In Elastic Beanstalk, the EC2 instances that form your environment rely on the instance profile (an IAM role) to retrieve the application source bundle from Amazon S3 during deployment. If that instance profile is missing a policy permitting s3:GetObject on the bucket or object containing the application version, the instances receive an Access Denied error and the deployment fails. This is the classic root cause because many assume the service role handles this, but the service role is only used by the Elastic Beanstalk service itself.

• ✗

  The Elastic Beanstalk service role does not have permissions to access S3

  Why it's wrong here

  The Elastic Beanstalk service role is an IAM role assumed by the Elastic Beanstalk service, not by your EC2 instances. It is responsible for managing the environment's underlying AWS resources, such as Auto Scaling groups, CloudWatch alarms, and Elastic Load Balancer. Even if this role lacks S3 permissions, it would not block the instances from downloading the application version, because the instances authenticate with their own instance profile. Therefore, this misconfiguration does not explain the S3 access failure during deployment.

• ✗

  The S3 bucket is in a different AWS Region

  Why it's wrong here

  An S3 bucket located in a different AWS Region than the Elastic Beanstalk environment is accessible as long as the instances have appropriate IAM permissions and network routes. S3 supports cross-region access via its global endpoint or by specifying the regional endpoint, so a regional mismatch alone is not a cause of failure. The deployment would still succeed because the object is fetched over HTTPS, though there might be slight latency. The likely culprit is still IAM, not the bucket's region.

• ✗

  The S3 bucket containing the application version has public read access disabled

  Why it's wrong here

  The EC2 instances never require the application version S3 bucket to be publicly readable; they authenticate by signing requests with temporary credentials obtained through the instance profile. Disabling public read access via bucket policies or Block Public Access settings is a security best practice and does not interfere with IAM-based access. A failed deployment despite this setting indicates the instance role lacks the necessary s3:GetObject permission, not that the object needs to be exposed publicly.

Go deeper

Related to this question