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 subnet's route table does not have a route to the internet gateway.

  Why this is correct

  Even when an instance has an Elastic IP and the VPC contains an internet gateway, the subnet's route table must include a default route (0.0.0.0/0) with the internet gateway as the target. Without that route, the instance cannot send traffic out to the internet because the IGW is the only mechanism that forwards VPC traffic to the outside world. In CloudFormation, if you create a custom route table but forget to add the IGW route or forget to associate the route table with the subnet, the subnet will use the VPC's main route table, which may not have the required route. This is the most direct and common cause of unreachable internet connectivity despite having a public IP.

• ✗

  The instance does not have a public IP address.

  Why it's wrong here

  The statement that the instance does not have a public IP address is incorrect in this scenario because an Elastic IP is, by definition, a public IP address assigned to the instance. Even if the instance originally relied on an auto-assigned public IP, attaching an Elastic IP provides a stable public address. The real problem is not the presence or absence of a public IP; it's that the network path to the internet is broken at the routing layer. A public IP alone does not enable internet access unless the subnet route table points to an internet gateway, so this option misidentifies the root cause.

• ✗

  The instance is in a private subnet.

  Why it's wrong here

  A private subnet is defined as a subnet that has no direct route to an internet gateway, so an instance there would indeed need a NAT gateway or NAT instance for outbound access. However, in this scenario the VPC has an internet gateway and the instance has an Elastic IP, which strongly implies the subnet was designed to be public and should have a direct IGW route. If the subnet were truly private, the absence of an IGW route would be normal, but the reported issue is that the instance cannot reach the internet at all. Therefore, the fact that the instance is in a subnet that lacks the IGW route is a routing misconfiguration, not a deliberate private-subnet design.

• ✗

  The security group does not allow outbound traffic.

  Why it's wrong here

  Security groups are stateful and, by default, allow all outbound traffic from an instance. Unless you explicitly created an inbound rule that restricts egress or removed the default outbound rule, the security group will not block internet-bound traffic. Additionally, any response traffic returning from the internet is automatically allowed because security groups track connection state, so even an inbound-only restriction would not affect established outbound sessions. The lack of outbound connectivity is far more likely caused by the route table missing the IGW route, not by security group egress rules. This option would only be plausible if the CloudFormation template explicitly removed or overrode the default egress rule, which is not indicated.

Go deeper

Related to this question