When you create a VM in Compute Engine, the network settings panel asks you to make a few decisions that have nothing to do with machine type or boot disk. These decisions show up on the Professional Cloud Architect exam because they shape what traffic can reach your VM and whether your VM has a stable address. The three I want to walk through are the firewall checkboxes at VM creation time, network tags, and the choice between dynamic and static IP addresses.
By default, all external traffic to a new VM is blocked. That is the right default. If your VM does not need to be publicly accessible, you can leave every firewall checkbox unchecked and configure more specific rules later through the Cloud Firewall service.
The creation panel exposes three convenience checkboxes:
Two takeaways from this panel for the exam. First, always prefer HTTPS over HTTP when the workload needs any kind of secure communication. Second, health check rules are not optional once a load balancer is in front of the VM. They are the mechanism that tells the load balancer whether the backend can serve.
Anything beyond these three boxes is handled by Cloud Firewall, which gives you full control over source ranges, protocols, ports, priorities, and direction. The checkboxes are just shortcuts for the most common cases.
Network tags are short labels you attach to a VM, and they are how you make firewall rules dynamic instead of having to enumerate VMs by name or IP.
The pattern looks like this. You have three VMs. VM1 and VM2 carry the tag web-server. VM3 carries the tag test-server. You write a single firewall rule that says "allow HTTP and HTTPS to any VM with the web-server tag." Now an inbound HTTPS request hits all three VMs, but only VM1 and VM2 accept it. VM3 is dropped by the default deny because its tag does not match.
The strength of this design is that the firewall rule never has to change. If VM3 later needs to serve web traffic, you add the web-server tag to it and the existing rule starts applying immediately. If you need to take a VM out of rotation, you remove the tag. Tags can be added, removed, or updated at any time, and the rule reacts.
This is how you manage access control for tiered architectures at scale. Web tier, app tier, database tier each get their own tag, and you write firewall rules per tier rather than per instance. For the Professional Cloud Architect exam, recognize network tags as the right answer when a question describes flexible, instance-level firewall targeting that survives VMs being added and removed from a fleet.
The other network decision at VM creation is whether to take the default dynamic IP or reserve a static IP.
By default, VMs are given dynamic IPs. The address is assigned automatically when the VM starts, and it changes whenever the VM is stopped and restarted. A VM might come up as 34.123.X.X, get stopped, and come back up as 35.187.Y.Y. For temporary or stateless workloads where nothing external is pinning to the address, this is fine and it is the cheaper option.
Static IPs, internal or external, are reserved addresses that stay linked to the VM across restarts. The IP does not change. You reserve it once, and the VM keeps it.
You want a static IP whenever something external depends on the address being stable:
For the exam, the rule of thumb is simple. Dynamic is the default and is fine for ephemeral workloads. Static is required when DNS, allowlists, or any other external system has the address baked in. The Professional Cloud Architect exam will test this by giving you a scenario where someone's mapping breaks after a VM restart, and the right answer is to reserve a static IP.
My Professional Cloud Architect course covers Compute Engine network settings alongside the rest of the compute material.
