GCP

Google Cloud Interconnect – Dedicated & Partner

~ Last updated on : ~ jayendrapatil

Google Cloud Interconnect

  • Google Cloud Interconnect provides low-latency, high-availability connections that enable reliable data transfer between networks.
  • Cloud Interconnect offers the following options for extending the network:
    • Dedicated Interconnect – provides a direct physical connection between the on-premises network and Google’s network.
    • Partner Interconnect – provides connectivity between the on-premises and VPC networks through a supported service provider.
    • Cross-Cloud Interconnect – provides dedicated connectivity between Google Cloud and another cloud service provider (AWS, Azure, OCI, Alibaba Cloud).
    • Cross-Site Interconnect – provides Layer 2 connectivity between on-premises network sites using Google’s global network.
  • Cloud Interconnect provides access to all Google Cloud products and services from the on-premises network except Google Workspace.
  • Cloud Interconnect also allows access to supported APIs and services by using Private Google Access from on-premises hosts.
  • Traffic between networks doesn’t traverse the public internet, reducing points of failure and improving latency.
  • VPC network’s internal IP addresses are directly accessible from on-premises without NAT or VPN tunnels.

Dedicated Interconnect

  • Dedicated Interconnect provides direct physical connections between the on-premises network and Google’s network.
  • Dedicated Interconnect enables the transfer of large amounts of data between networks, which can be more cost-effective than purchasing additional bandwidth over the public internet.
  • Dedicated Interconnect requires your network to physically meet Google’s network in a colocation facility with your own routing equipment.
  • Dedicated Interconnect supports only dynamic routing.
  • Dedicated Interconnect supports the following link types:
    • 10 Gbps circuits (single mode fiber, 10GBASE-LR)
    • 100 Gbps circuits (single mode fiber, 100GBASE-LR4)
    • 400 Gbps circuits (single mode fiber, 400GBASE-LR4) – GA March 2026
  • VLAN attachments support maximum bandwidths up to 400 Gbps (GA March 2026).
  • VLAN attachment should be associated with a Cloud Router.
  • Cloud Router creates a BGP session for the VLAN attachment and its corresponding on-premises peer router.
  • Cloud Router receives the routes that the on-premises router advertises. These routes are added as custom dynamic routes in the VPC network.
  • Cloud Router also advertises routes for Google Cloud resources to the on-premises peer router.
  • Supports IPv6 traffic exchange between IPv6-enabled VPC network and on-premises network.

Google Cloud Dedicated Interconnect

Dedicated Interconnect Provisioning

  • Find a collocation facility with GCP Point of Presence (PoP) which offers Direct Interconnect connections.
  • Order an Interconnect connection so that Google can allocate the necessary resources and send a Letter of Authorization and Connecting Facility Assignment (LOA-CFA).
  • LOA-CFA is sent via email to NOC (technical contact) or can be downloaded from the Google Cloud console.
  • Submit the LOA-CFA to the vendor so that they can provision the Interconnect connections between Google’s network and your network.
  • Configure and test the connections with Google before you can use them.
  • Create VLAN attachments to allocate a VLAN on the connection.
  • Configure the on-premises router to establish a BGP session with the Cloud Router.

Dedicated Interconnect Redundancy

  • Single Dedicated Interconnect connection does not offer redundancy or high availability.
  • Google recommends redundancy using 2 (99.9%) or 4 (99.99%) interconnect connections so that if one connection fails, the other connection can continue to serve traffic.
  • Redundant Interconnect connection with 2 connections must be created in the same metropolitan area (city) as the existing one, but in a different edge availability domain (metro availability zone).
  • Redundant Interconnect connection with 4 connections must be created with 2 connections in two different metropolitan areas (city), and each connection in a different edge availability domain (metro availability zone).
  • Dynamic routing mode for the VPC network must be global so that Cloud Router can advertise all subnets and propagate learned routes to all subnets regardless of the subnet’s region.
  • A single-region Critical production SLA (99.99%) topology is now available (GA June 2026), allowing 99.99% availability within a single region.

Google Cloud Dedicated Interconnect Redundancy

Partner Interconnect

  • Partner Interconnect provides connectivity between the on-premises network and the VPC network through a supported service provider.
  • A Partner Interconnect connection is useful if the data center is in a physical location that can’t reach a Dedicated Interconnect colocation facility, or the data needs don’t warrant an entire 10-Gbps connection.
  • Partner Interconnect supports bandwidth from 50 Mbps minimum to 50 Gbps maximum per VLAN attachment.
  • Service providers have existing physical connections to Google’s network that they make available for their customers to use.
  • After the connectivity with a service provider is established, a Partner Interconnect connection from the service provider can be requested.
  • After the service provider provisions the connection, you can start passing traffic between your networks by using the service provider’s network.
  • Partner Interconnect provides Layer 2 and Layer 3 connectivity:
    • For Layer 2 connections:
      • You must configure and establish a BGP session between the Cloud Routers and on-premises routers for each created VLAN attachment.
      • BGP configuration information is provided by the VLAN attachment after your service provider has configured it.
    • For Layer 3 connections:
      • The service provider establishes a BGP session between the Cloud Routers and their edge routers for each VLAN attachment.
      • You don’t need to configure BGP on the on-premises router. Google and the service provider automatically set the correct configuration.
  • Supports IPv6 traffic exchange between IPv6-enabled VPC network and on-premises network.

Google Cloud Partner Interconnect

Partner Interconnect Provisioning

  • Connect the on-premises network to a supported service provider.
  • Create a VLAN attachment for a Partner Interconnect connection in the Google Cloud project, which generates a unique pairing key that must be used to request a connection from the service provider.
  • Activate the connection.
  • Depending on the connection, either you or your service provider then establishes a Border Gateway Protocol (BGP) session.
  • Partner Interconnect provisioning does not require LOA-CFA.

Partner Interconnect Redundancy

  • Single Partner Interconnect connection does not offer redundancy or high availability.
  • 99.9% availability requires:
    • At least two VLAN attachments in a single Google Cloud region, in separate edge availability domains (metro availability zones).
    • At least one Cloud Router, connected to both VLAN attachments.
  • 99.99% availability requires:
    • At least four VLAN attachments across two metros, one in each edge availability domain (metro availability zone).
    • Two Cloud Routers (one in each Google Cloud region of a VPC network).
    • Associate one Cloud Router with each pair of VLAN attachments.
  • Dynamic routing mode for the VPC network must be global so that Cloud Router can advertise all subnets and propagate learned routes to all subnets regardless of the subnet’s region.

Google Cloud Dedicated Interconnect Redundancy - Layer 2

Cross-Cloud Interconnect

  • Cross-Cloud Interconnect provides high-bandwidth dedicated connectivity between Google Cloud and another cloud service provider.
  • Supported cloud providers include Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud Infrastructure (OCI), and Alibaba Cloud.
  • Provides private, SLA-backed connectivity without traversing the public internet.
  • Available connection capacities: 10 Gbps, 100 Gbps, and 400 Gbps (GA March 2026).
  • Google provisions and manages the physical connections from Google to the remote cloud provider.
  • Supports traffic differentiation through application awareness (GA September 2025).
  • Use cases:
    • Multicloud deployments requiring private connectivity between clouds.
    • Data replication and disaster recovery across cloud providers.
    • Distributed applications spanning multiple clouds.

Partner Cross-Cloud Interconnect

  • Partner Cross-Cloud Interconnect for AWS (GA April 2026) provides an on-demand, reliable method for establishing cross-cloud transport without manually setting up networking components.
  • Provides region-to-region transport with SLA-protected, coordinated underlay built with AWS.
  • Can be set up on-demand and sized up or down based on needs.
  • Supports both VPC Network Peering and Network Connectivity Center (NCC) connectivity models.
  • Partner Cross-Cloud Interconnect for OCI provides on-demand connections with variable speed options (1 Gbps to 50 Gbps).

Cross-Site Interconnect

  • Cross-Site Interconnect (Preview, April 2025) provides reliable, high-bandwidth Layer 2 connectivity between on-premises network sites using Google’s global network.
  • A transparent, on-demand, Layer 2 connectivity solution that leverages Google’s global infrastructure.
  • Supports 10 Gbps and 100 Gbps connections.
  • Supports an MTU size of 9,000 bytes for cross-site networks.
  • Use cases:
    • Site-to-site connectivity between on-premises locations.
    • Simplifying WAN infrastructure for high-performance and high-bandwidth connectivity.
    • Improving reliability posture across the WAN.
  • Provisioning requires LOA-CFA similar to Dedicated Interconnect.
  • Available in multiple colocation facilities globally (Singapore, Dallas, Miami, Melbourne, Taipei, Stockholm, etc.).

Cloud Interconnect Security

  • Cloud Interconnect does not encrypt the connection between your network and Google’s network by default.
  • Multiple encryption options are now available:
    • HA VPN over Cloud Interconnect – Deploys IPsec-encrypted HA VPN tunnels over VLAN attachments. Supported for both Dedicated Interconnect and Partner Interconnect. Each HA VPN tunnel provides up to 3 Gbps bandwidth.
    • MACsec for Cloud Interconnect – Uses IEEE 802.1AE MACsec standard to encrypt traffic between your on-premises router and Google’s edge routers. Available for 100 Gbps and 400 Gbps links regardless of location; for 10 Gbps links, availability varies by location.
    • Application-level encryption or your own VPN for additional security.
  • HA VPN over Cloud Interconnect helps maintain compliance with industry regulations requiring encryption of outgoing traffic or data in transit.

MACsec for Cloud Interconnect

  • MACsec encrypts traffic at the Layer 2 (data link) level between your on-premises router and Google’s edge routers.
  • MACsec doesn’t provide encryption in transit within Google’s network. For stronger security, combine with IPsec or TLS.
  • Supports two security modes:
    • Fail open (must-secure) – If MACsec session can’t be established, link operates without encryption.
    • Fail closed – If MACsec session can’t be established, the link fails (drops all traffic).
  • Available for 100 Gbps and 400 Gbps links regardless of location.
  • Uses pre-shared keys to encrypt traffic transiting between routers.

HA VPN over Cloud Interconnect

  • Establishes encrypted HA VPN tunnels over Cloud Interconnect VLAN attachments.
  • Supported for both Dedicated Interconnect and Partner Interconnect.
  • Each HA VPN tunnel provides up to 3 Gbps bandwidth.
  • Provides IPsec encryption at the IP layer (Layer 3).
  • Requires a Cloud Router with encrypted_interconnect_router = true.
  • Can reserve regional internal IP ranges for HA VPN gateway interfaces.

Traffic Differentiation (Application Awareness)

  • Dedicated Interconnect and Cross-Cloud Interconnect support network traffic differentiation through application awareness (GA September 2025).
  • Lets you map outbound traffic to different traffic classes.
  • Supports bandwidth percentage policy or strict priority policy for traffic prioritization.
  • Uses Differentiated Services Field Codepoint (DSCP) in IP headers for traffic differentiation.
  • Managed traffic classification (Preview April 2026) automates DSCP bit assignment in outgoing packets.
  • Contact your account team to enable application awareness.

Dedicated Interconnect vs Partner Interconnect

  • Choosing between Dedicated Interconnect vs Partner Interconnect, consider the connection requirements, such as the connection location and capacity:
    • If you can’t physically meet Google’s network in a colocation facility to reach your VPC networks, use Partner Interconnect to connect through service providers.
    • If you have high bandwidth needs (up to 400 Gbps per link), Dedicated Interconnect can be a cost-effective solution.
    • If you require lower bandwidth (50 Mbps to 50 Gbps), Partner Interconnect provides flexible options through service providers.
    • If you need connectivity to another cloud provider, use Cross-Cloud Interconnect or Partner Cross-Cloud Interconnect.

Cloud Interconnect MTU

  • Cloud Interconnect VLAN attachments support the following MTU sizes:
    • 1,440 bytes
    • 1,460 bytes
    • 1,500 bytes
    • 8,896 bytes
  • Cross-site networks support an MTU size of 9,000 bytes.

Connection Groups and SLA

  • Interconnect connection groups and VLAN attachment groups (GA June 2025) help communicate intended reliability levels.
  • Reliability options:
    • Critical production – 99.99% uptime SLA for maximum resiliency.
    • Non-critical production – 99.9% uptime SLA for non-critical workloads.
    • No SLA – No uptime guarantee (not recommended for production).
  • Resource groups provide feedback on how Cloud Interconnect resources meet the intended level of reliability.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company has decided to build a backup replica of their on-premises user authentication PostgreSQL database on Google
    Cloud Platform. The database is 4 TB, and large updates are frequent. Replication requires private address space communication.
    Which networking approach should you use?

    1. Google Cloud Dedicated Interconnect
    2. Google Cloud VPN connected to the data center network
    3. A NAT and TLS translation gateway installed on-premises
    4. A Google Compute Engine instance with a VPN server installed connected to the data center network
  2. A company wants to connect cloud applications to an Oracle database in its data center. Requirements are a maximum of 20 Gbps
    of data and a Service Level Agreement (SLA) of 99%. Which option best suits the requirements?

    1. Implement a high-throughput Cloud VPN connection
    2. Cloud Router with VPN
    3. Dedicated Interconnect
    4. Partner Interconnect
  3. A company wants to connect cloud applications to an Oracle database in its data center. Requirements are a maximum of 9 Gbps
    of data and a Service Level Agreement (SLA) of 99%. Which option best suits the requirements?

    1. Implement a high-throughput Cloud VPN connection
    2. Cloud Router with VPN
    3. Dedicated Interconnect
    4. Partner Interconnect
  4. A company needs to establish private connectivity between their Google Cloud environment and their AWS environment for a multicloud application. They require high bandwidth and an SLA. Which connectivity option should they use?
    1. Cloud VPN with AWS Site-to-Site VPN
    2. Partner Interconnect through a shared service provider
    3. Cross-Cloud Interconnect
    4. Dedicated Interconnect with VPN tunnels to AWS
  5. An organization requires encrypted traffic over their Dedicated Interconnect connection to meet regulatory compliance requirements. What is the recommended approach?
    1. Use a third-party VPN appliance on a Compute Engine instance
    2. Deploy HA VPN over Cloud Interconnect
    3. Enable Cloud Armor on the Interconnect
    4. Use application-level TLS only
  6. A company wants to connect two of their on-premises data centers using Google’s global network for high-bandwidth, low-latency Layer 2 connectivity. Which Google Cloud service should they use?
    1. Cloud VPN
    2. Dedicated Interconnect
    3. Network Connectivity Center
    4. Cross-Site Interconnect
  7. Which encryption options are available for Cloud Interconnect traffic? (Choose TWO)
    1. MACsec for Cloud Interconnect
    2. Cloud Armor DDoS protection
    3. HA VPN over Cloud Interconnect
    4. Cloud KMS envelope encryption
    5. Identity-Aware Proxy
  8. A company needs an on-demand, managed connection between Google Cloud and AWS without setting up physical infrastructure or colocation facilities. Which service should they use?
    1. Cross-Cloud Interconnect
    2. Dedicated Interconnect with AWS Direct Connect
    3. Partner Cross-Cloud Interconnect for AWS
    4. Cloud VPN with AWS Site-to-Site VPN

Google Cloud DNS – Managed Authoritative DNS

~ Last updated on : ~ jayendrapatil

Google Cloud DNS

  • Cloud DNS is a high-performance, resilient, reliable, low-latency, global Domain Name System (DNS) service that publishes the domain names to the global DNS in a cost-effective way.
  • Cloud DNS helps to publish the zones and records in DNS without the burden of managing your own DNS servers and software.
  • Cloud DNS offers both public zones and private managed DNS zones.
    • A public zone is visible to the public internet
    • A private zone is visible only from one or more specified VPC networks
    • Google Cloud also creates internal DNS names for VMs automatically, even if you do not use Cloud DNS
  • Cloud DNS also supports zonal DNS zones (GA since Dec 2022) that are scoped to a specific Google Cloud zone, providing higher availability for zonal resources.
  • With Shared VPC, Cloud DNS managed private zone, Cloud DNS peering zone, or Cloud DNS forwarding zone must be created in the host project
  • Google Cloud offers inbound and outbound DNS forwarding for private zones
  • Cloud DNS offers DNS forwarding zones and DNS server policies to allow lookups of DNS names between the on-premises and Google Cloud environment
  • Cloud DNS supports per-resource IAM permissions (GA since Dec 2022) allowing fine-grained read, write, or administrator permissions for different managed zones under the same project.
  • Cloud DNS supports Cloud Logging for both private and public zones (GA since Nov 2021) to monitor DNS queries, including query name, type, response code, and source IP address.

DNS Server Policies

  • DNS Server Policies can specify inbound DNS forwarding, outbound DNS forwarding, or both.
  • Inbound server policy refers to a policy that permits inbound DNS forwarding i.e. On-premises to VPC
  • Outbound server policy refers to one possible method for implementing outbound DNS forwarding i.e. VPC to On-premises
  • It is possible for a policy to be both an inbound server policy and an outbound server policy if it implements the features of both.
  • DNS Server Policies is similar to DNS Forwarding zones, except that it applies to all the traffic and not a single specific domain
  • DNS Outbound Policy disables internal DNS for the selected networks
  • DNS Server Policies also support DNS64 configuration to enable IPv6-only VM instances to communicate with IPv4-only destinations (see DNS64 section below).

DNS Forwarding Zones

  • Cloud DNS forwarding zones help configure target name servers for specific private zones.
  • Using a forwarding zone is one way to implement outbound DNS forwarding from the VPC network.
  • A Cloud DNS forwarding zone is a special type of Cloud DNS private zone. Instead of creating records within the zone, you specify a set of forwarding targets.
  • Each forwarding target is an IP address of a DNS server, located in the VPC network, or in an on-premises network connected to the VPC network by Cloud VPN or Cloud Interconnect.
  • Forwarding targets can also be specified as a fully qualified domain name (FQDN) (GA since June 2025), which allows outbound DNS forwarding without requiring a fixed IP address for the target name server.
  • Cloud DNS caches responses for queries sent to Cloud DNS forwarding zones
  • DNS forwarding does not work between two Google Cloud environments

DNS Peering

  • DNS peering allows sending requests for records that come from one zone’s namespace to another VPC network for e.g., a SaaS provider can give a SaaS customer access to DNS records it manages.
  • To provide DNS peering,
    • Cloud DNS peering zone must be created and configured to perform DNS lookups in a VPC network where the records for that zone’s namespace are available.
    • The VPC network where the DNS peering zone performs lookups is called the DNS producer network.
  • To use DNS peering,
    • A network must be authorized to use a peering zone.
    • The VPC network authorized to use the peering zone is called the DNS consumer network.
  • DNS peering and VPC Network Peering are different services. DNS peering can be used with VPC Network Peering, but VPC Network Peering is NOT required for DNS peering. VPC peering does not enable DNS peering and must be setup explicitly.

Cloud DNS Forwarding and Peering

DNS Routing Policies

  • Cloud DNS supports DNS routing policies (GA since Jan 2022) to steer traffic based on specific criteria for resource record sets in both private and public zones.
  • Cloud DNS supports the following routing policy types:
    • Weighted Round Robin (WRR) – assign different weights to each resource record set for a DNS name to distribute traffic according to configured weights. Supports manual active-active or active-passive configurations.
    • Geolocation – map traffic originating from source geographies (Google Cloud regions) to specific DNS targets. Applies nearest match when source doesn’t exactly match a policy item.
    • Geolocation with Geofence – restricts traffic to a specific geolocation even if all endpoints in that region are unhealthy (prevents automatic failover to next closest region).
    • Failover – active/backup configurations for high availability. Returns IP addresses from the active set normally; switches to backup set when all active endpoints are unhealthy.
  • DNS routing policies cannot be configured for forwarding zones, peering zones, managed reverse lookup zones, or Service Directory zones.
  • Cloud DNS supports health checks with routing policies for:
    • Internal Application Load Balancers (regional and cross-region)
    • Internal passthrough Network Load Balancers
    • Internal proxy Network Load Balancers (Preview)
    • External endpoints (GA since Feb 2025) – health checks for any public IP address including global/regional external load balancers and on-premises endpoints
  • Cloud DNS enables automatic failover when endpoints fail their health checks, dynamically adjusting traffic split among remaining healthy endpoints.
  • For external endpoint health checks, probes originate from three user-specified Google Cloud source regions with three prober instances per region (nine total probers per endpoint).
  • If all endpoints are unhealthy, Cloud DNS returns all endpoints as a result (fail-open behavior).

DNS Response Policies

  • Response policies (GA since Nov 2021) let you customize DNS management within a private zone by using rules instead of records.
  • If a rule in the response policy affects the incoming query, it is processed; otherwise, the lookup proceeds normally.
  • Response policy rules are selectors that apply behavior to queries matching the selector (DNS names via wildcards or exact matches).
  • Use cases include:
    • Setting up private connectivity to Google APIs from within a VPC Service Controls perimeter
    • Overriding DNS resolution for specific domains within a VPC network
    • Blocking access to specific domains by returning NXDOMAIN
    • Redirecting traffic to alternative endpoints for specific DNS names
  • Response policies can be bound to VPC networks and GKE clusters.

Alias Records

  • Alias records (GA since Sept 2025) provide CNAME-like functionality at the zone apex.
  • This custom record type maps the apex domain name to a canonical target, solving the limitation that CNAME records cannot coexist with other record types (like SOA) required at the zone apex.
  • Useful when you need to point a naked/apex domain (e.g., example.com) to a load balancer or CDN hostname without using a CNAME.
  • Similar in concept to AWS Route 53 Alias records.

DNS64

  • DNS64 (GA since Aug 2025) provides synthesized IPv6 addresses for IPv4 destinations, enabling IPv6-only VM instances to communicate with IPv4-only services.
  • DNS64 is configured as part of a DNS server policy and applies to VPC networks bound to the policy.
  • When an IPv6-only client queries for a domain that only has A records (IPv4), Cloud DNS synthesizes AAAA records (IPv6) using the 64:ff9b::/96 well-known prefix.
  • Works together with Cloud NAT’s NAT64 to provide end-to-end IPv6-to-IPv4 connectivity.
  • Useful for IPv6-only environments that need to reach legacy IPv4 applications on the internet.

DNS Armor – Advanced Threat Detection

  • DNS Armor (GA since Jan 2026), powered by Infoblox, is a fully-managed DNS-layer security service for Google Cloud workloads.
  • Monitors internet-bound DNS queries for malicious activity at the earliest point in the attack chain—the DNS query—without adding operational complexity or performance overhead.
  • Detects threats including:
    • Requests to malicious command and control (C2) servers
    • DNS tunneling for sensitive data exfiltration
    • Malware using DNS queries for communication
  • Complements existing cloud-first network security products (Cloud Armor, Cloud NGFW) by offering a foundational DNS-based security layer.
  • Threat findings are reported in Cloud Logging for integration with security operations workflows.

VPC Name Resolution Order

  • Each VPC network provides DNS name resolution services to the VM instances that use it.
  • When VMs use their metadata server 169.254.169.254 as their name server, Google Cloud searches for DNS records in the following order:
    • If the VPC network has an outbound server policy, Google Cloud forwards all DNS queries to those alternative servers. The VPC name resolution order consists only of this step.
    • If the VPC network does not have an outbound server policy:
      • Google Cloud tries to find a private zone that matches as much of the requested record as possible (longest suffix matching).
        • Searching records that you created in private zones.
        • Querying the forwarding targets for forwarding zones.
        • Querying the name resolution order of another VPC network by using peering zones.
      • Searches the automatically created Compute Engine internal DNS records for the project.
      • Queries publicly available zones

DNSSEC

  • DNSSEC is a feature of DNS that authenticates responses to domain name lookups
  • DNSSEC protects the domains from spoofing and cache poisoning attacks
  • DNSSEC provides strong authentication for domain lookups, but it does not provide encryption
  • Both the registrar and registry must support DNSSEC for the Top Level Domain (TLD) used
  • For Enabling DNSSEC
    • Enable DNSSEC on the domain. DNS zone for the domain must serve special DNSSEC records for public keys (DNSKEY), signatures (RRSIG), and non-existence (NSEC, or NSEC3 and NSEC3PARAM) to authenticate the zone’s contents.
    • DS record must be added to the TLD at the registrar
    • DNS resolver that validates signatures for DNSSEC-signed domains must be used
  • Note: When DNSSEC is enabled with DNS routing policies, only a single IP address can be used within each policy item.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Questions on DNS Routing Policies and New Features

  1. A company needs to distribute DNS traffic across multiple regions with automatic failover when a region becomes unhealthy. Which Cloud DNS routing policy should they use?
    1. Weighted Round Robin (WRR) routing policy
    2. Geolocation routing policy
    3. Failover routing policy
    4. DNS forwarding policy

    Answer: b. Geolocation routing policy – Geolocation routing with health checks automatically fails over to the next closest region when endpoints are unhealthy. Failover routing policy (c) provides active/backup, not multi-region distribution.

  1. A company wants to point their apex domain (example.com) to a load balancer hostname without using an A record with a static IP. What Cloud DNS feature should they use?
    1. CNAME record at the apex
    2. DNS peering zone
    3. Alias record
    4. DNS forwarding zone

    Answer: c. Alias record – Alias records (GA Sept 2025) provide CNAME-like functionality at the zone apex. CNAME records cannot be placed at the apex because they cannot coexist with SOA records.

  1. An organization has IPv6-only VM instances that need to access legacy IPv4-only services on the internet. Which combination of features should they configure?
    1. Cloud NAT with DNS forwarding
    2. DNS64 with NAT64
    3. DNS peering with Cloud VPN
    4. DNSSEC with IPv6 forwarding

    Answer: b. DNS64 with NAT64 – DNS64 synthesizes AAAA records from A records using the 64:ff9b::/96 prefix, and NAT64 handles the actual packet translation, enabling IPv6-only VMs to reach IPv4 destinations.

  1. A security team wants to detect DNS-based command and control (C2) communication and data exfiltration from their Google Cloud workloads. Which service should they enable?
    1. DNSSEC
    2. Cloud Armor
    3. DNS Armor
    4. DNS Response Policies

    Answer: c. DNS Armor – DNS Armor (GA Jan 2026), powered by Infoblox, provides DNS-layer threat detection for C2 communications, DNS tunneling, and malware DNS queries.

  1. Which of the following routing policy types restricts DNS traffic to a specific geolocation even when all endpoints in that region are unhealthy?
    1. Weighted Round Robin (WRR)
    2. Geolocation routing policy
    3. Geolocation routing policy with geofence
    4. Failover routing policy

    Answer: c. Geolocation routing policy with geofence – With geofencing enabled, automatic failover to the next closest region does not occur, even if all endpoints in a geolocation fail health checks.

  1. An organization wants to override DNS resolution for specific Google API domains within their VPC to route to VPC Service Controls restricted endpoints. What Cloud DNS feature should they use?
    1. DNS forwarding zone
    2. DNS server policy
    3. DNS response policy
    4. DNS peering zone

    Answer: c. DNS response policy – Response policies allow custom DNS resolution within VPCs, making it easy to route specific API domains to restricted VIPs for VPC Service Controls compliance.

  1. Cloud DNS health checks for external endpoints (GA Feb 2025) support which of the following? (Choose 2)
    1. Health checking endpoints behind Cloud VPN
    2. TCP, HTTP, and HTTPS protocols
    3. Health check probes from three user-specified regions
    4. gRPC protocol health checks
    5. Probes from fixed IP address ranges

    Answer: b, c – External endpoint health checks support TCP/HTTP/HTTPS protocols and originate from three user-specified source regions. gRPC, SSL, and HTTP/2 are not supported. Probe source IP ranges are not fixed.

References

Google Cloud Network Endpoint Groups – NEG

~ Last updated on : ~ jayendrapatil

Google Cloud Network Endpoint Groups – NEG

  • Network Endpoint Groups (NEG) is a configuration object that specifies a group of backend endpoints or services.
  • Network Endpoint Groups provides a logical grouping of IP addresses and ports for software services instead of entire VMs.
  • NEGs can be used as backends for External and Internal HTTP(S) load balancers, TCP/SSL Proxy load balancers, and with Traffic Director
  • Zonal NEG
    • contains one or more endpoints that can be Compute Engine VMs or services running on the VMs.
    • are zonal resources that represent collections of either IP addresses or IP address/port combinations for Google Cloud resources within a single subnet.
    • Each endpoint is specified either by an IP address or an IP:port combination.
    • All other backends in that backend service must also be zonal NEGs.
    • Zonal NEG can be used as a backend for more than one backend service
    • Backend services using zonal NEGs for backends only support balancing modes of RATE or CONNECTION. UTILIZATION is not supported
  • Internet NEG
    • contains a single endpoint that is hosted outside of Google Cloud. This endpoint is specified by hostname FQDN:port or IP:port.
    • can use an internet NEG as the backend for a backend service for a Google Cloud external HTTP(S) load balancer.
    • does not support other load balancer types.
    • ideal to serve content from an origin hosted outside of Google Cloud, and needs to be fronted by external HTTP(S) load balancer
    • allows you to
      • Use Google Edge infrastructure for terminating the user connection
      • Direct the connections to your custom origin.
      • Use Cloud CDN for your custom origin.
      • Deliver traffic to the public endpoint across Google’s private backbone, which improves reliability and can decrease latency between client and server.
  • Serverless NEG
    • points to Cloud Run, App Engine, Cloud Functions services residing in the same region as the NEG.
  • Zonal and internet NEGs define how endpoints should be reached, whether they are reachable, and where they are located.
  • Serverless NEGs don’t contain endpoints.
  • A hybrid connectivity NEG points to Traffic Director services running outside Google Cloud.

Google Cloud Network Endpoint Groups

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

References

Google_Cloud_Network_Endpoint_Groups

Google Kubernetes Engine – GKE

~ Last updated on : ~ jayendrapatil

Google Kubernetes Engine – GKE

  • Google Kubernetes Engine – GKE provides a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure.
  • GKE is available in two editions:
    • GKE Standard edition – core GKE functionality including cluster management, autoscaling, release channels, fleet management, Config Management, and Policy Controller at no additional cost.
    • GKE Enterprise edition – adds advanced security, compliance insights, Binary Authorization, service mesh, multi-cluster management, and richer networking features for enterprise-scale operations.

Standard vs Autopilot Cluster

  • Autopilot (Recommended – Default mode since 2023)
    • Provides a fully provisioned and managed cluster configuration.
    • Cluster configuration options are made for you.
    • Autopilot clusters are pre-configured with an optimized cluster configuration that is ready for production workloads.
    • GKE manages the entire underlying infrastructure of the clusters, including the control plane, nodes, and all system components.
    • Applies security best practices by default including hardened node configuration, automatic security patching, and default seccomp profiles.
    • Billing is based on Pod resource requests (CPU, memory, ephemeral storage) rather than node-level resources.
    • Uses a container-optimized compute platform (introduced 2025) that delivers up to 85% faster provisioning speed and improved autoscaling performance.
    • Supports ComputeClasses (Balanced, Scale-Out, custom) to let workloads specify hardware requirements like GPUs, high-memory, or accelerator-optimized nodes.
    • In 2024, 30% of all active GKE clusters were created in Autopilot mode.
  • Standard
    • Provides advanced configuration flexibility over the cluster’s underlying infrastructure.
    • Cluster configurations needed for the production workloads are determined by you.
    • You manage node pools, machine types, scaling policies, and node-level security.
    • Supports Autopilot mode workloads in Standard clusters – allows deploying ComputeClasses and letting GKE auto-create/manage node pools for specific workloads while retaining Standard cluster control for others.

GKE - Autopilot vs Standard Clusters

Zonal vs Regional Cluster

  • Zonal clusters
    • Zonal clusters have a single control plane in a single zone.
    • Depending on the availability requirements, nodes for the zonal cluster can be distributed in a single zone or in multiple zones.
    • Single-zone clusters
      • Control Plane -> Single Zone & Workers -> Single Zone
      • A single-zone cluster has a single control plane running in one zone.
      • Control plane manages workloads on nodes running in the same zone.
    • Multi-zonal clusters
      • Control Plane -> Single Zone & Workers -> Multi-Zone
      • A multi-zonal cluster has a single replica of the control plane running in a single zone and has nodes running in multiple zones.
      • During an upgrade of the cluster or an outage of the zone where the control plane runs, workloads still run. However, the cluster, its nodes, and its workloads cannot be configured until the control plane is available.
      • Multi-zonal clusters balance availability and cost for consistent workloads.
  • Regional clusters
    • Control Plane -> Multi Zone & Workers -> Multi-Zone
    • A regional cluster has multiple replicas of the control plane, running in multiple zones within a given region.
    • Nodes also run in each zone where a replica of the control plane runs.
    • Because a regional cluster replicates the control plane and nodes, it consumes more Compute Engine resources than a similar single-zone or multi-zonal cluster.

GKE Zonal vs Regional Cluster

Route-Based Cluster vs VPC-Native Cluster

  • VPC-native clusters (using Alias IPs) are the default and recommended networking mode.
  • VPC-native mode is always on for Autopilot clusters and cannot be turned off.
  • Route-based clusters require explicitly disabling the VPC-native option and are not recommended for new deployments.
  • VPC-native clusters offer better scalability (not subject to route quotas), native integration with VPC features, and support for Private Google Access.

Refer blog post @ Google Kubernetes Engine Networking

Private Cluster

  • Private clusters help isolate nodes from having inbound and outbound connectivity to the public internet by providing nodes with internal IP addresses only.
  • External clients can still reach the services exposed as a load balancer by calling the external IP address of the HTTP(S) load balancer.
  • Cloud NAT or self-managed NAT gateway can provide outbound internet access for certain private nodes.
  • By default, Private Google Access is enabled, which provides private nodes and their workloads with limited outbound access to Google Cloud APIs and services over Google’s private network.
  • The defined VPC network contains the cluster nodes, and a separate Google Cloud VPC network contains the cluster’s control plane.
  • The control plane’s VPC network is located in a project controlled by Google. The control plane’s VPC network is connected to the cluster’s VPC network with VPC Network Peering. Traffic between nodes and the control plane is routed entirely using internal IP addresses.
  • Control plane for a private cluster has a private endpoint in addition to a public endpoint.
  • Control plane public endpoint access level can be controlled:
    • Public endpoint access disabled
      • Most secure option as it prevents all internet access to the control plane.
      • Cluster can be accessed using Bastion host/Jump server or if Cloud Interconnect and Cloud VPN have been configured from the on-premises network to connect to Google Cloud.
      • Authorized networks must be configured for the private endpoint, which must be internal IP addresses.
    • Public endpoint access enabled, authorized networks enabled:
      • Provides restricted access to the control plane from defined source IP addresses.
    • Public endpoint access enabled, authorized networks disabled
      • Default and least restrictive option.
      • Publicly accessible from any source IP address as long as you authenticate.
  • Nodes always contact the control plane using the private endpoint.

Shared VPC Clusters

  • Shared VPC supports both zonal and regional clusters.
  • Shared VPC supports VPC-native clusters and must have Alias IPs enabled. Legacy networks are not supported.

Node Pools

  • A node pool is a group of nodes within a cluster that all have the same configuration and are identical to one another.
  • Node pools use a NodeConfig specification.
  • Each node in the pool has a cloud.google.com/gke-nodepool Kubernetes node label, which has the node pool’s name as its value.
  • Number of nodes and type of nodes specified during cluster creation becomes the default node pool. Additional custom node pools of different sizes and types can be added to the cluster for e.g. local SSDs, GPUs, Spot VMs, or different machine types.
  • Node pools can be created, upgraded, and deleted individually without affecting the whole cluster. However, a single node in a node pool cannot be configured; any configuration changes affect all nodes in the node pool.
  • You can resize node pools in a cluster by adding or removing nodes using gcloud container clusters resize CLUSTER_NAME --node-pool POOL_NAME --num-nodes NUM_NODES
  • Existing node pools can be manually upgraded or automatically upgraded.
  • For a multi-zonal or regional cluster, all of the node pools are replicated to those zones automatically. Any new node pool is automatically created or deleted in those zones.
  • GKE drains all the nodes in the node pool when a node pool is deleted.
  • Spot VMs (replacement for Preemptible VMs) can be used in node pools for fault-tolerant workloads with up to 60-91% cost savings.
  • Node pool auto-creation (formerly Node Auto-Provisioning/NAP) allows GKE to automatically create and delete node pools based on workload requirements and ComputeClass specifications.

Cluster Autoscaler

  • GKE’s cluster autoscaler automatically resizes the number of nodes in a given node pool, based on the demands of the workloads.
  • Cluster autoscaler is automatic by specifying the minimum and maximum size of the node pool and does not require manual intervention.
  • Cluster autoscaler increases or decreases the size of the node pool automatically, based on the resource requests (rather than actual resource utilization) of Pods running on that node pool’s nodes.
    • If Pods are unschedulable because there are not enough nodes in the node pool, cluster autoscaler adds nodes, up to the maximum size of the node pool.
    • If nodes are under-utilized, and all Pods could be scheduled even with fewer nodes in the node pool, cluster autoscaler removes nodes, down to the minimum size of the node pool. If the node cannot be drained gracefully after a timeout period (currently 10 minutes – not configurable), the node is forcibly terminated.
  • Before enabling cluster autoscaler, design the workloads to tolerate potential disruption or ensure that critical Pods are not interrupted.
  • Workloads might experience transient disruption with autoscaling, esp. with workloads running with a single replica.
  • With Autopilot clusters, you don’t need to configure cluster autoscaler because node pools are automatically provisioned and scaled to meet workload requirements.

ComputeClasses

  • A ComputeClass is a Kubernetes custom resource that defines a list of node configurations (machine types, feature settings, hardware requirements) for GKE to follow when provisioning nodes.
  • Built-in ComputeClasses (Autopilot):
    • General-Purpose (default) – standard compute for most workloads.
    • Balanced – optimized balance of compute, memory, and networking.
    • Scale-Out – cost-efficient for horizontally scalable workloads.
    • Accelerator – for GPU/TPU workloads (AI/ML).
  • Custom ComputeClasses let you define prioritized lists of node configurations for autoscaling, including machine families, Spot VM fallback, specific zones, and hardware constraints.
  • ComputeClasses work in both Autopilot and Standard clusters (with Autopilot mode enabled for the workload).
  • Pods select a ComputeClass using the cloud.google.com/compute-class node selector or nodeAffinity.

Release Channels & Extended Support

  • GKE release channels provide automatic version management:
    • Rapid – latest Kubernetes release; access new GKE features as soon as they go GA.
    • Regular – 1-2 months after Rapid; balance of feature access and stability.
    • Stable – 2-3 months after Regular; priority on stability.
    • Extended – for clusters needing longer support on a specific minor version.
  • Extended Support (since GKE 1.27): clusters can remain on a specific minor version for up to 24 months – 14 months of standard support plus ~10 months of extended support with continued security patches.
  • Clusters enrolled in release channels receive automatic upgrades within their channel’s schedule.

Auto-upgrading Nodes

  • Node auto-upgrades help keep the nodes in the GKE cluster up-to-date with the cluster control plane version when the control plane is updated on your behalf.
  • Node auto-upgrade is enabled by default when a new cluster or node pool is created with Google Cloud Console or the gcloud command.
  • Node auto-upgrades provide several benefits:
    • Lower management overhead – no need to manually track and update the nodes when the control plane is upgraded on your behalf.
    • Better security – GKE automatically ensures that security updates are applied and kept up to date.
    • Ease of use – provides a simple way to keep the nodes up to date with the latest Kubernetes features.
  • Node pools with auto-upgrades enabled are scheduled for upgrades when they meet the selection criteria. Rollouts are phased across multiple weeks to ensure cluster and fleet stability.
  • During the upgrade, nodes are drained and re-created to match the current control plane version. Modifications on the boot disk of a node VM do not persist across node re-creations. To preserve modifications across node re-creation, use a DaemonSet.
  • Enabling auto-upgrades does not cause the nodes to upgrade immediately.

Workload Identity Federation

  • Workload Identity Federation for GKE (previously known as Workload Identity) is the recommended way for workloads running on GKE to authenticate to Google Cloud APIs.
  • Eliminates the need for service account keys, which are a security risk due to being long-lived credentials.
  • Allows Kubernetes service accounts to act as IAM principals, directly referencing them in IAM policies without an intermediate Google service account.
  • Provides per-Pod identity using the principle of least privilege, unlike node-level service accounts that are shared by all workloads on a node.
  • Enabled by default on Autopilot clusters.
  • Supports fleet-level Workload Identity Federation for multi-cluster environments.

Fleet Management

  • A Fleet is a logical grouping of GKE clusters that enables multi-cluster management and governance.
  • Fleets allow you to manage features like Config Management, Policy Controller, and service mesh across multiple clusters simultaneously.
  • Fleet-level features include:
    • Teams – define team scopes across clusters for multi-tenancy.
    • Config Sync – apply consistent configuration across fleet members.
    • Policy Controller – enforce governance policies fleet-wide.
    • Service Mesh – unified service mesh across clusters (Cloud Service Mesh).
    • Multi-cluster Services (MCS) – discover and route to services across clusters.
    • Multi-cluster Gateway – global load balancing across clusters using Gateway API.
  • Fleet management features are available in GKE Standard edition at no additional cost (since 2024).

GKE Security

https://jayendrapatil.com/google-kubernetes-engine-gke-security/

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your existing application running in Google Kubernetes Engine (GKE) consists of multiple pods running on four GKE n1-standard-2 nodes. You need to deploy additional pods requiring n2-highmem-16 nodes without any downtime. What should you do?
    1. Use gcloud container clusters upgrade. Deploy the new services.
    2. Create a new Node Pool and specify machine type n2-highmem-16. Deploy the new pods.
    3. Create a new cluster with n2-highmem-16 nodes. Redeploy the pods and delete the old cluster.
    4. Create a new cluster with both n1-standard-2 and n2-highmem-16 nodes. Redeploy the pods and delete the old cluster.
  2. A company is running a production GKE cluster and wants to minimize operational overhead while ensuring nodes are always patched and running the latest supported Kubernetes version. What should they configure?
    1. Manually upgrade nodes each quarter using gcloud container clusters upgrade.
    2. Use GKE Autopilot mode with release channels enabled.
    3. Disable auto-upgrade and use a custom CI/CD pipeline for upgrades.
    4. Use preemptible VMs so nodes are recycled frequently.
  3. Your organization runs multiple GKE clusters across different regions. You need a way to apply consistent security policies and deploy services accessible across all clusters. Which features should you use?
    1. Create separate IAM policies for each cluster and use external load balancers.
    2. Register clusters in a Fleet and use Policy Controller with Multi-cluster Services.
    3. Deploy identical configurations manually to each cluster.
    4. Use a single regional cluster spanning all regions.
  4. A team wants their GKE workloads to securely access Google Cloud Storage and BigQuery APIs without managing service account keys. What is the recommended approach?
    1. Mount service account JSON keys as Kubernetes secrets.
    2. Use the node’s default service account for all Pods.
    3. Enable Workload Identity Federation and bind Kubernetes service accounts to IAM principals.
    4. Store service account keys in Secret Manager and inject at runtime.
  5. You are deploying an AI/ML training workload on GKE that requires GPU nodes. You want GKE to automatically provision the right node type without manual node pool creation. What should you use?
    1. Manually create a GPU node pool and set taints/tolerations.
    2. Use cluster autoscaler with a pre-created GPU node pool.
    3. Use GKE Autopilot with the Accelerator ComputeClass.
    4. Deploy the workload on CPU nodes and use software-based GPU emulation.
  6. You want your GKE cluster to remain on Kubernetes version 1.29 for 24 months to minimize disruption to production workloads. What should you configure?
    1. Disable auto-upgrades and manually manage the cluster version.
    2. Use the Rapid release channel for the latest patches.
    3. Enroll the cluster in the Extended release channel for extended support.
    4. Create a new cluster every 14 months on the desired version.

References

Google Kubernetes Engine Networking

~ Last updated on : ~ jayendrapatil

Google Kubernetes Engine – Networking

IP allocation

Kubernetes uses various IP ranges to assign IP addresses to Nodes, Pods, and Services.

  • Node IP
    • Each node has an IP address assigned from the cluster’s VPC network.
    • Node IP provides connectivity from control components like kube-proxy and kubelet to the Kubernetes API server.
    • Node IP is the node’s connection to the rest of the cluster.
  • Pod CIDR or Address Range
    • Each node has a pool of IP addresses that GKE assigns the Pods running on that node (a /24 CIDR block by default).
  • Pod Address
    • Each Pod has a single IP address assigned from the Pod CIDR range of its node.
    • Pod IP address is shared by all containers running within the Pod and connects them to other Pods running in the cluster.
  • Service Address Range
    • Each Service has an IP address, called the ClusterIP, assigned from the cluster’s VPC network.
  • For Standard clusters
    • a maximum of 110 Pods can run on a node with a /24 range, not 256 as you might expect. This provides a buffer so that Pods don’t become unschedulable due to a transient lack of IP addresses in the Pod IP range for a given node.
    • For ranges smaller than /24, roughly half as many Pods can be scheduled as IP addresses in the range.
  • Autopilot clusters can run a maximum of 32 Pods per node.

GKE Cluster Networking Types

  • GKE, clusters can be distinguished according to the way they route traffic from one Pod to another Pod.
    • VPC-native cluster: A cluster that uses alias IP address ranges
    • Routes-based cluster: A cluster that uses custom static routes in a VPC network

VPC-Native Clusters

  • VPC-native cluster uses alias IP address ranges
  • VPC-native is the recommended network mode for new clusters
  • VPC-native clusters have several benefits:
    • Pod IP addresses are natively routable within the cluster’s VPC network and other VPC networks connected to it by VPC Network Peering.
    • Pod IP address ranges, and subnet secondary IP address ranges in general, are accessible from on-premises networks connected with Cloud VPN or Cloud Interconnect using Cloud Routers.
    • Pod IP addresses are reserved in the VPC network before the Pods are created in the cluster. This prevents conflict with other resources in the VPC network and allows you to better plan IP address allocations.
    • Pod IP address ranges do not depend on custom static routes and do not consume the system-generated and custom static routes quota. Instead, automatically generated subnet routes handle routing for VPC-native clusters.
    • Firewall rules can be created that apply to just Pod IP address ranges instead of any IP address on the cluster’s nodes.

VPC-Native Clusters IP Allocation

Google Kubernetes Engine Networking VPC-Native Cluster IP Management

  • VPC-native cluster uses three unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are assigned from the primary IP address range of the subnet associated with the cluster.
      • Both node IP addresses and the size of the subnet’s secondary IP address range for Pods limit the number of nodes that a cluster can support
    • One secondary IP address range for all Pod IP addresses.
      • Pod IP addresses are taken from the cluster subnet’s secondary IP address range for Pods.
      • By default, GKE allocates a /24 alias IP range (256 addresses) to each node for the Pods running on it.
      • On each node, those 256 alias IP addresses support up to 110 Pods.
      • Pod Address Range cannot be changed. If exhausted,
        • a new cluster with a larger Pod address range must be created or
        • node pools should be recreated after decreasing the --max-pods-per-node for the node pools.
    • Another secondary IP address range for all Service (cluster IP) addresses.
      • Service (cluster IP) addresses are taken from the cluster’s subnet’s secondary IP address range for Services.
      • Service address range should be large enough to provide addresses for all the Kubernetes Services hosted in the cluster.
  • Node, Pod, and Services IP address ranges must all be unique and subnets with overlapping primary and secondary IP addresses cannot be created.

Routes-based Cluster

  • Routes-based cluster that uses custom static routes in a VPC network i.e. it uses Google Cloud Routes to route traffic between nodes
  • In a routes-based cluster,
    • each node is allocated a /24 range of IP addresses for Pods.
    • With a /24 range, there are 256 addresses, but the maximum number of Pods per node is 110.
    • With approximately twice as many available IP addresses as possible Pods, Kubernetes is able to mitigate IP address reuse as Pods are added to and removed from a node.
  • Routes-based cluster uses two unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are taken from the primary range of the cluster subnet
      • Cluster subnet must be large enough to hold the total number of nodes in your cluster.
    • Pod address range
      • A routes-based cluster has a range of IP addresses that are used for Pods and Services
      • Last /20 (4096 addresses) of the Pod address range is used for Services and the rest of the range is used for Pods
      • Pod address range size cannot be changed after cluster creation. So ensure that a large enough Pod address range is chosen to accommodate the cluster’s anticipated growth during cluster creation
  • Maximum number of nodes, Pods, and Services for a given GKE cluster is determined by the size of the cluster subnet and the size of the Pod address range.

Related Reads

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

 

Google Cloud NAT

~ Last updated on : ~ jayendrapatil

Google Cloud NAT

  • Cloud NAT allows VM instances without external IP addresses and private GKE clusters to send outbound packets to the internet and receive any corresponding established inbound response packets.
  • Cloud NAT is a distributed, software-defined managed service. It’s not based on proxy VMs or appliances.
  • Cloud NAT allows outbound and established inbound responses to those connections
  • Cloud NAT provides source network address translation (SNAT) for VMs without external IP addresses and destination network address translation (DNAT) for established inbound response packets.
  • Cloud NAT does not implement inbound connections from the internet. DNAT is only performed for packets that arrive as responses to outbound packets.
  • Cloud NAT works only for the VM’s network interface’s primary IP address and alias IP address provided that the network interface doesn’t have an external IP address assigned to it, in which case its routed through internet gateway.
  • Cloud NAT gateway is associated with a single VPC network, region, and Cloud Router
  • Cloud NAT provides the following benefits:
    • Security
      • Reduce the need for individual VMs to each have external IP addresses. Subject to egress firewall rules, VMs without external IP addresses can access destinations on the internet.
      • With manual NAT IP address assignment, whitelisting can be performed by the destination service to allow connections from known external IP addresses.
    • Availability
      • is a distributed, software-defined managed service.
      • Can be configured on a Cloud Router, which provides the control plane for NAT, holding specified configuration parameters
    • Scalability
      • can be configured to automatically scale the number of NAT IP addresses that it uses, and it supports VMs that belong to managed instance groups, including those with autoscaling enabled.
    • Performance
      • does not reduce the network bandwidth per VM.

Traditional NAT versus Cloud NAT (click to enlarge).

Cloud NAT Specifications

  • Cloud NAT gateway provides NAT services for packets sent from a VM’s network interface as long as that network interface doesn’t have an external IP address assigned to it
  • Cloud NAT gateway can be configured to provide NAT for the VM network interface’s primary internal IP address, alias IP ranges, or both
  • Cloud NAT gateway does not change the amount of outbound or inbound bandwidth that a VM can use, as it depends on VM’s machine type
  • Cloud NAT gateway can only apply to a single network interface of a VM.
  • Cloud NAT gateway can only use routes whose next hops are the default internet gateway
  • Cloud NAT never performs NAT for traffic sent to the select external IP addresses for Google APIs and services
  • Cloud NAT gateways are associated with subnet IP address ranges in a single region and a single VPC network.
  • Cloud NAT gateway created in one VPC network cannot provide NAT to VMs in other VPC networks connected by using VPC Network Peering, even if the VMs in peered networks are in the same region as the gateway.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You decide to set up Cloud NAT. After completing the configuration, you find that one of your instances is not using the Cloud NAT for outbound NAT. What is the most likely cause of this problem?
    1. The instance has been configured with multiple interfaces.
    2. An external IP address has been configured on the instance.
    3. You have created static routes that use RFC1918 ranges.
    4. The instance is accessible by a load balancer external IP address.

References

Google_Cloud_NAT

Google Cloud CDN – Content Delivery Network

~ Last updated on : ~ jayendrapatil

Google Cloud CDN

  • Google Cloud CDN (Content Delivery Network) uses Google’s global edge network to serve content closer to users, which accelerates websites and applications.
  • Cloud CDN works with the global external Application Load Balancer or the classic Application Load Balancer to deliver content to users.
  • Cloud CDN content can be sourced from various types of backends (also referred to as origin servers):
    • Instance groups
    • Zonal network endpoint groups (NEGs)
    • Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
    • Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
    • Buckets in Cloud Storage
    • GKE Ingress and GKE Gateway backends
  • Cloud CDN with Google Cloud Armor enforces security policies only for requests for dynamic content, cache misses, or other requests that are destined for the origin server. Cache hits are served even if the downstream Google Cloud Armor security policy would prevent that request from reaching the origin server.
  • Google Cloud Armor supports edge security policies (applied before CDN lookup for all traffic) and backend security policies (enforced only for cache misses/dynamic content).

Cloud CDN vs Media CDN

  • Cloud CDN is Google Cloud’s web acceleration solution optimized for web content delivery (websites, APIs, and small/medium assets).
  • Media CDN (GA since 2022) is Google Cloud’s media delivery CDN optimized for high-throughput egress workloads such as streaming video (VoD and live) and large file downloads. It uses YouTube’s serving infrastructure.
  • Media CDN complements Cloud CDN — they are separate products for different use cases.
  • Choose Cloud CDN for: websites, APIs, dynamic content caching, small/medium assets.
  • Choose Media CDN for: video streaming, large file downloads, high-throughput media delivery.

Cloud CDN Flow

Google Cloud CDN Response Flow

  • When a user requests content from an external Application Load Balancer, the request arrives at a Google Front End (GFE), which is at the edge of Google’s network as close as possible to the user.
  • GFE uses Cloud CDN if the load balancer’s URL map routes traffic to a backend service or backend bucket that has Cloud CDN configured.
  • Cloud CDN doesn’t perform any URL redirection. The Cloud CDN cache is located at the GFE.
  • Caching happens automatically for all cacheable content, once Cloud CDN is enabled.
  • Cache Hits and Cache Misses
    • A cache is a group of servers that stores and manages content so that future requests for that content can be served faster.
    • Cached content is a copy of cacheable content that is stored on origin servers.
    • Cache Hit – GFE sends the cached response, if the GFE looks in the Cloud CDN cache and finds a cached response to the user’s request.
    • Partial Hit – A request is served partially from cache and partially from a backend. This can happen if only part of the requested content is stored in cache (relevant to byte range requests).
    • Cache Miss – GFE determines that it can’t fulfill the request from the cache, if the content is requested for the first time or has expired or been evicted.
  • Cache Hit Ratio
    • Cache Hit Ratio is the percentage of times that a requested object is served from the cache.
    • Cache hit ratio can be monitored from the Cloud CDN page in Google Cloud Console.
  • Cache Egress and Cache Fill
    • Cache Egress – Data transfer from a cache to the client.
    • Cache Fill – Data transfer to a cache.
  • Cache Eviction
    • Cloud CDN removes or evicts content to insert new content once the cache reaches its capacity.
    • Content evicted is usually the one that hasn’t recently been accessed, regardless of the content’s expiration time.
    • Multiple Google Cloud projects share a common pool of cache space since they are served from the same set of GFEs.
  • Cache Expiration
    • Content in HTTP(S) caches can have a configurable expiration time or Time To Live (TTL).
    • Cloud CDN supports TTL settings and overrides: client TTL, default TTL, and max TTL.
  • Cache Invalidation
    • Cache Invalidation allows one to force an object or set of objects to be ignored by the cache.
    • Invalidations don’t affect cached copies in web browser caches or caches operated by third-party internet service providers.
    • Each invalidation request takes effect in about 10 seconds.
    • Invalidation supports URL path patterns (e.g., /images/* instead of each individual file).
    • Cache Tag Invalidation (GA May 2025) allows grouping objects by arbitrary metadata tags and invalidating them at scale with faster performance and higher rate limits.
  • Cache Preloading
    • Caching is reactive in that an object is stored in a particular cache only if a request goes through that cache and if the response is cacheable.
    • Caches cannot be preloaded except by causing the individual caches to respond to requests.
  • An object stored in one cache does not automatically replicate into other caches; cache fill happens only in response to a client-initiated request.

Cloud CDN Cache Modes

  • Cloud CDN supports three cache modes that define how responses are cached:
    • CACHE_ALL_STATIC (default) – Automatically caches static content (images, CSS, JS, video, audio, web fonts) that does not have no-store, private, or no-cache directives. Responses without caching directives use the configured default TTL.
    • USE_ORIGIN_HEADERS – Requires the origin to set valid caching directives (Cache-Control and Expires headers). Responses without these headers or with no-store/private directives are not cached.
    • FORCE_CACHE_ALL – Unconditionally caches responses, overriding any cache directives set by the origin. Should NOT be used if serving private, per-user content (e.g., dynamic HTML or API responses).
  • Cache modes can be configured per backend service or backend bucket.

Cloud CDN Content Targeting

  • Content Targeting (GA May 2025) helps cache and deliver assets customized for end-user contexts.
  • Supports:
    • Device characterization – serve different content based on device type (mobile, tablet, desktop).
    • Geo-targeting – serve content customized by user’s geographic location.
  • Useful for implementing responsive websites, language customization, and currency settings.
  • Content targeting works with cache keys to serve appropriate cached content per user context.

Cloud CDN Signed URLs and Signed Cookies

  • Cloud CDN signed URLs and signed cookies help serve responses from Google Cloud’s globally distributed caches, even for authorized requests.
  • Signed URLs
    • A Signed URL provides user read access to a private resource for a limited time without needing a Google Account.
    • Anyone who knows the URL can access the resource until the expiration time is reached or the key is rotated.
    • Cryptographic keys are created on a backend service or bucket, or both.
    • The signed URL contains authorization within the request URL with selected elements hashed and cryptographically signed using a strongly generated random key.
    • Best for controlling access to individual URLs.
  • Signed Cookies
    • Signed cookies provide access to a URL prefix — all requests under that prefix are automatically authenticated.
    • Signed cookies are better suited when you need to authorize access to multiple restricted files.
    • Avoid re-signing URLs for every request or embedding custom logic in applications.

Cloud CDN Private Origin Authentication

  • Private Origin Authentication (GA September 2023) gives Cloud CDN long-term resource access to private Amazon S3 buckets or other compatible object stores.
  • Limits connections to your private origins and prevents users from directly accessing them.
  • Uses AWS Signature Version 4 to sign requests to S3-compatible backends.
  • The backend verifies that requests genuinely come from your Cloud CDN setup, allowing the bucket to remain private.
  • Configurable through both gcloud CLI and Google Cloud Console.

Cloud CDN Service Extensions (Edge Compute)

  • Service Extensions for Cloud CDN (GA November 2025) lets you add custom code to the request processing path of global external Application Load Balancers.
  • Two types of extensions:
    • Edge Extensions (pre-cache) – run before Cloud CDN evaluates the cache, allowing you to manipulate request headers to influence caching and routing decisions.
    • Traffic Extensions (post-cache) – run after content is served from cache, allowing manipulation of cached content on the response path.
  • Use cases include: custom header manipulation, A/B testing, authentication at the edge, exception handling, and custom logging.

Cloud CDN with GKE Gateway

  • GKE Gateway integration (GA April 2026) allows configuring Cloud CDN using the Gateway API for workloads running on GKE.
  • Cloud CDN caching behavior is defined using GCPHTTPFilter resources attached to HTTPRoute resources.
  • Gateway API lets you configure, manage, and fine-tune caching configurations for different segments of traffic.
  • Filters support configuration of cache policies including cache modes and TTL settings.

Cloud CDN Additional Features

  • Cache Policies in URL Maps (GA May 2026) – Configure CDN cache policies at various levels of a URL map with granular control based on hostnames, URL paths, HTTP headers, and query parameters.
  • TLS 1.3 Early Data / 0-RTT (February 2025) – External Application Load Balancer and Cloud CDN support early data for TLS 1.3, allowing clients to include HTTP request data with a TLS handshake, improving performance for resumed connections.
  • Negative Caching – Allows configuring Cloud CDN to cache certain error responses (e.g., 404, 410) to reduce origin load for requests that consistently result in errors.
  • Stale Content Serving – Cloud CDN can serve stale (expired) content while asynchronously revalidating with the origin, reducing latency for users.
  • Dynamic Compression – Cloud CDN can dynamically compress responses using gzip or Brotli when serving content to clients that support it.
  • Predefined Dashboards (GA October 2025) – Default dashboards for monitoring traffic distribution and cache effectiveness without manual configuration.
  • Custom Cache Keys – Cache keys can include or omit any combination of protocol, host, query string, and HTTP headers to improve cache hit ratio.
  • Byte Range Requests – Cloud CDN can initiate multiple cache fill requests in reaction to a single client request when the origin supports byte ranges.

Cloud CDN Best Practices

  • Cache static content using CACHE_ALL_STATIC mode for automatic caching of common static content types.
  • Use proper expiration time or TTL for time-sensitive data.
  • Use custom cache keys to improve cache hit ratio.
    • Cloud CDN, by default, uses the entire request URL to build the cache key.
    • Cache keys can be customized to include or omit any combination of protocol, host, query string, and HTTP headers.
  • Use versioning to update content instead of cache invalidation.
    • Versioning content serves a different version of the same content, effectively replacing old content before the cache entry expires.
    • Invalidation is eventually consistent and should be used as a last resort.
  • Use cache tags for surgical invalidation instead of broad pattern-based invalidation when you need to purge specific groups of objects.
  • Enable negative caching for error responses to reduce origin load.
  • Use stale content serving (stale-while-revalidate) to improve latency for users while content is refreshed.
  • Enable dynamic compression for text-based content to reduce bandwidth usage.
  • Use Google Cloud Armor edge security policies for DDoS protection applied before CDN lookup.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to serve static website content globally with minimum latency. The content is hosted on Compute Engine instances. Which Google Cloud service should they use?
    1. Cloud DNS
    2. Cloud CDN with global external Application Load Balancer
    3. Cloud Interconnect
    4. Media CDN

    Answer: b – Cloud CDN with external Application Load Balancer caches static content at Google’s edge locations for low-latency delivery.

  2. Your organization hosts video-on-demand (VoD) content and needs a CDN solution optimized for high-throughput media streaming. Which Google Cloud product is best suited?
    1. Cloud CDN
    2. Media CDN
    3. Cloud Storage with multi-region buckets
    4. Cloud Interconnect

    Answer: b – Media CDN is optimized for high-throughput egress workloads like streaming video and large file downloads, using YouTube’s serving infrastructure.

  3. A company needs to cache content from a private Amazon S3 bucket using Google Cloud CDN without making the bucket public. What feature should they enable?
    1. Signed URLs
    2. Signed Cookies
    3. Private Origin Authentication
    4. Cloud Storage Transfer Service

    Answer: c – Private Origin Authentication allows Cloud CDN to sign requests to S3-compatible backends using AWS Signature V4, keeping the bucket private.

  4. Which Cloud CDN cache mode should you use if you want to unconditionally cache all responses, including dynamic content, regardless of origin cache directives?
    1. USE_ORIGIN_HEADERS
    2. CACHE_ALL_STATIC
    3. FORCE_CACHE_ALL
    4. CACHE_DYNAMIC

    Answer: c – FORCE_CACHE_ALL unconditionally caches responses, overriding origin cache directives. Should not be used with private, per-user content.

  5. You need to invalidate a large number of cached objects in Cloud CDN that belong to the same content group. What is the most efficient approach?
    1. Invalidate each URL individually
    2. Use URL path patterns with wildcards
    3. Use cache tag-based invalidation
    4. Wait for TTL expiration

    Answer: c – Cache tag invalidation (GA May 2025) allows grouping objects by arbitrary metadata tags and invalidating them at scale with better performance and higher rate limits.

  6. Your application needs to serve different cached content based on user device type (mobile vs desktop). Which Cloud CDN feature supports this?
    1. Custom cache keys
    2. Content Targeting
    3. Signed URLs
    4. Cache Modes

    Answer: b – Content Targeting (GA May 2025) supports device characterization and geo-targeting for serving customized cached content.

  7. You want to add custom authentication logic at the edge before Cloud CDN serves cached content. What feature should you use?
    1. Cloud Armor security policies
    2. Signed URLs
    3. Service Extensions edge extensions (pre-cache)
    4. Backend service IAM policies

    Answer: c – Service Extensions edge extensions (GA November 2025) run before Cloud CDN evaluates the cache, allowing custom code to manipulate requests and influence caching/routing.

  8. Which of the following are valid Cloud CDN backend (origin) types? (Choose THREE)
    1. Managed instance groups
    2. Cloud SQL instances
    3. Cloud Storage buckets
    4. Internet NEGs (custom origins)
    5. Cloud Memorystore

    Answer: a, c, d – Cloud CDN supports instance groups, Cloud Storage buckets, internet NEGs, zonal NEGs, serverless NEGs, and GKE backends.

References

Google Cloud Compute Engine Snapshots

~ Last updated on : ~ jayendrapatil

Compute Engine Snapshots

  • Snapshots provide periodic backup of the persistent disks
  • Snapshots incrementally back up data from the persistent disks.
  • Snapshots are global resources, so any snapshot is accessible by any resource within the same project.
  • Snapshots can be shared across projects.
  • Storage costs for persistent disk snapshots charge only for the total size of the snapshot.
  • Snapshots once created with the current state of the disk, can be restored as a new disk.
  • Compute Engine stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of the data.
  • Snapshots can be created from disks even while they are attached to running virtual machine (VM) instances.
  • Lifecycle of a snapshot created from a disk attached to a running VM instances is independent of the lifecycle of the VM instance.
  • Snapshots can be stored in either one Cloud Storage multi-regional location, such as asia, or one Cloud Storage regional location, such as asia-south1.
  • A multi-regional storage location provides higher availability and might reduce network costs when creating or restoring a snapshot
  • A snapshot can be used to create a new disk in any region and zone, regardless of the storage location of the snapshot.

Snapshot Creation

  • Snapshots are incremental and automatically compressed, so that they can be regularly created on a persistent disk faster and at a lower cost than regularly creating a full image of the disk.
  • Incremental snapshots work as follows:
    • The first successful snapshot of a persistent disk is a full snapshot that contains all the data on the persistent disk.
    • The second snapshot only contains any new data or modified data since the first snapshot. Data that hasn’t changed since snapshot 1 isn’t included. Instead, snapshot 2 contains references to snapshot 1 for any unchanged data.
    • Snapshot 3 contains any new or changed data since snapshot 2 but won’t contain any unchanged data from snapshot 1 or 2. Instead, snapshot 3 contains references to blocks in snapshot 1 and snapshot 2 for any unchanged data.

Snapshot Deletion

  • Compute Engine uses incremental snapshots so that each snapshot contains only the data that has changed since the previous snapshot.
  • For unchanged data, snapshots reference the data in previous snapshots.
  • When a snapshot is deleted, Compute Engine immediately marks the snapshot as DELETED in the system.
    • If the snapshot has no dependent snapshots, it is deleted outright.
    • However, if the snapshot does have dependent snapshots:
      • Any data that is required for restoring other snapshots is moved into the next snapshot, increasing its size.
      • Any data that is not required for restoring other snapshots is deleted. This lowers the total size of all your snapshots.
      • The next snapshot no longer references the snapshot marked for deletion, and instead references the snapshot before it.
  • Deleting a snapshot does not necessarily delete all the data on the snapshot because subsequent snapshots might require information stored in a previous snapshot, keep in mind that
  • To definitively delete data from the snapshots, you should delete all snapshots.

Snapshot Best Practices

  • If a snapshot is created of the persistent disk while the application is running, the snapshot might not capture pending writes that are in transit from memory to disk. So, prepare disk for consistency
    • Pause application/processes that write data, flush disk buffers
    • Unmount disk completely
    • For windows, use VSS snapshots
    • Use ext4 for linux to reduce the risk that data is cached without actually being written to the persistent disk.
  • Take only one snapshot at a time
  • Schedule snapshot off-peak hours
  • Avoid frequent snapshots, take a snapshot of the disk once per hour. Avoid taking snapshots more often than that. Disk snapshots can be created at most once every 10 minutes.
  • Use snapshot schedules as a best practice to back up your Compute Engine workloads
  • Use multiple persistent disks for large data volume. Larger amounts of data create larger snapshots, which cost more and take longer to create.
  • Run fstrim before snapshot (Linux) to clean up space, as this command removes blocks that the file system no longer needs, so that the system can create the snapshot more quickly and with a smaller size
  • Use image from an infrequently used snapshot, instead of using the snapshot itself

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have a workload running on Compute Engine that is critical to your business. You want to ensure that the data on the boot disk of this workload is backed up regularly. You need to be able to restore a backup as quickly as possible in case of disaster. You also want older backups to be cleaned automatically to save on cost. You want to follow Google-recommended practices. What should you do?
    1. Create a Cloud Function to create an instance template.
    2. Create a snapshot schedule for the disk using the desired interval.
    3. Create a cron job to create a new disk from the disk using gcloud.
    4. Create a Cloud Task to create an image and export it to Cloud Storage.

References

Google_Cloud_Compute_Engine_Snapshots

Google Cloud Compute Engine Storage Options

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Engine Storage Options

Persistent Disk

  • Persistent disks are durable network storage devices that the instances can access like physical disks in a desktop or a server.
  • Persistent disks are used as boot disks
  • Data on each persistent disk is distributed across several physical disks.
  • Compute Engine manages the physical disks and the data distribution to ensure redundancy and optimal performance.
  • Persistent disks are located independently from the VM instances and can be detached or moved to keep the data even after the instance is deleted
  • Persistent disk performance scales automatically with size, so they can be resized or additional ones added to meet the performance and storage space requirements.

Persistent Disk Types

  • Standard persistent disks (pd-standard) are backed by standard hard disk drives (HDD).
  • Balanced persistent disks (pd-balanced) are backed by solid-state drives (SSD). They are an alternative to SSD persistent disks that balance performance and cost.
  • SSD persistent disks (pd-ssd) are backed by solid-state drives (SSD).

Zonal Persistent Disks

  • Zonal persistent disks provide durable storage and replication of data within a single zone in a region.
  • Persistent disks have built-in redundancy to protect the data against equipment failure and to ensure data availability through datacenter maintenance events.
  • For additional space on the persistent disks, resize the disks and resize the single file system rather than repartitioning and formatting.
  • Compute Engine automatically encrypts the data in transit, before it travels outside of the instance to persistent disk storage space.
  • Zonal persistent disk remains encrypted either with system-defined keys or with customer-supplied keys.

Regional Persistent Disks

  • Regional persistent disks provide durable storage and replication of data between two zones in the same region.
  • Regional persistent disks are also designed to work with regional managed instance groups.
  • Zonal outage can be handled by force attaching the disk to the standby instance, even if the disk can’t be detached from the original VM
  • Regional persistent disks are designed for
    • workloads that require a lower RPO and RTO compared to using persistent disk snapshots.
    • write performance is less critical than data redundancy across multiple zones.
  • Regional persistent disks cannot be used with memory-optimized machines and compute-optimized machines.

Local SSD

  • Local SSDs are physically attached to the server that hosts the VM instance.
  • Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks.
  • Data stored on a local SSD persists only until the instance is stopped or deleted.
  • Local SSD disks cannot be used as boot disks
  • Local SSD disks can be attached only during instance creation, and not once the instance is created
  • Local SSDs performance gains require certain trade-offs in availability, durability, and flexibility. Because of these trade-offs, Local SSD storage isn’t automatically replicated and all data on the local SSD might be lost if the instance terminates for any reason.
  • Each local SSD is 375 GB in size, but a maximum of 24 local SSD partitions can be attached for a total of 9 TB per instance.
  • Compute Engine automatically encrypts the data when it is written to local SSD storage space. Customer-supplied encryption keys is not supported with local SSDs.

Cloud Storage Buckets

  • Cloud Storage buckets are the most flexible, scalable, and durable storage option for the VM instances.
  • Cloud Storage is ideal if you don’t require the lower latency of Persistent Disks and Local SSDs, and can store the data in a Cloud Storage bucket.
  • Performance of Cloud Storage depends on the selected storage class
  • Standard storage class used in the same location as the instance gives performance that is comparable to persistent disks but with higher latency and less consistent throughput characteristics.
  • Cloud Storage buckets have built-in redundancy to protect the data against equipment failure and to ensure data availability through datacenter maintenance events
  • Cloud Storage buckets aren’t restricted to the zone where the instance is located. Multiregional Cloud Storage buckets stores the data redundantly across at least two regions within a larger multiregional location.
  • Cloud Storage bucket can be mounted on the instance as file system
  • Cloud Storage allows read and write data to a bucket from multiple instances simultaneously.
  • However, Cloud Storage buckets are object stores that don’t have the same write constraints as a POSIX file system and can’t be used as boot disks. Multiple instances working on the same file can lead to overwritten data.
  • Cloud Storage supports both encryption at rest and in transit.

Filestore

  • Filestore provides high-performance, fully managed network attached Storage (NAS)  file storage

Storage Options Comparison

Google Cloud Compute Engine Storage Options

Storage Options Performance Comparison

Google Cloud Compute Engine Storage Performance

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

References

Google Cloud Router – Dynamic BGP Routing

~ Last updated on : ~ jayendrapatil ~ 1 Comment

Google Cloud Router

  • Cloud Router is a fully distributed and managed service that programs custom dynamic routes and scales with the network traffic.
  • Cloud Router works with both legacy networks and VPC networks.
  • Cloud Router isn’t a connectivity option, but a service that works over Cloud VPN or Interconnect connections to provide dynamic routing by using the Border Gateway Protocol (BGP) for the VPC networks.
  • Cloud Router isn’t supported for Direct Peering or Carrier Peering connections.
  • Cloud Router isn’t a physical device that might cause a bottleneck, and it can’t be used by itself.
  • Cloud Routers don’t provide packet routing or forwarding capability.
  • Cloud Router is required or recommended in the following cases:
    • Required for Cloud NAT
    • Required for Cloud Interconnect (Dedicated, Partner, and Cross-Cloud Interconnect)
    • Required for HA VPN
    • Required for Router appliances (Network Connectivity Center)
    • A recommended configuration option for Classic VPN
  • Cloud Router helps dynamically exchange routes between the Google Cloud network and the on-premises network.
  • Cloud Router peers with the on-premises VPN gateway or router to provide dynamic routing and exchanges topology information through BGP.
  • Cloud Router frees you from maintaining static routes.
  • Google Cloud recommends creating two Cloud Routers in each region for a Cloud Interconnect for 99.99% availability.
  • Cloud Router supports following dynamic routing mode:
    • Regional routing mode – provides visibility to resources only in the defined region.
    • Global routing mode – provides visibility to resources in all regions.

Google Cloud Router - Global Dynamic Routing

Cloud Router Key Features

  • BGP Session Management – Manages BGP sessions with support for Bidirectional Forwarding Detection (BFD) and MD5 authentication.
  • Advertised Routes – Advertises IP ranges to the peer network, including subnet routes and custom route advertisements.
  • Learned Routes – Uses routes received from BGP peers and custom learned routes to create dynamic routes in VPC networks.
  • BGP Route Policies – Allows setting rules to filter BGP routes or modify BGP route attributes (GA since March 2025).
  • IPv6 Support – Supports IPv6 route exchange through BGP over IPv6 or BGP over IPv4 using multiprotocol BGP (MP-BGP).

BGP Route Policies

  • BGP route policies let you set rules to filter BGP routes or modify BGP route attributes.
  • BGP route policies can be applied to both inbound (learned) and outbound (advertised) BGP routes.
  • A particular BGP route policy can be applied only in one direction (inbound OR outbound), but not both simultaneously.
  • BGP route policies can be applied to multiple BGP peers on Cloud Router.
  • Route policies use the Common Expression Language (CEL) to define conditions and actions.
  • Each policy is defined as an ordered list of terms, evaluated in sequence, with conditions and corresponding actions.
  • Use cases include:
    • Modifying the best-preferred BGP route to influence traffic paths
    • Filtering routes based on prefixes or communities
    • Modifying route attributes (MED, AS path, communities) before advertisement or import
  • Named Sets (Preview, March 2026) – Group together expressions of communities or BGP prefixes, allowing them to be managed or referenced as a single entity within route policies.
  • BGP route policies are not supported for custom learned routes.

Custom Learned Routes

  • Custom learned routes let you configure a BGP session to include learned routes that you manually specify.
  • Cloud Router behaves as if it learned these routes from the BGP peer.
  • Custom learned routes are useful when you don’t have administrator control to configure a remote peer router.
  • Advantages over static routes:
    • Can detect a loss of reachability in the next hop and react accordingly to avoid dropping traffic.
    • Support using HA VPN tunnels or Cloud Interconnect VLAN attachments as next hops.
  • Custom learned routes can be created along with a BGP session or added to an existing BGP session.
  • Custom learned routes became GA in July 2023.

Best Path Selection Modes

  • Cloud Router supports two best path selection modes for learned routes:
    • Legacy mode (default) – The default mode. Recommended for critical workloads.
    • Standard mode – Offers support for consistent AS path-based routing and more control over how BGP prefixes are ranked in VPC networks. GA since December 2024.
  • Standard mode provides more predictable path selection behavior, aligned with standard BGP best path selection algorithms.
  • The best path selection mode is configured at the VPC network level.

Bidirectional Forwarding Detection (BFD)

  • BFD is a UDP-based detection protocol that provides a low-overhead method of detecting failures in the forwarding path between two adjacent routers.
  • With BFD enabled on Cloud Router, end-to-end failure detection time can be as short as 5 seconds.
  • BFD helps quickly detect forwarding path outages such as BGP up or down events, allowing for more resilient hybrid networks.
  • BFD for Cloud Router is GA since February 2022.

BGP MD5 Authentication

  • Cloud Router supports MD5 authentication for BGP sessions to verify the authenticity of BGP messages.
  • MD5 authentication helps protect BGP sessions from spoofed TCP segments.
  • Both the Cloud Router and the peer router must use the same authentication key.
  • MD5 authentication for Cloud Router is GA since November 2022.

IPv6 Support and Multiprotocol BGP (MP-BGP)

  • Cloud Router supports IPv6 BGP sessions (GA since May 2024), allowing exchange of IPv6 prefixes over IPv6 BGP sessions.
  • With MP-BGP, you can exchange IPv6 routes over an IPv4 BGP session or IPv4 routes over an IPv6 BGP session.
  • To exchange both IPv4 and IPv6 traffic in a single BGP session, select the IPv4 and IPv6 (dual stack) stack type in the network connectivity product (e.g., HA VPN or Dedicated Interconnect).
  • You can enable or disable IPv4 or IPv6 route exchange in a specific BGP session by modifying the BGP peer configuration.
  • MP-BGP for exchanging IPv6 prefixes over IPv4 BGP sessions has been GA since December 2022.

Graceful Restart

  • Cloud Router supports graceful restart to minimize traffic disruption during Cloud Router task restarts or maintenance.
  • With graceful restart, traffic between networks isn’t disrupted as long as the BGP session is re-established within the graceful restart period.
  • Google Cloud recommends enabling graceful restart on the on-premises BGP device.
  • The default graceful restart timer and stalepath timer should be configured based on the specific deployment requirements.

Route Advertisements

  • Cloud Router advertises the IP ranges of subnets in the VPC network to on-premises peers by default.
  • Custom route advertisements allow you to control which routes are advertised:
    • Advertise all subnets (default behavior)
    • Advertise custom IP ranges
    • Advertise specific subnets
  • Custom route advertisements can be configured at the Cloud Router level or per BGP peer.

Cloud Router with Network Connectivity Center

  • Network Connectivity Center (NCC) is a hub-and-spoke orchestration framework for network connectivity.
  • Cloud Router is required for Router appliance instances, which are NCC features for using third-party network virtual appliances.
  • Router appliance instances use Cloud Router for BGP peering to exchange routes between the virtual appliance and the VPC network.
  • NCC supports site-to-site data transfer between on-premises sites using Google’s network.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Question 1: You need to detect forwarding path failures between your on-premises router and Google Cloud as quickly as possible. What feature should you enable on Cloud Router?

  1. MD5 Authentication
  2. Graceful Restart
  3. Bidirectional Forwarding Detection (BFD)
  4. Custom Learned Routes

Answer: c. Bidirectional Forwarding Detection (BFD)

BFD provides sub-5-second failure detection for forwarding path outages between adjacent routers.

Question 2: Your organization wants to filter specific BGP routes learned from an on-premises peer and modify route attributes before importing them into your VPC routing table. Which Cloud Router feature should you use?

  1. Custom Route Advertisements
  2. Custom Learned Routes
  3. BGP Route Policies
  4. Best Path Selection Mode

Answer: c. BGP Route Policies

BGP route policies let you set rules to filter BGP routes or modify BGP route attributes for both inbound (learned) and outbound (advertised) routes.

Question 3: You want to exchange IPv6 routes with your on-premises network over an existing IPv4 BGP session. What feature should you configure?

  1. IPv6 BGP Session
  2. Multiprotocol BGP (MP-BGP)
  3. Dual-stack Cloud Router
  4. IPv6 Route Advertisements

Answer: b. Multiprotocol BGP (MP-BGP)

MP-BGP allows exchanging IPv6 routes over IPv4 BGP sessions (or IPv4 routes over IPv6 sessions) by selecting the dual-stack type in the connectivity product.

Question 4: You need routes that can detect loss of reachability at the next hop and that can use HA VPN tunnels as next hops. Static routes don’t meet these requirements. What should you use?

  1. BGP Route Policies
  2. Dynamic Routes from BGP peers
  3. Custom Learned Routes
  4. Policy-based Routes

Answer: c. Custom Learned Routes

Custom learned routes let you manually configure routes on a BGP session. Unlike static routes, they can detect loss of reachability and support HA VPN tunnels or VLAN attachments as next hops.

Question 5: Which of the following Google Cloud products require Cloud Router for dynamic routing? (Choose 3)

  1. Dedicated Interconnect
  2. Cloud CDN
  3. HA VPN
  4. Cross-Cloud Interconnect
  5. Cloud DNS

Answer: a, c, d

Cloud Router is required for Dedicated Interconnect, HA VPN, Cross-Cloud Interconnect, Partner Interconnect, and Router appliances. It is not used by Cloud CDN or Cloud DNS.

References