Google PCA Manage and provision cloud infrastructure Practice Question

Exhibit

Refer to the exhibit.

gcloud compute instances create my-instance \
    --zone=us-central1-a \
    --machine-type=n1-standard-2 \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --boot-disk-size=50GB \
    --boot-disk-type=pd-standard \
    --tags=http-server,https-server

A developer runs the command above. The instance is created successfully, but cannot be reached via HTTP from the internet. What is the most likely cause?

⚠ Common exam trap

Google Cloud often tests the misconception that creating a VM with a public IP automatically makes it reachable from the internet, when in reality GCP's default firewall rules block all ingress traffic until explicitly opened.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

There is no firewall rule allowing ingress traffic on ports 80 and 443.

The most likely cause is that there is no firewall rule allowing ingress traffic on ports 80 and 443. By default, Google Cloud Platform (GCP) firewall rules block all incoming traffic from the internet. Even though the instance is created successfully, HTTP/HTTPS traffic cannot reach it unless a firewall rule explicitly permits ingress on TCP ports 80 and 443, typically via a target tag like 'http-server' or 'https-server'.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
There is no firewall rule allowing ingress traffic on ports 80 and 443.
Why this is correct
Compute Engine instances have no implicit inbound access; the default network's firewall rules govern traffic. Without an ingress rule permitting TCP 80 and 443 from the relevant source ranges, HTTP requests from the internet are dropped before reaching the instance, even though it booted successfully.
✗
The machine type n1-standard-2 is not suitable for HTTP.
Why it's wrong here
Machine type dictates vCPU and memory, not network reachability; n1-standard-2 handles web traffic without issue. The actual cause is the absent firewall rule allowing tcp:80 ingress. Machine type would matter when sizing for CPU-bound workloads, but it cannot block HTTP access from the internet.
✗
The image family debian-10 does not support HTTP.
Why it's wrong here
Debian 10 images run HTTP servers perfectly well; the family only determines the OS and package set. The real blocker is the missing firewall rule permitting tcp:80, since default VPC networks drop inbound traffic. Choosing a different image family is tempting when troubleshooting boot failures, but image selection never governs network reachability.
✗
The boot disk type pd-standard is too slow.
Why it's wrong here
pd-standard affects disk IOPS and latency, not inbound connectivity; the instance boots and serves fine on it. HTTP fails because no firewall rule permits tcp:80. Disk type becomes the correct consideration when tuning database throughput or boot performance, never when diagnosing unreachable ports.

Go deeper

Google PCA Manage and provision cloud infrastructure Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question