Prepare and test your skills
Prepare and test your skills
Designing and configuring perimeter security means combining certificates, firewalls, identity checks, and edge filtering so traffic is verified at several layers before it reaches a workload. Traffic flows from internet clients to the edge load balancer, then through identity and firewall checks, then to the destination workload. A failure at one layer does not grant access to the next layer.
Certificate Authority Service (CA Service) is Google Cloud's managed private public key infrastructure (PKI) service for issuing, renewing, and revoking internal certificates. An administrator creates a root certificate authority (CA) and subordinate CAs, defines templates for allowed domains and validity periods, and maintains revocation with certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP) responders. VPC Service Controls (opens in a new tab) adds Layer 7 perimeter control above routing when private services must stay inside a data boundary.
Certificate Manager requests certificates from a CA Service pool, stores them as certificate resources, and binds them to a load balancer target proxy through a certificate map. The certificate map binds hostnames to certificates, and during the Transport Layer Security (TLS) handshake the load balancer selects the certificate whose map entry matches the client's requested hostname. Map entries take precedence over Compute Engine SSL certificates on the same proxy, and if no entry matches the proxy presents the primary certificate in the map. Google-managed certificates renew automatically, while self-managed certificates require tracking expiry in Cloud Monitoring, creating a new certificate signing request, submitting it to the CA, and rebinding in one update to avoid a gap.
Domain authorization proves control of a domain in two ways. Load balancer authorization needs no DNS change but requires the global load balancer to be publicly reachable on port 443 and does not support wildcards. DNS authorization requires adding a CNAME record but supports wildcard certificates, works behind a content delivery network (CDN) or on nonstandard ports, and can provision before cutover.
Cloud Next Generation Firewall (Cloud NGFW) is distributed stateful filtering enforced on every virtual machine (VM) instance. Rules are organized in hierarchical firewall policies at the organization and folder levels and in global, regional, and Virtual Private Cloud (VPC) firewall rules at the network level. A rule targets VMs by Identity and Access Management (IAM)-governed Tags, service accounts, or network tags, so only VMs tagged frontend can reach VMs tagged backend without passing through a central appliance.
Design separates north-south traffic between the internet or on-premises and Google Cloud from east-west traffic between tiers inside Google Cloud. Three-tier designs place presentation, application, and data in separate segments and require firewall authorization for tier-to-tier flows to block lateral movement. Private-only VMs reach Google APIs through Private Service Connect or Private Google Access, and reach the internet through Secure Web Proxy for HTTP(S) with identity controls or through Cloud NAT otherwise. Identity-Aware Proxy (IAP) adds user and device verification on top of network reachability by authenticating every user and device and authorizing by role, device posture, and location, while a firewall rule must still allow the IAP traffic path to reach the protected VM.
Secure delivery places the correct load balancer at the correct boundary and filters traffic before it reaches backends. Global external Application Load Balancers handle HTTP, HTTPS, HTTP/2, and optionally QUIC for Layer 7 routing, while global external proxy Network Load Balancers handle TCP and SSL proxy traffic and regional passthrough Network Load Balancers handle TCP and UDP. In Premium Tier, traffic enters the Google point of presence closest to the user and travels over Google's backbone, while in Standard Tier traffic enters in the region where resources are deployed.
Google Cloud Armor attaches to backend services to allow, deny, throttle, rate-based ban, or redirect at the edge. Rules match Layer 3 through Layer 7 attributes such as IP, geography, autonomous system number, path, method, headers, and body, and rules are evaluated in priority order. A backend service can hold one backend security policy plus one edge security policy, but never two backend policies. For internal traffic, managed Envoy proxies for internal Application Load Balancers run in a proxy-only subnet and allow ingress by default, so restriction requires an explicit low-priority deny to 0.0.0.0/0 plus higher-priority allows for approved clients and Google health-check ranges.
Application layer inspection on Cloud NGFW adds Layer 7 analysis of domains, URLs, and TLS sessions on top of Layer 3 and Layer 4 decisions. Traffic subject to inspection follows a fixed order. First, firewall policy rules match traffic to and from VM instances or Google Kubernetes Engine (GKE) clusters. Second, matched packets are intercepted and sent to the firewall endpoint in the same zone. Third, the endpoint scans against threat signatures for anti-spyware, vulnerability protection, and antivirus. Fourth, the endpoint applies the action from the security profile, such as block or alert.
Two objects control inspection behavior. A security profile of type threat-prevention defines overrides for specific threats and can exist at organization or project level. A security profile group bundles profiles for use by firewall rules and can contain a maximum of one profile per threat-prevention type. A firewall rule references the group to enable inspection, so the rule selects which traffic to inspect and the group defines how threats are handled. This inspection is available only through firewall policies, not legacy VPC firewall rules.
Granular rules depend on least-privilege network allows because the endpoint only receives traffic the firewall policy forwards. Common hardened patterns are fw-allow-health-check for TCP port 80 from 35.191.0.0/16 and 130.211.0.0/22, fw-allow-proxy-only-subnet for TCP port 80 from the proxy-only subnet to backends, and fw-allow-ssh for TCP port 22 restricted to administrator addresses. When inspection is enabled, the endpoint reads the uri field for domain, the sni field for Server Name Indication, and protocolVersion for TLS version, including TLS1_0 through TLS1_3. A rule can therefore treat two services sharing one IP and port 443 differently by domain, SNI, and TLS version.
Private and public addressing defines whether a workload is reachable only inside Google Cloud or directly from the internet. A VPC network is a global isolated partition with its own subnets, routes, and firewall rules. Resources receive an internal IP from the subnet range and communicate privately when firewall rules permit, while an external IP adds both outbound and inbound internet connectivity and expands the perimeter to that resource.
Subnets allocate internal addresses from RFC 1918 private ranges, privately used public IPs used only internally, and internal IPv6 ranges that are not publicly routable. The same private address can exist in multiple VPCs without conflict, which conserves space. Reuse is safe only while those VPCs are neither peered nor connected by hybrid connectivity, because exchanged routes with overlapping ranges cause conflicts. Alias IP ranges give multiple internal addresses to one VM interface, and VPC-native GKE uses alias IPs so every Pod IP is routable without Network Address Translation (NAT).
Controlling exposure means denying per-VM external IPs by policy and using managed gateways for required flows:
| Outbound option | How traffic flows | Choose when |
|---|---|---|
| Direct external IP | Traffic flows directly between VM and internet in both directions | Only resources that must accept direct inbound internet connections |
| Cloud NAT | Traffic flows from private VM to regional NAT gateway, then to internet with shared NAT IPs | Private VMs need general outbound access without per-VM public addresses |
| Secure Web Proxy | Traffic flows from private VM through proxy to HTTP(S) destinations with policy applied | Web egress requires user or workload identity controls |
Secure Web Proxy is a managed outbound path that isolates private workloads from direct internet access. Traffic flows from clients to Envoy proxies, from the proxies through a Cloud NAT gateway, and then to the external destination, while policy and TLS inspection control what is allowed. The Envoy proxies live in a Google-managed proxy-only subnet, so clients never connect directly externally, and the internet sees only NAT addresses.
A proxy-only subnet reserves addresses for Google-managed proxies. There can be only one active proxy-only subnet for a given purpose per region per network, using purpose REGIONAL_MANAGED_PROXY for regional architectures and GLOBAL_MANAGED_PROXY for cross-region patterns. Integration follows an order: first create the proxy-only subnet, then create the Cloud Router in the same network and region, then create the Cloud NAT gateway scoped to the proxy-only subnet, and then enable dynamic port allocation. Do not assign forwarding-rule or backend addresses from the proxy-only range.
The GatewaySecurityPolicy is the control point where allow, deny, and inspection rules are defined for outbound web traffic. A next-hop gateway uses SECURE_WEB_GATEWAY type with next-hop routing mode, so VPC routes steer traffic transparently without per-client proxy configuration. A TLS inspection policy lets the proxy decrypt outbound traffic by referencing a Certificate Authority Service pool in the same region. Static routes need priority numerically lower than the default internet route 1000, while policy-based routes require a second default-routing route with lower priority.
Cloud DNS security protects name resolution against spoofing, hijacking, and leakage. Public zones use Domain Name System Security Extensions (DNSSEC) signing with a Key Signing Key (KSK) and Zone Signing Key (ZSK), and trust is completed only after Delegation Signer (DS) records are published at the registrar. Private managed zones are authoritative zones visible only to authorized VPC networks, so a workload outside an authorized VPC cannot resolve names in the zone. Cross-VPC DNS peering forwards lookups for a namespace to the producer VPC, DNS server policies govern hybrid lookup direction, and query logging supports detection of anomalous patterns.
API protection keeps calls to Google APIs on internal paths and limits how credentials can be used. private.googleapis.com reaches a broad set of APIs, while restricted.googleapis.com at 199.36.153.4/30 reaches only VPC Service Controls-supported APIs. Cloud Audit Logs record who called what: Admin Activity logs record ADMIN WRITE operations and are always written and cannot be disabled, while Data Access logs record ADMIN READ, DATA READ, and DATA WRITE operations and must be explicitly enabled. Organization policy Restrict Service Usage enforces an approved API allowlist, and API keys must be sent in the x-goog-api-key header, bound to application, network, and API targets, rotated every 90 days, and never hardcoded in client code.
Exam tip: Wildcard certificates require DNS authorization, Cloud NAT allows only outbound-initiated sessions with stateful return traffic, and Admin Activity logs are always on while Data Access logs must be enabled.
Continue with this study guide: Designing and configuring perimeter security
Configuring boundary segmentation means deciding who owns the network, which routes cross network boundaries, and which traffic is filtered at each workload. Shared VPC centralizes subnets, routes, and filtering in a host project while workload teams own instances in service projects. VPC Network Peering connects two VPC networks for internal communication without merging their firewalls or identities.
Shared VPC ownership places network control in one host project and workload ownership in attached service projects. The host project owns shared networks, subnets, routes, and firewall rules, while instances in service projects draw internal IP addresses from host subnets. Traffic flows between service projects over internal addresses, but central teams retain control of the boundary.
Attachment follows strict rules and an ordered delegation. A project cannot be a host and a service at the same time, and each service project can attach to only one host project, while an organization can operate multiple host projects. Delegation proceeds in order:
VPC Network Peering security is a bilateral route exchange that never merges security boundaries. Each peering has an exporting side that offers routes and an importing side that accepts them, and each VPC retains its own firewall rules, IAM controls, and routing table. Peering is non-transitive, so traffic flows only between the two directly peered networks and never forwards through one peer to a third network. Custom route exchange requires the exporter to enable export and the peer to enable import, and peering prohibits overlapping or nested IPv4 subnet routes.
| Access scope | Permitted subnets | Choose when |
|---|---|---|
| Subnet-level grant | Only explicitly authorized subnets | The team must be confined to one tier, environment, or region |
| Project-level grant | Any subnet in the host project | A central team needs placement flexibility across the shared network |
Hierarchical firewall policy layers Cloud NGFW rules from broad VPC coverage to narrow workload exceptions. Cloud NGFW is stateful and enforced in a distributed manner at each destination VM rather than at a single gateway. Traffic flows from the source to the destination VM, the decision is applied at the destination, and the VPC keeps full-mesh software-defined reachability.
Layering stays within per-VM rule capacity by using fewer, broader rules first. One ingress rule that allows 10 TCP ports is more efficient than 10 single-port rules. The documented order moves inward from VPC-wide common rules to group rules across several VMs to individual workload rules for single VMs such as a NAT gateway or bastion host. Identity-based micro-segmentation scopes rules to workload identity instead of only IP placement by using service accounts, network tags, and Tags to select destination VMs. Prefer service accounts when possible because the rule follows the workload as addresses change.
Centralized control differs between Shared VPC and peering. In Shared VPC, Security Admins in the host project create firewall rules that control traffic among service-project instances, while Service Project Admins cannot change network policy. In peering, each VPC keeps its own distributed firewall and IAM, and segmentation must be duplicated on both sides when both directions need filtering. VPC Flow Logs and firewall rule logging feed Network Intelligence Center tools for topology, connectivity tests, and firewall insights.
N-tier isolation keeps frontend, application, and data tiers on private paths with controlled APIs between them. Isolation places each tier in its own subnet or project with deny-by-default filtering, while encapsulation hides backend implementation behind internal load balancers, private service paths, and encrypted transport. The common three-tier pattern flows from clients to the web frontend, then to the application tier, then to the backend database, ideally through an API gateway.
Private ingress, egress, and managed service encapsulation keeps tier-to-tier traffic off the public internet. Private Google Access is a subnet-level setting that lets VMs without external addresses reach Google APIs over Google's internal network and must be enabled on each subnet where backend tiers need it. Private service access creates a private path between a consumer VPC and a service-producer network that hosts managed services such as Cloud SQL or Memorystore. Internal load balancers provide private ingress between tiers by terminating connections inside the VPC and forwarding to instance groups or zonal network endpoint groups.
All VM-to-VM traffic within a VPC and between peered VPCs is encrypted, and some proxy load balancers add automatic network-level encryption to backends. That automatic encryption applies only to instance groups and zonal NEGs and is not auditable. Choose HTTPS or HTTP/2 on the backend service when auditable encryption is required from the internal Application Load Balancer to backends. Cloud Armor applies IP allow and deny lists at the external HTTP(S) load balancer against distributed denial-of-service, SQL injection, and cross-site scripting before traffic enters the VPC.
Zero-trust microsegmentation removes implicit trust between containerized tiers by requiring explicit allow rules and cryptographic identity for every call. Default Pod connectivity in GKE is flat, so every Pod can reach every other Pod, which lets an attacker move laterally after compromising one microservice. Zero-trust control replaces that openness with reachability policy plus authenticated encryption.
Kubernetes NetworkPolicies are basic flow controls that define which Pods can send and receive traffic by Pod labels, namespaces, ports, and protocols. A policy on a backend tier allows traffic only from authorized frontend Pods to specific backend ports, while all other Pod-to-Pod traffic to that backend is denied. Cloud Service Mesh is the control plane that adds mutual TLS (mTLS) encryption, identity authentication, and authorization between microservices. Traffic flows from the client sidecar proxy to the server sidecar proxy only after both sides validate identities, and the payload stays encrypted between services.
| Option | Primary unit | Choose when |
|---|---|---|
| Kubernetes NetworkPolicies | Pod-to-Pod allow rule | The need is basic traffic flow control to block lateral movement |
| Cloud Service Mesh | mTLS-authenticated service call | The need is encrypted, authenticated calls with load balancing, throttling, and metrics |
VPC Service Controls (VPC-SC) is a context-based perimeter that isolates multi-tenant Google Cloud services to mitigate data exfiltration. A service perimeter wraps projects, VPC networks, and restricted services such as Cloud Storage and BigQuery, and data cannot cross that boundary unless an ingress or egress rule explicitly allows it. IAM controls who can call an API, while VPC-SC controls whether restricted-service data can cross the perimeter even when IAM would allow it.
A perimeter in enforced mode denies violating requests, while dry run mode logs violations without denying, which supports previewing policy and measuring change impact. An access level defines conditions on identity type, identity, device trust, and network origin such as IP range or VPC network. An ingress rule controls outside-to-inside traffic to protected resources, and an egress rule controls inside-to-outside traffic to external destinations. Each rule names source context, destination project or resource, and restricted services and methods. Perimeter bridges allow defined projects in different perimeters to interoperate without merging perimeters.
Design favors a single large unified perimeter enclosing all sensitive projects when possible because it eliminates east-west paths that each need authorization and lowers management overhead. Multiple perimeters isolate data with different trust or regulatory needs, such as separating Payment Card Industry Data Security Standard scope or independent tenants, but every cross-perimeter flow must then be reviewed. Private connectivity keeps API traffic off the internet through Private Google Access or a Private Service Connect endpoint for the vpc-sc bundle, with firewall rules allowing only TCP 443 to the endpoint.
Exam tip: A service project attaches to only one host project, peering is non-transitive and needs both export and import for custom routes, and dry run mode only logs a would-be denial before switching to enforced mode.
Continue with this study guide: Configuring boundary segmentation
Establishing private connectivity means keeping traffic between VPC networks, on-premises data centers, and Google APIs off the public internet with private routes and encryption. The design chooses Shared VPC or peering between VPCs, VPN or Interconnect for hybrid links, and private API paths for Google services. Each path names its source, its destination, and the boundary it preserves.
VPC Network Peering is a bilateral connection that provides internal IP connectivity between two VPC networks. The two networks can be in the same project, in different projects, or in different organizations, and can mix IPv4-only, dual-stack, and IPv6-only subnets. Traffic flows only between the two directly peered networks because peering is non-transitive and never forwards traffic to a third network.
A peering becomes usable only after both sides configure toward each other. First, one side creates a peering that references the peer project and network with import and export of custom routes selected. Second, the other side creates the matching peering back. Third, when both sides are ACTIVE, subnet routes and enabled custom routes are exchanged automatically as implicit routes. The first side alone stays INACTIVE while waiting for the peer. Peering operations require Compute Network Admin or explicit permissions for adding, updating, removing, and listing peering routes.
Shared VPC shares one or more VPC networks from a central host project with service projects in the same organization. The host project holds shared networks, subnets, routes, and firewall rules, while attached service projects hold workloads such as Compute Engine instances that use those shared subnets. A project is either a host or a service, never both, and each service project attaches to only one host. All firewall rules for the shared network are created in the host project, and hybrid gateways and routers are also created there so on-premises routes apply centrally.
High-Availability Virtual Private Network (HA VPN) is the IPsec VPN solution that securely connects a peer network to a VPC network through encrypted tunnels. When an HA VPN gateway is created, Google Cloud automatically assigns two external IP addresses, one per gateway interface, each from a unique pool. Each interface supports multiple tunnels, HA VPN supports only dynamic routing with Border Gateway Protocol (BGP), and HA VPN supports active/active and active/passive routing. Depending on topology, HA VPN provides 99.99% or 99.9% availability.
Cloud Interconnect is the private-transport family that extends an on-premises network to VPC networks without traversing the public internet. The family includes Dedicated Interconnect for direct physical connection, Partner Interconnect through a service provider, and Cross-Cloud Interconnect between clouds. Redundancy requires more than one attachment in more than one failure domain. A single Partner Interconnect connection has no service level agreement (SLA), while redundant topologies offer 99.9% to 99.99%.
Encryption behavior differs by product. Cloud VPN encrypts with IPsec, where one gateway encrypts and the other decrypts, and it cannot route to the public internet. Cloud Interconnect alone does not encrypt, so encryption must be added with Media Access Control Security (MACsec) or HA VPN over Cloud Interconnect, which combines IPsec encryption with Interconnect capacity and never traverses the public internet. Cloud Router provides BGP-based dynamic routing for hybrid connectivity and exchanges routes with the on-premises router over tunnels and VLAN attachments, so traffic flows from the data center to the VPC over the healthy path and fails over when a tunnel fails.
| Product | Throughput and use case | Cost and complexity |
|---|---|---|
| Cloud VPN (HA VPN) | Lower bandwidth; best for lower-cost or smaller migrations | Lower cost over public internet; no colocation hardware unless paired with Interconnect |
| Dedicated Interconnect | 10 Gbps or more per connection with deterministic performance | Higher complexity with physical routers in colocation |
| Partner Interconnect | Normally less than 10 Gbps through a provider | Monthly attachment plus provider charges; no SLA if single |
| Cross-Cloud Interconnect | Line-rate multicloud performance | Managed service without remote routing equipment |
Private Google Access is a subnet-level setting that lets VM interfaces without an external IP address reach Google APIs and services. Traffic from those VMs uses the VPC network's default-internet-gateway as the next hop but stays inside Google's network and does not traverse the public internet. All requirements must hold at once: the interface sits in a subnet with the feature on, the VPC meets Google API network requirements, the interface has no external address, and the packet source matches the primary internal, internal IPv6, or alias range.
Restricted Google Access and private connectivity configuration (opens in a new tab) endpoints are two private paths that keep traffic within Google's network. Restricted Google Access limits reachability to a VPC Service Controls-compliant subset through the restricted.googleapis.com virtual IP (VIP) at 199.36.153.4/30. Those VIPs are not announced to the internet, and using them denies unsupported APIs by default. Private Service Connect exposes Google APIs through an internal IP address inside the consumer VPC with a global forwarding rule that forwards to Google APIs. A private DNS zone for googleapis.com. maps names to the endpoint IP such as 10.0.1.1, and firewall policy then controls the endpoint directly.
| Approach | Connection mechanism | Service filtering |
|---|---|---|
| Restricted Google Access | Clients send through VPC default gateway to shared restricted VIP | Allows only VPC Service Controls-supported APIs; denies others |
| Private Service Connect endpoints | Clients send to internal endpoint IP, then forwarding rule forwards to Google APIs | Bundle controls scope; vpc-sc aligns with perimeter, all-apis needs patterns |
Private Google Access for on-premises hosts lets private on-premises systems reach Google APIs without public paths. Traffic flows from on-premises hosts through a Cloud VPN tunnel or Cloud Interconnect VLAN attachment into the VPC network, then to Google API VIP ranges. Cloud Router advertises a custom route for 35.199.192.0/19 back to on premises so return traffic stays private. DNS steers API names to private VIPs, and VPC Service Controls determines whether the API call may move data across the boundary.
Cloud NAT is a managed egress service that lets private workloads reach the internet without public addresses. Traffic flows from a private VM or Pod endpoint to a Cloud NAT gateway, which translates the private source to a selected outgoing address and forwards it externally. Return traffic flows back through the same gateway to the origin. Because private endpoints never appear directly on the internet, the gateway becomes the central point for controlling which workloads can egress.
A Public NAT gateway is bound to one VPC network in one region and serves only selected subnet ranges. A Cloud Router holds the gateway configuration as the control plane, while Andromeda software performs source translation on outbound packets and destination translation only for established responses. Cloud NAT never allows unsolicited inbound connections. VPC firewall rules still govern NAT egress, so a private VM reaches the internet only when egress rules allow it. Traffic to Google APIs bypasses Public NAT through Private Google Access, which takes precedence.
Static and dynamic port allocation control division of the NAT IP and port pool:
| Allocation mode | How ports are assigned | Choose when |
|---|---|---|
| Static port allocation | Same fixed reservation per VM, default 64 ports | Workloads are predictable and need uniform reservations |
| Dynamic port allocation | Gateway expands each VM between minimum and maximum by usage | Demand varies or NAT IPs are constrained |
Exam tip: Traffic to Google APIs uses Private Google Access even when Public NAT covers the subnet, and changing NAT addresses or port settings can break established flows.
Continue with this study guide: Establishing private connectivity
DNS authorization should be used when wildcard certificates are required, when the workload is behind a content delivery network (CDN) or on nonstandard ports, or when certificates must be provisioned before cutover, and it requires adding a CNAME record. Load balancer authorization needs no DNS change but requires the global load balancer to be publicly reachable on port 443 and does not support wildcards.
Shared VPC centralizes subnets, routes, and firewall rules in a host project while workload teams own instances in service projects, where each service project attaches to only one host and a project is never both host and service. VPC Network Peering provides internal IP connectivity between two VPC networks without merging firewalls or identities, is bilateral and non-transitive, and becomes ACTIVE only after both sides create matching peering configurations toward each other.
Cloud NAT translates private VM or Pod sources to shared outgoing addresses for outbound-initiated sessions and returns response traffic through the same gateway, and it never allows unsolicited inbound connections from the internet. Traffic to Google APIs bypasses Public NAT through Private Google Access even when the subnet is covered, and VPC firewall rules must still allow egress for internet access to work.
Layer 7 inspection is enabled only when a firewall policy rule references a security profile group, with matched traffic intercepted to the firewall endpoint in the same zone after the initial rule match and then scanned against threat signatures for anti-spyware, vulnerability protection, and antivirus. A security profile group can contain a maximum of one profile per threat-prevention type and defines how threats are handled, and this inspection is available only through firewall policies, not legacy VPC firewall rules.
Last updated