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 launch template is using an incorrect version.

  Why it's wrong here

  The launch template version controls which AMI, user data, and instance settings are applied at launch; an incorrect or old version would still honor whatever AMI/repository configuration that template points to. The failure is not caused by the version selection itself—it merely selects a configuration—so the observed cloud-init repo error would only happen if that version's AMI is itself stale. A version mismatch typically shows symptoms like mismatched instance type, security groups, or key pair, not invalid package repository URLs.

• ✗

  The IAM instance profile does not have sufficient permissions.

  Why it's wrong here

  An IAM instance profile grants the instance permissions to make AWS API calls (e.g., to S3, SSM, or EC2 actions), but package repository access over yum/apt is an OS-level HTTPS request to public repositories and is not authenticated by IAM. Insufficient IAM permissions would cause failures when cloud-init tries to call AWS APIs for things like SSM registration or custom metadata, not when it tries to reach a repo. The error message about invalid repositories indicates the issue is the upstream repo endpoint, not the instance's AWS credentials.

• ✗

  The Auto Scaling group is in a private subnet without a NAT gateway.

  Why it's wrong here

  A private subnet without a NAT gateway would prevent the instance from reaching the internet, so package downloads would fail with timeouts or DNS resolution errors, not with a clear 'repository no longer valid' message. The scenario states instances boot and cloud-init runs, which means the user-data script began executing; if there were no internet access, cloud-init would likely hang or report inability to connect rather than getting a definitive repo invalidity response. Therefore, the network path is probably intact, and the 'invalid repository' error points to a stale repository configuration, not to lack of outbound connectivity.

• ✓

  The AMI used by the launch template is outdated and the repositories are no longer valid.

  Why this is correct

  An outdated AMI often contains yum or apt repository URLs that point to deprecated or retired endpoints. When cloud-init executes user data that runs package installs, the package manager tries to reach those old repositories and receives a 404 or 'repository not found' response, causing the boot-time failure. This is a common issue with Amazon Linux AMIs that have reached end-of-life, where the original repositories are no longer maintained and the instance cannot update or install software despite successfully booting.

Go deeper

Related to this question