DVA-C02 Troubleshooting and Optimization 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.

• ✗

  Verify that the instance has an Elastic IP associated.

  Why it's wrong here

  An Elastic IP (EIP) provides a static, public IPv4 address that you can associate with an EC2 instance, ensuring its public IP remains constant even after stop/start cycles. However, an EC2 instance can be perfectly reachable from the internet using a dynamically assigned public IP address, which AWS automatically provides to instances launched into a public subnet by default. Therefore, the absence of an EIP does not inherently prevent an instance from being reachable if it already possesses a public IP, making this an unlikely cause for general reachability issues.

• ✓

  Check the network ACL associated with the subnet for rules that may block traffic.

  Why this is correct

  Network ACLs are stateless, meaning both inbound and outbound rules must be explicitly evaluated for traffic to flow, unlike security groups which are stateful and automatically allow return traffic. In this scenario, the instance passes status checks and security group rules appear correct, so the developer must verify whether the subnet’s network ACL is blocking inbound or outbound traffic, satisfying the constraint that the issue lies at the subnet boundary rather than the instance or security group.

• ✗

  Review the route table for a route to an internet gateway.

  Why it's wrong here

  The route table dictates how network traffic is routed out of a subnet, including traffic destined for the internet via an Internet Gateway (IGW). If an EC2 instance were completely unreachable from the internet, a misconfigured or missing route to the IGW would be a primary suspect. However, if the instance passes status checks or was previously reachable, it strongly suggests that the fundamental routing to the internet gateway is correctly established, shifting the focus to other network layers that might be selectively blocking traffic.

• ✗

  Inspect the IAM role attached to the instance for network permissions.

  Why it's wrong here

  IAM roles are used to grant permissions to applications running on an EC2 instance to make API calls to other AWS services, such as S3 or DynamoDB, or to manage AWS resources. They define what actions the instance *itself* can perform within the AWS ecosystem. Crucially, IAM roles do not govern or filter inbound or outbound network traffic at the IP packet level; that function is handled by security groups and network ACLs. Therefore, inspecting an IAM role for network permissions would be irrelevant to troubleshooting network reachability issues.

Go deeper

Related to this question