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.

• ✗

  Check the AMI ID to ensure it is a valid Linux AMI

  Why it's wrong here

  The instance is already in a "running" state, which confirms that the specified AMI ID was valid and successfully used to launch the EC2 instance. The issue described is an inability to SSH, which is a connectivity problem, not a fundamental issue with the AMI's validity or its ability to boot an operating system. While a misconfigured AMI could prevent SSH, the primary concern here, given the instance is running, is usually network access or SSH service configuration, not the AMI's basic validity.

• ✗

  Check the instance's network interfaces for a public IP

  Why it's wrong here

  The `describe-instances` command output *should* directly display the `PublicIpAddress` attribute if the instance has one assigned for direct internet access. If this attribute is absent from the command's output, it strongly suggests the instance lacks a public IP, which would indeed prevent direct SSH connectivity from the internet. While `describe-network-interfaces` provides more granular details, the initial `describe-instances` output is sufficient to determine the presence of a public IP for the primary interface.

• ✗

  Check the instance status checks in the EC2 console

  Why it's wrong here

  EC2 instance status checks, comprising system status checks and instance status checks, primarily monitor the underlying AWS infrastructure and the guest operating system's health, respectively. While a failed status check could indicate an underlying issue preventing the instance from fully booting or running the SSH daemon, a "running" instance state, as implied by the question, typically means these checks are passing. Therefore, passing status checks do not guarantee network reachability or correct security group configuration for SSH.

• ✓

  Check the security group rules associated with the instance

  Why this is correct

  Security groups function as stateful virtual firewalls that control inbound and outbound traffic for an EC2 instance. For SSH connectivity, an inbound rule must explicitly permit TCP traffic on port 22 from the source IP address range (e.g., `0.0.0.0/0` for anywhere, or a specific IP) to the instance. If no such rule exists, or if the source IP is not allowed, the connection attempt will be silently dropped at the security group level, preventing SSH from establishing.

Go deeper

Related to this question