Cloud Firewall lets you define and enforce rules that control network traffic to and from your resources in Google Cloud. It is used mainly for virtual machines, whether they are standalone VMs or part of a larger service such as the Managed Spark, but it also applies to Load Balancers, GKE clusters, and Cloud SQL instances. Rules can govern both ingress, which is incoming traffic, and egress, which is outgoing traffic, so you control what reaches a resource and what a resource is allowed to send out. For the Professional Cloud Database Engineer exam, the useful thing to be precise about is how a rule decides whether a given packet matches and how Google Cloud resolves the situation when more than one rule could apply.
A firewall rule filters traffic based on familiar networking attributes. You can write rules against protocols such as TCP and UDP, against IP address ranges, and against port numbers. You can also attach tags to your resources and match on those. Beyond network-level attributes, you can base a rule on the identity of the traffic source, such as a specific service account, which gives you a more granular form of access control. A rule that allows TCP from a particular IP range to a database instance, while leaving everything else blocked, is the kind of narrow ingress control these attributes are meant for.
When more than one rule could apply to the same traffic, Google Cloud uses a priority system to decide the order in which rules are evaluated. Each rule carries a priority attribute, a number in the range from 0 to 65535. Lower numbers indicate higher priority, so a rule with priority 100 is evaluated before a rule with priority 200. This ordering is what lets you build a layered configuration. You can start with broad, lower-priority rules and then add more specific, higher-priority rules on top to handle exceptions or to fine-tune access.
The interaction between priority and matching is worth working through, because it is where the behavior is easy to get wrong. Suppose one rule allows TCP traffic from a given IP range and is set to priority 100, and a second rule denies all SSH traffic at priority 200. Traffic that is TCP from that range is evaluated against the higher-priority allow rule first and is permitted to pass. That happens even for traffic that also happens to be SSH, because SSH runs over TCP and the allow rule has already matched it at the earlier checkpoint. The lower-priority deny rule never gets the chance to act on that traffic. Traffic that is not TCP from that range falls through to the next rule, where SSH is denied and everything else is allowed. The order, set by priority, determines the final outcome for each packet, so two rules that look contradictory in isolation can produce a predictable result once you account for which one is evaluated first.
Identity-based firewall rules extend matching beyond IP addresses, protocols, and ports to the service accounts associated with instances and services. When your workloads carry service accounts, you can write rules that allow or deny traffic based on those identities, which means you are controlling access by who or what is making the request rather than only by where it originates. Consider a setup with a Cloud Run service tied to one service account and two VM instances, each tied to its own service account. A rule that denies traffic where the source is the second service account and the target is the third service account blocks that specific VM from reaching the other VM, while a Cloud Run service on a service account the rule does not mention is left free to communicate. This style of rule aligns with least privilege and zero trust, since access is scoped to identity rather than granted broadly by network location.
Firewall rule logging is disabled by default, which is worth keeping in mind when you set up security policies, because a rule can be working without producing any record of the connections it matches. To turn logging on for a specific rule, open the configuration page for that rule, find the section labeled Logs, and set the Logs option to On. That logs connections that match the rule. From the command line, the equivalent is a single gcloud command.
gcloud compute firewall-rules update --enable-logging You replace the placeholder with the name of the rule you want to log. Logging helps with troubleshooting, auditing, and understanding the traffic reaching your resources, so enabling it on the rules that protect critical resources, including database instances, is a reasonable practice even though it is off by default.
Pulling this together for the Professional Cloud Database Engineer exam, the points that tend to matter are that Cloud Firewall covers both ingress and egress and applies to Cloud SQL instances as well as VMs, that rules can match on protocols, IP ranges, ports, tags, or service account identity, that priority runs from 0 to 65535 with lower numbers winning and being evaluated first, and that logging is something you have to turn on deliberately.
Our Professional Cloud Database Engineer course covers Cloud Firewall and VPC firewall rules alongside private connectivity and IAM for database access, with practice questions that drill these distinctions.
