GCP

Google Cloud gcloud CLI Cheat Sheet – Commands

~ Last updated on : ~ jayendrapatil

Google Cloud GCloud Cheat Sheet

📋 Last Updated: June 2026. Updated with gcloud storage commands (replacing deprecated gsutil), Spot VMs (replacing preemptible), Cloud Run, Artifact Registry, and Deployment Manager deprecation notice.

Google Cloud Config

PURPOSE COMMAND
Initialize gcloud CLI gcloud init
Display version and components gcloud version
List config properties gcloud config list
Show project info gcloud compute project-info describe
Switch project gcloud config set project <project-id>
Set the active account gcloud config set account <ACCOUNT>
Set default region gcloud config set compute/region us-west1
Set default zone gcloud config set compute/zone us-west1-b
List configurations gcloud config configurations list
Create configuration gcloud config configurations create <config-name>
Activate configuration gcloud config configurations activate <config-name>
Get property value gcloud config get compute/region

Google Cloud IAM

PURPOSE COMMAND
Get project IAM policy gcloud projects get-iam-policy <project-id>
Add IAM policy binding gcloud projects add-iam-policy-binding <project-id> --member=<member> --role=<role>
Copy roles across org and projects gcloud iam roles copy --source=<role> --destination=<role> --dest-project=<project-id>
List grantable roles gcloud iam list-grantable-roles <resource>
Create custom role gcloud iam roles create <role-id> --project=<project-id> --permissions=<permissions>
Create service account gcloud iam service-accounts create <name> --display-name=<display-name>
List service accounts gcloud iam service-accounts list
List service account keys gcloud iam service-accounts keys list --iam-account=<sa-email>

Google Cloud Auth

PURPOSE COMMAND
Authorize with user credentials gcloud auth login
Display a list of credentialed accounts gcloud auth list
Authenticate with service account gcloud auth activate-service-account --key-file=<key-file>
Auth to Container/Artifact Registry gcloud auth configure-docker <region>-docker.pkg.dev
Print access token for active account gcloud auth print-access-token
Set up Application Default Credentials gcloud auth application-default login
Revoke credentials gcloud auth revoke <account>

Google Cloud Storage

⚠️ Note: gsutil is no longer the recommended CLI for Cloud Storage. Google recommends using gcloud storage commands instead, which are faster by default and support newer features like soft delete and managed folders.

PURPOSE COMMAND (gcloud storage – Recommended) LEGACY COMMAND (gsutil)
List all buckets gcloud storage ls gsutil ls
List bucket contents gcloud storage ls gs://<bucket-name> gsutil ls -lh gs://<bucket-name>
Create bucket gcloud storage buckets create gs://<bucket-name> gsutil mb gs://<bucket-name>
Download file gcloud storage cp gs://<bucket>/<path>/file.txt . gsutil cp gs://<bucket>/<path>/file.txt .
Upload file gcloud storage cp <file> gs://<bucket>/<dir>/ gsutil cp <file> gs://<bucket>/<dir>/
Delete file gcloud storage rm gs://<bucket>/<filepath> gsutil rm gs://<bucket>/<filepath>
Move/rename file gcloud storage mv <src> gs://<bucket>/<dest> gsutil mv <src> gs://<bucket>/<dest>
Copy folder recursively gcloud storage cp -r ./conf gs://<bucket>/ gsutil cp -r ./conf gs://<bucket>/
Show disk usage gcloud storage du gs://<bucket>/<dir> gsutil du -h gs://<bucket>/<dir>
Sync directories gcloud storage rsync ./local gs://<bucket>/<dir> gsutil rsync ./local gs://<bucket>/<dir>
Generate signed URL gcloud storage sign-url gs://<bucket>/<object> --duration=20m gsutil signurl -d 20m <key-file> gs://<bucket>/<object>
Describe bucket gcloud storage buckets describe gs://<bucket-name> gsutil ls -L -b gs://<bucket-name>

Google Kubernetes Engine (GKE)

PURPOSE COMMAND
Create Standard cluster gcloud container clusters create <cluster-name> --num-nodes=3 --zone=<zone>
Create Autopilot cluster gcloud container clusters create-auto <cluster-name> --region=<region>
List all container clusters gcloud container clusters list
Get cluster credentials (set kubectl context) gcloud container clusters get-credentials <cluster-name> --zone=<zone>
Set default cluster gcloud config set container/cluster <cluster-name>
Resize cluster node pool gcloud container clusters resize <cluster-name> --num-nodes=<count> --node-pool=<pool>
Update cluster (enable autoscaling) gcloud container clusters update <cluster-name> --enable-autoscaling --min-nodes=1 --max-nodes=5
Delete cluster gcloud container clusters delete <cluster-name>
List node pools gcloud container node-pools list --cluster=<cluster-name>
Create node pool with Spot VMs gcloud container node-pools create <pool-name> --cluster=<cluster> --spot

Google Cloud Compute Engine

PURPOSE COMMAND
List all instances gcloud compute instances list
List instance templates gcloud compute instance-templates list
Show instance info gcloud compute instances describe <instance-name> --zone=<zone>
Stop an instance gcloud compute instances stop <instance-name> --zone=<zone>
Start an instance gcloud compute instances start <instance-name> --zone=<zone>
Create an instance gcloud compute instances create <vm-name> --image-family=<family> --image-project=<project> --zone=<zone> --machine-type=e2-micro
Create a Spot VM gcloud compute instances create <vm-name> --provisioning-model=SPOT --instance-termination-action=STOP
Create preemptible instance (legacy) gcloud compute instances create <vm-name> --preemptible
SSH to instance gcloud compute ssh <instance-name> --zone=<zone>
List available images gcloud compute images list
List available zones gcloud compute zones list
List machine types gcloud compute machine-types list --filter="zone:<zone>"
Create snapshot gcloud compute disks snapshot <disk-name> --zone=<zone>
List snapshots gcloud compute snapshots list

💡 Spot VMs vs Preemptible VMs: Spot VMs are the latest version of preemptible VMs and are recommended. Key differences: Spot VMs have no 24-hour maximum runtime limit, and pricing is the same. Use --provisioning-model=SPOT instead of --preemptible.

Cloud Run & Cloud Functions

PURPOSE COMMAND
Deploy a Cloud Run service gcloud run deploy <service-name> --image=<image> --region=<region>
List Cloud Run services gcloud run services list
Describe Cloud Run service gcloud run services describe <service-name> --region=<region>
Delete Cloud Run service gcloud run services delete <service-name> --region=<region>
Update traffic splitting gcloud run services update-traffic <service> --to-revisions=<rev>=100
Deploy Cloud Run function gcloud functions deploy <function-name> --runtime=<runtime> --trigger-http --region=<region>
List Cloud Functions gcloud functions list
View function logs gcloud functions logs read <function-name>
Delete Cloud Function gcloud functions delete <function-name> --region=<region>

Virtual Private Cloud (VPC) Network

PURPOSE COMMAND
List all networks gcloud compute networks list
Detail of one network gcloud compute networks describe <network-name> --format=json
Create network gcloud compute networks create <network-name> --subnet-mode=custom
Create subnet gcloud compute networks subnets create <subnet-name> --network=<network> --range=10.0.0.0/24 --region=<region>
List all firewall rules gcloud compute firewall-rules list
List all forwarding rules gcloud compute forwarding-rules list
Describe one firewall rule gcloud compute firewall-rules describe <rule-name>
Create firewall rule gcloud compute firewall-rules create <rule-name> --network=default --allow=tcp:22 --source-ranges=0.0.0.0/0
Update firewall rule gcloud compute firewall-rules update <rule-name> --allow=tcp:80,tcp:443
Delete firewall rule gcloud compute firewall-rules delete <rule-name>

Artifact Registry

PURPOSE COMMAND
List repositories gcloud artifacts repositories list
Create Docker repository gcloud artifacts repositories create <repo> --repository-format=docker --location=<region>
List images in repository gcloud artifacts docker images list <region>-docker.pkg.dev/<project>/<repo>
Configure Docker authentication gcloud auth configure-docker <region>-docker.pkg.dev
Delete repository gcloud artifacts repositories delete <repo> --location=<region>

App Engine

PURPOSE COMMAND
Create App Engine app gcloud app create --region=<region>
Deploy application gcloud app deploy
List versions gcloud app versions list
Open app in browser gcloud app browse
View application logs gcloud app logs read

Components

PURPOSE COMMAND
List installed components gcloud components list
Update all components gcloud components update
Install a component gcloud components install <component-name>
Remove a component gcloud components remove <component-name>

Deployment Manager

⚠️ DEPRECATED: Google Cloud Deployment Manager reached End of Support on December 31, 2025, and will be discontinued on March 31, 2026. Migrate to Infrastructure Manager (Terraform-based) or use Terraform directly.

PURPOSE COMMAND
Create deployment gcloud deployment-manager deployments create <name> --config=<config.yaml>
Update deployment gcloud deployment-manager deployments update <name> --config=<config.yaml>
Delete deployment gcloud deployment-manager deployments delete <name>
List deployments gcloud deployment-manager deployments list

Miscellaneous

PURPOSE COMMAND
Display environment details gcloud info
List project logs gcloud logging logs list
Read log entries gcloud logging read "resource.type=gce_instance" --limit=10
Decrypt with KMS gcloud kms decrypt --key=<key> --keyring=<ring> --location=<loc> --ciphertext-file=<in> --plaintext-file=<out>
List Cloud SQL instances gcloud sql instances list
Export Cloud SQL to SQL file gcloud sql export sql <instance> gs://<bucket>/<file>.sql --database=<db>
List Pub/Sub topics gcloud pubsub topics list
Publish message to topic gcloud pubsub topics publish <topic> --message="Hello"

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 development project with appropriate IAM roles defined. You are creating a production project and want to have the same IAM roles on the new project, using the fewest possible steps. What should you do?
    1. Use gcloud iam roles copy and specify the production project as the destination project.
    2. Use gcloud iam roles copy and specify your organization as the destination organization.
    3. In the Google Cloud Platform Console, use the ‘create role from role’ functionality.
    4. In the Google Cloud Platform Console, use the ‘create role’ functionality and select all applicable permissions.
  2. Your team is working on GKE cluster named dev. You have downloaded and installed the gcloud command line interface (CLI) and SDK. You want to avoid having to specify this GKE config with each CLI command when managing this cluster. What should you do?
    1. Set the dev cluster as the default cluster using the gcloud container update dev
    2. Set the dev cluster as the default cluster using the gcloud config set container/cluster dev
    3. Set the dev cluster as the default cluster by adding the config to gke.default in ~/gcloud folder
    4. Set the dev cluster as the default cluster by adding the config to defaults.json in ~/gcloud folder
  3. You have a Kubernetes cluster with 1 node-pool. The cluster receives a lot of traffic and needs to grow. You decide to add a node. What should you do?
    1. Use “gcloud container clusters resize” with the desired number of nodes.
    2. Use “kubectl container clusters resize” with the desired number of nodes.
    3. Edit the managed instance group of the cluster and increase the number of VMs by 1.
    4. Edit the managed instance group of the cluster and enable autoscaling.
  4. You’re trying to provide temporary access to some files in a Cloud Storage bucket with 20 minutes availability. What is the best way to generate a signed URL?
    1. Create a service account and JSON key. Use the gsutil signurl -t 20m command and pass in the JSON key and bucket.
    2. Create a service account and JSON key. Use the gsutil signurl -d 20m command and pass in the JSON key and bucket.
    3. Create a service account and JSON key. Use the gsutil signurl -p 20m command and pass in the JSON key and bucket.
    4. Create a service account and JSON key. Use the gsutil signurl -m 20m command and pass in the JSON key and bucket.

    Note: The modern equivalent command is gcloud storage sign-url gs://<bucket>/<object> --duration=20m --private-key-file=<key-file>

  5. You need to deploy a containerized application to Google Cloud with minimal infrastructure management. The application handles variable traffic and you want it to scale to zero when not in use. Which service and command should you use?
    1. Deploy to GKE Autopilot using gcloud container clusters create-auto and kubectl apply.
    2. Deploy to Cloud Run using gcloud run deploy <service-name> –image=<image> –region=<region> –allow-unauthenticated.
    3. Deploy to Compute Engine using gcloud compute instances create-with-container.
    4. Deploy to App Engine using gcloud app deploy with a Dockerfile.
  6. Your organization is migrating from gsutil to the new recommended CLI. Which command should you use to upload a local directory to Cloud Storage recursively?
    1. gsutil cp -r ./data gs://my-bucket/
    2. gcloud storage objects upload ./data gs://my-bucket/ –recursive
    3. gcloud storage cp -r ./data gs://my-bucket/
    4. gcloud storage buckets cp ./data gs://my-bucket/ –recursive
  7. You need to create a cost-effective VM for a fault-tolerant batch processing workload. Google recommends using Spot VMs instead of preemptible VMs. Which command creates a Spot VM?
    1. gcloud compute instances create batch-vm –preemptible –max-run-duration=24h
    2. gcloud compute instances create batch-vm –spot
    3. gcloud compute instances create batch-vm –provisioning-model=SPOT –instance-termination-action=STOP
    4. gcloud compute instances create batch-vm –scheduling=spot –maintenance-policy=TERMINATE
  8. You need to create a fully managed Kubernetes cluster where Google manages the nodes, scaling, and security. Which command should you use?
    1. gcloud container clusters create my-cluster –enable-autopilot
    2. gcloud container clusters create-auto my-cluster –region=us-central1
    3. gcloud container clusters create my-cluster –managed-mode=autopilot
    4. gcloud container clusters create my-cluster –num-nodes=0 –enable-autoscaling

Google Cloud Identity – SSO, Directory & Federation Guide

~ Last updated on : ~ jayendrapatil

Google Cloud Identity

  • Cloud Identity is an Identity as a Service (IDaaS) solution that helps centrally manage the users and groups.
  • can be configured to federate identities between Google and other identity providers, such as Active Directory and Microsoft Entra ID (formerly Azure Active Directory).
  • also gives more control over the accounts that are used in the organization.
  • Cloud Identity account is created for each of your users and groups and IAM can be used to manage access to Google Cloud resources for each Cloud Identity account.
  • Cloud Identity is available in two editions:
    • Cloud Identity Free – Core identity, basic endpoint management, and user/group management at no cost.
    • Cloud Identity Premium – Adds advanced endpoint management, enterprise security features, context-aware access, and application management.

Mandatory Multi-Factor Authentication (MFA)

  • Google Cloud enforced mandatory multi-factor authentication (MFA) for all Google Cloud users during 2025.
  • All users signing into the Google Cloud Console, Firebase Console, and gCloud CLI are required to enable MFA.
  • MFA supports multiple second-factor methods including security keys, Google Authenticator, phone-based verification, and passkeys.
  • This requirement applies to all Google Cloud accounts, including those managed through Cloud Identity.

Google Cloud Identity Management

Google Cloud Identity Management

  • Google identity is related to a number of other entities that are all relevant in the context of managing identities:
    • Google for consumers contains the entities that are relevant for consumer-focused usage of Google services such as Gmail.
    • Google for organizations contains entities managed by Cloud Identity or Google Workspace. These entities are the most relevant for managing corporate identities.
    • Google Cloud contains entities that are specific to Google Cloud.
    • External contains entities that are relevant if you integrate Google with an external Identity Provider (IdP).
  • A Cloud Identity or Google Workspace account is the top-level container for users, groups, configuration, and data.
  • A Cloud Identity or Google Workspace account is created when a company signs up for Cloud Identity or Google Workspace and corresponds to the notion of a tenant.
  • Cloud Identity or Google Workspace account federation with an external IdP enables employees to use their existing identity and credentials to sign in to Google services.
  • External IdP is the source of truth and the sole system for authentication and provides a SSO experience for the employees across applications.
  • With single sign-on enabled, Cloud Identity or Google Workspace relays authentication decisions to the SAML IdP.
  • In SAML terms, Cloud Identity or Google Workspace acts as a service provider that trusts the SAML IdP to verify a user’s identity on its behalf.
  • Each Cloud Identity or Google Workspace account can refer to at most one external IdP.

Single Sign-on – SSO

  • Cloud Identity or Google Workspace account can be configured to use a single sign-on (SSO).
  • With SSO enabled, users are redirected to an external identity provider (IdP) for authentication.
  • Using SSO can provide several advantages:
    • better experience for users because they can use their existing credentials to authenticate and don’t have to enter credentials as often.
    • existing IdP remains the system of record for authenticating users.
    • don’t need to synchronize passwords to Cloud Identity or Google Workspace.
  • Cloud Identity and Google Workspace support Security Assertion Markup Language (SAML) 2.0 for single sign-on.
  • SAML is an open standard for exchanging authentication and authorization data between a SAML IdP and SAML service providers.
  • With SSO for Cloud Identity or Google Workspace, the external IdP is the SAML IdP and Google is the SAML service provider.
  • Google implements SAML 2.0 HTTP Redirect binding.

Using SSO to access the Google Cloud Console.

Workforce Identity Federation

  • Workforce Identity Federation is an alternative approach to Cloud Identity federation that allows external IdP users to access Google Cloud resources without provisioning identities in Cloud Identity.
  • Uses an identity federation approach instead of directory synchronization — no need for GCDS or Directory Sync.
  • Supports both OpenID Connect (OIDC) and SAML 2.0 protocols.
  • Works with identity providers including Microsoft Entra ID (formerly Azure AD), Active Directory Federation Services (AD FS), Okta, and Ping Identity.
  • Key features:
    • Workforce Identity Pools – manage groups of workforce identities and control their access to Google Cloud resources.
    • Attribute-based access control – uses attributes (claims/assertions) from the external IdP to determine the scope of access.
    • Multiple providers per pool – supports multiple IdPs within a single workforce identity pool.
    • Syncless authentication – no need to synchronize user accounts to Cloud Identity.
  • Workforce Identity Federation is available as a no-cost feature.
  • Supports access to Google Cloud Console, gCloud CLI, and Google Cloud APIs.
  • Helps address regulatory and compliance requirements by leveraging existing identity investments.
  • Use Workforce Identity Federation when:
    • You want to avoid provisioning and managing user accounts in Cloud Identity.
    • You need to onboard partners, contractors, or external workforce quickly.
    • You want to use OIDC (not just SAML) for federation.
  • Use Cloud Identity federation when:
    • You need access to Google Workspace services (Gmail, Calendar, Drive).
    • You need full Google managed account lifecycle management.
    • You require endpoint management capabilities.

Federating Google Cloud with Active Directory

Federating Google Cloud with Active Directory

  • Federating user identities between Google Cloud and existing identity management systems helps automate the maintenance of Google identities and tie their lifecycle to existing users in Active Directory.
  • Federation can be supported using the following tools:
    • Google Cloud Directory Sync (GCDS)
      • is a free Google-provided tool that implements the synchronization process from Active Directory or LDAP server to Google Domain.
      • communicates with Google Cloud over Secure Sockets Layer (SSL) and usually runs in the existing computing environment.
      • requires on-premises software installation.
      • supports all LDAP-compliant directories, including Active Directory and OpenLDAP.
    • Directory Sync (Cloud-based) — Public Beta
      • is a newer, cloud-based version of GCDS that requires no on-premises software installation.
      • currently supports Microsoft Entra ID (formerly Azure AD) as the external directory source.
      • synchronizes users and groups directly from the cloud — no hardware or software installation required.
      • recommended for organizations looking for a simpler, fully managed sync solution.
      • can be used alongside GCDS (GCDS for shared contacts, Directory Sync for users/groups).
    • Microsoft Entra ID (formerly Azure AD) Provisioning
      • uses SCIM-based automatic provisioning to sync users from Microsoft Entra ID to Cloud Identity or Google Workspace.
      • provides single sign-on between Microsoft Entra ID and Cloud Identity.
    • Active Directory Federation Services (AD FS)
      • is provided by Microsoft as part of Windows Server.
      • helps use Active Directory for federated authentication.
      • runs within the existing computing environment.

POSIX Groups Deprecation

⚠️ Deprecation Notice: Cloud Identity POSIX groups were deprecated on September 26, 2024. As of that date, no new POSIX groups can be created. Existing POSIX groups were removed on or after September 26, 2025.

Migration: Use Linux groups with OS Login as the replacement for managing POSIX group information for VM access.

Context-Aware Access

  • Context-Aware Access (available with Cloud Identity Premium) allows defining access policies based on attributes like user identity, device state, network location, and IP address.
  • Integrates with Identity-Aware Proxy (IAP) to enforce the BeyondCorp zero-trust security model.
  • Key capabilities:
    • Define access policies for Google Cloud resources based on device posture and network context.
    • Control session length and reauthentication methods for ongoing access.
    • Enforce policies when accessing Google Cloud Console and gCloud CLI.
    • Requires Chrome Enterprise Premium license for device attribute-based access levels.
  • Works with Endpoint Verification to assess device security posture before granting access.

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 organization has user identities in Active Directory. Your organization wants to use Active Directory as its source of truth for identities. Your organization wants to have full control over the Google accounts used by employees for all Google services, including your Google Cloud Platform (GCP) organization. What should you do?
    1. Use Google Cloud Directory Sync (GCDS) to synchronize users into Cloud Identity.
    2. Use the Cloud Identity APIs and write a script to synchronize users to Cloud Identity.
    3. Export users from Active Directory as a CSV and import them to Cloud Identity via the Admin Console.
    4. Ask each employee to create a Google account using self signup. Require that each employee use their company email address and password.
  2. Your company has a single sign-on (SSO) identity provider that supports Security Assertion Markup Language (SAML) integration with service providers. Your company has users in Cloud Identity. You would like users to authenticate using your company’s SSO provider. What should you do?
    1. In Cloud Identity, set up SSO with Google as an identity provider to access custom SAML apps.
    2. In Cloud Identity, set up SSO with a third-party identity provider with Google as a service provider.
    3. Obtain OAuth 2.0 credentials, configure the user consent screen, and set up OAuth 2.0 for Mobile & Desktop Apps.
    4. Obtain OAuth 2.0 credentials, configure the user consent screen, and set up OAuth 2.0 for Web Server Applications.
  3. Your organization uses Microsoft Entra ID (formerly Azure AD) for identity management. You need to enable employees to access Google Cloud resources without provisioning individual accounts in Cloud Identity. You want to minimize administrative overhead. What should you do?
    1. Use GCDS to synchronize users from Active Directory to Cloud Identity and configure SSO.
    2. Create individual Cloud Identity accounts for each employee and use SAML SSO.
    3. Configure Workforce Identity Federation with a workforce identity pool using your Microsoft Entra ID as the OIDC provider.
    4. Export users from Microsoft Entra ID and import them to Cloud Identity via CSV.
  4. Your company wants to synchronize user and group information from Microsoft Entra ID to Cloud Identity without installing any on-premises software. Which solution should you use?
    1. Google Cloud Directory Sync (GCDS)
    2. Active Directory Federation Services (AD FS)
    3. Directory Sync (cloud-based)
    4. Workforce Identity Federation
  5. You need to grant temporary contractors access to specific Google Cloud projects. The contractors already have accounts in your organization’s Okta identity provider. You want to avoid creating Cloud Identity accounts for them. What is the recommended approach?
    1. Create guest accounts in Cloud Identity for each contractor.
    2. Share service account keys with the contractors.
    3. Set up Workforce Identity Federation with Okta as the identity provider and use IAM to grant access to specific projects.
    4. Create Google consumer accounts for each contractor and grant them access.

References

Google Cloud App Engine – PaaS & Serverless Apps

~ Last updated on : ~ jayendrapatil

⚠️ Important: Google Recommends Cloud Run for New Projects

As of 2025, Google officially recommends Cloud Run over App Engine for new projects. Cloud Run offers greater flexibility, container support, GPU access, multi-region load balancing, and lower pricing for idle instances. App Engine remains fully supported for existing applications, but Google has established an App Engine Migration Center to help customers transition to Cloud Run.

Google Cloud App Engine

  • App Engine helps build highly scalable applications on a fully managed serverless platform
  • App Engine provides PaaS and helps build and deploy apps quickly using popular languages or bring your own language runtimes and frameworks.
  • App Engine allows to scale the applications from zero to planet scale without having to manage infrastructure
  • Each Cloud project can contain only a single App Engine application
  • App Engine is regional, which means the infrastructure that runs the apps is located in a specific region, and Google manages it so that it is available redundantly across all of the zones within that region
  • App Engine application location or region cannot be changed once created
  • App Engine is well suited to applications that are designed using a microservice architecture
  • App Engine creates a default bucket in Cloud Storage for each app creation
  • App Engine supports two generations of runtimes — first-generation (legacy bundled services) and second-generation (standard Cloud Client Libraries)

App Engine Environments

App Engine provides two environments:

  • Standard Environment — runs in a secure sandbox, supports specific language runtimes, scale-to-zero capable, faster instance startup
  • Flexible Environment — runs in Docker containers on Compute Engine VMs, supports any language via custom runtimes, minimum 1 instance always running

Refer blog post Standard vs Flexible Environment

Supported Runtimes (2025-2026)

  • App Engine follows a runtime lifecycle with stages: General Availability → End of Support → Deprecated → Decommissioned
  • Current Standard Environment Runtimes:
    • Java: Java 25 (preview), Java 21, Java 17
    • Python: Python 3.14, 3.13, 3.12, 3.11, 3.10
    • Node.js: Node.js 24, 22, 20
    • Go: Go 1.26, 1.25, 1.24, 1.23, 1.22
    • PHP: PHP 8.5, 8.4, 8.3, 8.2
    • Ruby: Ruby 4.0, 3.4, 3.3, 3.2
  • Deprecated Runtimes (Jan 31, 2026): Python 2.7, Java 8, Go 1.11, PHP 5.5 — these first-generation runtimes are deprecated and will be decommissioned on January 31, 2027
  • First-generation runtimes with legacy bundled services (Memcache, Task Queues, Users API) should be migrated to second-generation runtimes using Cloud Client Libraries

App Engine Scaling

  • App Engine can automatically create and shut down instances as traffic fluctuates, or a number of instances can be specified to run regardless of the amount of traffic
  • App Engine supports the following scaling types, which controls how and when instances are created:
    • Basic (Standard Only)
      • creates instances when the application receives requests.
      • each instance will be shut down when the application becomes idle.
      • is ideal for work that is intermittent or driven by user activity.
    • Automatic
      • creates instances based on request rate, response latencies, and other application metrics.
      • thresholds can be specified for each of these metrics, as well as a minimum number instances to keep running at all times.
      • supports configuring target_cpu_utilization, target_throughput_utilization, min_instances, max_instances, min_pending_latency, and max_pending_latency
    • Manual
      • specifies the number of instances that continuously run regardless of the load level.
      • allows tasks such as complex initializations and applications that rely on the state of the memory over time.

Managing Traffic

App engine allows traffic management to an application version by migrating or splitting traffic.

Traffic Migration

  • Traffic migration smoothly switches request routing
  • Gradually moves traffic from the versions currently receiving traffic to one or more specified versions
  • Standard environment allows you to choose to route requests to the target version, either immediately or gradually.
  • Flexible environment only allows immediate traffic migration

Traffic Splitting

  • Traffic splitting distributes a percentage of traffic to versions of the application.
  • Allows canary deployments or conduct A/B testing between the versions and provides control over the pace when rolling out features
  • Traffic can be split to move 100% of traffic to a single version or to route percentages of traffic to multiple versions.
  • Traffic splitting is applied to URLs that do not explicitly target a version.
  • Traffic split is supported by using either an IP address or HTTP cookie.
  • Default behaviour for splitting traffic is to do it by IP.
  • Setting up IP address traffic split is easier, but a cookie split is more precise
  • For traffic splitting, execute gcloud app deploy --no-promote to make a new version of the application available and then run gcloud app services set-traffic to start sending the new version traffic. Use --splits flag with two versions and weight

App Engine Networking

  • Ingress Settings — control where incoming traffic can originate: all traffic, internal only, or internal + Cloud Load Balancing
  • VPC Connectivity — App Engine standard supports connecting to a VPC using Serverless VPC Access connectors or Direct VPC Egress (preview)
  • Custom Domains — supported via App Engine settings or by using Cloud Load Balancing for advanced routing (recommended for production)
  • Firewall Rules — allow or deny traffic from specified IP ranges
  • Identity-Aware Proxy (IAP) — supported for controlling access to App Engine applications

Migration to Cloud Run

  • Google recommends evaluating Cloud Run for new projects as it provides more flexibility, lower pricing, and advanced features like GPU support
  • The App Engine Migration Center provides comprehensive guidance for transitioning
  • Key advantages of Cloud Run over App Engine:
    • Container-based deployments (any language, any framework)
    • GPU support for AI/ML workloads
    • Multi-region load balancing
    • Sidecar containers
    • Lower cost for idle minimum instances
    • Committed use discounts (CUDs)
    • Services in the same project can be deployed to different regions
    • Cloud Run Invoker IAM role for fine-grained access control
  • Migration paths:
    • Standard environment → Deploy directly to Cloud Run from source
    • Flexible environment → Containerize and deploy to Cloud Run
    • Apps using legacy bundled services should first migrate off those services

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 website hosted on App Engine standard environment. You want 1% of your users to see a new test version of the website. You want to minimize complexity. What should you do?
    1. Deploy the new version in the same application and use the –migrate option.
    2. Deploy the new version in the same application and use the –splits option to give a weight of 99 to the current version and a weight of 1 to the new version.
    3. Create a new App Engine application in the same project. Deploy the new version in that application. Use the App Engine library to proxy 1% of the requests to the new version.
    4. Create a new App Engine application in the same project. Deploy the new version in that application. Configure your network load balancer to send 1% of the traffic to that new application.
  2. You have created an App engine application in the us-central region. However, you found out the network team has configured all the VPN connections in the asia-east2 region, which are not possible to move. How can you change the location efficiently?
    1. Change the region in app.yaml and redeploy
    2. From App Engine console, change the region of the application
    3. Change the region in application.xml within the application and redeploy
    4. Create a new project in the asia-east2 region and create app engine in the project
  3. Your team is deploying a new Python application. You need a serverless platform that supports scale-to-zero, container deployments, and multi-region load balancing. Which Google Cloud service should you use?
    1. App Engine Standard Environment
    2. App Engine Flexible Environment
    3. Cloud Run
    4. Google Kubernetes Engine
  4. You are running a legacy Python 2.7 application on App Engine first-generation runtime. The runtime is deprecated as of January 31, 2026. What is the recommended migration approach?
    1. Continue running on the deprecated runtime as it will be supported indefinitely
    2. Migrate to App Engine flexible environment with Python 2.7
    3. Migrate the application to a second-generation runtime (Python 3.x) and replace legacy bundled services with Cloud Client Libraries, or migrate to Cloud Run
    4. Move the application to Compute Engine with Python 2.7
  5. Your application on App Engine needs to perform background processing tasks between requests. Which configuration should you use?
    1. Automatic scaling with default settings
    2. Basic scaling with idle_timeout set to maximum
    3. Manual scaling, which allows continuous CPU access between requests
    4. Deploy to App Engine flexible environment only
  6. You want to deploy an application that requires services in multiple regions within the same project. Which platform should you choose?
    1. App Engine Standard — deploy services to different regions in the same project
    2. App Engine Flexible — configure multi-region deployment in app.yaml
    3. Cloud Run — services in the same project can be deployed to different regions
    4. App Engine — use traffic splitting across regions

Google Cloud Logging – Setup, Queries & Best Practices [2026]

~ Last updated on : ~ jayendrapatil ~ 2 Comments

Google Cloud Logging

  • Cloud Logging is a fully managed service for storing, searching, analyzing, monitoring, and alerting on log data and events.
  • Answers the questions “Who did what, where and when” within the GCP projects
  • Maintains non-tamperable audit logs for each project and organizations
  • Logs buckets are a regional resource, which means the infrastructure that stores, indexes, and searches the logs are located in a specific geographical location. Google manages that infrastructure so that the applications are available redundantly across the zones within that region.
  • Cloud Logging is scoped by the project.
  • Cloud Logging is integrated with Cloud Monitoring, Error Reporting, and Cloud Trace for end-to-end observability.
  • Previously known as Stackdriver Logging, it is now part of the Google Cloud Observability suite.

Cloud Logging Process

Google Cloud Logging Export

  • For each Google Cloud project, Logging automatically creates two logs buckets: _Required and _Default.
    • _Required bucket
      • holds Admin Activity audit logs, System Event audit logs, and Access Transparency logs
      • retains them for 400 days.
      • the retention period of the logs stored here cannot be modified.
      • aren’t charged for the logs stored in _Required, and
      • cannot delete this bucket.
    • _Default bucket
      • holds all other ingested logs in a Google Cloud project except for the logs held in the _Required bucket.
      • are charged
      • are retained for 30 days, by default, and can be customized from 1 to 3650 days
    • these buckets cannot be deleted
  • All logs generated in the project are stored in the _Required and _Default logs buckets, which live in the project that the logs are generated in
  • Logs buckets only have regional availability, including those created in the global region.
  • User-defined (custom) log buckets can be created for more granular log management
    • Allow custom retention periods (1 to 3650 days)
    • Support CMEK (Customer-Managed Encryption Keys) for encryption
    • Can be upgraded to use Observability Analytics for SQL-based querying
    • Can have linked BigQuery datasets for advanced analytics
    • Cannot be created in folders or organizations

Cloud Logging Types

Cloud Platform Logs

  • Cloud platform logs are service-specific logs that can help troubleshoot and debug issues, as well as better understand the Google Cloud services.
  • Cloud Platform logs are logs generated by GCP services and vary depending on which Google Cloud resources are used in your Google Cloud project or organization.

Security Logs

  • Audit Logs
    • Cloud Audit Logs includes four types of audit logs:
      • Admin Activity,
      • Data Access,
      • System Event, and
      • Policy Denied.
    • Cloud Audit Logs provide audit trails of administrative changes and data accesses of the Google Cloud resources.
      • Admin Activity
        • captures user-initiated resource configuration changes
        • enabled by default
        • no additional charge
        • admin activity – administrative actions and API calls
        • have 400-day retention
      • System Events
        • captures system initiated resource configuration changes
        • enabled by default
        • no additional charge
        • system events – GCE system events like live migration
        • have 400-day retention
      • Data Access logs
        • Log API calls that create, modify or read user-provided data for e.g. object created in a GCS bucket.
        • 30-day retention
        • disabled by default (except BigQuery, which is enabled by default)
        • size can be huge
        • charged beyond free limits
        • Available for GCP-visible services only. Not available for public resources.
      • Policy Denied logs
        • Records when a Google Cloud service denies access to a user or service account because of a security policy violation.
        • Generated by VPC Service Controls, Organization Policies, and other security services when access is denied.
        • Enabled by default
        • Stored in the _Default bucket (30-day retention by default)
        • Can be excluded from ingestion using exclusion filters
        • Log name: cloudaudit.googleapis.com/policy
  • Access Transparency Logs
    • provides logs of actions taken by Google staff when accessing the Google Cloud content.
    • can help track compliance with the organization’s legal and regulatory requirements.
    • have 400-day retention

User Logs

  • User logs are generated by user software, services, or applications and written to Cloud Logging using a logging agent, the Cloud Logging API, or the Cloud Logging client libraries
  • Agent logs
    • produced by logging agent installed that collects logs from user applications and VMs
    • covers log data from third-party applications
    • charged beyond free limits
    • 30-day retention

Cloud Logging Export / Log Router

  • Log entries are stored in logs buckets for a specified length of time i.e. retention period and are then deleted and cannot be recovered
  • The Log Router receives all log entries and routes them through sinks to supported destinations.
  • Logs can be exported by configuring log sinks, which then continue to export log entries as they arrive in Logging.
  • A sink includes a destination and a filter that selects the log entries to export.
  • Exporting involves writing a filter that selects the log entries to be exported, and choosing a destination from the following options:
    • Cloud Storage: JSON files stored in buckets for long term retention
    • BigQuery: Tables created in BigQuery datasets for analytics
    • Pub/Sub: JSON messages delivered to Pub/Sub topics to stream to other resources. Supports third-party integrations, such as Splunk
    • Cloud Logging bucket: Log entries held in another Cloud Logging logs bucket (including in another project).
  • Every time a log entry arrives in a project, folder, billing account, or organization resource, Logging compares the log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink’s export destination.
  • Exporting happens for new log entries only, it is not retrospective.
    • However, Batch and Route Retroactively (Copy Logs) feature now allows copying existing logs stored in log buckets to supported destinations retroactively.
  • Exclusion Filters can be added to sinks to exclude matching log entries from being ingested or routed, helping reduce costs.

Aggregated Sinks

  • Aggregated sinks let you route logs from an organization or folder to a supported destination.
  • Can be configured as intercepting or non-intercepting:
    • Intercepting sink: prevents log entries from being routed to sinks in child resources (except _Required sinks). Gives centralized control over log routing.
    • Non-intercepting sink: routes matching log entries to the destination but does not prevent child resource sinks from also routing those entries.
  • Useful for centralized log storage and compliance across organizations.

Observability Analytics (formerly Log Analytics)

  • Observability Analytics lets you search, aggregate, and analyze logs using SQL queries directly in the Cloud Console.
  • Provides a SQL editor and a menu-based system for building queries.
  • Query results can be viewed in tabular form or visualized as charts.
  • Charts can be saved to custom dashboards.
  • Supports querying log views on log buckets and Analytics Views.
  • Analytics Views allow transforming log data from the LogEntry format into a custom schema more suitable for specific use cases.
  • Can also be used to query trace data for correlated observability.
  • Linked BigQuery Datasets:
    • Not required for basic log querying — Observability Analytics handles that directly.
    • Required when you want to: join log data with other BigQuery datasets, query from BigQuery Studio or Looker Studio, or run queries on BigQuery reserved slots for better performance.
  • SQL-based alerting policies can be configured to monitor query results and trigger alerts.
  • Log buckets need to be upgraded to use Observability Analytics.

Log Scopes

  • Log scopes are named collections of log views that span the same or different projects.
  • Control which resources the Logs Explorer searches for log data.
  • Enable multi-project log querying from a single view.
  • Made up of groups of log views that control and grant permissions to a subset of logs in a log bucket.
  • Useful for teams that need access to logs across multiple projects without switching between them.

Log-based Metrics

  • Log-based metrics are based on the content of log entries for e.g., the metrics can record the number of log entries containing particular messages, or they can extract latency information reported in log entries.
  • Log-based metrics can be used in Cloud Monitoring charts and alerting policies.
  • Log-based metrics are of two kinds
    • System-defined log-based metrics
      • provided by Cloud Logging for use by all Google Cloud projects.
      • System log-based metrics are calculated from included logs only i.e. they are calculated only from logs that have been ingested by Logging. If a log has been explicitly excluded from ingestion by Logging, it isn’t included in these metrics.
    • User-defined log-based metric
      • user-created to track things in the Google Cloud project for e.g. a log-based metric to count the no. of log entries that match a given filter.
      • User-defined log-based metrics are calculated from both included and excluded logs. i.e. are calculated from all logs received by the Logging API for the Cloud project, regardless of any inclusion filters or exclusion filters that may apply to the Cloud project.
  • Log-based metrics can be project-scoped or bucket-scoped:
    • Project-scoped: apply to a single Google Cloud project (traditional behavior)
    • Bucket-scoped: created on a specific log bucket, allowing metrics on logs from multiple projects stored in one bucket
  • Log-based metrics support the following types
    • Counter metrics count the number of log entries matching a given filter.
    • Distribution metrics accumulate numeric data from log entries matching a filter.

Cloud Logging Agent / Ops Agent

⚠️ Legacy Logging Agent Deprecated: The legacy Cloud Logging Agent (fluentd-based) is deprecated. While still supported, Google recommends against using it for new workloads. Use the Ops Agent for all new deployments and plan migration for existing VMs.

Ops Agent (Recommended)

  • The Ops Agent is the recommended agent for collecting logs and metrics from Compute Engine VMs.
  • Sends logs to Cloud Logging and metrics to Cloud Monitoring from a single unified agent.
  • Built on Fluent Bit (for logs) and the OpenTelemetry Collector (for metrics), providing better performance and resource efficiency.
  • Features:
    • Simple, unified YAML-based configuration
    • Support for standard Linux and Windows distros
    • Proxy support
    • OTLP receiver for collecting OpenTelemetry metrics, traces, and logs from instrumented applications
    • Supports 40+ third-party application integrations (Apache, MySQL, PostgreSQL, MongoDB, Nginx, etc.)
    • High throughput with efficient resource management
  • Telemetry API (Preview, May 2026): Starting with Ops Agent v2.66.0, logs and metrics can be exported using the OpenTelemetry-based Telemetry API instead of the proprietary Cloud Logging API and Cloud Monitoring API.
  • OTLP Log Ingestion (April 2026): OTLP-formatted logs can now be ingested into Cloud Logging using an OpenTelemetry Collector, an OTLP exporter, and the Telemetry API.
  • Can be installed on individual VMs, via VM Extension Manager policies, or via agent policies on a fleet of VMs.

Legacy Logging Agent (Deprecated)

  • Cloud Logging Agent streams logs from VM instances and from selected third-party software packages to Cloud Logging.
  • Helps capture logs from GCE and AWS EC2 instances.
  • VM images for GCE and Amazon EC2 don’t include the Logging agent and must be installed explicitly.
  • Uses fluentd for capturing logs.
  • No new feature development or support for new operating systems.
  • The legacy installation script (install-logging-agent.sh) is deprecated.
  • Migration to Ops Agent is recommended for all existing workloads.

Cloud Logging MCP Server (GA – April 2026)

  • The Cloud Logging API MCP (Model Context Protocol) server allows AI agents and LLM-powered applications to interact with log entries programmatically.
  • Enabled automatically when the Cloud Logging API is enabled in a project.
  • Standardizes how large language models connect to Cloud Logging as an external data source.
  • Supports enterprise-grade security through Cloud IAM and is integrated with Cloud Audit Logs for monitoring agent activity.
  • Useful for AI-powered troubleshooting, automated incident response, and log analysis workflows.

Abuse Event Logging (January 2025)

  • Google Cloud customers can track Cloud Abuse Events using Cloud Logging.
  • Events include:
    • Leaked service account keys
    • Crypto mining incidents
    • Malware detection
  • Enables automated incident remediation through integration with Security Command Center and Cloud Functions.
  • Helps organizations detect and respond to security threats faster.

Cloud Logging IAM Roles

  • Logs Viewer (roles/logging.viewer) – View logs except Data Access/Access Transparency logs
  • Private Logs Viewer (roles/logging.privateLogViewer) – View all logs including Data Access logs
  • Logging Admin (roles/logging.admin) – Full access to all logging actions
  • Logs Writer (roles/logging.logWriter) – Write log entries
  • Logs Bucket Writer (roles/logging.bucketWriter) – Write logs to a specific bucket
  • Project Viewer – View logs except Data Access/Access Transparency logs
  • Project Editor – Write, view, and delete logs. Create log based metrics. However, it cannot create export sinks or view Data Access/Access Transparency logs.
  • Project Owner – Full access to all logging actions

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 organization is a financial company that needs to store audit log files for 3 years. Your organization has hundreds of Google Cloud projects. You need to implement a cost-effective approach for log file retention. What should you do?
    1. Create an export to the sink that saves logs from Cloud Audit to BigQuery.
    2. Create an export to the sink that saves logs from Cloud Audit to a Coldline Storage bucket.
    3. Write a custom script that uses logging API to copy the logs from Cloud Logging to BigQuery.
    4. Export these logs to Cloud Pub/Sub and write a Dataflow pipeline to store logs to Cloud SQL.
  2. A company needs to analyze Cloud Logging data to detect security threats across 50 projects. They want to use SQL queries and visualize the results in dashboards. What approach should they use?
    1. Export logs from all projects to BigQuery using individual sinks per project.
    2. Create an aggregated sink to route logs to a central log bucket, upgrade to Observability Analytics, and use SQL queries with dashboard charts.
    3. Use the Logging API to programmatically read logs from each project.
    4. Create log-based metrics in each project and use Cloud Monitoring dashboards.
  3. Your security team wants to be alerted when VPC Service Controls denies access to resources. Which type of audit log should they monitor?
    1. Admin Activity audit logs
    2. Data Access audit logs
    3. System Event audit logs
    4. Policy Denied audit logs
  4. You are deploying a new application on Compute Engine and need to collect application logs and system metrics. Which agent should you install?
    1. Legacy Cloud Logging Agent
    2. Legacy Cloud Monitoring Agent
    3. Ops Agent
    4. OpenTelemetry Collector only
  5. Your organization needs to centrally control log routing and prevent individual projects from routing certain logs to their own destinations. What should you configure?
    1. Exclusion filters on each project’s _Default sink
    2. Organization policy constraints on logging
    3. An intercepting aggregated sink at the organization level
    4. A non-intercepting aggregated sink at the folder level
  6. A company wants to query log data from Cloud Logging using BigQuery Studio and join it with data from other BigQuery datasets. What do they need to configure?
    1. Export logs to BigQuery using a sink
    2. Use Observability Analytics SQL queries directly
    3. Upgrade the log bucket to use Observability Analytics and create a linked BigQuery dataset
    4. Create a scheduled query in BigQuery to import logs
  7. Which of the following statements about Cloud Audit Logs are correct? (Choose 2)
    1. Admin Activity and System Event logs are enabled by default and cannot be disabled.
    2. Data Access logs are enabled by default for all services.
    3. Policy Denied logs record when access is denied due to VPC Service Controls or Organization Policies.
    4. All audit log types are stored in the _Required bucket with 400-day retention.

Reference

Google Cloud SQL – Managed MySQL, PostgreSQL & SQL

~ Last updated on : ~ jayendrapatil

GCP Cloud SQL

  • Cloud SQL provides a cloud-based alternative to local MySQL, PostgreSQL, and Microsoft SQL Server databases
  • Cloud SQL is a managed solution that helps handle backups, replication, high availability and failover, data encryption, monitoring, and logging.
  • Cloud SQL is ideal for lift and shift migration from existing on-premises relational databases
  • Cloud SQL supports MySQL 5.6, 5.7, 8.0, 8.4, PostgreSQL (multiple versions), and SQL Server 2019, 2022, 2025

Cloud SQL Editions

  • Cloud SQL offers two editions: Cloud SQL Enterprise Plus and Cloud SQL Enterprise
  • Cloud SQL Enterprise Plus edition
    • Provides the best performance, availability, and observability for business-critical applications
    • Delivers up to 4x improved read performance using Data Cache (local SSD)
    • Delivers up to 3x higher write throughput and up to 98% lower write latency with Optimized Writes
    • Offers 99.99% availability SLA (inclusive of maintenance)
    • Provides near-zero downtime (<1 second) for planned maintenance and operations
    • Supports up to 128 vCPUs and 864 GB RAM (N2 machine series)
    • Supports Advanced Disaster Recovery with cross-region replication, switchover, and failover
    • Supports Read Pools with autoscaling for operational simplicity
    • Supports Managed Connection Pooling
    • Supports up to 35 days PITR log retention
    • Provides AI-assisted troubleshooting, enhanced Query Insights (30-day retention), and Index Advisor
    • Supports MySQL 8.0, 8.4 (MySQL 8.4 defaults to Enterprise Plus)
  • Cloud SQL Enterprise edition
    • Provides all core capabilities of Cloud SQL at a lower cost
    • Suitable for applications with less stringent availability and performance requirements
    • Offers 99.95% availability SLA (excludes maintenance)
    • Maintenance downtime of <60 seconds
    • Supports up to 7 days PITR log retention
    • Supports MySQL 5.6, 5.7, 8.0, 8.4
  • All existing Cloud SQL instances created before July 12, 2023 were automatically updated to Cloud SQL Enterprise edition
  • You can upgrade to Enterprise Plus edition using in-place upgrade with near-zero downtime

Cloud SQL High Availability

  • Cloud SQL instance HA configuration provides data redundancy and failover capability with minimal downtime, when a zone or instance becomes unavailable due to a zonal outage, or an instance corruption
  • HA configuration is also called a regional instance or cluster
  • With HA, the data continues to be available to client applications.
  • HA is made up of a primary and a standby instance and is located in a primary and secondary zone within the configured region
  • If an HA-configured instance becomes unresponsive, Cloud SQL automatically switches to serving data from the standby instance.
  • Data is synchronously replicated to each zone’s persistent disk, all writes made to the primary instance are replicated to disks in both zones before a transaction is reported as committed.
  • In the event of an instance or zone failure, the persistent disk is attached to the standby instance, and it becomes the new primary instance.
  • After a failover, the instance that received the failover continues to be the primary instance, even after the original instance comes back online.
  • Once the zone or instance that experienced an outage becomes available again, the original primary instance is destroyed and recreated and It becomes the new standby instance.
  • If a failover occurs in the future, the new primary will failover to the original instance in the original zone.
  • Cloud SQL Standby instance does not increase scalability and cannot be used for read queries
  • To see if failover has occurred, check the operation log’s failover history.
  • Write Endpoint (Enterprise Plus) – provides a DNS name that automatically resolves to the current primary instance IP, so applications don’t need to update connection strings after failover.

Cloud SQL High Availability

Cloud SQL Failover Process

  • Each second, the primary instance writes to a system database as a heartbeat signal.
  • Primary instance or zone fails.
  • If multiple heartbeats aren’t detected, failover is initiated. This occurs if the primary instance is unresponsive for approximately 60 seconds or the zone containing the primary instance experiences an outage.
  • Standby instance now serves data upon reconnection.
  • Through a shared static IP address with the primary instance, the standby instance now serves data from the secondary zone.
  • Users are then automatically rerouted to the new primary.

Cloud SQL Advanced Disaster Recovery

  • Advanced Disaster Recovery (DR) is available exclusively on Cloud SQL Enterprise Plus edition
  • Allows configuring cross-regional replication with a designated DR replica
  • Provides Replica Failover — promotes the DR replica immediately in the event of a regional failure
  • Provides Switchover — reverses the roles of the primary instance and a DR replica with zero data loss
  • Switchover can be used to restore a deployment to its original state after replica failover, or to test DR readiness
  • The DR replica is a cross-region read replica designated for disaster recovery
  • Uses a write endpoint to automatically redirect application traffic to the new primary after failover or switchover
  • Reduces RTO (Recovery Time Objective) significantly compared to manual promotion of cross-region replicas

Cloud SQL Read Replica

  • Read replicas help scale horizontally the use of data in a database without degrading performance
  • Read replica is an exact copy of the primary instance. Data and other changes on the primary instance are updated in almost real time on the read replica.
  • Read replica can be promoted if the original instance becomes corrupted.
  • Primary instance and read replicas all reside in Cloud SQL
  • Read replicas are read-only; you cannot write to them
  • Read replicas do not provide failover capability (use HA or Advanced DR instead)
  • Read replicas can now be configured with high availability for increased resilience
  • Google recommends limiting direct read replicas to 10 or fewer per primary instance. For additional replicas, use cascading read replicas.
  • During a zonal outage, traffic to read replicas in that zone stops.
  • Once the zone becomes available again, any read replicas in the zone will resume replication from the primary instance.
  • If read replicas are in a zone that is not in an outage, they are connected to the standby instance when it becomes the primary instance.
  • GCP recommends putting read replicas in a different zone from the primary and standby instances. for e.g., if you have a primary instance in zone A and a standby instance in zone B, put the read replicas in zone C. This practice ensures that read replicas continue to operate even if the zone for the primary instance goes down.
  • Client application needs to be configured to send reads to the primary instance when read replicas are unavailable.
  • Cloud SQL supports Cross-region replication that lets you create a read replica in a different region from the primary instance.
  • Cloud SQL supports External read replicas that are external MySQL instances which replicate from a Cloud SQL primary instance
  • Read replicas can have different vCPUs and memory from the primary instance but must have at least as much storage capacity.

Cascading Read Replicas

  • Cascading replication lets you create a read replica under another read replica in the same or a different region
  • Supports up to 4 levels of replicas in the hierarchy (including the primary instance)
  • A cascading replica can have up to 8 siblings (replicas from the same parent)
  • Use cases:
    • Disaster Recovery — cascading replicas in another region retain their own replicas when promoted
    • Performance — offloads replication work from the primary instance
    • Cost Reduction — only one cross-region replication incurs network egress; sub-replicas use free in-region transfer
    • Scale Reads — more replicas to share read load without burdening the primary
  • When a cascading replica is promoted, all its sub-replicas continue to replicate from it
  • You cannot delete a replica that has replicas under it; must start with leaf replicas

Read Pools (Enterprise Plus)

  • Read Pools provide a simplified, fully managed way to scale reads using multiple read replicas behind a single read endpoint
  • Available exclusively on Cloud SQL Enterprise Plus edition for MySQL and PostgreSQL
  • A read pool contains between 1 and 20 read pool nodes
  • Provides a single load balancer (read endpoint) that dispatches queries to nodes in round-robin fashion
  • Supports autoscaling — automatically adds or removes read pool nodes based on workload
  • You can add and remove replicas without making application changes
  • Simplifies connection management for read-heavy applications

Cloud SQL Point In Time Recovery

  • Point-in-time recovery (PITR) helps recover a Cloud SQL instance to a specific point in time
  • PITR uses write-ahead logs (for PostgreSQL) or binary logs (for MySQL)
  • PITR requires backups to be enabled for the instance
  • Point-in-time recovery is enabled by default when a new Cloud SQL instance is created
  • Log retention:
    • Cloud SQL Enterprise Plus edition: up to 35 days
    • Cloud SQL Enterprise edition: up to 7 days
  • Transaction logs are stored in the same region as the instance at no additional cost
  • PITR logs are stored in Cloud Storage (no longer on instance storage), eliminating storage impact on the instance

Cloud SQL Auth Proxy

  • Cloud SQL Auth Proxy (formerly known as Cloud SQL Proxy) provides secure access to instances without the need for Authorized networks or for configuring SSL.
    • Secure connections: Automatically encrypts traffic to and from the database using TLS 1.3 with a 256-bit AES cipher; SSL certificates are used to verify client and server identities.
    • Easier connection management: Handles authentication via IAM, removing the need to provide static IP addresses or manage SSL certificates.
    • IAM-based authorization: Uses IAM permissions to control which identities can connect to an instance.
  • Cloud SQL Auth Proxy does not provide a new connectivity path; it relies on existing IP connectivity. To connect to a Cloud SQL instance using private IP, the Cloud SQL Auth Proxy must be on a resource with access to the same VPC network as the instance.
  • Cloud SQL Auth Proxy works by having a local client running in the local environment. The application communicates with the Cloud SQL Auth Proxy with the standard database protocol used by the database.
  • Cloud SQL Auth Proxy uses a secure tunnel to communicate with its companion process running on the server.
  • While the proxy can listen on any port, it only creates outgoing connections to the Cloud SQL instance on port 3307.
  • For GKE deployments, the recommended pattern is running the Auth Proxy as a sidecar container in the same pod as the application.

Cloud SQL Auth Proxy

Cloud SQL Connectivity Options

  • Public IP — connect over the internet with authorized networks or Cloud SQL Auth Proxy
  • Private IP (Private Services Access) — connect using an internal IP address via VPC peering
  • Private Service Connect (PSC) — connect to Cloud SQL from multiple VPC networks across different projects, teams, or organizations without VPC peering
    • PSC provides a service attachment endpoint with a dedicated private IP
    • Works with both primary instances and read replicas
    • Can be combined with Private Services Access on the same instance
    • PSC Automation (Preview) simplifies deployment of PSC endpoints at scale
  • Cloud SQL Auth Proxy — IAM-authenticated, encrypted connections without managing SSL certificates or IP allowlists
  • Cloud SQL Language Connectors — open-source libraries for Java, Python, Go, and Node.js for simplified and secure connectivity
  • Managed Connection Pooling (Enterprise Plus) — built-in connection pooling to optimize database connection management

Cloud SQL AI and Vector Search

  • Cloud SQL integrates with Vertex AI to bring AI capabilities directly to your database
  • Supports generating vector embeddings using simple SQL functions (no external pipeline needed)
  • Supports vector storage and similarity search for MySQL and PostgreSQL, enabling gen AI use cases without a specialized vector database
  • Can invoke Vertex AI models (including Gemini) directly from SQL for online predictions
  • Supports building LLM-powered applications using LangChain integration
  • Supports Model Endpoint Management — register, invoke, and manage AI models from within Cloud SQL
  • Enables RAG (Retrieval-Augmented Generation) workflows with vector search capabilities

Cloud SQL Features Comparison

Cloud SQL Features Comparison

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 work for a mid-sized enterprise that needs to move its operational system transaction data from an on-premises database to GCP. The database is about 20 TB in size. Which database should you choose?
    1. Cloud SQL
    2. Cloud Bigtable
    3. Cloud Spanner
    4. Cloud Datastore
  2. An application that relies on Cloud SQL to read infrequently changing data is predicted to grow dramatically. How can you increase capacity for more read-only clients?
    1. Configure high availability on the master node
    2. Establish an external replica in the customer’s data center
    3. Use backups so you can restore if there’s an outage
    4. Configure read replicas.
  3. A Company is using Cloud SQL to host critical data. They want to enable high availability in case a complete zone goes down. How should you configure the same?
    1. Create a Read replica in the same region different zone
    2. Create a Read replica in the different region different zone
    3. Create a Failover replica in the same region different zone
    4. Create a Failover replica in the different region different zone
  4. A Company is using Cloud SQL to host critical data. They want to enable Point In Time recovery (PIT) to be able to recover the instance to a specific point in time. How should you configure the same?
    1. Create a Read replica for the instance
    2. Switch to Spanner 3 node cluster
    3. Create a Failover replica for the instance
    4. Enable Binary logging and backups for the instance
  5. A company needs a Cloud SQL deployment that provides 99.99% availability SLA inclusive of maintenance window downtime. Which configuration should they choose?
    1. Cloud SQL Enterprise edition with HA enabled
    2. Cloud SQL Enterprise edition with read replicas in multiple zones
    3. Cloud SQL Enterprise Plus edition with HA enabled
    4. Cloud SQL Enterprise Plus edition with read replicas only
  6. A company wants to set up cross-region disaster recovery for their Cloud SQL database with the ability to perform switchover drills with zero data loss. What should they use?
    1. Cross-region read replicas with manual promotion
    2. Cloud SQL Enterprise Plus edition with Advanced Disaster Recovery
    3. Cloud SQL Enterprise edition with automated backups in another region
    4. Cloud Spanner with multi-region configuration
  7. A company wants to scale read traffic for their Cloud SQL MySQL database by adding multiple read replicas that can be accessed via a single endpoint and auto-scaled based on demand. What feature should they use?
    1. Cross-region read replicas with DNS load balancing
    2. Cascading read replicas in the same region
    3. Cloud SQL Read Pools (Enterprise Plus)
    4. External read replicas with a custom load balancer
  8. An organization wants to connect to a Cloud SQL instance from multiple VPCs across different projects without using VPC peering. Which connectivity option should they choose?
    1. Cloud SQL Auth Proxy with public IP
    2. Private Services Access with shared VPC
    3. Private Service Connect (PSC)
    4. Authorized networks with IP allowlisting

See also: Google Cloud Storage Services Cheat Sheet

References

 

Google Cloud Storage & Database Options Comparison

~ Last updated on : ~ jayendrapatil ~ 2 Comments

GCP Storage Options

GCP provides various storage options and the selection can be based on

  • Structured vs Unstructured
  • Relational (SQL) vs Non-Relational (NoSQL)
  • Transactional (OLTP) vs Analytical (OLAP)
  • Fully Managed vs Requires Provisioning
  • Global vs Regional
  • Horizontal vs Vertical scaling

Cloud Firestore

  • Cloud Firestore is a fully managed, highly scalable, serverless, non-relational NoSQL document database
  • fully managed with no-ops and no planned downtime and no need to provision database instances (vs Bigtable)
  • uses a distributed architecture to automatically manage scaling.
  • queries scale with the size of the result set, not the size of the data set
  • supports ACID Atomic transactions – all or nothing (vs Bigtable)
  • provides High availability of reads and writes – runs in Google data centers, which use redundancy to minimize impact from points of failure.
  • provides massive scalability with high performance – uses a distributed architecture to automatically manage scaling.
  • scales from zero to terabytes with flexible storage and querying of data
  • provides SQL-like query language
  • supports strong consistency
  • supports data encryption at rest and in transit
  • provides terabytes of capacity with a maximum unit size of 1 MB per entity (vs Bigtable)
  • Firestore Editions (2025)
    • Standard edition – core Firestore capabilities with standard querying support
    • Enterprise edition – provides MongoDB API compatibility, a new pipeline query engine with 200+ query operations, additional data types, new index types, and text/geospatial search
  • Enterprise Edition Features
    • MongoDB Compatibility (GA Aug 2025) – use existing MongoDB application code, drivers, and tools as a drop-in replacement while getting Firestore’s auto-scaling and high availability
    • Pipeline Query Engine – supports 200+ new query capabilities (pipeline operations) for complex queries directly within the database
    • Text Search and Geospatial Search – native full-text and geospatial query support without external services
    • Maximum document size increased to 16 MiB (Enterprise edition)
    • Indexes are not required for queries in Enterprise edition
  • Consider using Cloud Firestore if you need to store semi-structured objects, or if require support for transactions and SQL-like queries.

Cloud Bigtable

  • Bigtable provides a scalable, fully managed, non-relational NoSQL wide-column analytical big data database service suitable for both low-latency single-point lookups and precalculated analytics.
  • supports large quantities (>1 TB) of semi-structured or structured data (vs Datastore)
  • supports high throughput or rapidly changing data (vs BigQuery)
  • managed, but needs provisioning of nodes and can be expensive (vs Datastore and BigQuery)
  • does not support transactions or strong relational semantics (vs Datastore)
  • Now supports GoogleSQL queries (GA 2024) – familiar SQL syntax for querying Bigtable data directly
  • Not Transactional and does not support ACID
  • provides eventual consistency
  • ideal for time-series or natural semantic ordering data
  • can run asynchronous batch or real-time processing on the data
  • can run machine learning algorithms on the data
  • provides petabytes of capacity with a maximum unit size of 10 MB per cell and 100 MB per row.
  • Bigtable Editions (GA April 2026)
    • Enterprise edition – advanced features in performance, analytic query capability, and resource management
    • Enterprise Plus edition – includes in-memory tier with sub-millisecond latency and hotspot resistance supporting up to 120,000 queries per second on a single row
  • New Features (2024-2026)
    • Bigtable SQL (GoogleSQL) – query data using familiar SQL syntax with specialized features preserving flexible schema
    • Data Boost – serverless analytical queries without impacting operational workloads
    • Incremental Materialized Views – simplify creation of real-time metrics
    • Window Functions (GA April 2026) – advanced analytic operations over multiple table rows
    • KNN Vector Search – K nearest neighbors similarity search for AI/ML use cases
    • Distributed Counting – instant metric retrieval for real-time dashboards
    • In-Memory Tier – hotspot resistance with sub-millisecond latency
    • Agent Skills (April 2026) – let AI agents assist with schema design, SQL queries, and infrastructure management
  • Usage Patterns
    • Low-latency read/write access
    • High-throughput data processing
    • Time series support
  • Anti Patterns
    • Not an ideal storage option for future analysis – Use BigQuery instead
    • Not an ideal storage option for transactional data – Use relational database or Datastore
  • Common Use cases
    • IoT, finance, adtech
    • Personalization, recommendations
    • Monitoring
    • Geospatial datasets
    • Graphs
    • Real-time AI/ML inference and vector search
  • Consider using Cloud Bigtable, if you need high-performance datastore to perform analytics on a large number of structured objects

Cloud Storage

  • Cloud Storage provides durable and highly available object storage.
  • fully managed, simple administration, cost-effective, and scalable service that does not require capacity management
  • supports unstructured data storage like binary or raw objects
  • provides high performance, internet-scale
  • supports data encryption at rest and in transit
  • provides 99.999999999% (11 nines) annual durability
  • Storage Classes: Standard, Nearline (30-day min), Coldline (90-day min), Archive (365-day min)
  • Autoclass – automatically transitions objects to appropriate storage classes based on access patterns
  • New Features (2024-2026)
    • Cloud Storage Rapid (2025-2026) – high-performance storage tier for AI/ML workloads
      • Rapid Bucket (formerly Rapid Storage) – zonal object storage with <1ms random read/write latency, 6 TB/s throughput
      • Rapid Cache (formerly Anywhere Cache) – accelerates reads and colocates compute with data, up to 20 Tbps throughput
    • Smart Storage – automated metadata annotation for unstructured data with AI agent connectivity via MCP
    • Storage Intelligence – zero-configuration dashboards, aggregated activity views, and enhanced batch operations
    • Bucket Relocation – move buckets between regions with minimal downtime
    • Batch Operations Dry Run Mode – simulate batch jobs without modifying data
  • Consider using Cloud Storage, if you need to store immutable blobs larger than 10 MB, such as large images or movies. This storage service provides petabytes of capacity with a maximum unit size of 5 TB per object.
  • Usage Patterns
    • Images, pictures, and videos
    • Objects and blobs
    • Unstructured data
    • Long term storage for archival or compliance
    • AI/ML training data and model checkpoints
  • Anti Patterns
    • Not ideal for structured/relational data
    • Not ideal for frequently changing data requiring low-latency updates
  • Common Use cases
    • Storing and streaming multimedia
    • Storage for custom data analytics pipelines
    • Archive, backup, and disaster recovery
    • AI/ML training datasets and model serving

Cloud SQL

  • provides fully managed, relational SQL databases
  • offers MySQL, PostgreSQL, and SQL Server databases as a service
  • manages OS & Software installation, patches and updates, backups and configuring replications, failover however needs to select and provision machines (vs Cloud Spanner)
  • single region only – although it now supports cross-region read replicas (vs Cloud Spanner)
  • Cloud SQL Editions
    • Enterprise edition – core capabilities, suitable for applications with less stringent availability/performance requirements. Up to 96 vCPU, 624 GB RAM.
    • Enterprise Plus edition – highest performance with optimized software/hardware stack. Up to 128 vCPU, 864 GB RAM. Includes data cache, up to 35-day point-in-time log retention, sub-second maintenance downtime, and advanced disaster recovery.
  • Scaling
    • provides vertical scalability (Max. storage of 64 TB)
    • storage can be increased without incurring any downtime
    • provides an option to increase the storage automatically
    • storage CANNOT be decreased
    • supports Horizontal scaling for read-only using read replicas (vs Cloud Spanner)
    • performance is linked to the disk size
  • Security
    • data is encrypted when stored in database tables, temporary files, and backups.
    • external connections can be encrypted by using SSL, or by using the Cloud SQL Proxy.
    • Private Service Connect (PSC) support for simplified private connectivity
  • High Availability
    • fault-tolerance across zones can be achieved by configuring the instance for high availability by adding a failover replica
    • failover is automatic
    • can be created from primary instance only
    • replication from the primary instance to failover replica is semi-synchronous.
    • failover replica must be in the same region as the primary instance, but in a different zone
    • only one instance for every primary instance allowed
    • supports managed backups and backups are created on primary instance only
    • supports automatic replication
    • Enterprise Plus: sub-second maintenance downtime (vs up to 120 seconds for Enterprise)
  • Backups
    • Automated backups can be configured and are stored for 7 days
    • Manual backups (snapshots) can be created and are not deleted automatically
    • Fast Clone (GA) – clone operations within the same zone for rapid environment creation
  • Point-in-time recovery
    • requires binary logging enabled.
    • every update to the database is written to an independent log, which involves a small reduction in write performance.
    • performance of the read operations is unaffected by binary logging, regardless of the size of the binary log files.
    • Enterprise Plus: up to 35-day log retention (vs 7 days for Enterprise)
  • Usage Patterns
    • direct lift and shift for MySQL, PostgreSQL, SQL Server database only
    • relational database service with strong consistency
    • OLTP workloads
  • Anti Patterns
    • need data storage more than 64 TB or horizontal write scaling, use Cloud Spanner
    • need global availability with low latency, use Cloud Spanner
    • not a direct replacement for Oracle – use installation on GCE or consider AlloyDB for PostgreSQL workloads
  • Common Use cases
    • Websites, blogs, and content management systems (CMS)
    • Business intelligence (BI) applications
    • ERP, CRM, and eCommerce applications
    • Geospatial applications
  • Consider using Cloud SQL for full relational SQL support for OLTP and lift and shift of MySQL, PostgreSQL, SQL Server databases

Cloud Spanner

  • Cloud Spanner provides fully managed, relational SQL databases with joins and secondary indexes
  • provides cross-region, global, horizontal scalability, and availability
  • supports strong consistency, including strongly consistent secondary indexes
  • provides high availability through synchronous and built-in data replication.
  • provides strong global consistency
  • supports database sizes exceeding ~2 TB (vs Cloud SQL)
  • does not provide direct lift and shift for relational databases (vs Cloud SQL)
  • expensive as compared to Cloud SQL
  • Multi-Model Database (2024-2025)
    • Spanner Graph (GA Jan 2025) – supports industry-standard Graph Query Language (GQL) with full SQL interoperability for querying structured and connected data
    • Vector Search – native vector embeddings and similarity search for AI/ML and RAG applications
    • Full-Text Search – native text search capabilities without external services
    • Hybrid Search – combine vector search, full-text search, and ML model reranking in a unified platform
    • Vertex AI Integration – native integration for model serving and inferencing with SQL
  • Spanner Omni (2026 Preview)
    • Self-managed version of Spanner that runs on-premises, across clouds, or on a laptop
    • Brings Spanner’s scalability, high availability, strong consistency, and multi-model capabilities anywhere
    • Supports air-gapped or connected deployments, single machine to clusters of thousands
  • Tiered Storage (GA) – store data across SSD or HDD tiers for cost optimization
  • Consider using Cloud Spanner for full relational SQL support, with horizontal scalability spanning petabytes for OLTP, or as a multi-model database supporting relational, graph, vector, and text search workloads

BigQuery

  • provides fully managed, no-ops, OLAP, enterprise data warehouse (EDW) with SQL and fast ad-hoc queries.
  • provides high capacity, data warehousing analytics solution
  • ideal for big data exploration and processing
  • not ideal for operational or transactional databases
  • provides SQL interface
  • A scalable, fully managed data-to-AI platform
  • BigQuery Editions – Standard, Enterprise, and Enterprise Plus with different pricing and feature tiers
  • New Features (2024-2026)
    • Conversational Analytics (Preview Jan 2026) – analyze data using natural language with AI-powered data agents that understand context and generate SQL
    • BigQuery Graph – uncover complex relationships and patterns in data
    • Vector Search – embeddings and hybrid search for RAG applications
    • BigQuery ML – train and run ML models directly in BigQuery using SQL
    • Data Engineering Agent – automates data preparation, error detection, and pipeline building
    • Data Science Agent – automates data loading, feature engineering, model training and evaluation
    • BigQuery Studio – unified workspace with Gemini-powered assistant for resource discovery and query generation
    • MCP Integration – Model Context Protocol for AI agent connectivity
  • Usage Patterns
    • OLAP workloads up to petabyte-scale
    • Big data exploration and processing
    • Reporting via business intelligence (BI) tools
    • AI/ML model training and inference at scale
  • Anti Patterns
    • Not an ideal storage option for transactional data or OLTP – Use Cloud SQL or Cloud Spanner instead
    • Low-latency read/write access – Use Bigtable instead
  • Common Use cases
    • Analytical reporting on large data
    • Data science and advanced analyses
    • Big data processing using SQL
    • GenAI and agentic AI applications with data

AlloyDB for PostgreSQL

  • AlloyDB is a fully managed, PostgreSQL-compatible database designed for enterprise-grade OLTP and hybrid transactional/analytical (HTAP) workloads
  • wire-compatible with PostgreSQL 14 and 15 – existing drivers, ORMs, and most extensions work without modification
  • provides up to 4x faster for transactional workloads and up to 100x faster for analytical queries compared to standard PostgreSQL
  • uses a scale-out architecture with compute and storage separation
  • built-in AI capabilities with Google’s cutting-edge technology
  • AlloyDB AI
    • Generate vector embeddings from within the database
    • Native vector search with up to 10x faster index creation and 4x faster search queries
    • Filtered vector search up to 10x faster than standard PostgreSQL HNSW
    • Integration with Vertex AI for model serving and inferencing
    • AlloyDB AI query engine with Vertex AI Ranking API
  • AlloyDB Omni – downloadable version that runs on-premises or in other clouds
  • 99.99% availability SLA with automated backups, replication, and failover
  • Usage Patterns
    • Enterprise PostgreSQL workloads requiring high performance
    • HTAP (hybrid transactional/analytical) workloads
    • AI-powered applications requiring vector search
    • Migration from commercial databases (Oracle, SQL Server) to PostgreSQL
  • Anti Patterns
    • Need global horizontal scaling – Use Cloud Spanner
    • Need non-relational/NoSQL – Use Firestore or Bigtable
    • Need MySQL or SQL Server compatibility – Use Cloud SQL
  • Consider using AlloyDB for PostgreSQL workloads requiring high performance, AI integration, or migration from commercial databases

Memorystore

  • provides scalable, secure, and highly available in-memory service
  • fully managed as provisioning, replication, failover, and patching are all automated
  • is protected from the internet using VPC networks and private IP and comes with IAM integration
  • Supported Engines
    • Memorystore for Valkey (GA 2025) – open-source, high-performance key-value store (successor to Redis OSS). Supports Valkey 8.0 and 9.0. 99.99% availability SLA, instances up to 14.5 TB, cross-region replication, Private Service Connect, multi-VPC access.
    • Memorystore for Redis Cluster – managed Redis cluster mode with zero-downtime scaling
    • Memorystore for Redis – standard Redis instances (standalone and high availability)
    • Memorystore for Memcached – distributed in-memory caching
  • Valkey 9.0 Features (GA 2026)
    • SIMD optimizations for improved throughput and latency
    • Enhanced performance over previous versions
    • Full compatibility with Redis OSS commands
  • Usage Patterns
    • Lift and shift migration of applications
    • Low latency data caching and retrieval
    • Session management
    • Real-time leaderboards and counting
  • Anti Patterns
    • Relational or NoSQL database
    • Analytics solution
    • Persistent primary data store (use as cache layer)
  • Common Use cases
    • User session management
    • Application caching
    • Real-time analytics and pub/sub
    • Gaming leaderboards

GCP Storage Options Decision Tree

GCP Storage Options Decision Tree

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 application is hosted across multiple regions and consists of both relational database data and static images. Your database has over 10 TB of data. You want to use a single storage repository for each data type across all regions. Which two products would you choose for this task? (Choose two)
    1. Cloud Bigtable
    2. Cloud Spanner
    3. Cloud SQL
    4. Cloud Storage
  2. You are building an application that stores relational data from users. Users across the globe will use this application. Your CTO is concerned about the scaling requirements because the size of the user base is unknown. You need to implement a database solution that can scale with your user growth with minimum configuration changes. Which storage solution should you use?
    1. Cloud SQL
    2. Cloud Spanner
    3. Cloud Firestore
    4. Cloud Datastore
  3. Your company processes high volumes of IoT data that are time-stamped. The total data volume can be several petabytes. The data needs to be written and changed at a high speed. You want to use the most performant storage option for your data. Which product should you use?
    1. Cloud Datastore
    2. Cloud Storage
    3. Cloud Bigtable
    4. BigQuery
  4. Your App Engine application needs to store stateful data in a proper storage service. Your data is non-relational database data. You do not expect the database size to grow beyond 10 GB and you need to have the ability to scale down to zero to avoid unnecessary costs. Which storage service should you use?
    1. Cloud Bigtable
    2. Cloud Dataproc
    3. Cloud SQL
    4. Cloud Firestore (Datastore mode)
  5. A financial organization wishes to develop a global application to store transactions happening from different part of the world. The storage system must provide low latency transaction support and horizontal scaling. Which GCP service is appropriate for this use case?
    1. Bigtable
    2. Datastore
    3. Cloud Storage
    4. Cloud Spanner
  6. You work for a mid-sized enterprise that needs to move its operational system transaction data from an on-premises database to GCP. The database is about 20 TB in size. Which database should you choose?
    1. Cloud SQL
    2. Cloud Bigtable
    3. Cloud Spanner
    4. Cloud Datastore

    Note: With Cloud SQL now supporting up to 64 TB, Cloud SQL could also be a valid option for 20 TB. However, for operational transactional data requiring high scalability, Cloud Spanner remains the better choice.

  7. Your team needs a PostgreSQL-compatible database that can handle both transactional and analytical queries with high performance. The application also requires built-in vector search capabilities for an AI-powered recommendation engine. Which GCP service should you choose?
    1. Cloud SQL for PostgreSQL
    2. AlloyDB for PostgreSQL
    3. Cloud Spanner
    4. BigQuery
  8. Your company is building a real-time fraud detection system that needs to query relationships between entities (accounts, transactions, merchants) while also performing vector similarity searches on transaction patterns. The system must provide strong consistency and global availability. Which database should you use?
    1. Cloud Bigtable
    2. BigQuery
    3. Cloud Spanner
    4. Cloud Firestore
  9. Your organization is migrating from MongoDB to Google Cloud. You want to minimize code changes and use existing MongoDB drivers and tools. The application requires automatic scaling and high availability. Which GCP service should you use?
    1. Cloud SQL for PostgreSQL
    2. Cloud Bigtable
    3. Cloud Firestore (Enterprise edition with MongoDB compatibility)
    4. AlloyDB for PostgreSQL
  10. You need a high-performance caching layer for your microservices application on GCP. The solution must support cross-region replication, provide 99.99% availability, and be compatible with open-source tooling. Which service should you choose?
    1. Memorystore for Redis
    2. Cloud CDN
    3. Memorystore for Valkey
    4. Cloud Firestore

See also: Google Cloud Storage Services Cheat Sheet

Google Cloud Load Balancing – ALB, NLB & Proxy

~ Last updated on : ~ jayendrapatil

Google Cloud Load Balancing

📢 Important Naming Update (2023-2024)

Google Cloud has rebranded all Cloud Load Balancing products. The older names (HTTP(S) Load Balancing, SSL Proxy, TCP Proxy, Network Load Balancing) are now replaced with the new naming convention:

  • Application Load Balancer (formerly HTTP/S Load Balancing) — Layer 7
  • Proxy Network Load Balancer (formerly SSL Proxy & TCP Proxy Load Balancing) — Layer 4 proxy-based
  • Passthrough Network Load Balancer (formerly TCP/UDP Network Load Balancing) — Layer 4 passthrough

The older names may still appear in some documentation and exam questions.

  • Cloud Load Balancing distributes user traffic across multiple instances of applications, reducing the risk of performance issues by spreading the load.
  • Cloud Load Balancing helps serve content as close as possible to users on a system that can respond to over one million queries per second.
  • Cloud Load Balancing is a fully distributed, software-defined managed service. It isn’t hardware-based and there is no need to manage a physical load balancing infrastructure.
  • Google Cloud load balancers are built on the same frontend-serving infrastructure that powers Google’s own services (Search, Gmail, YouTube).

Cloud Load Balancing — Current Product Family (Updated Naming)

Load Balancer Type Previous Name Layer Proxy/Passthrough
Application Load Balancer HTTP(S) Load Balancing Layer 7 Proxy
Proxy Network Load Balancer SSL Proxy / TCP Proxy Load Balancing Layer 4 Proxy
Passthrough Network Load Balancer TCP/UDP Network Load Balancing Layer 4 Passthrough

Cloud Load Balancing Features

External versus Internal Load Balancing

  • External load balancing
    • for internet-facing applications
    • Types
      • External Application Load Balancer (formerly External HTTP/S LB) — Global, Classic, or Regional modes
      • External Proxy Network Load Balancer (formerly SSL Proxy & TCP Proxy LB) — Global, Classic, or Regional modes
      • External Passthrough Network Load Balancer (formerly External TCP/UDP Network LB) — Regional only
  • Internal load balancing
    • for internal clients inside of Google Cloud VPC networks
    • Types
      • Internal Application Load Balancer (formerly Internal HTTP/S LB) — Cross-region or Regional modes
      • Internal Proxy Network Load Balancer (formerly Internal TCP Proxy) — Cross-region or Regional modes
      • Internal Passthrough Network Load Balancer (formerly Internal TCP/UDP Network LB) — Regional only

Global versus Regional Load Balancing

  • Regional load balancing
    • for single-region applications
    • supports IPv4 and IPv6 (Preview for some types)
    • Types
      • Regional External Application Load Balancer
      • Regional Internal Application Load Balancer
      • Regional External Proxy Network Load Balancer
      • Regional Internal Proxy Network Load Balancer
      • External Passthrough Network Load Balancer
      • Internal Passthrough Network Load Balancer
  • Global load balancing
    • for globally distributed applications
    • provides access using a single anycast IP address
    • supports IPv4 and IPv6 termination
    • requires Premium Tier of Network Service Tiers
    • Types
      • Global External Application Load Balancer (Premium Tier)
      • Classic Application Load Balancer (Premium Tier, global; Standard Tier, regional)
      • Global External Proxy Network Load Balancer (Premium Tier)
      • Cross-region Internal Application Load Balancer
      • Cross-region Internal Proxy Network Load Balancer

Passthrough vs Proxy-based Load Balancing

  • Proxy-based load balancing
    • acts as a proxy performing address and port translation and terminating the request before forwarding to the backend service
    • clients and backends interact with the load balancer
    • original client IP, port, and protocol is forwarded using X-Forwarded-For headers
    • automatically all proxy-based external load balancers inherit DDoS protection from Google Front Ends (GFEs)
    • Google Cloud Armor can be configured for Application Load Balancers
    • Types
      • Application Load Balancers (all modes — external and internal)
      • Proxy Network Load Balancers (all modes — external and internal)
  • Passthrough load balancing
    • does not terminate client connections; packets are passed unchanged to the backend
    • preserves client source IP address
    • supports additional protocols like UDP, ESP, and ICMP
    • Types
      • External Passthrough Network Load Balancer
      • Internal Passthrough Network Load Balancer

Layer 4 vs Layer 7

  • Layer 4-based load balancing
    • directs traffic based on data from network and transport layer protocols, such as IP address and TCP or UDP port
    • Types: Proxy Network Load Balancers and Passthrough Network Load Balancers
  • Layer 7-based load balancing
    • adds content-based routing decisions based on attributes, such as the HTTP header, URL path, cookies, and query parameters
    • Types: Application Load Balancers

Traffic type

  • For HTTP and HTTPS traffic, use:
    • External Application Load Balancer
    • Internal Application Load Balancer
  • For TCP traffic (with proxy), use:
    • External Proxy Network Load Balancer
    • Internal Proxy Network Load Balancer
  • For TCP/UDP traffic (passthrough), use:
    • External Passthrough Network Load Balancer
    • Internal Passthrough Network Load Balancer
  • For SSL offload, use:
    • External Proxy Network Load Balancer (with SSL)

Application Load Balancer Modes

  • Global External Application Load Balancer
    • Implemented on Google Front Ends (GFEs) using Envoy proxy
    • Supports advanced traffic management (traffic mirroring, weight-based splitting, header transformations)
    • Uses EXTERNAL_MANAGED load balancing scheme
    • Premium Tier only
    • Supports Cloud CDN, Cloud Armor, and Service Extensions
  • Classic Application Load Balancer
    • The legacy external Application Load Balancer on GFEs
    • Global in Premium Tier, regional in Standard Tier
    • Uses EXTERNAL load balancing scheme
    • Fewer advanced traffic management features than the global variant
    • Google recommends migrating to the Global External Application Load Balancer
  • Regional External Application Load Balancer
    • Implemented on open-source Envoy proxy
    • Supports advanced traffic management
    • Requires proxy-only subnet
    • Uses EXTERNAL_MANAGED load balancing scheme
    • Available in Premium or Standard Tier
  • Cross-region Internal Application Load Balancer
    • Distributes traffic to globally distributed internal backends
    • Supports global access and global backends
  • Regional Internal Application Load Balancer
    • Distributes Layer 7 traffic to backends within a single region in a VPC
    • Requires proxy-only subnet

Google Cloud Load Balancing Types

Refer blog post @ Google Cloud Load Balancing Types

Load Balancing Components

Backend Services

  • A backend service distributes requests to healthy backends.
  • Google Cloud supports several types of backends:
    • Instance groups — managed or unmanaged groups of VM instances
    • Zonal NEGs (GCE_VM_IP_PORT) — network endpoint groups in a single zone
    • Serverless NEGs — Cloud Run, App Engine, or Cloud Run functions
    • Internet NEGs — external endpoints outside Google Cloud
    • Hybrid NEGs — on-premises or other cloud backends via hybrid connectivity
    • Private Service Connect NEGs — access published services
    • Cloud Storage buckets — as backend buckets
  • A backend service is either global or regional in scope.
  • Backend service protocol options: HTTP, HTTPS, HTTP/2, H2C (cleartext HTTP/2), gRPC

Forwarding Rules

  • A forwarding rule and its corresponding IP address represent the frontend configuration of a Google Cloud load balancer.
  • Each forwarding rule provides a single IP address (IPv4 or IPv6) for DNS configuration.
  • Forwarding rules can be global or regional depending on the load balancer type.

Health Checks

  • Google Cloud provides health checking mechanisms that determine if backends are healthy and properly respond to traffic.
  • Health checks are global or regional depending on the load balancer type.
  • Each connection attempt is called a probe, and each health check system is called a prober.
  • Backends that respond successfully for the configured number of times are considered healthy; those that fail are marked unhealthy.
  • Supported health check protocols: HTTP, HTTPS, HTTP/2, TCP, SSL, gRPC

IPv6 Termination

  • Application Load Balancers and Proxy Network Load Balancers support IPv6 clients.
  • The load balancer accepts IPv6 connections from users and proxies those connections to backends.
  • Cross-region, regional external, and regional internal Application Load Balancers support terminating IPv6 traffic (Preview).

SSL Certificates

  • Load balancers that use HTTPS or SSL require SSL certificates.
  • Two configuration methods:
    • Compute Engine SSL certificates — self-managed or Google-managed
    • Certificate Manager — recommended approach for advanced certificate management, supports certificate maps, DNS/LB authorization, and wildcard certificates
  • Certificate Manager (2nd gen) — released in 2024/2025, provides centralized management, deployment, and automation of SSL/TLS certificates across organizations
  • Supports multiple SSL certificates per load balancer for multi-domain serving

SSL Policies

  • SSL policies control the SSL features (versions and ciphers) that the load balancer negotiates with clients.
  • Supported on Application Load Balancers and Proxy Network Load Balancers.
  • Predefined profiles: COMPATIBLE, MODERN, RESTRICTED, or CUSTOM

URL Maps

  • URL maps direct requests to a destination based on defined rules.
  • Supports routing based on host, path, headers, cookies, and query parameters.
  • Advanced traffic management: traffic mirroring, weight-based traffic splitting, URL rewrites, URL redirects, header-based routing.

New Features (2023-2026)

HTTP/3 Support (IETF QUIC)

  • HTTP/3 is supported between external Application Load Balancers and clients.
  • Built on IETF QUIC — provides faster connection initiation, eliminates head-of-line blocking, supports connection migration.
  • Advertised via Alt-Svc HTTP response header.
  • Clients automatically fall back to HTTP/2 or HTTPS if HTTP/3 is unavailable.
  • Supported on Global External ALB, Classic ALB (Premium), and Regional External ALB.

Service Extensions (Plugins and Callouts)

  • Service Extensions lets you insert custom logic into the load balancing data path.
  • Plugins — run custom code (e.g., Rust/Wasm) directly in the request/response path with minimal latency.
  • Callouts — send gRPC callouts from the load balancer to external backend services for custom processing.
  • Use cases: custom authentication, header manipulation, request validation, A/B testing logic.
  • Supported on Application Load Balancers.

Authorization Policies

  • Authorization policies (AuthzPolicy) enforce access control on traffic entering load balancers.
  • Define rules specifying source of incoming traffic and permitted/restricted operations.
  • Applied on the forwarding rule of Application Load Balancers.
  • Can delegate authorization to IAP (Identity-Aware Proxy) and IAM.

Backend mTLS and Managed Workload Identity

  • Frontend mTLS — load balancer requests client certificates for mutual authentication.
  • Backend authenticated TLS — load balancer verifies backend server certificates.
  • Backend mTLS — mutual authentication between load balancer and backends.
  • Managed workload identity — automates certificate provisioning and rotation for backend mTLS.

Post-Quantum TLS

  • Google Cloud load balancers support quantum-safe key exchange (X25519MLKEM768 hybrid).
  • Combines NIST ML-KEM standard with traditional encryption for forward-secure TLS connections.
  • Protects against future quantum computing threats (harvest-now, decrypt-later attacks).

TLS 1.3 Early Data (0-RTT)

  • Reduces latency for resumed TLS connections by allowing clients to send data with the initial handshake.
  • Modes: STRICT (safe methods only, no query params), PERMISSIVE (safe methods with query params), DISABLED, UNRESTRICTED.
  • Supported on Global and Classic External Application Load Balancers.
  • Backends must handle potential replay risks with appropriate checks (HTTP 425 Too Early response).

Advanced Load Balancing Optimizations (Service LB Policy)

  • Auto-capacity draining — quickly drains traffic from unhealthy backends.
  • Failover threshold — configurable threshold to determine when failover triggers.
  • Traffic isolation — prevents cascading failures by limiting cross-region traffic overflow.
  • Load balancing algorithms — Waterfall by Region, Waterfall by Zone, Spray to Region.

Cloud Service Mesh Integration

  • Traffic Director has been rebranded to Cloud Service Mesh (GA June 2024).
  • Provides a managed service mesh with Envoy proxies or proxyless gRPC clients.
  • Integrates with Cloud Load Balancing for advanced traffic management.

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 Load Balancing Types Compared [2026 Guide]

~ Last updated on : ~ jayendrapatil

Google Cloud Load Balancing Types – Comparison & Decision Guide [2025]

📢 Important Naming Update (2023)

Google Cloud has rebranded all load balancers with a simplified naming convention:

  • Application Load Balancer — previously “HTTP(S) Load Balancing” (Layer 7, proxy-based)
  • Proxy Network Load Balancer — previously “SSL Proxy” and “TCP Proxy Load Balancing” (Layer 4, proxy-based)
  • Passthrough Network Load Balancer — previously “TCP/UDP Network Load Balancing” (Layer 4, passthrough)

This post uses the current naming with references to previous names for clarity.

Google Cloud Load Balancer Summary

Load Balancer Deployment Mode Traffic Type Network Tier
Application Load Balancer Global external HTTP/HTTPS Premium
Regional external HTTP/HTTPS Premium or Standard
Classic HTTP/HTTPS Global in Premium, Regional in Standard
Regional internal HTTP/HTTPS Premium
Cross-region internal HTTP/HTTPS Premium
Proxy Network Load Balancer Global external TCP with optional SSL offload Premium
Regional external TCP Premium or Standard
Classic TCP with optional SSL offload Global in Premium, Regional in Standard
Regional internal TCP (no SSL offload) Premium
Cross-region internal TCP (no SSL offload) Premium
Passthrough Network Load Balancer External (regional) TCP, UDP, ESP, GRE, ICMP, ICMPv6 Premium or Standard
Internal (regional) TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, GRE Premium

Google Cloud Load Balancer Comparison

Application Load Balancer — Internal (Regional)

Previously known as: Internal HTTP(S) Load Balancing

  • is a proxy-based, regional Layer 7 load balancer that enables running and scaling services behind an internal IP address.
  • distributes HTTP and HTTPS traffic to backends hosted on Compute Engine, GKE, and Cloud Run
  • is accessible only in the chosen region of the Virtual Private Cloud (VPC) network on an internal IP address.
  • can be made globally accessible by enabling global access on the forwarding rule, allowing clients from any region to access the load balancer.
  • enables rich traffic control capabilities based on HTTP(S) parameters.
  • is a managed service based on the open source Envoy proxy.
  • needs one proxy-only subnet in each region of a VPC network where the internal Application Load Balancer is used. All load balancers in a region and VPC network share the same proxy-only subnet.
  • supports path-based and host-based routing
  • supports advanced traffic management including traffic mirroring, weight-based traffic splitting, and header transformations
  • preserves the Host header of the original client request and also appends two IP addresses (Client and LB) to the X-Forwarded-For header
  • supports backend services distributing requests to healthy backends (instance groups, zonal NEGs, serverless NEGs for Cloud Run, or hybrid NEGs for on-premises backends).
  • supports health checks that periodically monitor the readiness of the backends.
  • if a backend becomes unhealthy, traffic is automatically redirected to healthy backends within the same region.
  • has native support for the WebSocket protocol
  • supports TLS 1.0, 1.1, 1.2, and 1.3 when terminating client SSL requests.
  • supports mutual TLS (mTLS) for client certificate-based authentication (added 2023)
  • supports IPv6 termination (Preview, expanded May 2026)
  • supports access from connected networks via VPC Network Peering, Cloud VPN, or Cloud Interconnect
  • isn’t compatible with the following features:
    • Cloud CDN
    • Cloud Storage buckets — now supported (GA April 2026)

Application Load Balancer — Internal (Cross-Region)

New deployment mode added in 2023

  • is a proxy-based Layer 7 load balancer that distributes HTTP/HTTPS traffic to backends across multiple regions.
  • provides an internal IP address accessible from any region (global access built-in).
  • enables high availability and cross-region failover — if backends in one region go down, traffic fails over to another region gracefully.
  • uses the open source Envoy proxy and supports advanced traffic management.
  • supports backends hosted on Compute Engine, GKE, Cloud Run (serverless NEGs), Cloud Storage (backend buckets), and hybrid NEGs for on-premises backends.
  • supports mutual TLS (mTLS) for frontend and backend authentication.
  • supports IPv6 termination (Preview).
  • ideal for multi-region internal services requiring automatic failover.

Application Load Balancer — External

Previously known as: External HTTP(S) Load Balancing

Available in three deployment modes:

  • Global external — Premium Tier only, uses Envoy proxy, supports advanced traffic management
  • Regional external — Premium or Standard Tier, uses Envoy proxy, provides jurisdictional compliance
  • Classic — Legacy mode using Google Front Ends (GFEs), global in Premium Tier, regional in Standard Tier

Note: Google recommends migrating from Classic to Global external Application Load Balancer for access to new features.

Key Features

  • is a global (or regional), proxy-based Layer 7 load balancer that enables running and scaling services worldwide behind a single external IP address.
  • distributes HTTP and HTTPS traffic to backends hosted on Compute Engine, GKE, Cloud Run, Cloud Storage, and external backends.
  • Global external mode uses Envoy proxy and supports advanced traffic management (traffic mirroring, weight-based splitting, header transformations).
  • Classic mode is implemented on Google Front Ends (GFEs) distributed globally.
    • In Premium Tier, GFEs offer global load balancing
    • With Standard Tier, the load balancing is handled regionally.
  • provides cross-regional or location-based load balancing, directing traffic to the closest healthy backend.
  • supports content-based load balancing using URL maps to select a backend service based on host name, request path, headers, or query parameters.
  • supports the following backend types:
    • Instance groups (managed and unmanaged)
    • Zonal network endpoint groups (NEGs)
    • Serverless NEGs: Cloud Run, App Engine, or Cloud Run functions services
    • Internet NEGs, for endpoints outside of Google Cloud
    • Hybrid NEGs, for on-premises or other cloud backends via Cloud VPN/Interconnect
    • Buckets in Cloud Storage
  • preserves the Host header of the original client request and appends to the X-Forwarded-For header
  • integrates with Cloud CDN for caching responses at edge locations
  • integrates with Google Cloud Armor for DDoS protection and WAF capabilities
  • supports Cloud Load Balancing Autoscaler for backend instance groups
  • supports connection draining on backend services
  • supports Session affinity:
    • NONE — no session affinity
    • Client IP affinity
    • Generated cookie affinity
    • Header field affinity (global external and regional external only)
    • HTTP cookie affinity (global external and regional external only)
  • if a backend becomes unhealthy, traffic is automatically redirected to healthy backends.
  • has native support for the WebSocket protocol and HTTP/2, gRPC
  • supports TLS 1.0, 1.1, 1.2, and 1.3
  • supports mutual TLS (mTLS) for client certificate-based authentication
  • supports SSL policies to control TLS cipher suites and versions
  • supports IPv6 termination
  • supports QUIC protocol (global external and classic modes)
  • supports Service Extensions to inject custom logic into the load balancing path
  • supports Authorization Policies for fine-grained access control

Passthrough Network Load Balancer — Internal

Previously known as: Internal TCP/UDP Load Balancing

  • is a managed, internal, pass-through, regional Layer 4 load balancer that enables running and scaling services behind an internal IP address.
  • distributes traffic among VM instances in the same region in a VPC network by using an internal IP address.
  • supports TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, and GRE protocols.
  • routes original connections directly from clients to the healthy backends, without any interruption.
  • Responses from the healthy backend VMs go directly to the clients, not back through the load balancer. TCP responses use direct server return.
  • does not terminate SSL traffic; SSL traffic can be terminated by the backends.
  • Unlike proxy load balancers, it doesn’t terminate connections from clients and then open new connections to backends.
  • provides access through VPC Network Peering, Cloud VPN, or Cloud Interconnect
  • supports global access — when enabled, clients from any region can access the load balancer.
  • supports zonal NEGs with GCE_VM_IP endpoints as backends
  • supports zonal affinity to prefer routing new connections to backends in the same zone as the client (GA May 2026)
  • can be used as next hops for routes, enabling third-party appliance integration
  • supports Session affinity:
    • None: default, effectively same as Client IP, protocol, and port.
    • Client IP: based on client IP and destination IP.
    • Client IP and protocol: based on client IP, destination IP, and protocol.
    • Client IP, protocol, and port: 5-tuple hash (source IP, source port, destination IP, destination port, protocol).
  • UDP protocol doesn’t support sessions; session affinity doesn’t affect UDP traffic.
  • supports health checks (HTTP, HTTPS, HTTP2, TCP, SSL protocols); does not offer UDP health checks but can use TCP-based health checks.
  • supports failover backends that are only used when healthy VMs in primary backends fall below a configurable threshold.
  • supports multiple forwarding rules sharing a common IP address

Passthrough Network Load Balancer — External

Previously known as: External TCP/UDP Network Load Balancing

  • is a managed, external, pass-through, regional Layer 4 load balancer that distributes TCP or UDP traffic from the internet to VM instances in the same region.
  • supports TCP, UDP, ESP, GRE, ICMP, and ICMPv6 protocols.
  • is not a proxy — packets are pass-through:
    • Load-balanced packets are received by backend VMs with their source IP unchanged.
    • Load-balanced connections are terminated by the backend VMs.
    • Responses from the backend VMs go directly to the clients, not back through the load balancer.
    • TCP responses use direct server return.
  • scope is regional, not global. Within a single region, the load balancer services all zones.
  • supports two architectures:
    • Backend service-based (recommended) — uses instance groups or zonal NEGs with GCE_VM_IP endpoints
    • Target pool-based (legacy) — simpler but fewer features
  • supports zonal NEGs with GCE_VM_IP endpoints, enabling forwarding to any network interface (not just nic0)
  • supports weighted load balancing for gradual traffic migration
  • supports regional health checks (HTTP, HTTPS, HTTP2, TCP, SSL); does not offer UDP health checks.
  • supports connection tracking table and configurable consistent hashing algorithm for traffic distribution.
  • supports Session affinity:
    • None: default, effectively same as Client IP, protocol, and port.
    • Client IP: based on client IP and destination IP.
    • Client IP and protocol: based on client IP, destination IP, and protocol.
    • Client IP, protocol, and port: 5-tuple hash.
  • UDP protocol doesn’t support sessions; session affinity doesn’t affect UDP traffic.
  • supports connection draining for established TCP connections.
  • supports failover configuration for high availability.
  • available in Premium or Standard Network Service Tier.

Proxy Network Load Balancer — External (SSL/TCP Proxy)

Previously known as: External SSL Proxy Load Balancing and External TCP Proxy Load Balancing

Available in three deployment modes:

  • Global external — Premium Tier only, supports SSL offload
  • Regional external — Premium or Standard Tier, TCP only (no SSL offload)
  • Classic — Legacy mode, global in Premium Tier, regional in Standard Tier

Key Features

  • is a reverse proxy, Layer 4 load balancer that distributes SSL/TCP traffic from the internet to VM instances.
  • with SSL traffic, supports SSL offload where SSL (TLS) connections are terminated at the load balancing layer, then proxied to backends using SSL or TCP.
  • is intended for non-HTTP(S) traffic. For HTTP(S) traffic, use Application Load Balancer.
  • Global mode uses a single IP address for all users worldwide and automatically routes traffic to the closest backends.
  • supports proxy protocol header to preserve original source IP addresses.
  • supports two types of balancing mode:
    • CONNECTION: load spread based on concurrent connections the backend can handle.
    • UTILIZATION: load spread based on instance utilization.
  • supports Session Affinity with client IP affinity.
  • does not support mutual TLS (mTLS) authentication.
  • supports SSL policies to control minimum TLS versions and cipher suites.

Proxy Network Load Balancer — Internal

New deployment mode added in 2023

Available in two deployment modes:

  • Regional internal — for TCP traffic within a region
  • Cross-region internal — for TCP traffic across multiple regions

Key Features

  • is a proxy-based, internal, Layer 4 load balancer for TCP traffic.
  • uses Envoy proxy infrastructure.
  • does not support SSL offload (unlike the external proxy Network Load Balancer).
  • supports backends in instance groups, zonal NEGs, and hybrid NEGs.
  • provides access from connected networks via VPC Network Peering, Cloud VPN, or Cloud Interconnect.
  • cross-region mode enables backends distributed globally with automatic failover.

Choosing a Load Balancer

  • Choose an Application Load Balancer for HTTP(S) traffic with flexible Layer 7 features.
  • Choose a Proxy Network Load Balancer for TCP proxy load balancing with SSL offload to backends in one or more regions.
  • Choose a Passthrough Network Load Balancer to preserve client source IP addresses, avoid proxy overhead, and support additional protocols (UDP, ESP, ICMP, GRE).

Global vs. Regional

  • Global/Cross-region — distributed across multiple regions, resilient to both zonal and regional outages. Use when backends are in multiple regions or you need automatic cross-region failover.
  • Regional — distributed across zones within one region. Required for jurisdictional compliance where traffic must stay in a specific region.

Proxy vs. Passthrough

  • Proxy load balancers terminate client connections at the load balancer and open new connections to backends. Client IP is not preserved by default.
  • Passthrough load balancers don’t terminate client connections. Backend VMs receive packets with original source IP unchanged. Use when you need to preserve client IP.

Security Features (2023-2026 Updates)

  • Mutual TLS (mTLS) — Application Load Balancers now support frontend mTLS (client authenticates to LB) and backend mTLS (LB authenticates to backend). Supported on global external, regional external, regional internal, and cross-region internal Application Load Balancers. Backend mTLS is GA for all Application Load Balancer modes (2025-2026).
  • Authorization Policies — Fine-grained access control policies that can be applied to Application Load Balancers to allow or deny requests based on attributes. GA since October 2025. New policy profiles (Preview 2026) support REQUEST_AUTHZ for header-based decisions and CONTENT_AUTHZ for deep payload inspection (blocking prompt injection attacks, preventing data leaks).
  • SSL Policies — Control minimum TLS version and cipher suites. New FIPS_202205 profile (GA January 2026) restricts to FIPS 140-2/140-3 validated cryptographic modules. TLS 1.3 minimum enforcement is now supported.
  • Google Cloud Armor — DDoS protection and WAF for external Application Load Balancers (global, regional, and classic modes) and external proxy Network Load Balancers.
  • Post-Quantum TLS — Support for post-quantum key exchange (X25519MLKEM768) to protect against future quantum computing threats (GA June 2026). Three-phase rollout: opt-in now, default by October 2026, mandatory after October 2027.
  • Service Extensions — Inject custom processing logic into the load balancing data path. Plugins (Preview October 2024, enhanced 2026) let you run WebAssembly (Wasm) code in a fully managed serverless environment directly in the data path.
  • TLS 1.3 Early Data (0-RTT) — Supported on global external and classic Application Load Balancers (GA February 2025). Can improve performance for resumed connections by 30-50%.
  • Large TLS Key Support — RSA-3072, RSA-4096, and ECDSA P-384 keys now supported (GA July 2025) in addition to RSA-2048 and ECDSA P-256.
  • JA4 Fingerprint — Global external Application Load Balancers support JA4 TLS fingerprinting via custom request headers (GA July 2025) for advanced bot detection and traffic analysis.

Advanced Features (2025-2026 Updates)

  • SNI-based Routing (TLS Routes) — Proxy Network Load Balancers support routing TLS traffic based on Server Name Indication (SNI) hostnames without terminating TLS (Preview March 2026). Enables end-to-end mTLS and reduces IPv4 address exhaustion via single PSC endpoints.
  • Custom Metrics — Application Load Balancers support custom metrics-based traffic distribution instead of standard utilization/rate-based metrics (GA June 2025).
  • Traffic Duration & In-Flight Balancing — Configure backends with SHORT or LONG traffic duration settings. In-flight balancing mode distributes traffic when requests take more than a second (GA May 2026).
  • Traffic Isolation — Global/cross-region load balancers can restrict traffic to the nearest region only, with optional STRICT mode preventing overflow entirely (Preview May 2025).
  • Failover for External ALBs — Global, classic, and regional external Application Load Balancers support failover to regional external ALBs in other regions (GA November 2024).
  • Stateful Cookie-Based Session Affinity — All Application Load Balancers (except classic) support persistent cookie-based stickiness (GA October 2024).
  • Cross-VPC Backends — All Application and Proxy Network Load Balancers support backends in different VPC networks without Shared VPC (April 2025).
  • Cloud Storage Backend Buckets — Now available for regional external and regional internal Application Load Balancers (GA April 2026), completing support across the entire ALB portfolio.
  • Classic to Global Migration — Migrate classic Application Load Balancer resources to global external ALB infrastructure with 90-day rollback option (GA May 2025).

GCP Cloud Load Balancing Decision Tree

Google Cloud Load Balancer Decision Tree

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 development team has asked you to set up an external TCP load balancer with SSL offload. Which load balancer should you use?
    1. External proxy Network Load Balancer (SSL proxy)
    2. Application Load Balancer (HTTP)
    3. External proxy Network Load Balancer (TCP proxy)
    4. Application Load Balancer (HTTPS)
  2. You have an instance group that you want to load balance. You want the load balancer to terminate the client SSL session. The instance group is used to serve a public web application over HTTPS. You want to follow Google-recommended practices. What should you do?
    1. Configure an external Application Load Balancer.
    2. Configure an internal passthrough Network Load Balancer.
    3. Configure an external proxy Network Load Balancer (SSL proxy).
    4. Configure an external proxy Network Load Balancer (TCP proxy).
  3. Your development team has asked you to set up load balancer with SSL termination. The website would be using HTTPS protocol. Which load balancer should you use?
    1. External proxy Network Load Balancer (SSL proxy)
    2. Application Load Balancer (HTTP)
    3. External proxy Network Load Balancer (TCP proxy)
    4. External Application Load Balancer (HTTPS)
  4. You have an application that receives SSL-encrypted TCP traffic on port 443. Clients for this application are located all over the world. You want to minimize latency for the clients. Which load balancing option should you use?
    1. External Application Load Balancer (HTTPS)
    2. External passthrough Network Load Balancer
    3. External proxy Network Load Balancer (SSL Proxy)
    4. Internal passthrough Network Load Balancer. Add a firewall rule allowing ingress traffic from 0.0.0.0/0 on the target instances.
  5. You need to deploy an internal load balancer for HTTP traffic that can automatically failover to backends in another region if the primary region goes down. Which load balancer should you choose?
    1. Regional internal Application Load Balancer
    2. Cross-region internal Application Load Balancer
    3. Internal passthrough Network Load Balancer
    4. Internal proxy Network Load Balancer
  6. Your organization requires that TLS be terminated only within a specific region for compliance. You need an external load balancer for HTTPS traffic. Which deployment mode should you use?
    1. Global external Application Load Balancer
    2. Classic Application Load Balancer (Premium Tier)
    3. Regional external Application Load Balancer
    4. External proxy Network Load Balancer (SSL proxy)
  7. You want to load balance UDP traffic to backend VMs while preserving the client source IP address. Which load balancer type should you use?
    1. External Application Load Balancer
    2. External proxy Network Load Balancer
    3. External passthrough Network Load Balancer
    4. Internal Application Load Balancer
  8. You need to set up mutual TLS (mTLS) authentication where the load balancer verifies client certificates. Which load balancer supports this? (Choose two)
    1. Global external Application Load Balancer
    2. External passthrough Network Load Balancer
    3. Regional internal Application Load Balancer
    4. External proxy Network Load Balancer (SSL proxy)

References

 

App Engine Standard vs Flexible – Differences & When to Use

~ Last updated on : ~ jayendrapatil

Google Cloud – App Engine Standard vs Flexible Environment

📢 Important Updates (2024-2026)

  • Legacy Runtimes Deprecated (Jan 31, 2026): Python 2.7, Java 8, Go 1.11, and PHP 5.5 first-generation runtimes have been deprecated. Existing apps continue to run but new deployments are blocked.
  • Second-Generation Runtimes: Standard environment now uses gVisor-based sandboxing with significantly fewer restrictions than the first-generation sandbox.
  • Cloud Run Recommended: Google recommends Cloud Run as the preferred serverless platform for new projects, combining the best of both App Engine environments.
  • VPC Connectivity: Standard environment now supports VPC access via Direct VPC egress and Serverless VPC connectors.

Application Execution

  • Standard environment
    • Application instances run in a sandboxed environment using second-generation runtimes (gVisor-based containers) for supported languages: Go, Java, Node.js, PHP, Python, and Ruby.
    • Second-generation runtimes (current) provide significantly relaxed restrictions compared to the original sandbox:
      • Can write to the /tmp directory (in-memory filesystem)
      • Can use any language-native libraries and system calls supported by gVisor
      • Supports network access including VPC connectivity
      • Background threads supported within request lifecycle
    • First-generation sandbox (deprecated Jan 2026) had strict restrictions:
      • Only allowed a limited set of binary libraries
      • App could not write to disk
      • Limited CPU and memory options
      • Did not support SSH debugging, background processes, or Cloud VPN
    • Supported Languages: Go (up to 1.26), Java (up to 25), Node.js (up to 24), PHP (up to 8.5), Python (up to 3.14), Ruby (up to 4.0)
  • Flexible environment
    • Application instances run within Docker containers on Compute Engine virtual machines (VM).
    • Supports custom runtimes or source code written in any programming language via Docker containers.
    • Allows selection of any Compute Engine machine type for instances, providing access to more memory and CPU (up to 80 vCPU and 6.5GB per vCPU).
    • Supports SSH debugging into instances.

Accessing External Services

  • Standard environment
    • Second-generation runtimes: Use Google Cloud Client Libraries (recommended) for accessing services like Firestore, Cloud Storage, etc. These libraries are portable across all Google Cloud platforms.
    • First-generation runtimes: Used legacy bundled services (google.appengine APIs) – these are still available on second-gen runtimes for Java, Python, Go, and PHP for backward compatibility but are not recommended for new apps.
  • Flexible environment
    • Legacy google.appengine APIs are not available.
    • Uses Google Cloud Client Libraries, making the application more portable.

Scaling

  • Standard Environment
    • Rapid scaling with scale-to-zero capability — can scale from zero instances up to thousands very quickly.
    • Uses a custom-designed autoscaling algorithm.
    • Supports three scaling types: automatic, basic, and manual scaling.
    • Configurable: max/min instances, target CPU utilization, target throughput utilization, max concurrent requests, and pending latency.
  • Flexible Environment
    • Must have at least one instance running for each active version (cannot scale to zero).
    • Uses the Compute Engine Autoscaler.
    • Can take longer to scale up in response to traffic compared to Standard.
    • Supports automatic and manual scaling only.

Health Checks

  • Standard environment
    • Performs automatic readiness and liveness checks on instances.
    • If an instance consistently fails checks, App Engine terminates and replaces it with a new instance.
  • Flexible environment
    • Instances are health-checked using configurable health check endpoints.
    • Health check results are used by the load balancer to determine whether to send traffic to an instance and whether it should be autohealed.

Networking & Connectivity

  • Standard environment
    • VPC connectivity supported via Direct VPC egress (Preview) or Serverless VPC Access connectors.
    • Supports Shared VPC for cross-project networking.
    • Direct VPC egress supports: network tags, Public NAT, dual-stack subnets.
    • Supports configurable ingress settings (internal-only, internal-and-Cloud-Load-Balancing, all traffic).
    • App Engine firewall rules available for access control.
  • Flexible environment
    • Instances run on Compute Engine VMs within the project’s VPC network directly.
    • Full network access including SSH and Cloud VPN support.
    • Configurable ingress settings and firewall rules available.

Traffic Migration

  • Standard environment
    • Allows routing requests to the target version either immediately or gradually (traffic splitting).
    • Supports splitting traffic by IP address, cookie, or random.
  • Flexible environment
    • Supports both immediate and gradual traffic migration.
    • Supports traffic splitting by IP address or cookie.

Single Zone Failures

  • Standard environment
    • Applications are single-zoned; all instances live in a single availability zone.
    • In the event of a zone failure, the application starts new instances in a different zone in the same region and the load balancer routes traffic to the new instances.
    • Latency spike can be observed due to loading requests and Memcache flush.
  • Flexible environment
    • Applications use Regional Managed Instance Groups with instances distributed among multiple availability zones within a region.
    • In the event of a single zone failure, the load balancer stops routing traffic to that zone.
    • Provides higher availability compared to Standard environment.

Deployment

  • Standard Environment
    • Deployments are generally faster — instance startup time is in seconds for auto-scaling.
    • Deploys from source code only (no container image support).
    • Uses app.yaml for all configuration.
  • Flexible Environment
    • Instance startup time in minutes (not seconds).
    • Deployment time is longer due to Docker image building.
    • Supports custom runtime Docker containers.
    • Uses app.yaml for configuration.

Compute Resources

  • Standard Environment
    • Predefined instance classes: F1 (384MB/600MHz), F2 (768MB/1.2GHz), F4 (1.5GB/2.4GHz), F4_1G (3GB/2.4GHz) for automatic scaling.
    • B1, B2, B4, B4_1G, B8 (up to 3GB/4.8GHz) for basic and manual scaling.
    • No GPU support.
  • Flexible Environment
    • Any Compute Engine machine type — up to 80 vCPU and 6.5GB RAM per vCPU.
    • Much greater resource flexibility.
    • No GPU support (use Cloud Run or Compute Engine for GPU workloads).

Pricing

  • Standard Environment
    • Billed per instance-hour based on instance class.
    • Includes a generous free tier (28 instance-hours/day for F1, 8 instance-hours/day for B1).
    • No per-request fees.
    • No committed use discounts (CUDs) available.
  • Flexible Environment
    • Billed based on vCPU, memory, and persistent disk resources of the underlying Compute Engine VMs.
    • No free tier.
    • Minimum one instance always running (cannot scale to zero).

Cloud Run — The Recommended Alternative

Cloud Run is the latest evolution of Google Cloud Serverless and is officially recommended by Google for new projects. It combines the best features of both App Engine environments:

  • Scale-to-zero like Standard environment
  • Container flexibility like Flexible environment (any language, any library)
  • GPU support — one GPU per instance configurable
  • Sidecar containers — run multiple containers per service
  • Volume mounts — mount Cloud Storage buckets directly
  • Multi-region load balancing — deploy services across regions
  • Committed Use Discounts (CUDs) available
  • Up to 8 vCPU and 32GB memory per instance
  • IAM-based access control with Cloud Run Invoker role
  • Configurable health checks — startup and liveness probes
  • Direct VPC egress (GA) with full VPC Flow Logs support

Google provides a comprehensive migration guide from App Engine Standard to Cloud Run and from Flexible to Cloud Run.

Summary Comparison Table

Feature Standard Environment Flexible Environment
Instance startup Seconds Minutes
Scale to zero Yes No (min 1 instance)
Custom runtimes No (predefined only) Yes (Docker)
Supported languages Go, Java, Node.js, PHP, Python, Ruby Any (via Docker)
SSH access No Yes
VPC connectivity Yes (Direct VPC egress / connectors) Yes (native VPC)
Max compute F4_1G (3GB/2.4GHz) Any CE machine type
Background processes Limited (within request lifecycle) Yes
Write to disk Yes (/tmp only, in-memory) Yes (ephemeral disk)
Free tier Yes No
Health checks Automatic Configurable
Traffic splitting IP, cookie, random IP, cookie
High availability Single zone (auto-recovers) Multi-zone (regional MIG)

Google Cloud - App Engine Standard vs Flexible Environment

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’re writing a Python application and want your application to run in a sandboxed managed environment with the ability to scale up in seconds to account for huge spikes in demand. Which service should you host your application on?
    1. Compute Engine
    2. App Engine Flexible Environment
    3. Kubernetes Engine
    4. App Engine Standard Environment
  2. A Company is planning the migration of their web application to Google App Engine. However, they would still continue to use their on-premises database. How can they setup application?
    1. Setup the application using App Engine Standard environment with Cloud VPN to connect to database
    2. Setup the application using App Engine Flexible environment with Cloud VPN to connect to database
    3. Setup the application using App Engine Standard environment with Cloud Router to connect to database
    4. Setup the application using App Engine Flexible environment with Cloud Router to connect to database

    Note: With second-generation runtimes, Standard environment can now connect to VPC using Direct VPC egress or Serverless VPC connectors, making option A potentially valid for newer deployments. However, for direct Cloud VPN connectivity, Flexible environment remains the straightforward choice.

  3. A startup wants to deploy a containerized application written in Rust with minimal operational overhead and the ability to scale to zero during periods of inactivity. Which Google Cloud service should they use?
    1. App Engine Standard Environment
    2. App Engine Flexible Environment
    3. Cloud Run
    4. Google Kubernetes Engine
  4. Your team is running an application on App Engine Standard environment using Python 2.7 runtime. Google has deprecated first-generation runtimes. What is the recommended migration path?
    1. Migrate directly to Compute Engine
    2. Migrate to the latest Python 3 runtime on App Engine Standard or migrate to Cloud Run
    3. No action needed; the application will continue running indefinitely
    4. Migrate to App Engine Flexible environment
  5. Which of the following is TRUE about App Engine Standard environment with second-generation runtimes? (Choose TWO)
    1. Applications can connect to VPC networks using Direct VPC egress
    2. Applications can use any programming language via custom Docker containers
    3. Applications can scale to zero instances when there is no traffic
    4. Applications support SSH access for debugging
    5. Applications require at least one instance always running
  6. A company wants to deploy a web application that requires GPU access for AI inference with automatic scaling and minimal infrastructure management. Which service should they use?
    1. App Engine Standard Environment
    2. App Engine Flexible Environment
    3. Cloud Run
    4. Compute Engine with managed instance groups
  7. Which App Engine environment provides multi-zone high availability by distributing instances across multiple zones in a region?
    1. Standard Environment with automatic scaling
    2. Standard Environment with manual scaling
    3. Flexible Environment
    4. Both Standard and Flexible environments

Frequently Asked Questions

What is the difference between App Engine Standard and Flexible?

Standard environment runs in a sandbox with automatic scaling to zero, supports specific language runtimes, and has free daily quota. Flexible environment runs in Docker containers on Compute Engine VMs with custom runtimes, no free tier, and minimum 1 instance.

Can App Engine scale to zero?

App Engine Standard can scale to zero instances when there’s no traffic, meaning you pay nothing during idle time. Flexible environment requires at least one instance running at all times.

Should I use App Engine or Cloud Run?

Cloud Run is recommended for new applications — it offers container-based serverless with scale-to-zero, any language/binary support, and per-request pricing. App Engine is still valid for existing apps but Cloud Run provides more flexibility.

References