Google PCA Design and plan a cloud solution architecture Practice Question

Exhibit

resource "google_compute_firewall" "allow_ssh" {
  name    = "allow-ssh"
  network = "default"
  priority = 1000
  allow {
    protocol = "tcp"
    ports    = ["22"]
  }
  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["ssh-allowed"]
}

resource "google_compute_instance" "my_instance" {
  name         = "my-instance"
  machine_type = "e2-micro"
  zone         = "us-central1-a"
  tags         = ["web", "ssh-allowed"]
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
  network_interface {
    network = "default"
    access_config {
      // Ephemeral public IP
    }
  }
}

Refer to the exhibit. An engineer deploys this Terraform configuration. After deployment, they can SSH into the VM using its public IP. However, they want to restrict SSH access to only a specific IP range (203.0.113.0/24). What change is required?

⚠ Common exam trap

PCA often tests whether candidates over-engineer the fix by adding tags or new rules when the existing rule already targets the instance correctly and only the source range needs tightening.

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

✓

Change the 'source_ranges' in the firewall rule to ['203.0.113.0/24']. The instance already has the required tag.

The firewall rule already targets the instance via the 'ssh-allowed' tag, so the only change needed is to narrow the source_ranges from the current open range (e.g., 0.0.0.0/0) to ['203.0.113.0/24']. Since the instance already carries the required tag, no tag modification is necessary — just update the source range in the existing rule. This is the minimal, correct change to restrict SSH to the specified CIDR.

Answer analysis

Option-by-option breakdown

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

✓
Change the 'source_ranges' in the firewall rule to ['203.0.113.0/24']. The instance already has the required tag.
Why this is correct
Editing the firewall rule's `source_ranges` to `['203.0.113.0/24']` narrows the permitted source addresses at the VPC firewall layer, satisfying the requirement to restrict SSH to that range. Because the instance already carries the matching target tag, the rule continues to apply, so no other configuration change is needed.
✗
Modify the instance to use a network tag 'restricted-ssh' and update the firewall rule target_tags accordingly.
Why it's wrong here
Introducing a new tag creates a rule the existing firewall does not match, so the original 0.0.0.0/0 rule still permits SSH from anywhere. Retagging is correct when deliberately reassigning an instance between separate firewall policies, not when merely restricting source ranges.
✗
Add a new firewall rule with higher priority allowing SSH from 203.0.113.0/24, and keep the existing rule but change its priority to 100.
Why it's wrong here
Incorrect: This would still allow SSH from all IPs because the existing rule with lower priority (100) would still apply. Lower priority number means higher priority, so the new rule would take precedence only if it has higher priority (lower number). But the existing rule would still match traffic from 0.0.0.0/0 and allow it.
✗
Update the 'source_ranges' in the firewall rule to ['203.0.113.0/24'] and remove the 'ssh-allowed' tag from the instance.
Why it's wrong here
Removing the tag while leaving the firewall rule's target_tags unchanged detaches the rule from the instance, so no firewall applies and SSH stays open to 0.0.0.0/0. Tag removal is right when decommissioning an instance from a rule entirely, not when narrowing permitted source ranges.

Visual reference

Go deeper

Google PCA Design and plan a cloud solution architecture Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question