Cloud Firewall rules are how you control network traffic to and from your GCP resources, and the Associate Cloud Engineer exam tests them in a few distinct patterns. This article covers the structure of a firewall rule, how priority works, the difference between network tags and service-account-based rules, and the question patterns that show up on the ACE exam.
It does not cover hierarchical firewall policies in detail, organization-level rules, or every protocol GCP supports. The goal is the version that shows up on the exam.
A firewall rule is a policy that says "allow or deny traffic matching these criteria". The criteria can include direction (ingress or egress), protocol (TCP, UDP, ICMP), port range, source or destination (IP ranges, network tags, or service accounts), and a priority number.
Firewall rules apply mainly to VMs, but they also affect Load Balancers, GKE clusters, and Cloud SQL instances that live in the VPC. Both ingress (incoming) and egress (outgoing) traffic can be controlled.
Every firewall rule has a priority number from 0 to 65535. Lower numbers mean higher priority. The rule with priority 100 wins over the rule with priority 200.
This matters because rules can conflict. You might have a broad "allow all internal traffic" rule and a narrower "deny SSH from outside" rule. Priority determines which one wins for traffic that matches both.
The pattern most people use. Broad allow rules at higher priority numbers (lower priority), specific deny rules at lower priority numbers (higher priority) to override them. Build your default access posture first, then add the exceptions on top.
Network tags are labels you apply to VMs. You then write firewall rules that target VMs with specific tags. "Allow port 80 ingress to any VM with the tag web-server." Apply the web-server tag to your web VMs and the rule applies to them automatically.
Tags make firewall rules portable across VMs without having to list IP addresses individually. They are simple and convenient.
The downside is that tags are user-applied. Anyone with permission to edit a VM can add or remove a tag. That makes tags a relatively weak identity for security purposes. Anyone who can manage VMs can grant themselves access to a tag-protected service by adding the right tag to their VM.
This is the newer approach the Associate Cloud Engineer exam calls out specifically. Instead of (or in addition to) tags, you can write firewall rules that target VMs by the service account those VMs run as.
"Allow traffic from VMs running as service-account-A to VMs running as service-account-B." The rule fires based on identity, not on a label that anyone can set.
This is more secure than tags because service accounts are managed through IAM, with proper auditing, and you cannot just slap a different service account on a VM the way you can with a tag. Changing a VM's service account requires IAM permissions.
A common ACE exam pattern. A scenario describes two firewall rules that both apply to the same traffic, and asks what happens. The answer requires you to know which rule has higher priority.
Remember. Lower priority number means higher precedence. So a rule with priority 100 takes effect before a rule with priority 200. If priority 100 says allow and priority 200 says deny, the traffic is allowed.
The pattern. A scenario describes a security requirement to control access between specific workloads. The right answer depends on what kind of identity you have.
If the scenario emphasizes simplicity or labeling many VMs at once, network tags are the answer. If the scenario emphasizes stronger security, least privilege, or zero-trust principles, identity-based rules using service accounts are the answer.
If you see "more secure than tags" or "based on identity", think service-account-based firewall rules. If you see "label-based" or "tag a group of VMs", think network tags.
One detail worth flagging. Firewall rule logging is disabled by default. If a scenario asks how to audit which connections are matching a specific firewall rule, the answer is to enable logging on that rule.
gcloud compute firewall-rules update my-rule \
--enable-loggingThe logs land in Cloud Logging and are useful for troubleshooting, auditing, and security analysis. Enabling logs only on the rules that matter (rather than all of them) keeps log volume reasonable.
gcloud compute firewall-rules create allow-web \
--network=my-vpc \
--direction=INGRESS \
--priority=1000 \
--action=ALLOW \
--rules=tcp:80,tcp:443 \
--target-tags=web-server \
--source-ranges=0.0.0.0/0Replace --target-tags with --target-service-accounts (and --source-service-accounts for the source side) if you want identity-based targeting.
Firewall rules in GCP have a priority (0-65535, lower number wins), a direction (ingress or egress), an action (allow or deny), and target criteria. Targets can be IP ranges, network tags, or service accounts. Tags are simple but user-applied. Service accounts are stronger because they are managed through IAM. Logging is off by default and you turn it on per rule when you need it.
The Associate Cloud Engineer exam tests these in scenarios that involve resolving conflicting rules (priority), choosing between tag and service-account targeting (security strength), and enabling logging for audit purposes.
My Associate Cloud Engineer course covers Cloud Firewall in the networking section alongside VPC structure, identity-based rules, and the patterns the exam tests for combining priority, tags, and service accounts.
