Answer-first summary for fast verification
Answer: The setup of compute instance network tags and VPC firewall rules permits SSH from 0.0.0.0 but blocks SSH from the VPC subnets IP range.
The correct answer is **D**. The combination of compute instance network tags and VPC firewall rules can indeed lead to SSH traffic being permitted on the external IP range while being blocked from the subnets IP range. Specifically, a firewall rule might be set to allow SSH traffic from 0.0.0.0/0 but deny it from the VPC range, such as 10.0.0.0/8. This configuration would result in all SSH traffic from within the VPC being denied, whereas external SSH traffic (via external IP) is allowed. - **Option A** is incorrect because every compute instance is assigned one or more internal IP addresses, making it impossible for the internal IP address to be 'disabled'. - **Option B** is incorrect as there are no such things as cross-region SSH IAM permissions. - **Option C** is incorrect because static internal IPs do not inherently prevent SSH connections; with proper network setup, SSH works fine on static internal IPs. For more information, refer to [Google Cloud's documentation on IP addresses](https://cloud.google.com/compute/docs/ip-addresses#networkaddresses) and [using firewalls](https://cloud.google.com/vpc/docs/using-firewalls).
Author: LeetQuiz Editorial Team
Ultimate access to all questions.
No comments yet.
You have two compute instances within the same VPC but located in different regions. While you can SSH from one instance to another using their external IP addresses, attempts using internal IP addresses fail. What could be causing the SSH failure on the internal IP address?
A
The internal IP address is disabled.
B
The compute instances are not configured with the correct cross-region SSH IAM permissions.
C
The compute instances have a static IP assigned to their internal IP.
D
The setup of compute instance network tags and VPC firewall rules permits SSH from 0.0.0.0 but blocks SSH from the VPC subnets IP range.