Network security foundations: the invisible rules that decide what data gets in and out of your cloud services. For the PCSE exam, you must understand how to build these digital walls and gates (VPCs and Firewall Rules) to protect a company's most valuable asset: its data. If you get this wrong, the rest of the security castle is built on sand.
Jump to a section
A simple way to picture Network Security Foundations: VPCs and Firewall Rules
You are the head of security for a massive warehouse complex. The complex is your Virtual Private Cloud (VPC), a private, isolated section of the internet's warehouse district that only your company rents. Inside the complex, you have different buildings: one for packing, one for shipping, and one for admin. These buildings are your subnets, each serving a specific purpose within your VPC.
Your job is to decide who can enter each building, from which door, and with what. You cannot rely on the district's general traffic cops (the internet's basic security). Instead, you write specific rules, or firewall rules, for every door. For the admin building (your most sensitive subnet), you only allow entry to people with a specific ID badge (a specific IP address from your corporate headquarters). For the shipping building, you let in delivery trucks (incoming traffic from the internet) but only if they come through the main gate during business hours (a specific port and protocol). You also set up a secondary, smaller gate for your most trusted partner company to drop off materials directly to the packing building (a VPC peering connection), which is faster and safer than having them drive through the main entrance.
One day, a delivery truck arrives claiming to be from a trusted partner, but its papers look wrong. Because of your precise firewall rules, the guard at the gate (your VPC's implicit firewall) doesn't let it through. It must wait outside until you verify its identity. This is the essence of network security: you do not trust any visitor by default; you only allow traffic that matches exact, pre-approved conditions.
Let's start with the most basic problem. Before cloud computing, companies ran their own servers in a physical room, a data centre. To connect those servers to the internet or to each other, they bought cables, switches, and routers. They physically connected wires. This is the 'old way'.
Cloud computing changed that by offering a network that exists purely in software. This is called a Virtual Private Cloud, or VPC. The word 'virtual' means it's not a physical cable or router you can touch. It's a private, logically isolated section of the cloud provider's network, like Google Cloud. 'Private' means that by default, no one from the public internet can access the resources (like virtual machines or databases) inside it. It is your own slice of the cloud.
To organise this private space, you divide it into subnets. A subnet is a smaller, compartmentalised section of your VPC. Think of it as a room in a house. You might have one subnet for your public-facing web servers (the 'living room') and another for your private database servers (the 'safe in the basement'). Subnets exist entirely within one 'region' (a specific geographic location, like London or Iowa).
Now, how do things connect? Data travels in packets. A packet is a small chunk of data with a 'from' address (source IP address), a 'to' address (destination IP address), and a 'port' number (like a door). For example, a web browser sends a packet to port 80 or 443 (the standard doors for web traffic) on a server.
This is where firewall rules come in. A firewall is a gatekeeper that examines every packet trying to enter or leave a VPC or a particular virtual machine (VM). In Google Cloud, these are called VPC Firewall Rules. Each rule is a statement that says: 'If a packet looks like X, then Y should happen.'
A rule has several parts:
Direction: Is this packet coming into the network (ingress) or going out (egress)?
Source / Destination: Where is it coming from (a specific IP address, a range of IPs, or another subnet) and where is it going?
Protocol and port: What kind of traffic is it? TCP (reliable, like a phone call), UDP (fast, like a radio broadcast), or ICMP (used for testing)? What door (port) does it want? Port 22 for SSH (secure shell, a way to manage servers), port 3389 for RDP (remote desktop protocol), or port 443 for HTTPS (secure web traffic).
Action: Allow or deny.
Priority: If two rules contradict each other, the one with a lower priority number wins (higher priority).
Crucially, Google Cloud uses an 'implicit deny' (or 'default deny') policy. This means that if no firewall rule explicitly allows a packet, that packet is automatically dropped. It is rejected. This is a fundamental principle of security: everything is blocked unless you specifically say it is allowed.
You also need to understand VPC Peering. VPC Peering is a direct, private connection between two different VPCs, even if they are owned by different companies or in different projects. It allows them to communicate using internal IP addresses, bypassing the public internet entirely, which is much faster and more secure.
Finally, consider Cloud Router and Cloud NAT. Cloud Router is a tool that allows your VPC to learn about other networks (like an on-premises data centre) automatically using a protocol called BGP (Border Gateway Protocol). Cloud NAT (Network Address Translation) is a service that allows resources inside your VPC (like a private VM) to initiate outbound connections to the internet (for example, to download an update) while still blocking inbound connections from the internet. It is like a secure mailbox: your house can send letters out, but no one can deliver unsolicited mail directly to your inbox.
1. Define the Network Scope
Decide on the VPC name (e.g., 'my-company-vpc') and its configuration. You choose if it is an 'auto-mode' VPC (which automatically creates subnets in every region) or a 'custom-mode' VPC (where you manually define subnets). For security, custom-mode is preferred because you control exactly which regions your data lives in.
2. Create Subnets
Divide your VPC into logical segments. For example, create a subnet called 'web-subnet' for public-facing web servers and another called 'db-subnet' for private database servers. Assign each subnet a unique IP address range (CIDR block, like 10.0.1.0/24) that does not overlap with others.
3. Write Firewall Rules for Ingress (Inbound)
Create rules that specify who can talk to your resources. For the 'web-subnet', allow traffic on port 443 (HTTPS) from the internet (0.0.0.0/0). For the 'db-subnet', deny all traffic from the internet, and only allow traffic from the 'web-subnet' on port 3306 (MySQL). This is the 'least privilege' principle: only allow what is strictly necessary.
4. Write Firewall Rules for Egress (Outbound)
By default, all outbound traffic is allowed. To tighten security, create egress rules that block specific dangerous ports, like port 25 (SMTP) to prevent spam, or restrict outbound access to a known list of trusted IP addresses for software updates.
5. Configure Advanced Connectivity (Peering/Shared VPC)
If your application needs to talk to a different VPC (e.g., a separate project for logging), set up VPC Peering. Alternatively, if you manage multiple projects under one organisation, use Shared VPC to centralise network administration. Both eliminate the need for traffic to traverse the public internet.
6. Test and Validate with Connectivity Tests
Use Google Cloud's Network Intelligence Center or VPC Flow Logs to verify that your rules are working as intended. Simulate traffic: try to connect to the database from an external IP, and confirm that the connection is blocked. This step catches misconfigurations before they become security incidents.
Imagine you are the new cloud security engineer for 'FinRetail', a small but growing online bank. Your boss says, 'We are moving our entire banking application to Google Cloud. We need a secure network. Make it happen.'
Here is what you do step by step, as an IT professional:
First, you design the VPC. You call it finretail-prod-vpc. You choose a region: europe-west2 (London) because your main customers are in the UK. You create two subnets: subnet-public-web and subnet-private-db.
Next, you create the lowest-level firewall rules. You want to block all access to the database subnet from the public internet. You create a rule that says: 'Deny all ingress traffic to subnet-private-db from the IP range 0.0.0.0/0 (the entire internet)'. You give it a priority of 65535 (the lowest possible). This acts as a safety net.
Then, you create the specific 'allow' rules. - For the public web subnet, you allow traffic on port 443 (HTTPS) from any source. This is because customers need to reach your website over the secure web. - For the public web subnet, you allow traffic on port 22 (SSH) ONLY from a specific IP address that belongs to your company's VPN (Virtual Private Network) gateway. This is so your system administrators can log in to the web servers to fix them, but only from the company network. - For the private database subnet, you allow traffic from the public web subnet on port 3306 (MySQL, your database type). This allows your web servers to talk to the database to read customer balances, but the database itself is invisible to the internet.
You also need to set up outbound rules. By default, Google Cloud allows all outbound traffic. Your security policy says this is too risky. You create an egress rule that denies all traffic to any IP address on port 25 (SMTP, used for email), because you do not want a compromised server to be used to send spam. You then create a rule that allows all other outbound traffic (for necessary updates).
Later, you need to connect the bank's office in a different Google Cloud project to this VPC. You set up VPC Peering. You configure the peering connection on both ends. You then update your firewall rules to allow traffic from the peered VPC's subnet to reach the subnet-public-web for internal reporting tools.
Finally, you use Cloud NAT so that the private database servers can download security patches from the internet without having a public IP address.
This is what a day in the life looks like: designing and testing these digital gates, ensuring no one can walk in the wrong door, and making sure the right doors are open for business.
The PCSE exam loves to test your understanding of implicit deny and how firewall rules actually get evaluated. They do not just ask you to define a VPC. They will present a scenario with multiple firewall rules and ask which packet gets through.
Key exam topics to master:
The order of rule evaluation. Rules are evaluated from highest priority (lowest number) to lowest priority. If no rule matches, the packet is denied by the implicit deny rule. The exam will test this by giving you multiple rules that overlap.
The difference between 'direction' (ingress vs egress). A common trap is that a rule that allows traffic in one direction does NOT automatically allow the reply traffic. You must think about stateful vs stateless firewalls. Google Cloud VPC firewalls are stateful. This means if you allow an incoming packet for a new connection, the firewall automatically allows the response traffic for that same connection back out, even if you have a deny rule for egress. The exam tests this heavily.
The difference between 'allow' and 'deny' rules. A deny rule always wins over an allow rule if they have the same priority. If they have different priorities, the higher priority rule wins, regardless of whether it is 'allow' or 'deny'.
Subnet-level vs VM-level (network tag) rules. You can apply firewall rules to specific VMs using 'target tags'. A rule can target all instances with the tag 'web-server' instead of applying to an entire subnet. The exam loves questions where a VM has a tag and a subnet has a rule, and you must predict the outcome.
VPC Peering specifics. The exam tests that VPC Peering is not transitive. If VPC A is peered with VPC B, and VPC B is peered with VPC C, traffic cannot flow from A to C through B unless there is a direct peering or a VPN. This is a classic 'non-transitive peering' trap.
Shared VPC. You need to know that Shared VPC allows you to define a host project that contains a VPC, and then share that VPC with other service projects. This is different from VPC Peering. The exam will ask which scenario requires Shared VPC vs Peering.
The concept of 'firewall rules' vs 'firewall policies' (hierarchical firewall policies). Hierarchical firewall policies are a newer feature that allows you to apply rules at the organisation level, overriding rules at the project level. The exam tests when you would use one over the other.
Specific traps to avoid:
Assuming all VPCs are globally isolated. They are global, but subnets are regional.
Forgetting that firewall rules are stateful in Google Cloud.
Thinking that allowing egress automatically allows ingress. It does not.
Confusing VPC Peering with Shared VPC.
A VPC is a private, isolated, global network within Google Cloud, while subnets are regional subdivisions of that network.
Google Cloud VPC firewalls are stateful, meaning they automatically allow reply traffic for any allowed connection without a separate rule.
Implicit deny is the final rule: if no firewall rule explicitly allows a packet, it is automatically dropped.
Firewall rules are evaluated from highest priority (lowest number) to lowest priority, with deny rules overriding allow rules at the same priority level.
VPC Peering is a direct, non-transitive private connection between two VPCs that does not use the public internet.
Network tags allow you to apply firewall rules to specific virtual machine instances rather than an entire subnet, giving you fine-grained control.
These come up on the exam all the time. Here's how to tell them apart.
VPC Peering
Connects two separate VPCs, possibly in different projects, using a private connection.
Is non-transitive: traffic cannot hop from one peered VPC to another through a third VPC.
Each VPC is independently managed by its own project administrators.
Shared VPC
Allows one host project to share a VPC with multiple service projects within the same organisation.
Is transitive within the shared network: all attached projects can communicate with each other via the shared VPC.
Centralises network administration in the host project, giving it control over all subnets and firewall rules.
Ingress Firewall Rule
Controls traffic coming into a VPC or VM from an external source (like the internet or another subnet).
Requires a 'source' IP address or range in the rule definition.
Is commonly used to protect VMs from unauthorised access, such as blocking all except HTTPS traffic.
Egress Firewall Rule
Controls traffic leaving a VPC or VM to an external destination.
Requires a 'destination' IP address or range in the rule definition.
Is used to prevent data exfiltration or to restrict VMs to only talk to specific services (e.g., only Google APIs).
VPC Firewall Rules (Stateful)
Automatically tracks connection state; return traffic for an allowed connection is permitted without an extra rule.
Simplifies rule management because you only write rules for the initial connection direction.
Is the default behaviour in Google Cloud VPC firewalls.
Traditional Network Firewall (Stateless)
Does not track connection state; you must write explicit rules for both inbound and outbound directions.
Requires more rules and careful planning to avoid blocking legitimate reply traffic.
Is common in older, on-premises firewall appliances.
Cloud NAT
Allows private VMs to initiate outbound connections to the internet without giving them a public IP address.
All incoming connection attempts to the VM from the internet are still blocked by default.
Is managed as a service, scaling automatically and providing high availability.
Public IP Address on VM
Assigns a public IP directly to a VM, allowing it to be directly reachable from the internet (if firewall rules permit).
Increases the attack surface because the VM is directly exposed to the internet.
Is a one-to-one mapping: one public IP per VM, which can be limited and costly.
Mistake
A VPC is a single geographic location, like a country.
Correct
A VPC is a global resource that spans all regions. However, its subnets are regional (exist only in one specific geographic area). A VM in one region cannot use an IP address from a subnet in a different region.
People confuse the concept of a 'virtual private cloud' with a physical data centre, which is in one building. The cloud's virtual nature allows the VPC to exist everywhere, which is both a benefit and a source of confusion.
Mistake
If I create a firewall rule that allows all traffic from the internet (0.0.0.0/0) on port 22, my VM is perfectly safe because the firewall is 'protecting' it.
Correct
Allowing all traffic from the internet on port 22 (SSH) is extremely dangerous. It exposes your VM to brute-force attacks and automated scanners. A secure rule should restrict the source IP to only your corporate VPN or a small, trusted IP range.
Beginners often see a firewall as a 'shield' that makes things safe, when in fact a permissive rule is just an open door. The security is only as good as the rules you write.
Mistake
Firewall rules in Google Cloud are 'stateless', so I must explicitly allow both directions (ingress and egress) for a single conversation to work.
Correct
Google Cloud VPC firewall rules are 'stateful'. If you allow an incoming connection, the firewall automatically tracks that connection (the 'state') and allows the returning traffic to go out, no separate egress rule needed.
This confusion comes from people who have worked with traditional (stateless) network firewalls, where you must write rules for both directions. Google Cloud handles this automatically, simplifying security but surprising those with legacy experience.
Mistake
VPC Peering is the same as connecting two VPCs over the internet, just with better marketing.
Correct
VPC Peering uses Google's private internal network, not the public internet, to connect two VPCs. This means lower latency, higher bandwidth, and no exposure to public internet routing. It is a private, direct link.
People think 'connection' always involves the internet because that is how most networks connect. They do not realise cloud providers have massive private fibre backbones that can be used for direct connections.
Mistake
If I deny all inbound traffic to a subnet, no VM in that subnet can ever initiate a connection out to the internet.
Correct
Denying inbound traffic only blocks incoming connection attempts. A VM can still initiate an outbound connection (like fetching a web page or an update), and the return traffic for that specific connection is allowed back in by the stateful firewall.
This is a fundamental misunderstanding of connection direction. People think 'blocking incoming' means the whole VM is cut off, but outbound traffic is governed by separate egress rules.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Virtual Private Cloud (VPC) is a private, isolated virtual network within Google Cloud where you run your cloud resources. It is like having your own private data centre inside the cloud, with complete control over IP addresses, subnets, and firewall rules.
No. You can create firewall rules at the VPC or subnet level that apply to many VMs at once. You can also use 'network tags' to apply rules only to specific VMs that have that tag, giving you fine-grained control without managing each VM separately.
A VPC is the entire private network. A subnet is a smaller segment within that VPC, usually defined for a specific purpose (like hosting web servers or databases). Subnets are regional, meaning they live in one geographic area, while the VPC itself is global.
Yes. You can use Cloud VPN (a secure tunnel over the internet) or Cloud Interconnect (a dedicated physical connection) to connect your on-premises network to your VPC, making it behave as an extension of your local network.
By default, all inbound traffic from the internet is blocked (because of the implicit deny rule), but all outbound traffic is allowed. Your VMs can talk to the internet, but no one can talk to them unless you create an appropriate ingress rule.
It means the firewall remembers active connections. If you allow an incoming packet for a new session (like a web request), the firewall automatically allows all reply packets for that same session to go back out, without needing a separate outbound rule.
You've finished Network Security Foundations: VPCs and Firewall Rules. Continue through the PCSE study guide to build a complete picture of the exam.
Done with this chapter?