Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
VPC firewall rules act as virtual barriers that control the flow of data into and out of your cloud network. These rules regulate traffic based on specific criteria like IP addresses, protocols, and ports to ensure only authorized connections reach sensitive resources. To achieve granular network isolation, Google Cloud applies rules using either target tags or service accounts. Target tags act as simple labels to group virtual machines, while service accounts provide a secure, identity-based method to define which workloads can communicate. Defining rules by identity rather than IP addresses significantly minimizes the attack surface.
Hierarchical firewall policies allow organization administrators to establish consistent security rules across multiple projects. Because these policies are defined at the organization or folder level, they prevent individual project owners from creating local rules that might violate company-wide security standards. In complex network topologies involving Private Service Connect, specific firewall rules manage traffic between different subnets. For example, a rule might allow a NAT subnet to communicate with a service attachment to facilitate secure data migration.
Security administrators configure these rules by prioritizing specific parameters to dictate the order of operations. The core components of these rules include:
To audit and monitor these connections, teams use firewall rules logging alongside proxy setups like a SOCKS server or a bastion host. These proxies control and log access to private databases that are isolated from the public internet.
Google Cloud Armor protects applications from Distributed Denial-of-Service (DDoS) attacks at the network edge before traffic enters your Virtual Private Cloud. This always-on defense filters out volumetric attacks to keep backend services stable and responsive behind Google Cloud load balancers. Cloud Armor also functions as a Web Application Firewall (WAF) by using security policies to block common web application exploits. These policies include preconfigured rules to mitigate specific threats:
Security teams can also write custom rules with a flexible match language to allow or deny traffic based on IP addresses, geography, or specific request headers.
To defend against sophisticated threats, Adaptive Protection uses machine learning models to detect anomalous traffic patterns. The system establishes a baseline of normal traffic and automatically generates a custom attack signature when it detects a potential application-level attack. This allows the system to suggest specific WAF rules to block the malicious traffic while letting legitimate users pass through. For deeper network visibility, Cloud IDS performs deep packet inspection to look inside data packets inside your network. This monitoring layer helps identify advanced threats that bypass the initial perimeter, specifically looking for:
Organizations requiring advanced protection can upgrade to Cloud Armor Enterprise to secure Network Load Balancers and virtual machines. This tier integrates with Google Threat Intelligence to automatically block traffic coming from known malicious IP addresses. All security events, including blocked requests and matched rules, are sent to Cloud Logging for later analysis and security audits. Combining these services ensures that your network architecture remains resilient against evolving internet threats.
Identity-Aware Proxy (IAP) provides secure access to applications and resources based on user identity and context rather than network location. This identity-based model eliminates the need for traditional, perimeter-based VPNs and external IP addresses on your workloads. To use IAP with a Google Kubernetes Engine (GKE) cluster, you must enable the iap.googleapis.com service in your project. You must also turn on the HttpLoadBalancing add-on for the cluster to route incoming traffic. This setup is a key dependency when integrating with Cloud Service Mesh to manage secure communication between internal microservices.
Setting up IAP requires registering a domain name and reserving a static external IP address. You must create an A record in your DNS settings to point your domain to this reserved global IP address. This ensures that user requests route through the Google Cloud HTTP(S) Load Balancer, which validates the user's identity before forwarding the traffic to the backend. This structure ensures that unauthenticated traffic never reaches your private workloads.
To secure data at the API level, VPC Service Controls create a service perimeter around sensitive cloud resources. This perimeter limits access to specified APIs and prevents data from being copied or moved outside the safe zone. This mechanism secures critical services like Cloud SQL from unauthorized access or accidental data exfiltration. Managing these security features requires precise Identity and Access Management (IAM) configurations. The core components of identity-based access include:
Prepare and test your skills
Prepare and test your skills
VPC firewall rules achieve granular network isolation using either target tags or service accounts. Target tags act as simple labels to group virtual machines, while service accounts provide a secure, identity-based method to define which workloads can communicate.
Hierarchical firewall policies allow organization administrators to establish consistent security rules across multiple projects at the organization or folder level. They prevent individual project owners from creating local rules that might violate company-wide security standards.
Cloud Armor functions as a Web Application Firewall and includes preconfigured rules to block SQL injection (SQLi) attempts to interfere with databases and Cross-Site Scripting (XSS) attempts to inject harmful scripts into web content.
Adaptive Protection uses machine learning models to detect anomalous traffic patterns by establishing a baseline of normal traffic. When it detects a potential attack, it automatically generates a custom attack signature and suggests specific WAF rules to block the malicious traffic.
Create an allow egress rule for destination range 199.36.153.4/30 on TCP port 443 with a priority before 1000 (such as 900), and create a deny egress rule for destination 0.0.0.0/0 with a priority after 1000 (such as 1100).
Create an allow egress rule for destination range 199.36.153.4/30 filtered by source network tags, and rely on the implied default allow egress rule at priority 65535.
Create a deny egress rule for destination 0.0.0.0/0 with a priority before 1000 (such as 900), and create an allow egress rule for destination range 199.36.153.4/30 on TCP port 443 with a priority after 1000 (such as 1100).
Create an allow ingress rule for 199.36.153.4/30 on TCP port 443 at priority 1000, and rely on the default implied deny ingress rule at priority 65535 to block outbound internet traffic.
An enterprise is designing network security controls in Google Cloud to prevent data exfiltration from resources within a Virtual Private Cloud (VPC) network. Workloads in the VPC must communicate with Google APIs exclusively through the restricted virtual IP (VIP) range 199.36.153.4/30 on TCP port 443.
The security architect must enforce strict egress controls to ensure that all general outbound internet traffic is blocked while outbound access to Google services via the restricted VIP is permitted without disrupting internal traffic flows or connector communication.
How should the VPC egress firewall rules and priority levels be configured?