CompTIA Cloud+ (CV0-004)TroubleshootingMedium

A cloud administrator is unable to access a newly deployed Linux virtual machine (VM) via SSH. The VM is in a private subnet, and a NAT Gateway is configured in a public subnet for outbound internet access. The security group associated with the VM allows inbound SSH (port 22) from the administrator's IP address. A bastion host is set up in the public subnet, and the administrator can successfully SSH into the bastion host. What is the MOST likely reason for the SSH failure to the private VM?

  1. AThe NAT Gateway is misconfigured, preventing inbound SSH traffic.
  2. BThe Network Access Control List (NACL) for the private subnet is blocking inbound SSH.
  3. CThe security group on the bastion host is blocking outbound SSH to the private VM.
  4. DThe routing table for the public subnet is not configured to send traffic to the private subnet.
Show answer & explanation

Correct answer: B. The Network Access Control List (NACL) for the private subnet is blocking inbound SSH.

Since the administrator can SSH into the bastion, and the VM's security group allows SSH, the issue is likely at the subnet level. NAT Gateways are for outbound traffic, not inbound. NACLs are stateless and apply to subnets, so an incorrectly configured NACL on the private subnet could be blocking the inbound SSH traffic from the bastion host.

Why the other options are wrong

  • A. NAT Gateways are for outbound traffic from private subnets and do not handle inbound connections.
  • C. The question implies the administrator is trying to SSH *from* the bastion *to* the private VM. The bastion's outbound rules would need to allow this, but a failure to reach the private VM points to an issue on the private VM's path or its own network controls.
  • D. Traffic between subnets in the same VPC is typically handled by local routes, which are usually default. The failure to reach indicates a specific block, not a general routing absence.

Bastion Host

A special purpose server in a public subnet that acts as a secure jump server to access instances located in private subnets.

  • Provides a single, hardened entry point.
  • Requires inbound SSH/RDP rules from trusted IPs only.
  • Used to manage instances in private subnets without public IPs.

Memory trick: Bastion's Door is Open, But Subnet's Gate May Be Shut.

More Troubleshooting questions