GCP

Google Cloud Bigtable – NoSQL Wide-Column Database

~ Last updated on : ~ jayendrapatil

Google Cloud Bigtable

  • Cloud Bigtable is a fully managed, scalable, wide-column NoSQL database service with up to 99.999% availability.
  • Bigtable is ideal for applications that need very high throughput and scalability for key/value data, where each value is max. of 10 MB.
  • Bigtable supports high read and write throughput at low latency and provides consistent sub-10ms latency – handle millions of requests/second
  • Bigtable is a sparsely populated table that can scale to billions of rows and thousands of columns,
  • Bigtable supports storage of terabytes or even petabytes of data
  • Bigtable is not a relational database. It does not support joins or multi-row transactions. However, as of April 2025, Bigtable supports GoogleSQL for read queries (SELECT statements only — no INSERT, UPDATE, DELETE, or DDL).
  • Fully Managed
    • Bigtable handles upgrades and restarts transparently, and it automatically maintains high data durability.
    • Data replication can be performed by simply adding a second cluster to the instance, and replication starts automatically.
  • Scalability
    • Bigtable scales linearly in direct proportion to the number of machines in the cluster
    • Bigtable throughput can be scaled dynamically by adding or removing cluster nodes without restarting
    • Bigtable supports Autoscaling (GA since Dec 2021), which automatically adds or removes nodes based on CPU utilization, storage utilization, and throughput targets.
  • Bigtable integrates easily with big data tools like Hadoop, Dataflow, Dataproc and supports HBase APIs.
  • Bigtable Editions (GA April 2026)
    • Bigtable now offers Enterprise and Enterprise Plus editions with advanced features.
    • Enterprise Plus includes Data Boost for SQL queries, in-memory tier, tiered storage (up to 64 TB/node), and extended backup retention (up to 365 days).

Bigtable Architecture

Bigtable Architecture

  • Bigtable Instance is a container for Cluster where Nodes are organized.
  • Bigtable stores data in Colossus, Google’s file system.
  • Instance
    • A Bigtable instance is a container for data.
    • Instances have one or more clusters, located in a different zone and different region (Different region adds to latency)
    • An instance can have clusters in up to 8 regions, with as many clusters in each region as there are zones.
    • Each cluster has at least 1 node
    • A Table belongs to an instance and not to the cluster or node.
    • An instance also consists of the following properties
      • Storage Type – SSD or HDD
      • Application Profiles – primarily for instances using replication
  • Instance Type
    • Development – Single node cluster with no replication or SLA
    • Production – 1+ clusters which 1+ nodes per cluster (minimum of 1 node per cluster)
    • Free Trial (GA April 2026) – 1-node SSD cluster with up to 500 GB storage for 90 days at no cost
  • Storage Type
    • Storage Type dictates where the data is stored i.e. SSD or HDD
    • Choice of SSD or HDD storage for the instance is permanent
    • SSD storage is the most efficient and cost-effective choice for most use cases.
    • HDD storage is sometimes appropriate for very large data sets (>10 TB) that are not latency-sensitive or are infrequently accessed.
    • Tiered Storage (Preview, Oct 2025) — automatically moves older, infrequently accessed data to a less expensive storage tier while keeping it queryable. Supports up to 64 TB per node (Enterprise Plus).
  • Application Profile
    • An application profile, or app profile, stores settings indicate Bigtable on how to handle incoming requests from an application
    • Application profile helps define custom application-specific settings for handling incoming connections
    • Supports Request Priorities (GA April 2024) to prioritize certain workload data requests over others
    • Supports Row-Affinity Routing (GA Dec 2024) to automatically ensure single-row requests for a given row are routed to the same cluster
    • Supports Data Boost app profiles for serverless analytical compute
  • Cluster
    • Clusters handle the requests sent to a single Bigtable instance
    • Each cluster belongs to a single Bigtable instance, and an instance can have clusters in up to 8 regions
    • Each cluster is located in a single-zone
    • Bigtable instances with only 1 cluster do not use replication
    • An Instances with multiple clusters replicate the data, which
      • improves data availability and durability
      • improves scalability by routing different types of traffic to different clusters
      • provides failover capability, if another cluster becomes unavailable
    • If multiple clusters within an instance, Bigtable automatically starts replicating the data by keeping separate copies of the data in each of the clusters’ zones and synchronizing updates between the copies
    • 2x Node Scaling (GA Dec 2024) — treats two standard nodes as a larger, single compute node for improved performance stability at higher utilization rates
  • Nodes
    • Each cluster in an instance has 1 or more nodes, which are the compute resources that Bigtable uses to manage the data.
    • Each node in the cluster handles a subset of the requests to the cluster
    • All client requests go through a front-end server before they are sent to a Bigtable node.
    • Bigtable separates the Compute from the Storage. Data is never stored in nodes themselves; each node has pointers to a set of tablets that are stored on Colossus. This helps as
      • Rebalancing tablets from one node to another is very fast, as the actual data is not copied. Only pointers for each node are updated
      • Recovery from the failure of a Bigtable node is very fast as only the metadata needs to be migrated to the replacement node.
      • When a Bigtable node fails, no data is lost.
    • A Bigtable cluster can be scaled by adding nodes which would increase
      • the number of simultaneous requests that the cluster can handle
      • the maximum throughput of the cluster.
    • Each node is responsible for:
      • Keeping track of specific tablets on disk.
      • Handling incoming reads and writes for its tablets.
      • Performing maintenance tasks on its tablets, such as periodic compactions
    • Bigtable nodes are also referred to as tablet servers
  • Tables
    • Bigtable stores data in massively scalable tables, each of which is a sorted key/value map.
    • A Table belongs to an instance and not to the cluster or node.
    • A Bigtable table is sharded into blocks of contiguous rows, called tablets, to help balance the workload of queries.
    • Bigtable splits all of the data in a table into separate tablets.
    • Tablets are stored on the disk, separate from the nodes but in the same zone as the nodes.
    • Each tablet is associated with a specific Bigtable node.
    • Tablets are stored in SSTable format which provides a persistent, ordered immutable map from keys to values, where both keys and values are arbitrary byte strings.
    • In addition to the SSTable files, all writes are stored in Colossus’s shared log as soon as they are acknowledged by Bigtable, providing increased durability.
    • Tables support deletion protection (GA Dec 2022) to prevent accidental deletion.

Bigtable Storage Model

Bigtable Storage Model

  • Bigtable stores data in tables, each of which is a sorted key/value map.
  • A Table is composed of rows, each of which typically describes a single entity, and columns, which contain individual values for each row.
  • Each row is indexed by a single row key, and columns that are related to one another are typically grouped together into a column family.
  • Each column is identified by a combination of the column family and a column qualifier, which is a unique name within the column family.
  • Each row/column intersection can contain multiple cells.
  • Each cell contains a unique timestamped version of the data for that row and column.
  • Storing multiple cells in a column provides a record of how the stored data for that row and column has changed over time.
  • Bigtable tables are sparse; if a column is not used in a particular row, it does not take up any space.
  • Aggregate Columns (GA Aug 2024) — special column families that support write-time aggregation using SUM, MIN, MAX, and HyperLogLog (HLL). Enables distributed counters without read-modify-write cycles.

Bigtable Schema Design

  • Bigtable schema is a blueprint or model of a table that includes Row Keys, Column Families, and Columns
  • Bigtable is a key/value store, not a relational store. It does not support joins, and transactions are supported only within a single row.
  • Each table has only one index, the row key. There are no secondary indices natively, but Continuous Materialized Views (GA April 2026) can serve as asynchronous secondary indexes.
  • Rows are sorted lexicographically by row key, from the lowest to the highest byte string. Row keys are sorted in big-endian byte order, the binary equivalent of alphabetical order.
  • Column families are not stored in any specific order.
  • Columns are grouped by column family and sorted in lexicographic order within the column family.
  • Intersection of a row and column can contain multiple timestamped cells. Each cell contains a unique, timestamped version of the data for that row and column.
  • All operations are atomic at the row level. This means that an operation affects either an entire row or none of the row.
  • Bigtable tables are sparse. A column doesn’t take up any space in a row that doesn’t use the column.

Bigtable Replication

  • Bigtable Replication helps increase the availability and durability of the data by copying it across multiple zones in a region or multiple regions.
  • Replication helps isolate workloads by routing different types of requests to different clusters using application profiles.
  • Bigtable replication can be implemented by
    • creating a new instance with more than 1 cluster or
    • adding clusters to an existing instance.
  • Bigtable synchronizes the data between the clusters, creating a separate, independent copy of the data in each zone with the instance cluster.
  • Replicated clusters in different regions typically have higher replication latency than replicated clusters in the same region.
  • Bigtable replicates any changes to the data automatically, including all of the following types of changes:
    • Updates to the data in existing tables
    • New and deleted tables
    • Added and removed column families
    • Changes to a column family’s garbage collection policy
  • Bigtable treats each cluster in the instance as a primary cluster, so reads and writes can be performed in each cluster.
  • Application profiles can be created so that the requests from different types of applications are routed to different clusters.
  • Consistency Model
    • Eventual Consistency
      • Replication for Bigtable is eventually consistent, by default.
    • Read-your-writes Consistency
      • Bigtable can also provide read-your-writes consistency when replication is enabled, which ensures that an application will never read data that is older than its most recent writes.
      • To gain read-your-writes consistency for a group of applications, each application in the group must use an app profile that is configured for single-cluster routing, and all of the app profiles must route requests to the same cluster.
      • You can use the instance’s additional clusters at the same time for other purposes.
    • Strong Consistency
      • For some replication use cases, Bigtable can also provide strong consistency, which ensures that all of the applications see the data in the same state.
      • To gain strong consistency, you use the single-cluster routing app-profile configuration for read-your-writes consistency, but you must not use the instance’s additional clusters unless you need to failover to a different cluster.
  • Use cases
    • Isolate real-time serving applications from batch reads
    • Improve availability
    • Provide near-real-time backup
    • Ensure your data has a global presence

Bigtable Best Practices

  • Store datasets with similar schemas in the same table, rather than in separate tables as in SQL.
  • Bigtable has a limit of 1,000 tables per instance
  • Creating many small tables is a Bigtable anti-pattern.
  • Put related columns in the same column family
  • Create up to about 100 column families per table. A higher number would lead to performance degradation.
  • Choose short but meaningful names for your column families
  • Put columns that have different data retention needs in different column families to limit storage cost.
  • Create as many columns as you need in the table. Bigtable tables are sparse, and there is no space penalty for a column that is not used in a row
  • Don’t store more than 100 MB of data in a single row as a higher number would impact performance
    • Don’t store more than 10 MB of data in a single cell.
  • Design the row key based on the queries used to retrieve the data
  • Following queries provide the most efficient performance
    • Row key
    • Row key prefix
    • Range of rows defined by starting and ending row keys
  • Other types of queries trigger a full table scan, which is much less efficient.
  • Store multiple delimited values in each row key. Multiple identifiers can be included in the row key.
  • Use human-readable string values in your row keys whenever possible. Makes it easier to use the Key Visualizer tool.
  • Row keys anti-pattern
    • Row keys that start with a timestamp, as it causes sequential writes to a single node
    • Row keys that cause related data to not be grouped together, which would degrade the read performance
    • Sequential numeric IDs
    • Frequently updated identifiers
    • Hashed values as hashing a row key removes the ability to take advantage of Bigtable’s natural sorting order, making it impossible to store rows in a way that are optimal for querying
    • Values expressed as raw bytes rather than human-readable strings
    • Domain names, instead use the reverse domain name as the row key as related data can be clubbed.

Bigtable Load Balancing

  • Each Bigtable zone is managed by a primary process, which balances workload and data volume within clusters.
  • This process redistributes the data between nodes as needed as it
    • splits busier/larger tablets in half and
    • merges less-accessed/smaller tablets together
  • Bigtable automatically manages all of the splitting, merging, and rebalancing, saving users the effort of manually administering the tablets
  • Bigtable write performance can be improved by distributed writes as evenly as possible across nodes with proper row key design.

Bigtable Consistency

  • Single-cluster instances provide strong consistency.
  • Multi-cluster instances, by default, provide eventual consistency but can be configured to provide read-over-write consistency or strong consistency, depending on the workload and app profile settings

Bigtable Security

  • Access to the tables is controlled by your Google Cloud project and the Identity and Access Management (IAM) roles assigned to the users.
  • All data stored within Google Cloud, including the data in Bigtable tables, is encrypted at rest using Google’s default encryption.
  • Bigtable supports using customer-managed encryption keys (CMEK) for data encryption, including multi-region CMEK and Cloud EKM with Key Access Justification.
  • Authorized Views (GA April 2024) — control access to data at a sub-table level, enabling fine-grained data sharing without keeping multiple copies of data.
  • Logical Views (GA July 2025) — save a SQL query as a specific, shareable view of your data and control who has permission to see the results.
  • Bigtable supports IAM Conditions for conditional access control at instance, cluster, and table levels.
  • Bigtable supports tags for allow/deny security policies on instances.

Bigtable SQL Support (GA April 2025)

  • Bigtable supports GoogleSQL for read queries, the same SQL dialect used by BigQuery and Spanner.
  • SQL support is read-only — DML (INSERT, UPDATE, DELETE) and DDL (CREATE, ALTER, DROP) are not supported.
  • SQL queries can be run via the Bigtable Studio query editor, client libraries, JDBC driver (GA April 2026), or the Data API.
  • Supports window functions (GA April 2026), geography/geospatial functions (GA April 2026), and pipe syntax (GA April 2026).
  • The UNPACK table function lets you read time series data in a tabular format.
  • SQL queries do not support subqueries, JOINs, UNIONs, UNNEST, or CTEs.
  • Gemini in Bigtable Studio can help write GoogleSQL queries (Preview).

Bigtable Data Boost (GA February 2025)

  • Data Boost is a serverless compute service for high-throughput read jobs and queries without impacting operational cluster performance.
  • Provides isolated analytical processing on transactional data — eliminates the need to maintain multiple copies of data.
  • Supports a requester-pays model, billing data consumers directly for their usage.
  • Can be used with BigQuery external tables, Spark applications, and GoogleSQL queries.
  • Available in the Enterprise Plus edition (GA for SQL queries and tiered storage reads as of April 2026).

Bigtable Change Streams (GA July 2023)

  • A change stream captures data changes to a Bigtable table as the changes happen.
  • Changes can be streamed for processing or analysis via Dataflow.
  • Dataflow templates are available to stream change records to BigQuery or Pub/Sub.
  • Pub/Sub Bigtable Subscriptions (Preview April 2026) — stream Pub/Sub messages directly to a Bigtable table without needing Dataflow.
  • Use cases: event-driven architectures, real-time analytics, data synchronization, and audit trails.

Bigtable Continuous Materialized Views (GA April 2026)

  • Continuous materialized views are precomputed tables that Bigtable automatically keeps in sync with source data.
  • Defined using a continuously running SQL query that incrementally updates the view as data changes arrive.
  • Can serve as asynchronous secondary indexes — enabling fast lookups on non-row-key columns.
  • Support aggregation functions (SUM, COUNT, MIN, MAX, HLL) for real-time metrics and dashboards.
  • Supports up to 5 continuous materialized views per table.
  • No impact on write and read performance of the source table; scales automatically with traffic.

Bigtable In-Memory Tier (Preview, April 2026)

  • Part of the Enterprise Plus edition’s hybrid storage architecture.
  • Provides sub-millisecond read latency and up to 120,000 queries per second per row (hotspot resistance).
  • Supports independent vertical scaling to handle traffic surges without adding nodes.
  • Eliminates the need for a separate caching layer for latency-sensitive workloads.
  • Works seamlessly with Bigtable autoscaling.

Bigtable Backups

  • Bigtable backups let you save a copy of a table’s schema and data and restore it to a new table later.
  • Maximum backup retention period is 90 days (or up to 365 days with Enterprise Plus edition).
  • Hot Backups (GA Oct 2024) — optimized backups that restore data to production performance more efficiently.
  • Automated Backup (GA Feb 2025) — create daily backups automatically with configurable retention periods.
  • Cross-project restore (GA Dec 2022) — restore a backup to a different project.
  • Copy Backup (GA Aug 2023) — copy a backup and store it in any project or region.
  • When you undelete a table, deletion protection is automatically enabled for that table.

Bigtable Vector Search (GA April 2025)

  • Bigtable supports K-nearest neighbors (KNN) similarity vector search.
  • Enables building recommendation systems, semantic search, and ML feature stores directly in Bigtable.
  • Uses GoogleSQL for vector search queries.

Bigtable Integrations

  • BigQuery Federation (GA Aug 2022) — query Bigtable data directly from BigQuery using external tables.
  • Spark Connector (GA May 2024) — read/write data using Spark SQL and DataFrames.
  • LangChain (Preview April 2024, Vector/KV Store GA Oct 2025) — build LLM-powered applications with Bigtable as vector and key-value store.
  • Cassandra-Bigtable Proxy Adapter (GA Oct 2025) — connect Apache Cassandra-based applications directly to Bigtable.
  • Kafka Sink Connector (GA April 2025) — directly connect Apache Kafka to Bigtable.
  • MCP Servers (GA April 2026) — interact with Bigtable from LLMs and AI applications via Model Context Protocol.
  • Agent Development Kit (ADK) (GA March 2026) — build AI agents that query Bigtable metadata and execute SQL.
  • JDBC Driver (GA April 2026) — connect from Java applications and reporting tools via generic JDBC adapter.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company 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
  2. You want to optimize the performance of an accurate, real-time, weather-charting application. The data comes from 50,000 sensors sending 10 readings a second, in the format of a timestamp and sensor reading. Where should you store the data?
    1. Google BigQuery
    2. Google Cloud SQL
    3. Google Cloud Bigtable
    4. Google Cloud Storage
  3. Your team is working on designing an IoT solution. There are thousands of devices that need to send periodic time series data for
    processing. Which services should be used to ingest and store the data?

    1. Pub/Sub, Datastore
    2. Pub/Sub, Dataproc
    3. Dataproc, Bigtable
    4. Pub/Sub, Bigtable
  4. A company needs to run real-time analytics on operational data stored in Bigtable without impacting the performance of their production workloads. Which Bigtable feature should they use?
    1. Change Streams
    2. Data Boost
    3. Continuous Materialized Views
    4. BigQuery Federation
  5. You need to implement a real-time distributed counter system that can handle millions of increments per second across a globally distributed application. Which Bigtable feature is best suited for this?
    1. Read-modify-write operations
    2. Aggregate column families with SUM
    3. Continuous Materialized Views
    4. Change Streams to BigQuery
  6. Your application requires fast lookups on a non-row-key column in Bigtable. The lookups need to reflect changes in near real-time. What is the recommended approach?
    1. Create a second table with a different row key design
    2. Use GoogleSQL full table scans with filters
    3. Create a Continuous Materialized View as an asynchronous secondary index
    4. Export data to BigQuery for querying
  7. A financial services company needs sub-millisecond read latency for their high-frequency trading application stored in Bigtable, with resistance to hotspots on frequently accessed rows. Which Bigtable configuration should they use?
    1. SSD storage with autoscaling enabled
    2. Multi-cluster replication with row-affinity routing
    3. Enterprise Plus edition with In-Memory Tier
    4. Data Boost with single-cluster routing

References

GCP Professional Cloud Developer Cert Path

Google Cloud Profressional Cloud Developer Certificate
~ Last updated on : ~ jayendrapatil

Google Cloud – Professional Cloud Developer Certification learning path

📌 Last Updated: June 2026 — This post has been updated to reflect current exam format, service renamings (Cloud Run functions, Spot VMs, Sensitive Data Protection), deprecated services (Cloud Debugger shut down May 2023), and the transition to Pearson VUE for exam delivery.

Continuing on the Google Cloud Journey, glad to have passed the sixth certification with the Professional Cloud Developer certification.

Google Cloud – Professional Cloud Developer Certification Summary

  • The exam has 50-60 multiple choice and multiple select questions to be answered in 2 hours.
  • Registration fee is $200 (plus tax where applicable).
  • Covers a wide range of Google Cloud services mainly focusing on application development, containerization, CI/CD pipelines, and cloud service integration.
  • As of March 2026, exams are delivered through Pearson VUE (previously Kryterion). You can take the exam online-proctored or at a testing center.
  • Exams are being updated to reflect product updates announced at Google Cloud Next ’26, including Gemini and AI-related services. Refer to the exam guide for current topics.
  • Make sure you cover the case studies beforehand. I got ~5-6 questions and it can really be a savior for you in the exams.
  • As mentioned for all the exams, Hands-on is a MUST, if you have not worked on GCP before make sure you do lots of labs else you would be absolutely clueless about some of the questions and commands.
  • Google recommends 3+ years of industry experience including 1+ years designing and managing solutions using Google Cloud.

Google Cloud – Professional Cloud Developer Certification Resources

Google Cloud – Professional Cloud Developer Certification Topics

Case Studies

Compute Services

  • Compute services like Google Compute Engine, Google Kubernetes Engine, Cloud Run, and App Engine are covered with focus on selecting the right platform and security aspects.
  • Google Compute Engine
    • Google Compute Engine is the best IaaS option for compute and provides fine-grained control.
    • Compute Engine is recommended to be used with Service Account with the least privilege to provide access to Google services and the information can be queried from instance metadata.
    • Compute Engine Persistent disks can be attached to multiple VMs in read-only mode.
    • Compute Engine launch issues reasons:
      • Boot disk is full.
      • Boot disk is corrupted.
      • Boot Disk has an invalid master boot record (MBR).
      • Quota Errors.
      • Can be debugged using Serial console.
    • Spot VMs (previously known as Preemptible VMs) and their use cases. Spot VMs are the recommended replacement — they have no 24-hour maximum lifetime (unlike legacy Preemptible VMs) and run indefinitely as long as capacity is available. HINT — shutdown script to perform cleanup actions.
  • Cloud Run
    • Cloud Run is a fully managed serverless platform for deploying and running containerized applications without managing infrastructure.
    • Cloud Run services — run containers that are invocable via HTTP requests or events, with automatic scaling (including scale-to-zero).
    • Cloud Run jobs — run containers to completion for batch workloads, scripts, and data processing tasks (GA since 2023).
    • Cloud Run functions (formerly Cloud Functions, renamed August 2024) — event-driven functions with the same simple programming model, now deployed on Cloud Run infrastructure with fine-grained control over concurrency, CPU/memory, and networking.
    • Cloud Run supports GPU access for AI/ML inference workloads.
    • Cloud Run integrates with Eventarc for event delivery from 130+ Google Cloud sources.
    • Supports minimum instances to avoid cold starts, and maximum instances to control costs.
  • Google Kubernetes Engine
    • Google Kubernetes Engine enables running containers on Google Cloud.
    • GKE Autopilot is the recommended fully managed mode — Google manages nodes, nodepools, and scaling. In 2024, 30% of active GKE clusters used Autopilot mode. As of 2026, Autopilot is available to all qualifying clusters.
    • Understand GKE containers, Pods, Deployments, Service, DaemonSet, StatefulSets:
      • Pods are the smallest, most basic deployable objects in Kubernetes. A Pod represents a single instance of a running process in the cluster and can contain single or multiple containers.
      • Deployments represent a set of multiple, identical Pods with no unique identities. A Deployment runs multiple replicas of the application and automatically replaces any instances that fail or become unresponsive.
      • StatefulSets represent a set of Pods with unique, persistent identities and stable hostnames that GKE maintains regardless of where they are scheduled.
      • DaemonSets manage groups of replicated Pods. DaemonSets attempt to adhere to a one-Pod-per-node model, either across the entire cluster or a subset of nodes.
      • Service is to group a set of Pod endpoints into a single resource. GKE Services can be exposed as ClusterIP, NodePort, and Load Balancer.
      • Ingress object defines rules for routing HTTP(S) traffic to applications running in a cluster. An Ingress object is associated with one or more Service objects.
      • Gateway API is the next-generation routing API for Kubernetes (successor to Ingress). It provides expressive, extensible, and role-oriented traffic routing with built-in capabilities for header-based matching, traffic weighting, and traffic splitting.
    • GKE supports Horizontal Pod Autoscaler (HPA) to autoscale deployments based on CPU and Memory.
    • GKE supports health checks using liveness and readiness probes:
      • Readiness probes are designed to let Kubernetes know when the app is ready to serve traffic.
      • Liveness probes let Kubernetes know if the app is alive or dead.
    • Understand Workload Identity Federation for GKE (formerly Workload Identity) for security — the recommended way to provide Pods running on the cluster access to Google resources without service account keys.
    • GKE integrates with Istio/Anthos Service Mesh for mTLS and service-to-service security.
  • Google App Engine
  • Cloud Tasks
    • is a fully managed service that allows you to manage the execution, dispatch, and delivery of a large number of distributed tasks.

Security Services

  • Cloud Identity-Aware Proxy
    • Identity-Aware Proxy IAP allows managing access to HTTP-based apps both on Google Cloud and outside of Google Cloud.
    • IAP uses Google identities and IAM and can leverage external identity providers as well like OAuth with Facebook, Microsoft, SAML, etc.
    • Signed headers using JWT provide secondary security in case someone bypasses IAP.
  • Sensitive Data Protection (formerly Cloud DLP)
    • Sensitive Data Protection (previously Cloud Data Loss Prevention / Cloud DLP) is a fully managed service designed to help discover, classify, and protect the most sensitive data.
    • Provides key features:
      • Classification/Inspection — inspect the data and know what data you have, how sensitive it is, and the likelihood.
      • De-identification — the process of removing, masking, redaction, replacing information from data.
      • Discovery — continuously monitors data resources in your organization, profiling data sensitivity and risk levels across BigQuery, Cloud Storage, and Datastore.
  • Web Security Scanner
    • Web Security Scanner identifies security vulnerabilities in the App Engine, GKE, and Compute Engine web applications.
    • Scans provide information about application vulnerability findings, like OWASP, XSS, Flash injection, outdated libraries, cross-site scripting, clear-text passwords, or use of mixed content.
  • Secret Manager
    • Secret Manager stores API keys, passwords, certificates, and other sensitive data securely.
    • Provides versioning, automatic rotation, and fine-grained IAM access control.
    • Integrates natively with Cloud Run, GKE, and Cloud Build for secure secret injection.

Networking Services

  • Virtual Private Cloud
    • Understand Virtual Private Cloud (VPC), subnets, and host applications within them.
    • Private Access options for services allow instances with internal IP addresses to communicate with Google APIs and services.
    • Private Google Access allows VMs to connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM’s network interface.
  • Cloud Load Balancing
    • Google Cloud Load Balancing provides scaling, high availability, and traffic management for your internet-facing and private applications.

Identity Services

  • Resource Manager
    • Understand Resource Manager the hierarchy Organization → Folders → Projects → Resources.
    • IAM Policy inheritance is transitive and resources inherit the policies of all of their parent resources.
    • Effective policy for a resource is the union of the policy set on that resource and the policies inherited from higher up in the hierarchy.
  • Identity and Access Management
    • Identify and Access Management – IAM provides administrators the ability to manage cloud resources centrally by controlling who can take what action on specific resources.
    • A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.
    • Understand IAM Best Practices:
      • Use groups for users requiring the same responsibilities.
      • Use service accounts for server-to-server interactions.
      • Use Workload Identity Federation instead of service account keys for external workloads and GKE pods.
      • Use Organization Policy Service to get centralized and programmatic control over the organization’s cloud resources.
    • Domain-wide delegation of authority to grant third-party and internal applications access to the users’ data (e.g., Google Drive).

Storage Services

  • Cloud Storage
    • Cloud Storage is cost-effective object storage for unstructured data and provides an option for long term data retention.
    • Understand Signed URL to give temporary access and the users do not need to be GCP users. HINT: Signed URL would work for direct upload to GCS without routing the traffic through App Engine or CE.
    • Understand Google Cloud Storage Classes and Object Lifecycle Management to transition objects.
    • Retention Policies help define the retention period for the bucket, before which the objects in the bucket cannot be deleted.
    • Bucket Lock feature allows configuring a data retention policy for a bucket that governs how long objects in the bucket must be retained. The feature also allows locking the data retention policy, permanently preventing the policy from being reduced or removed.
    • Know Cloud Storage Best Practices — GCS auto-scaling performs well if requests ramp up gradually rather than having a sudden spike. Also, retry using exponential back-off strategy.
    • Cloud Storage can be used to host static websites.
    • Cloud CDN can be used with Cloud Storage to improve performance and enable caching.
  • Firestore
    • Firestore (successor to Cloud Datastore) provides a managed NoSQL document database built for automatic scaling, high performance, and ease of application development.
    • Firestore operates in Native mode (real-time sync, offline support) or Datastore mode (backward compatible with Cloud Datastore).
  • Artifact Registry
    • Artifact Registry is the recommended container and package registry (Container Registry was shut down on March 18, 2025).
    • Supports Docker images, language packages (Maven, npm, Python, etc.), and OS packages.
    • Integrates with Cloud Build for CI/CD pipelines and provides vulnerability scanning.

Developer Tools

  • Google Cloud Build
    • Cloud Build is a serverless CI/CD platform that integrates with GitHub, GitLab, and Bitbucket (Cloud Source Repositories is no longer available to new customers as of June 2024; Secure Source Manager is the replacement).
    • Cloud Build can import source code, execute build to specifications, and produce artifacts such as Docker containers or Java archives.
    • Cloud Build build config file specifies the instructions to perform, with steps defined for each task like test, build, and deploy.
    • Cloud Build supports custom images as well for the steps.
    • Cloud Build uses a directory named /workspace as a working directory and the assets produced by one step can be passed to the next one via the persistence of the /workspace directory.
    • Cloud Build 2nd gen repositories provide improved integration with GitHub and GitLab.
  • Google Cloud Code
    • Cloud Code helps write, debug, and deploy cloud-based applications for IntelliJ, VS Code, or in the browser.
  • Google Cloud Client Libraries
    • Google Cloud Client Libraries provide client libraries and SDKs in various languages for calling Google Cloud APIs.
    • If the language is not supported, Cloud REST APIs can be used.
  • Deployment Techniques
    • Recreate deployment — fully scale down the existing application version before you scale up the new application version.
    • Rolling update — update a subset of running application instances instead of simultaneously updating every application instance.
    • Blue/Green deployment — (also known as a red/black deployment), perform two identical deployments of your application.
    • GKE supports Rolling and Recreate deployments.
      • Rolling deployments support maxSurge (new pods would be created) and maxUnavailable (existing pods would be deleted).
    • Managed Instance Groups support Rolling deployments using maxSurge and maxUnavailable configurations.
    • Cloud Run supports traffic splitting for gradual rollouts (route percentages between revisions).
  • Testing Strategies
    • Canary testing — partially roll out a change and then evaluate its performance against a baseline deployment.
    • A/B testing — test a hypothesis by using variant implementations. A/B testing is used to make business decisions (not only predictions) based on the results derived from data.

Data Services

  • Bigtable
  • Cloud Pub/Sub
    • Understand Cloud Pub/Sub as an asynchronous messaging service.
    • Know patterns for One to Many, Many to One, and Many to Many.
    • roles/publisher and roles/pubsub.subscriber provides applications with the ability to publish and consume.
  • Cloud SQL
    • Cloud SQL is a fully managed service that provides MySQL, PostgreSQL, and Microsoft SQL Server.
    • HA configuration provides data redundancy and failover capability with minimal downtime when a zone or instance becomes unavailable.
    • Read replicas help scale horizontally the use of data in a database without degrading performance.
  • Cloud Spanner
    • is a fully managed relational database with unlimited scale, strong consistency, and up to 99.999% availability.
    • Can read and write up-to-date strongly consistent data globally.
    • Multi-region instances give higher availability guarantees (99.999% availability) and global scale.
    • Cloud Spanner’s table interleaving is a good choice for many parent-child relationships where the child table’s primary key includes the parent table’s primary key columns.

Monitoring & Observability

  • Google Cloud Monitoring (part of Google Cloud Observability, formerly Stackdriver)
    • Provides monitoring, alerting, error reporting, metrics, and diagnostics.
    • Cloud Monitoring helps gain visibility into the performance, availability, and health of your applications and infrastructure.
  • Google Cloud Logging
    • Cloud Logging provides real-time log management and analysis.
    • Cloud Logging allows ingestion of custom log data from any source.
    • Logs can be exported by configuring log sinks to BigQuery, Cloud Storage, or Pub/Sub.
    • Cloud Logging Agent (Ops Agent) can be installed for logging and capturing application logs.
  • Cloud Error Reporting
    • Counts, analyzes, and aggregates the crashes in the running cloud services.
  • Cloud Trace
    • is a distributed tracing system that collects latency data from the applications and displays it in the Google Cloud Console.
    • Supports OpenTelemetry Protocol (OTLP) for sending trace data — the recommended approach for new and existing users.
  • Cloud Debugger
    • ⚠️ DEPRECATED: Cloud Debugger was deprecated on May 16, 2022 and shut down on May 31, 2023. It is no longer available.

      Alternative: Use Snapshot Debugger (open-source) or standard logging/tracing with Cloud Logging and Cloud Trace for application debugging.

All the Best !!

Google Cloud Pub/Sub – Messaging & Event Streaming

~ Last updated on : ~ jayendrapatil

Google Cloud Pub/Sub

  • Pub/Sub is a fully managed, asynchronous messaging service designed to be highly reliable and scalable.
  • Pub/Sub service allows applications to exchange messages reliably, quickly, and asynchronously
  • Pub/Sub allows services to communicate asynchronously, with latencies on the order of 100 milliseconds.
  • Pub/Sub enables the creation of event producers and consumers, called publishers and subscribers.
  • Publishers communicate with subscribers asynchronously by broadcasting events, rather than by synchronous remote procedure calls.
  • Pub/Sub offers at-least-once message delivery and best-effort ordering to existing subscribers
  • Pub/Sub also supports exactly-once delivery for pull subscriptions, ensuring messages are not redelivered after a successful acknowledgment within the same region.
  • Pub/Sub accepts a maximum of 1,000 messages in a batch, and the size of a batch can not exceed 10 megabytes.
  • Pub/Sub serves as a versatile entry point to ingest streaming data into Google Cloud’s ecosystem and is integrated with products like BigQuery, Cloud Storage, Dataflow, and more.

🆕 What’s New (2024-2025)

  • Import Topics — No-code ingestion from AWS Kinesis Data Streams, Cloud Storage, Azure Event Hubs, Amazon MSK, and Confluent Cloud (2024)
  • Single Message Transforms (SMTs) — JavaScript UDFs and AI Inference transforms directly within Pub/Sub (GA June 2025)
  • Bigtable Subscriptions — Direct export to Cloud Bigtable (2025)
  • OpenTelemetry Tracing — Distributed tracing for the full message lifecycle (2024)
  • Pub/Sub Lite deprecated — EOL March 18, 2026; migrate to standard Pub/Sub or Managed Service for Apache Kafka

Pub/Sub Core Concepts

  • Topic: A named resource to which messages are sent by publishers.
  • Publisher: An application that creates and sends messages to a topic(s).
  • Subscriber: An application with a subscription to a topic(s) to receive messages from it.
  • Subscription: A named resource representing the stream of messages from a single, specific topic, to be delivered to the subscribing application.
  • Message: The combination of data and (optional) attributes that a publisher sends to a topic and is eventually delivered to subscribers.
  • Message attribute: A key-value pair that a publisher can define for a message.
  • Acknowledgment (or “ack”): A signal sent by a subscriber to Pub/Sub after it has received a message successfully. Acked messages are removed from the subscription’s message queue.
  • Schema: A schema is a format that messages must follow, creating a contract between publisher and subscriber that Pub/Sub will enforce
  • Push and pull: The two message delivery methods. A subscriber receives messages either by Pub/Sub pushing them to the subscriber’s chosen endpoint or by the subscriber pulling them from the service.

Message lifecycle

Pub/Sub Topic Types

  • Pub/Sub supports two kinds of topics: Standard topics and Import topics.
  • Standard Topic
    • A standard topic receives messages from publishers through Pub/Sub client libraries or REST/gRPC APIs.
  • Import Topics (New – 2024)
    • Import topics provide a fully managed, no-code way to ingest streaming data from external sources directly into Pub/Sub.
    • Supported sources include:
      • AWS Kinesis Data Streams — Ingest streaming data from AWS Kinesis without custom connectors
      • Cloud Storage — Ingest batch data from GCS buckets for batch-to-streaming use cases or replaying archived data
      • Azure Event Hubs — Ingest from Azure messaging infrastructure
      • Amazon MSK (Managed Streaming for Apache Kafka) — Cross-cloud Kafka ingestion
      • Confluent Cloud — Ingest from Confluent Kafka clusters
    • Once data flows into an import topic, you can create any subscription type (Pull, Push, BigQuery, or Cloud Storage) to route data to downstream sinks.

Pub/Sub Subscription Types

  • Pull Subscription
    • The subscriber application initiates requests to the Pub/Sub server to retrieve messages.
    • If unspecified, Pub/Sub subscriptions use pull delivery.
  • Push Subscription
    • Pub/Sub initiates requests to the subscriber application to deliver messages.
    • The push endpoint must be a publicly accessible HTTPS address.
  • BigQuery Subscription (Export Subscription)
    • Writes messages directly from Pub/Sub to a BigQuery table without needing Dataflow or custom middleware.
    • Supports BigQuery tables for Apache Iceberg for high-throughput ingestion stored in Parquet format.
  • Cloud Storage Subscription (Export Subscription)
    • Writes messages directly from Pub/Sub to Cloud Storage buckets in Text or Avro format.
  • Bigtable Subscription (Export Subscription – New 2025)
    • Writes messages directly from Pub/Sub into Cloud Bigtable tables.
  • Messages published before a subscription is created will not be delivered to that subscription

Pub/Sub Subscription Properties

  • Acknowledgment deadline
    • Message not acknowledged before the deadline is sent again.
    • Default acknowledgment deadline is 10 secs. with a min of 10 secs and max of 600 secs (10 mins).
  • Message retention duration
    • Message retention duration specifies how long Pub/Sub retains messages after publication.
    • Acknowledged messages are no longer available to subscribers and are deleted, by default
    • After the message retention duration, Pub/Sub might discard the message, regardless of its acknowledgment state.
    • Default message retention duration is 7 days with a min of 10 mins and max of 31 days
    • Retaining unacknowledged messages for more than 24 hours incurs additional storage charges.
  • Dead-letter topics
    • If a subscriber can’t acknowledge a message, Pub/Sub can forward the message to a dead-letter topic.
    • With a dead-letter topic, message ordering can’t be enabled
    • With a dead-letter topic, the maximum number of delivery attempts can be specified.
    • Default is 5 delivery attempts; with a min-max of 5-100
  • Expiration period
    • Subscriptions expire without any subscriber activity such as open connections, active pulls, or successful pushes
    • Subscription deletion clock restarts, if subscriber activity is detected or subscription properties are updated
    • Default expiration period is 31 days with a min of 1 day; can be set to “never expire”
  • Retry policy
    • If the acknowledgment deadline expires or a subscriber responds with a negative acknowledgment, Pub/Sub can send the message again using exponential backoff.
    • If the retry policy isn’t set, Pub/Sub resends the message as soon as the acknowledgment deadline expires or a subscriber responds with a negative acknowledgment (Retry immediately).
    • Maximum and minimum backoff values can be configured, with a maximum backoff of 600 seconds.
  • Message ordering
    • If publishers send messages with an ordering key, are in the same region and message ordering is set, Pub/Sub delivers the messages in order.
    • If not set, Pub/Sub doesn’t deliver messages in order, including messages with ordering keys.
    • When using ordered delivery, acknowledgments for later messages are not processed until acknowledgments for earlier messages are processed.
  • Filter
    • Filter is a string with a filtering expression where the subscription only delivers the messages that match the filter.
    • Pub/Sub service automatically acknowledges the messages that don’t match the filter.
    • Messages can be filtered using their attributes.
    • Filters cannot be changed or removed after they are applied.
    • Filtered (auto-acknowledged) messages don’t incur egress fees but do incur message delivery fees.
  • Exactly-once delivery
    • Pub/Sub supports exactly-once delivery for pull subscriptions (including StreamingPull).
    • Push and export subscriptions don’t support exactly-once delivery.
    • Exactly-once guarantee only applies when subscribers connect to the service in the same region.
    • Provides stronger guarantees that messages are not redelivered before the acknowledgment deadline passes.

Pub/Sub Single Message Transforms (SMTs)

  • Single Message Transforms (SMTs) allow lightweight modifications to message attributes and data directly within Pub/Sub without additional services. (GA June 2025)
  • SMTs can be applied to a topic, a subscription, or both independently.
  • Up to five transforms can be added per topic or subscription.
  • JavaScript User-Defined Functions (UDFs)
    • Perform lightweight modifications to message data and attributes using JavaScript code snippets.
    • Use cases include: data format conversion, field casting, adding composite fields, data masking/redaction of PII, and enhanced filtering on message data (not just attributes).
    • If a Topic SMT is configured, the message is transformed and persisted in its transformed state.
    • If a Subscription SMT is configured, the message is transformed before delivery to the subscriber.
  • AI Inference SMT
    • Sends message data to a Vertex AI endpoint for inference and enriches/transforms the message with the response.
  • SMTs eliminate the need for maintaining extra services (Dataflow, Cloud Run) for simple, lightweight transformations.

Pub/Sub Seek Feature

  • Acknowledged messages are no longer available to subscribers and are deleted
  • Subscriber clients must process every message in a subscription even if only a subset is needed.
  • Seek feature extends subscriber functionality by allowing you to alter the acknowledgment state of messages in bulk
  • Timestamp Seeking
    • With Seek feature, you can replay previously acknowledged messages or purge messages in bulk
    • Seeking to a time marks every message received by Pub/Sub before the time as acknowledged, and all messages received after the time as unacknowledged.
    • Seeking to a time in the future allows you to purge messages.
    • Seeking to a time in the past allows replay and reprocess previously acknowledged messages
    • Timestamp seeking approach is imprecise as
      • Possible clock skew among Pub/Sub servers.
      • Pub/Sub has to work with the arrival time of the publish request rather than when an event occurred in the source system.
  • Snapshot Seeking
    • State of one subscription can be copied to another by using seek in combination with a Snapshot.
    • Once a snapshot is created, it retains:
      • All messages that were unacknowledged in the source subscription at the time of the snapshot’s creation.
      • Any messages published to the topic thereafter.
    • The maximum possible lifetime of a snapshot is seven days.

Pub/Sub Locations

  • Pub/Sub servers run in all GCP regions around the world, which helps offer fast, global data access while giving users control over where messages are stored
  • Cloud Pub/Sub offers global data access in that publisher and subscriber clients are not aware of the location of the servers to which they connect or how those services route the data.
  • Pub/Sub’s load balancing mechanisms direct publisher traffic to the nearest GCP data center where data storage is allowed, as defined in the Resource Location Restriction
  • Publishers in multiple regions may publish messages to a single topic with low latency. Any individual message is stored in a single region. However, a topic may have messages stored in many regions.
  • Subscriber client requesting messages published to this topic connects to the nearest server which aggregates data from all messages published to the topic for delivery to the client.
  • Message Storage Policy
    • Message Storage Policy helps ensure that messages published to a topic are never persisted outside a set of specified Google Cloud regions, regardless of where the publish requests originate.
    • Pub/Sub chooses the nearest allowed region, when multiple regions are allowed by the policy

Pub/Sub Security

  • Pub/Sub encrypts messages with Google-managed keys, by default.
  • Pub/Sub also supports Customer-Managed Encryption Keys (CMEK) using Cloud KMS, giving control over key protection level, location, rotation schedule, usage permissions, and cryptographic boundaries.
  • Every message is encrypted at the following states and layers:
    • At rest
      • Hardware layer
      • Infrastructure layer
      • Application layer
        • Pub/Sub individually encrypts incoming messages as soon as the message is received
    • In transit
  • Pub/Sub does not encrypt message attributes at the application layer.
  • Message attributes are still encrypted at the hardware and infrastructure layers.

Pub/Sub Observability

  • OpenTelemetry Tracing (New – 2024)
    • Provides a detailed distributed trace of the message lifecycle, from publish to receive and process.
    • Helps identify bottlenecks, misconfigurations, and failures in Pub/Sub applications.
    • Allows tracing of client library operations including batching, lease management, and flow control.
    • Integrates with Cloud Trace for analysis.
  • Cloud Monitoring Integration
    • Monitor topics and subscriptions with built-in metrics.
    • Labels can be used to organize and filter monitoring data.

Pub/Sub Integrations

  • Dataflow — Natively integrated for stream processing pipelines.
  • BigQuery Engine for Apache Flink — Serverless Flink with native Pub/Sub integration (Preview 2024).
  • Apache Flink Connector — GA connector for existing Flink deployments to read from/write to Pub/Sub.
  • BigQuery Continuous Queries — Process real-time data in BigQuery and export results to a Pub/Sub topic (reverse ETL).
  • Analytics Hub — Share Pub/Sub topics as data products for real-time streaming data sharing across organizations (Preview 2024).
  • Cloud Run / Cloud Functions — Event-driven compute triggered by Pub/Sub messages.

Common use cases

  • Ingestion user interaction and server events
  • Real-time event distribution
  • Replicating data among databases
  • Parallel processing and workflows
  • Data streaming from IoT devices
  • Refreshing distributed caches
  • Load balancing for reliability
  • Cross-cloud data ingestion (AWS, Azure)
  • Streaming data sharing and monetization

Pub/Sub Lite (Deprecated)

⚠️ Pub/Sub Lite — DEPRECATED

Pub/Sub Lite reached End of Life (EOL) on March 18, 2026.

New customers could not access Pub/Sub Lite after September 24, 2024. Existing customers had until March 18, 2026.

Migration Options:

  • Standard Pub/Sub — Fully managed, auto-scaling messaging with global routing
  • Google Cloud Managed Service for Apache Kafka — Managed Kafka for teams requiring Kafka API compatibility

GCP Certification Exam Practice Questions

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

Questions on New Features:

  1. A company wants to ingest streaming data from AWS Kinesis Data Streams into BigQuery without maintaining custom connectors. What is the simplest approach using Pub/Sub?
    1. Use a Dataflow pipeline to read from Kinesis and write to Pub/Sub
    2. Use a Pub/Sub import topic configured for AWS Kinesis Data Streams, then create a BigQuery subscription
    3. Use Cloud Functions to poll Kinesis and publish to Pub/Sub
    4. Use the Kafka Connect Pub/Sub connector

    Answer: b. Import topics provide no-code ingestion from Kinesis, and BigQuery subscriptions write directly to BigQuery.

  2. Which Pub/Sub delivery guarantee requires subscribers to connect to the service in the same region?
    1. At-least-once delivery
    2. At-most-once delivery
    3. Exactly-once delivery
    4. Best-effort delivery

    Answer: c. Exactly-once delivery guarantee only applies when subscribers connect in the same region.

  3. A team needs to redact PII from messages before they are delivered to subscribers, without deploying additional infrastructure. Which Pub/Sub feature should they use?
    1. Subscription filters
    2. Dead-letter topics
    3. Single Message Transforms with JavaScript UDFs
    4. Schema validation

    Answer: c. SMTs with JavaScript UDFs can perform data masking and redaction directly within Pub/Sub.

  4. Which subscription types does Pub/Sub’s exactly-once delivery support? (Choose TWO)
    1. Pull subscriptions
    2. Push subscriptions
    3. BigQuery subscriptions
    4. StreamingPull subscriptions
    5. Cloud Storage subscriptions

    Answer: a, d. Exactly-once delivery is supported for pull subscriptions including StreamingPull. Push and export subscriptions do not support it.

  5. An organization using Pub/Sub Lite needs to migrate before the service is discontinued. What are the recommended migration targets? (Choose TWO)
    1. Cloud Tasks
    2. Standard Pub/Sub
    3. Cloud Scheduler
    4. Google Cloud Managed Service for Apache Kafka
    5. Eventarc

    Answer: b, d. Google recommends migrating Pub/Sub Lite workloads to standard Pub/Sub or Managed Service for Apache Kafka.

  6. Where can Single Message Transforms (SMTs) be applied in Pub/Sub? (Choose TWO)
    1. At the project level
    2. On a topic
    3. On a subscription
    4. At the message attribute level only
    5. On the dead-letter topic

    Answer: b, c. SMTs can be applied independently to a topic, a subscription, or both.

References

GKE Security – Workload Identity, RBAC & Hardening

~ Last updated on : ~ jayendrapatil

GKE Security

Google Kubernetes Engine – GKE Security provides multiple layers of security to secure workloads including the contents of the container image, the container runtime, the cluster network, and access to the cluster API server.

Authentication and Authorization

  • Kubernetes supports two types of authentication:
    • User accounts are accounts that are known to Kubernetes but are not managed by Kubernetes
    • Service accounts are accounts that are created and managed by Kubernetes but can only be used by Kubernetes-created entities, such as pods.
  • In a GKE cluster, Kubernetes user accounts are managed by Google Cloud and can be of the following type
    • Google Account
    • Google Cloud service account
  • Once authenticated, these identities need to be authorized to create, read, update or delete Kubernetes resources.
  • Kubernetes service accounts and Google Cloud service accounts are different entities.
    • Kubernetes service accounts are part of the cluster in which they are defined and are typically used within that cluster.
    • Google Cloud service accounts are part of a Google Cloud project, and can easily be granted permissions both within clusters and to Google Cloud project clusters themselves, as well as to any Google Cloud resource using IAM.

Control Plane Security

  • In GKE, the Kubernetes control plane components are managed and maintained by Google.
  • Control plane components host the software that runs the Kubernetes control plane, including the API server, scheduler, controller manager, and the etcd database where the Kubernetes configuration is persisted.
  • By default, the control plane components use a public IP address.
  • Kubernetes API server can be protected by using authorized networks, and private clusters, which allow assigning a private IP address to the control plane and disable access on the public IP address.
  • Control plane can also be secured by doing credential rotation on a regular basis. When credential rotation is initiated, the SSL certificates and cluster certificate authority are rotated. This process is automated by GKE and also ensures that your control plane IP address rotates.
  • GKE encrypts etcd data at rest by default. Application-layer secrets encryption provides an additional layer of security by encrypting Kubernetes Secrets in etcd using a Cloud KMS key that you manage.

Node Security

Container-Optimized OS

  • GKE nodes, by default, use Google’s Container-Optimized OS (cos_containerd) as the operating system on which to run Kubernetes and its components.
  • Container-Optimized OS features include
    • Locked-down firewall
    • Read-only filesystem where possible
    • Limited user accounts and disabled root login
  • GKE uses containerd as the container runtime for all new clusters and node pools.

Shielded GKE Nodes

  • Shielded GKE Nodes provide verifiable node identity and integrity by using Secure Boot, vTPM, and integrity monitoring.
  • Shielded GKE Nodes are enabled by default and cannot be overridden on new clusters.
  • They protect against boot-level and kernel-level malware or rootkits that could persist beyond an infected OS.

Node upgrades

  • GKE recommends upgrading nodes on a regular basis to patch the OS for security issues in the container runtime, Kubernetes itself, or the node operating system.
  • GKE supports automatic as well as manual upgrades.
  • GKE automatically applies security patches to nodes when available, adhering to configured maintenance schedules.

Protecting nodes from untrusted workloads

  • GKE Sandbox can be enabled on the cluster to isolate untrusted workloads in sandboxes on the node if the clusters run unknown or untrusted workloads.
  • GKE Sandbox is built using gVisor, an open-source container runtime that provides a specialized guest kernel for each container, intercepting system calls between the application and the host kernel.
  • GKE Agent Sandbox (2025) is an evolution of GKE Sandbox optimized for AI agent workloads, providing kernel-level isolation for untrusted LLM-generated code execution with sub-second latency and the ability to orchestrate hundreds of sandboxes per second.

Seccomp Profiles

  • GKE applies the default containerd seccomp profile to provide baseline syscall filtering while maintaining workload compatibility.
  • Autopilot clusters enforce Pod Security Standards at the Baseline level by default, preventing known privilege escalation pathways.

Securing instance metadata

  • GKE nodes run as Compute Engine instances and have access to instance metadata by default, which a Pod running on the node does not necessarily need.
  • Workload Identity Federation for GKE replaces the need to use Metadata Concealment. When Workload Identity Federation is enabled, it blocks access to the node’s metadata server from workloads.
  • Legacy metadata APIs are disabled by default on GKE versions 1.12 and newer.

Network Security

  • Network Policies help cluster administrators and users lock down the ingress and egress connections created to and from the Pods in a namespace.
  • GKE has two mutually exclusive network policy plugins:
    • GKE Dataplane V2 (based on Cilium/eBPF) – the recommended plugin for all clusters and the default for Autopilot clusters. Provides enhanced visibility, performance, and advanced policy features.
    • Calico (iptables-based) – available only in Standard clusters.
  • FQDN Network Policies (GKE Dataplane V2) allow controlling Pod egress traffic based on fully qualified domain names rather than IP addresses.
  • mTLS for Pod-to-Pod communication can be enabled using Cloud Service Mesh (previously known as Istio on GKE/Anthos Service Mesh).

Giving Pods Access to Google Cloud Resources

Workload Identity Federation for GKE (recommended)

  • Workload Identity Federation for GKE (previously called Workload Identity) is the simplest and most secure way to authorize Pods to access Google Cloud resources.
  • Pods authenticate with short-lived federated tokens tied to their Kubernetes ServiceAccount — no long-lived credentials are stored in the container.
  • Kubernetes entities (clusters, service accounts) can now be addressed directly as IAM principals.
  • Workload Identity Federation for GKE replaces the need for Metadata Concealment, and the two approaches are incompatible.
  • Fleet Workload Identity Federation extends this capability across an entire fleet, including clusters outside Google Cloud and across multiple projects.

Node Service Account

  • Pods can authenticate to Google Cloud using the Kubernetes cluster’s service account credentials from metadata.
  • Node Service Account credentials can be reached by any Pod running in the cluster if Workload Identity Federation is not enabled.
  • It is recommended to create and configure a custom service account that has the minimum IAM roles required by all the Pods running in the cluster.

Service Account JSON key

  • Applications can access Google Cloud resources by using the service account’s key.
  • This approach is NOT recommended because of the difficulty of securely managing account keys.
  • A JSON service account key can be created and then mounted into the Pod using a Kubernetes Secret.
  • Workload Identity Federation for GKE eliminates the need for key files entirely and is the preferred alternative.

Secrets Management

  • Application-layer Secrets Encryption encrypts Kubernetes Secrets stored in etcd using a Cloud KMS key that you manage, providing an additional layer of protection beyond default GKE encryption.
  • Secret Manager add-on for GKE allows Pods to directly access secrets stored in Google Cloud Secret Manager via the Secrets Store CSI Driver, without requiring custom code.
  • Secret Manager add-on supports auto-rotation and syncing secrets as Kubernetes Secret objects.

Binary Authorization

  • Binary Authorization helps ensure that internal processes that safeguard the quality and integrity of the software have successfully completed before an application is deployed to the production environment.
  • Binary Authorization works with images deployed to GKE from Artifact Registry (Container Registry was shut down on March 18, 2025).
  • Binary Authorization provides:
    • A policy model that lets you describe the constraints under which images can be deployed
    • An attestation model that lets you define trusted authorities who can attest or verify that required processes have completed before deployment
    • A deploy-time enforcer that prevents images that violate the policy from being deployed
  • Continuous Validation (CV) monitors running Pods to ensure their container images continue to conform to Binary Authorization check-based platform policies, including:
    • Image freshness checks
    • Simple signing attestation checks
    • Sigstore signature verification
    • SLSA provenance checks (requires Cloud Build)
    • Vulnerability checks

GKE Autopilot Security

  • Autopilot mode clusters have a stricter default security posture than Standard mode clusters.
  • GKE Autopilot automatically configures nodes, node pools, and in-cluster policy according to security best practices.
  • Key Autopilot security defaults:
    • Workload Identity Federation for GKE is always enabled
    • Shielded GKE Nodes are enabled
    • GKE Dataplane V2 is the default network plugin
    • Pod Security Standards are enforced at the Baseline level
    • Privileged containers and host namespace access are restricted
    • Container-Optimized OS with containerd is the only supported node image

GKE Security Posture

  • The GKE security posture dashboard helps proactively identify and address security vulnerabilities in GKE clusters.
  • Features include Kubernetes security configuration scanning (misconfiguration detection) and workload vulnerability scanning.
  • Note: As of January 2025, several GKE security posture capabilities have been deprecated:
    • GKE threat detection (deprecated Jan 28, 2025, shut down March 31, 2025)
    • GKE Compliance dashboard (deprecated Jan 28, 2025)
    • Workload vulnerability scanning in GKE Standard edition has been removed; it requires GKE Enterprise edition
  • For comprehensive threat detection and vulnerability management, Google recommends using Security Command Center.

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 are building a product on top of Google Kubernetes Engine (GKE). You have a single GKE cluster. For each of your customers, a Pod is running in that cluster, and your customers can run arbitrary code inside their Pod. You want to maximize the isolation between your customers’ Pods. What should you do?
    1. Use Binary Authorization and whitelist only the container images used by your customers’ Pods.
    2. Use the Container Analysis API to detect vulnerabilities in the containers used by your customers’ Pods.
    3. Create a GKE node pool with a sandbox type configured to gVisor. Add the parameter runtimeClassName: gvisor to the specification of your customers’ Pods.
    4. Use the cos_containerd image for your GKE nodes. Add a nodeSelector with the value cloud.google.com/gke-os-distribution: cos_containerd to the specification of your customers’ Pods.
  2. Your organization runs workloads on GKE and wants to ensure that Pods can only access Google Cloud APIs using short-lived credentials without managing service account keys. What should you configure?
    1. Create a Google Cloud service account key and store it as a Kubernetes Secret.
    2. Enable Workload Identity Federation for GKE and bind the Kubernetes ServiceAccount to a Google Cloud service account as an IAM principal.
    3. Use the node’s default service account credentials with metadata concealment enabled.
    4. Download a service account key and mount it as a volume in the Pod.
  3. You need to control egress traffic from Pods in your GKE cluster to specific external services by domain name. Which feature should you use?
    1. Standard Kubernetes NetworkPolicy with IP address blocks.
    2. Cloud Armor policies applied to the cluster.
    3. FQDN Network Policies with GKE Dataplane V2 enabled.
    4. VPC firewall rules targeting the node IP addresses.
  4. Your company needs to ensure that only container images that have been verified and attested by your CI/CD pipeline can be deployed to your GKE production cluster. Additionally, you want ongoing monitoring of running workloads. What should you implement?
    1. Use Artifact Registry vulnerability scanning only.
    2. Configure Pod Security Standards at the Restricted level.
    3. Enable Binary Authorization with attestation policies and Continuous Validation (CV) for runtime monitoring.
    4. Use GKE Sandbox to isolate all production workloads.
  5. You want your GKE cluster to have the strongest default security configuration with minimal manual setup. Which cluster mode should you use?
    1. Standard mode with all security features manually enabled.
    2. Autopilot mode, which enforces security best practices by default including Workload Identity Federation, Shielded Nodes, and Pod Security Standards.
    3. Standard mode with Container-Optimized OS selected.
    4. Standard mode with Shielded GKE Nodes enabled.

References

Cloud Run Functions – Serverless Event Processing

~ Last updated on : ~ jayendrapatil

Google Cloud Run Functions (formerly Cloud Functions)

📢 Important Rebranding (August 2024): Google Cloud Functions has been renamed to Cloud Run functions. Cloud Functions (2nd gen) is now “Cloud Run functions” and is deployed as a service on Cloud Run. Cloud Functions (1st gen) is now “Cloud Run functions (1st gen).” All new functions should use Cloud Run functions (the latest version).

  • Cloud Run functions (formerly Cloud Functions) is a serverless execution environment for building and connecting cloud services.
  • Cloud Run functions provide scalable pay-as-you-go functions as a service (FaaS) to run code with zero server management.
  • Cloud Run functions are attached to events emitted from cloud services and infrastructure and are triggered when an event being watched is fired.
  • Cloud Run functions supports multiple language runtimes including Node.js, Python, Go, Java, .NET, Ruby, and PHP.
  • Cloud Run functions features include
    • Zero server management
      • No servers to provision, manage, or upgrade
      • Google Cloud handles the operational infrastructure including managing servers, configuring software, updating frameworks, and patching operating systems
      • Provisioning of resources happens automatically in response to events
    • Automatically scale based on the load
      • Cloud Run functions can scale from a few invocations a day to many millions of invocations without any work from you.
    • Integrated monitoring, logging, and debugging capability
    • Built-in security at role and per function level based on the principle of least privilege
      • Cloud Run functions uses Google Service Account credentials to seamlessly authenticate with the majority of Google Cloud services
      • Supports Secret Manager integration for securely accessing API keys and credentials
      • Supports Customer-Managed Encryption Keys (CMEK) for encrypting function source code and container images
    • Key networking capabilities for hybrid and multi-cloud scenarios
      • Direct VPC egress support for connecting to VPC networks
      • Shared VPC support
      • Static outbound IP address configuration

Cloud Run Functions Versions

  • There are two versions of Cloud Run functions:
    • Cloud Run functions (formerly Cloud Functions 2nd gen) — the latest version, deployed as a service on Cloud Run
      • Can be created using the Cloud Run Admin API (recommended) or the Cloud Functions v2 API
      • Built on Cloud Run infrastructure for better performance, scalability, and configurability
      • Uses run.app URL endpoint
    • Cloud Run functions (1st gen) (formerly Cloud Functions 1st gen) — the original version with limited event triggers, runtimes, and configurability
      • Uses cloudfunctions.net URL endpoint
      • Google plans to continue supporting 1st gen but recommends 2nd gen for new functions
  • Key differences between versions:
    Feature Cloud Run functions (Latest) Cloud Run functions (1st gen)
    Request Timeout Up to 60 minutes (HTTP), 9 minutes (event-driven via v2 API) Up to 9 minutes
    Instance Size Up to 16 GiB RAM with 4 vCPU Up to 8 GB RAM with 2 vCPU
    Concurrency Up to 1000 concurrent requests per instance 1 concurrent request per instance
    Traffic Splitting Supported Not supported
    Event Types 90+ event sources via Eventarc 7 direct event sources
    Minimum Instances Supported (reduces cold starts) Supported
    Infrastructure Cloud Run Google internal

Cloud Run Functions Execution Environment

  • Cloud Run functions handles incoming requests by assigning them to instances of the function and based on the volume or existing functions, it can assign it to an existing one or spawn a new instance.
  • Cloud Run functions (latest) supports up to 1000 concurrent requests per instance, allowing a single instance to handle multiple requests simultaneously, reducing costs and cold starts.
  • Cloud Run functions (1st gen) handles only one concurrent request at a time per instance.
  • Cloud Run functions may start multiple new instances to handle requests, thus providing auto-scaling and parallelism.
  • Cloud Run functions must be stateless i.e. one function invocation should not rely on an in-memory state set by a previous invocation, to allow Google to automatically manage and scale the functions.
  • Every deployed function is isolated from all other functions — even those deployed from the same source file. In particular, they don’t share memory, global variables, file systems, or other state.
  • Cloud Run functions allows you to set a limit on the total number of function instances that can co-exist at any given time (maximum instances).
  • Minimum instances can be configured to keep instances warm and reduce cold starts.
  • Cloud Function instance is created when it’s deployed or the function needs to be scaled.
  • Cloud Run functions can have a Cold Start, which is the time involved in loading the runtime and the code.
  • Function execution time is limited by the timeout duration:
    • Cloud Run functions (latest): Up to 60 minutes for HTTP-triggered functions, up to 9 minutes for event-driven functions (via v2 API)
    • Cloud Run functions (1st gen): Default 1 minute, maximum 9 minutes
  • Cloud Run functions provides a writable filesystem i.e. /tmp directory only, which can be used to store temporary files in a function instance. The rest of the file system is read-only and accessible to the function.
  • Cloud Run functions has 2 scopes
    • Global Scope
      • contains the function definition
      • is executed on every cold start, but not if the instance has already been initialized
      • can be used for initialization like database connections etc.
    • Function Scope
      • only the body of the function declared as the entry point
      • is executed for each request and should include the actual logic
  • Cloud Run Functions Execution Guarantees
    • Functions are typically invoked once for each incoming event. However, Cloud Run functions does not guarantee a single invocation in all cases.
    • HTTP functions are invoked at most once as they are synchronous and the execution is not retried in an event of a failure.
    • Event-driven functions are invoked at least once as they are asynchronous and can be retried.

Cloud Run Functions Events and Triggers

  • Events are things that happen within the cloud environment that you might want to take action on.
  • Trigger is creating a response to that event. Trigger type determines how and when the function executes.
  • Cloud Run functions (latest) uses Eventarc for event routing, supporting any event type supported by Eventarc, including 90+ event sources through Cloud Audit Logs and using the standard CloudEvents format.
  • Cloud Run functions supports the following trigger mechanisms:
    • HTTP Triggers
      • Cloud Run functions can be invoked with an HTTP request using the POST, PUT, GET, DELETE, and OPTIONS HTTP methods.
      • HTTP invocations are synchronous and the result of the function execution will be returned in the response to the HTTP request.
    • Eventarc Triggers (Cloud Run functions – latest)
      • Eventarc is Google Cloud’s universal event routing service that delivers events from 90+ sources to Cloud Run functions.
      • Supports Cloud Audit Logs events from virtually any Google Cloud service.
      • Uses the standard CloudEvents format in all language runtimes.
      • Supports dead-letter topics for failed event delivery.
    • Cloud Pub/Sub Triggers
      • Cloud Run functions can be triggered by messages published to Pub/Sub topics in the same Cloud project as the function.
      • Pub/Sub is a globally distributed message bus that automatically scales as needed and provides a foundation for building robust, global services.
    • Cloud Storage Triggers
      • Cloud Run functions can respond to change notifications emerging from Google Cloud Storage.
      • Notifications can be configured to trigger in response to various events inside a bucket — object creation, deletion, archiving, and metadata updates.
    • Cloud Firestore Triggers
      • Cloud Run functions can handle events in Cloud Firestore in the same Cloud project as the function.
      • Cloud Firestore can be read or updated in response to these events using the Firestore APIs and client libraries.
    • Firebase Triggers
      • Analytics for Firebase
      • Firebase Realtime Database
      • Firebase Authentication — Can be triggered by events from Firebase Authentication in the same Cloud project.
    • Direct Triggers
      • Cloud Run functions provides a call command in the CLI and testing functionality in the Cloud Console UI to support quick iteration and debugging.
      • Function can be directly invoked to ensure it is behaving as expected.
  • Cloud Run functions can also be integrated with any other Google service that supports Cloud Pub/Sub (e.g., Cloud Scheduler) or any service that provides HTTP callbacks (webhooks).
  • Google Cloud Logging events can be exported to a Cloud Pub/Sub topic from which they can then be consumed by Cloud Run functions.

Cloud Run Functions Networking

  • Direct VPC Egress — allows functions to send traffic directly to a VPC network without a Serverless VPC Access connector, reducing latency and cost.
  • VPC Service Controls — supports VPC SC for data exfiltration protection.
  • Ingress Controls — restrict incoming traffic to internal-only, internal-and-cloud-load-balancing, or all traffic.
  • Static Outbound IP — configure a static IP for outbound traffic when connecting to external services that require IP allowlisting.
  • Shared VPC — supports deploying functions that connect to resources in a Shared VPC network.

Cloud Run Functions Security

  • IAM-based Access Control — fine-grained permissions using IAM roles (Cloud Run Source Developer, Service Usage Consumer, Service Account User).
  • Secret Manager Integration — securely access API keys, database credentials, and other secrets without hardcoding them. Secrets can be mounted as volumes or exposed as environment variables.
  • Customer-Managed Encryption Keys (CMEK) — encrypt function source code and container images with your own keys from Cloud KMS.
  • Binary Authorization — enforce deploy-time security policies to ensure only trusted container images are deployed.
  • Cloud Armor — protect functions from DDoS attacks and apply WAF rules.
  • Identity-Aware Proxy (IAP) — add authentication layer for functions.

Cloud Run Functions Best Practices

  • Write Idempotent functions — produce same results when invoked multiple times with the same parameters.
  • Do not start background activities i.e. activity after function has terminated. Any code run after graceful termination cannot access the CPU and will not make any progress.
  • Always delete temporary files — As files can persist between invocations, failing to delete files may lead to memory issues.
  • Use dependencies wisely — Import only what is required as it would affect the cold starts due to invocation latency.
  • Use global variables to reuse objects in future invocations, e.g., database connections.
  • Do lazy initialization of global variables.
  • Use retry to handle only transient and retryable errors, with the handling being idempotent.
  • Configure minimum instances to reduce cold starts for latency-sensitive workloads.
  • Use concurrency (latest version) to handle multiple requests per instance, reducing costs for high-traffic functions.
  • Use Secret Manager instead of environment variables for sensitive configuration data.
  • Configure dead-letter topics for event-driven functions to capture failed events for later processing.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company needs a serverless function that processes large files from Cloud Storage and may take up to 30 minutes. Which version should they use?
    1. Cloud Run functions (1st gen) with HTTP trigger
    2. Cloud Run functions (latest) with HTTP trigger
    3. Cloud Run functions (1st gen) with Cloud Storage trigger
    4. Cloud Run functions (latest) with Cloud Storage event trigger via Eventarc
    Show Answer

    Answer: b – Only the latest version supports up to 60 minutes timeout for HTTP-triggered functions. 1st gen is limited to 9 minutes.

  2. What is the maximum number of concurrent requests a single Cloud Run functions (latest) instance can handle?
    1. 1
    2. 100
    3. 1000
    4. Unlimited

    Answer: c — Cloud Run functions (latest) supports up to 1000 concurrent requests per function instance.

  3. Which event routing service does Cloud Run functions (latest) use to support 90+ event sources?
    1. Cloud Pub/Sub directly
    2. Eventarc
    3. Cloud Scheduler
    4. Cloud Tasks

    Answer: b — Cloud Run functions (latest) uses Eventarc for event routing, supporting 90+ event sources through Cloud Audit Logs.

  4. Which feature helps reduce cold starts in Cloud Run functions?
    1. Maximum instances
    2. Minimum instances
    3. Concurrency
    4. Traffic splitting

    Answer: b — Configuring minimum instances keeps pre-warmed instances ready to serve requests, reducing cold starts.

  5. A team needs to gradually roll out a new version of their function with 10% of traffic first. Which feature should they use?
    1. Cloud Run functions (1st gen) with multiple deployments
    2. Cloud Run functions (latest) with traffic splitting
    3. Cloud Pub/Sub with message filtering
    4. Cloud Load Balancer with URL maps

    Answer: b — Cloud Run functions (latest) supports traffic splitting between revisions, allowing gradual rollouts. 1st gen does not support this feature.

  6. What was the rebranding change announced for Cloud Functions in August 2024?
    1. Cloud Functions was deprecated and replaced by Cloud Run
    2. Cloud Functions (2nd gen) was renamed to Cloud Run functions
    3. Cloud Functions was merged with App Engine
    4. Cloud Functions was moved to Firebase only

    Answer: b — In August 2024, Google renamed Cloud Functions (2nd gen) to Cloud Run functions and folded it under the Cloud Run umbrella.

See also: Google Cloud Compute Services Cheat Sheet

References

Google Cloud – HipLocal Case Study

~ Last updated on : ~ jayendrapatil

⚠️ Case Study Retired from PCA Exam (October 2025)

The HipLocal case study was retired from the Google Cloud Professional Cloud Architect (PCA) exam as of October 30, 2025 (exam version 6.1).

The updated PCA exam now includes the following case studies:

  • EHR Healthcare – Retained from the previous version
  • Altostrat Media – New; focuses on content management and AI-powered personalization
  • Cymbal Retail – New; focuses on real-time personalization and inventory optimization
  • KnightMotives Automotive – New; focuses on edge computing and IoT data ingestion

All new case studies incorporate AI integration as core business requirements, reflecting Google Cloud’s expanded Vertex AI and generative AI services.

This content is maintained for historical reference and for understanding Google Cloud architectural patterns related to global scaling, observability, and hybrid connectivity.

Google Cloud – HipLocal Case Study

HipLocal is a community application designed to facilitate communication between people in close proximity. It is used for event planning and organizing sporting events, and for businesses to connect with their local communities. HipLocal launched recently in a few neighborhoods in Dallas and is rapidly growing into a global phenomenon. Its unique style of hyper-local community communication and business outreach is in demand around the world.

Key point here is HipLocal is expanding globally

HipLocal Solution Concept

HipLocal wants to expand their existing service with updated functionality in new locations to better serve their global customers. They want to hire and train a new team to support these locations in their time zones. They will need to ensure that the application scales smoothly and provides clear uptime data, and that they analyze and respond to any issues that occur.

Key points here are HipLocal wants to expand globally, with an ability to scale and provide clear observability, alerting and ability to react.

HipLocal Existing Technical Environment

HipLocal’s environment is a mixture of on-premises hardware and infrastructure running in Google Cloud. The HipLocal team understands their application well, but has limited experience in globally scaled applications. Their existing technical environment is as follows:

  • Existing APIs run on Compute Engine virtual machine instances hosted in Google Cloud.
  • Expand availability of the application to new locations.
  • Support 10x as many concurrent users.
  • State is stored in a single instance MySQL database in Google Cloud.
  • Release cycles include development freezes to allow for QA testing.
  • The application has no consistent logging.
  • Applications are manually deployed by infrastructure engineers during periods of slow traffic on weekday evenings.
  • There are basic indicators of uptime; alerts are frequently fired when the APIs are unresponsive.

Business requirements

HipLocal’s investors want to expand their footprint and support the increase in demand they are experiencing. Their requirements are:

  • Expand availability of the application to new locations.
    • Availability can be achieved using either
      • scaling the application and exposing it through Global Load Balancer OR
      • deploying the applications across multiple regions.
  • Support 10x as many concurrent users.
    • As the APIs run on Compute Engine, the scale can be implemented using Managed Instance Groups frontend by a Load Balancer OR App Engine OR Container-based application deployment
    • Scaling policies can be defined to scale as per the demand.
    • Modern Alternative: Cloud Run provides a fully managed serverless container platform with automatic scaling to zero and per-request billing, making it an ideal choice for API workloads requiring global scale.
  • Ensure a consistent experience for users when they travel to different locations.
    • Consistent experience for the users can be provided using either
      • Google Cloud Global Load Balancer which uses GFE and routes traffic close to the users
      • multi-region setup targeting each region
  • Obtain user activity metrics to better understand how to monetize their product.
    • User activity data can also be exported to BigQuery for analytics and monetization
    • Cloud Monitoring and Cloud Logging (part of Google Cloud Observability) can be configured for application logs and metrics to provide observability, alerting, and reporting.
    • Cloud Logging can be exported to BigQuery for analytics
  • Ensure compliance with regulations in the new regions (for example, GDPR).
    • Compliance is shared responsibility, while Google Cloud ensures compliance of its services, application hosted on Google Cloud would be customer responsibility
    • GDPR or other regulations for data residency can be met using setup per region, so that the data resides with the region
    • Update: Google Cloud now offers Assured Workloads and data sovereignty controls to help enforce regional data residency and compliance requirements.
  • Reduce infrastructure management time and cost.
    • As the infrastructure is spread across on-premises and Google Cloud, it would make sense to consolidate the infrastructure into one place i.e. Google Cloud
    • Consolidation would help in automation, maintenance, as well as provide cost benefits.
    • Update: Google Cloud Migration Center provides automated workload assessment, dependency mapping, and migration planning to streamline the migration from on-premises.
  • Adopt the Google-recommended practices for cloud computing:
    • Develop standardized workflows and processes around application lifecycle management.
    • Define service level indicators (SLIs) and service level objectives (SLOs).
      • Update: Cloud Monitoring now provides built-in SLI/SLO monitoring with configurable burn rate alerts and error budgets, aligned with Google’s Site Reliability Engineering (SRE) practices.

Technical requirements

  • Provide secure communications between the on-premises data center and cloud hosted applications and infrastructure
    • Secure communications can be enabled between the on-premise data centers and the Cloud using Cloud VPN and Interconnect.
  • The application must provide usage metrics and monitoring.
    • Cloud Monitoring and Cloud Logging (part of Google Cloud Observability) can be configured for application logs and metrics to provide observability, alerting, and reporting.
    • Update: Google Cloud Observability now supports OpenTelemetry Protocol (OTLP) for both traces and metrics, enabling vendor-agnostic instrumentation. Application Monitoring in Cloud Observability provides pre-curated dashboards with SRE best practices.
  • APIs require authentication and authorization.
    • APIs can be configured for various Authentication mechanisms.
    • APIs can be exposed through Apigee API management platform for full lifecycle API management including authentication, rate limiting, and analytics.
    • Internal Applications can be exposed using Cloud Identity-Aware Proxy (IAP), which enforces the BeyondCorp zero-trust security model for secure access without VPN.
  • Implement faster and more accurate validation of new features.
    • QA Testing can be improved using automated testing
    • Production Release cycles can be improved using canary deployments to test the applications on a smaller base before rolling out to all.
    • Application can be deployed to App Engine which supports traffic splitting out of the box for canary releases
    • Modern Alternative: Cloud Run supports traffic splitting between revisions for canary deployments and gradual rollouts. Cloud Deploy provides managed continuous delivery with approval workflows and promotion across environments.
  • Logging and performance metrics must provide actionable information to be able to provide debugging information and alerts.
    • Cloud Monitoring and Cloud Logging (part of Google Cloud Observability) can be configured for application logs and metrics to provide observability, alerting, and reporting.
    • Cloud Logging can be exported to BigQuery for analytics using log sinks.
    • Update: Cloud Trace and Cloud Profiler provide distributed tracing and continuous profiling for identifying performance bottlenecks. Log Analytics enables SQL-based log querying directly within Cloud Logging.
  • Must scale to meet user demand.
    • As the APIs run on Compute Engine, the scale can be implemented using Managed Instance Groups frontend by a Load Balancer and using scaling policies as per the demand.
    • Single instance MySQL instance can be migrated to Cloud SQL. This would not need any application code changes and can be as-is migration. With read replicas to scale both horizontally and vertically seamlessly.
    • Update: AlloyDB for PostgreSQL is now available as a high-performance, PostgreSQL-compatible database with up to 4x faster transactional workloads and 100x faster analytical queries than standard PostgreSQL. For applications requiring global scale with strong consistency, Cloud Spanner remains an option.

Key Architectural Patterns (Updated for 2025-2026)

While HipLocal is no longer an active exam case study, the architectural patterns it illustrates remain relevant:

Modern Compute Options for API Workloads

  • Cloud Run – Fully managed serverless containers with automatic scaling, ideal for stateless API workloads. Supports traffic splitting for canary deployments.
  • GKE Autopilot – Fully managed Kubernetes for complex microservices architectures with automatic node provisioning.
  • Compute Engine MIGs – Still valid for stateful workloads or when specific VM configurations are required.

Modern Observability Stack

  • Google Cloud Observability (formerly Stackdriver/Operations Suite) – Unified platform for monitoring, logging, tracing, and profiling.
  • SLO Monitoring – Built-in SLI/SLO tracking with error budgets and burn rate alerts.
  • OpenTelemetry Support – OTLP for metrics and traces enables vendor-agnostic instrumentation.
  • Log Analytics – SQL-based log querying and BigQuery-linked log buckets for advanced analysis.

Modern API Management

  • Apigee – Full lifecycle API management with security policies, rate limiting, analytics, and developer portals. (Note: Cloud Endpoints Portal was deprecated in March 2023.)
  • Identity-Aware Proxy (IAP) – BeyondCorp zero-trust access for internal applications without VPN.

Modern Database Options

  • Cloud SQL – Managed MySQL/PostgreSQL/SQL Server with high availability, read replicas, and automated backups. Best for lift-and-shift MySQL migrations.
  • AlloyDB for PostgreSQL – High-performance PostgreSQL-compatible database with AI-native features including vector search.
  • Cloud Spanner – Globally distributed, strongly consistent database for applications requiring global scale.

CI/CD and Deployment

  • Cloud Build – Serverless CI/CD platform for building, testing, and deploying.
  • Cloud Deploy – Managed continuous delivery service with promotion workflows across environments.
  • Terraform / Infrastructure Manager – Infrastructure as Code for Google Cloud. (Note: Cloud Deployment Manager reached end of support on March 31, 2026. Migrate to Terraform or Infrastructure Manager.)

GCP Certification Exam Practice Questions

  • ⚠️ The HipLocal case study was retired from the PCA exam in October 2025. These questions are maintained for learning purposes and to understand Google Cloud architectural patterns.
  • GCP services are updated regularly and both the answers and questions might be outdated soon, so research accordingly.
  • Open to further feedback, discussion and correction.
  1. Which database should HipLocal use for storing state while minimizing application changes?
    1. Firestore
    2. BigQuery
    3. Cloud SQL
    4. Cloud Bigtable

    Note: Cloud SQL for MySQL is the correct answer as it’s a managed MySQL-compatible service requiring minimal application changes. AlloyDB would be the modern high-performance alternative for PostgreSQL workloads.

  2. Which architecture should HipLocal use for log analysis?
    1. Use Cloud Spanner to store each event.
    2. Start storing key metrics in Memorystore.
    3. Use Cloud Logging with a BigQuery sink.
    4. Use Cloud Logging with a Cloud Storage sink.

    Note: Cloud Logging with BigQuery sink (now called log sink with BigQuery-linked dataset) remains the best approach for log analytics. Log Analytics also provides direct SQL querying within Cloud Logging.

  3. HipLocal wants to improve the resilience of their MySQL deployment, while also meeting their business and technical requirements. Which configuration should they choose?
    1. ​Use the current single instance MySQL on Compute Engine and several read-only MySQL servers on Compute Engine.​
    2. ​Use the current single instance MySQL on Compute Engine, and replicate the data to Cloud SQL in an external master configuration.​
    3. ​Replace the current single instance MySQL instance with Cloud SQL, and configure high availability.​
    4. ​Replace the current single instance MySQL instance with Cloud SQL, and Google provides redundancy without further configuration.​

    Note: Cloud SQL high availability requires explicit configuration (regional HA with failover replica). It is not automatic by default.

  4. Which service should HipLocal use to enable access to internal apps?
    1. Cloud VPN
    2. Cloud Armor
    3. Virtual Private Cloud
    4. Cloud Identity-Aware Proxy

    Note: IAP enforces the BeyondCorp zero-trust model, providing authenticated access to internal apps without requiring a VPN. Now part of Google Cloud’s broader security portfolio.

  5. Which database should HipLocal use for storing user activity?
    1. BigQuery
    2. Cloud SQL
    3. Cloud Spanner
    4. Cloud Datastore

    Note: BigQuery remains the correct answer for analytics workloads on user activity data. Cloud Datastore has been rebranded to Firestore in Datastore mode.

Additional Practice Questions (Architectural Patterns)

  1. HipLocal wants to modernize their API deployment for global scale with minimal infrastructure management. Which solution best meets their needs?
    1. Deploy APIs on Compute Engine MIGs behind a Global HTTP(S) Load Balancer
    2. Deploy containerized APIs on Cloud Run with a Global External Application Load Balancer
    3. Deploy APIs on App Engine flexible environment
    4. Deploy APIs on GKE Standard with cluster autoscaler

    Cloud Run provides automatic scaling (including to zero), global deployment, and minimal infrastructure management. Combined with the Global External Application Load Balancer, it provides the least operational overhead.

  2. HipLocal needs to implement Infrastructure as Code for their Google Cloud resources. Which is the recommended approach in 2026?
    1. Cloud Deployment Manager with YAML templates
    2. Terraform with the Google Cloud provider
    3. Custom scripts using gcloud CLI
    4. Pulumi with TypeScript

    Cloud Deployment Manager reached end of support on March 31, 2026. Terraform is the recommended IaC tool for Google Cloud and is now explicitly required knowledge for the PCA exam.

  3. HipLocal wants to define and monitor SLOs for their APIs. Which Google Cloud services should they use? (Choose 2)
    1. Cloud Monitoring with SLO monitoring
    2. Cloud Scheduler
    3. Cloud Logging with log-based metrics
    4. Cloud Tasks

    Cloud Monitoring provides built-in SLO monitoring with burn rate alerts. Log-based metrics from Cloud Logging can serve as SLIs (e.g., error rates) for SLO tracking.

Reference

Google Cloud Storage Security – IAM, ACLs & CMEK

~ Last updated on : ~ jayendrapatil

Google Cloud Storage Security

Google Cloud Storage Security includes controlling access using

  • Uniform Bucket or Fine-grained ACL access control policies
  • Public Access Prevention
  • VPC Service Controls for data perimeter security
  • Managed Folders for granular IAM
  • Data encryption at rest and transit
  • Retention policies, Object Retention Lock, and Bucket Lock
  • Soft Delete for recovery from accidental deletion
  • Signed URLs

GCS Access Control

  • Cloud Storage offers two systems for granting users permission to access the buckets and objects: IAM and Access Control Lists (ACLs)
  • IAM and ACLs can be used on the same resource, Cloud Storage grants the broader permission set on the resource
  • Cloud Storage access control can be performed using
    • Uniform (recommended)
      • Uniform bucket-level access allows using IAM alone to manage permissions.
      • IAM applies permissions to all the objects contained inside the bucket or groups of objects with common name prefixes.
      • IAM also allows using features that are not available when working with ACLs, such as IAM Conditions and Cloud Audit Logs.
      • Enabling uniform bucket-level access disables ACLs, but it can be reversed before 90 days
    • Fine-grained
      • Fine-grained option enables using IAM and Access Control Lists (ACLs) together to manage permissions.
      • ACLs are a legacy access control system for Cloud Storage designed for interoperability with S3.
      • Access and apply permissions can be specified at both the bucket level and per individual object.
  • Objects in the bucket can be made public using ACLs AllUsers:R or IAM allUsers:objectViewer permissions

Public Access Prevention

  • Public Access Prevention protects Cloud Storage buckets and objects from being accidentally exposed to the public.
  • When enforced, no one can make data in applicable buckets public through IAM policies or ACLs.
  • Can be set at the bucket level or enforced at the project, folder, or organization level using the storage.publicAccessPrevention organization policy constraint.
  • When applied at the organization level, public access is restricted for all buckets and objects, both new and existing, under that resource.
  • Public access prevention does not apply to Signed URLs, since signed URLs grant access through scoped service account permissions.

Managed Folders

  • Managed folders allow granting IAM roles on specific groups of objects within a bucket, providing more fine-grained access control.
  • IAM policies can be set on managed folders to control access to objects that share a common name prefix.
  • Managed folders can be nested up to 15 levels deep.
  • Requires uniform bucket-level access to be enabled on the bucket.
  • Useful for meeting data security and compliance requirements by restricting access to specific data partitions within a shared bucket.

VPC Service Controls

  • VPC Service Controls create a security perimeter around Cloud Storage resources to prevent data exfiltration.
  • Data cannot be copied to unauthorized resources outside the perimeter using operations such as gcloud storage cp.
  • Protects against data exfiltration risks such as stolen credentials, misconfigured permissions, or malicious insiders.
  • Fine-grained perimeter controls can be enforced across multiple Google Cloud services and projects.
  • Supports access levels, ingress/egress rules, and perimeter bridges for controlled data sharing.

Bucket IP Filtering

  • Bucket IP filtering allows restricting access to a bucket based on the source IP address of incoming requests.
  • IP filtering rules can be configured to allow or deny access from specific IP ranges.
  • Provides an additional layer of network-level security for sensitive buckets.
  • Can be bypassed by authorized principals with specific IAM permissions when needed.

Data Encryption

  • Cloud Storage always encrypts the data on the server-side, before it is written to disk, at no additional charge.
  • Cloud supports the following encryption
    • Server-side encryption: encryption that occurs after Cloud Storage receives the data, but before the data is written to disk and stored.
      • Google-managed encryption keys (default)
        • Cloud Storage always encrypts the data on the server-side, before it is written to disk
        • Cloud Storage manages server-side encryption keys using the same hardened key management systems, including strict key access controls and auditing.
        • Cloud Storage encrypts user data at rest using AES-256.
        • Data is automatically decrypted when read by an authorized user
      • Customer-managed encryption keys (CMEK)
        • Customers manage their own encryption keys generated by Cloud Key Management Service (KMS)
        • CMEK keys can be set as the default encryption key for a bucket, which then applies to all new objects.
        • Supports organization policy constraints (constraints/gcp.restrictNonCmekServices) to enforce CMEK usage across the organization.
        • Cloud KMS Autokey (GA 2024) simplifies CMEK by automatically provisioning key rings, keys, and service agent IAM roles on demand during resource creation — eliminating manual key planning and assignment.
        • CMEK keys can be stored as software keys, in an HSM cluster, or externally (Cloud External Key Manager).
      • Customer-supplied encryption keys (CSEK)
        • Customers create and manage their own encryption keys outside of Google Cloud.
        • Customer provides the key for each GCS operation, and the key is purged from Google’s servers after the operation is complete.
        • Cloud Storage stores only a cryptographic hash of the key so that future requests can be validated against the hash.
        • The key cannot be recovered from this hash, and the hash cannot be used to decrypt the data.
    • Client-side encryption: encryption that occurs before data is sent to Cloud Storage, encrypted at the client-side. This data also undergoes server-side encryption.
  • Cloud Storage supports Transport Layer Security, commonly known as TLS or HTTPS for data encryption in transit
  • Organization policy constraints can be used to enforce or restrict encryption types (e.g., require CMEK for all new buckets).

Signed URLs

  • Signed URLs provide time-limited read or write access to an object through a generated URL.
  • Anyone having access to the URL can access the object for the duration of time specified, regardless of whether or not they have a Google account.
  • Uses the V4 signing process with a maximum expiration of 604,800 seconds (7 days).
  • Signed URLs can only be used to access resources through XML API endpoints.
  • Can be signed using a service account private key or HMAC key credentials.
  • Public access prevention does not block access via signed URLs.

Signed Policy Documents

  • Signed policy documents help specify what can be uploaded to a bucket.
  • Policy documents allow greater control over size, content type, and other upload characteristics than signed URLs, and can be used by website owners to allow visitors to upload files to Cloud Storage.

Soft Delete

  • Soft delete (GA 2024) provides bucket-level protection against accidental or malicious deletion by retaining recently deleted objects for a configurable retention period.
  • Soft delete is enabled by default on all buckets with a retention duration of 7 days.
  • Retention duration can be set between 7 and 90 days, or soft delete can be disabled entirely.
  • Soft-deleted objects can be restored within the retention window.
  • Soft-deleted buckets can also be restored.
  • Organization-level tags can be used to set a default soft delete retention duration for new buckets.
  • Soft-deleted objects incur storage charges at the same rate as active objects.

Retention Policies

  • Retention policy on a bucket ensures that all current and future objects in the bucket cannot be deleted or replaced until they reach the defined age
  • Retention policy can be applied when creating a bucket or to an existing bucket
  • Retention policy retroactively applies to existing objects in the bucket as well as new objects added to the bucket.

Retention Policy Locks

  • Retention policy locks will lock a retention policy on a bucket, which prevents the policy from ever being removed or the retention period from ever being reduced (although it can be increased)
  • Once a retention policy is locked, the bucket cannot be deleted until every object in the bucket has met the retention period.
  • Locking a retention policy is irreversible

Bucket Lock

  • Bucket Lock feature provides immutable storage i.e. Write Once Read Many (WORM) on Cloud Storage
  • Bucket Lock feature allows configuring a data retention policy for a bucket that governs how long objects in the bucket must be retained
  • Bucket Lock feature also locks the data retention policy, permanently preventing the policy from being reduced or removed.
  • Bucket Lock applies the retention policy uniformly to all objects in the bucket.
  • Bucket Lock can help with regulatory, legal, and compliance requirements

Object Retention Lock

  • Object Retention Lock (GA 2024) allows defining data retention requirements on a per-object basis, unlike Bucket Lock which applies uniformly to all objects.
  • A retention configuration on an object contains:
    • Retain-until time — a date and time until which the object cannot be deleted or replaced (max 100 years from current date).
    • Retention mode:
      • Unlocked (Governance) — authorized users can modify or remove the retention configuration.
      • Locked (Compliance) — permanently prevents the retention date from being reduced or removed; the mode cannot be changed and retention can only be increased.
  • Object Retention Lock must be enabled on the bucket before retention configurations can be set on objects. Once enabled, it cannot be disabled.
  • Can help with regulatory and compliance requirements such as FINRA, SEC, CFTC, and health care regulations.
  • An object can be subject to both its own Object Retention Lock and a Bucket Lock retention policy — the object is retained until both are satisfied.
  • Storage batch operations can be used to set or update retention configurations on millions of objects in a single job.

Object Holds

  • Object holds, when set on individual objects, prevents the object from being deleted or replaced, however allows metadata to be edited.
  • Cloud Storage offers the following types of holds:
    • Event-based holds.
    • Temporary holds.
  • When an object is stored in a bucket without a retention policy, both hold types behave exactly the same.
  • When an object is stored in a bucket with a retention policy, the hold types have different effects on the object when the hold is released:
    • An event-based hold resets the object’s time in the bucket for the purposes of the retention period.
    • A temporary hold does not affect the object’s time in the bucket for the purposes of the retention period.

Organization Policy Constraints

  • Cloud Storage supports predefined and custom organization policy constraints to enforce security standards across the organization.
  • Key predefined constraints include:
    • storage.publicAccessPrevention — enforce public access prevention on all buckets.
    • storage.uniformBucketLevelAccess — require uniform bucket-level access (disable ACLs).
    • storage.retentionPolicySeconds — enforce minimum retention policies.
    • gcp.restrictNonCmekServices — require CMEK encryption for Cloud Storage.
    • storage.restrictAuthTypes — restrict authentication types.
  • Custom constraints can be created to enforce specific bucket or object behaviors not covered by predefined constraints.
  • Detailed audit logging mode logs request and response details for Cloud Storage, helping with regulatory compliance.

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 an object in a Cloud Storage bucket that you want to share with an external company. The object contains sensitive data. You want access to the content to be removed after four hours. The external company does not have a Google account to which you can grant specific user-based access privileges. You want to use the most secure method that requires the fewest steps. What should you do?
    1. Create a signed URL with a four-hour expiration and share the URL with the company.
    2. Set object access to “public” and use object lifecycle management to remove the object after four hours.
    3. Configure the storage bucket as a static website and furnish the object’s URL to the company. Delete the object from the storage bucket after four hours.
    4. Create a new Cloud Storage bucket specifically for the external company to access. Copy the object to that bucket. Delete the bucket after four hours have passed
  2. Your organization requires that all Cloud Storage buckets in production must use Customer-Managed Encryption Keys (CMEK) and must not be publicly accessible. How should you enforce this?
    1. Set organization policy constraints gcp.restrictNonCmekServices with Cloud Storage in the deny list and storage.publicAccessPrevention enforced at the organization level.
    2. Create a Cloud Function that checks each new bucket and deletes it if not compliant.
    3. Use IAM conditions to prevent bucket creation without CMEK.
    4. Train developers to always use CMEK and enable public access prevention manually.
  3. A compliance requirement states that certain objects in a shared bucket must be retained for 5 years and cannot be deleted, while other objects in the same bucket have no retention requirement. What is the best approach?
    1. Create separate buckets with different Bucket Lock retention policies for each set of objects.
    2. Use Object Retention Lock with Locked (Compliance) mode and set a retain-until time of 5 years on the specific objects that require retention.
    3. Use Object Lifecycle Management to prevent deletion of specific objects.
    4. Set a Bucket Lock retention policy of 5 years on the entire bucket.
  4. Your team accidentally deleted critical objects from a Cloud Storage bucket yesterday. The bucket has default settings. What is the best recovery option?
    1. Recover from a backup bucket if one was configured.
    2. Restore the soft-deleted objects, since soft delete is enabled by default with a 7-day retention duration.
    3. Contact Google Cloud support to recover the objects.
    4. Use Object Versioning to retrieve previous versions.
  5. You need to provide granular access to a specific set of objects within a bucket that uses uniform bucket-level access, without granting access to the entire bucket. What should you use?
    1. Switch to fine-grained access control and use ACLs on individual objects.
    2. Create signed URLs for each object.
    3. Create a managed folder for the objects and set IAM policies on the managed folder.
    4. Create a separate bucket for those objects.

GCP Professional Cloud Security Engineer Cert Path

GCP - Professional Cloud Security Engineer Certificate
~ Last updated on : ~ jayendrapatil ~ 1 Comment

Google Cloud – Professional Cloud Security Engineer Certification learning path

Continuing on the Google Cloud Journey, have just cleared the Professional Cloud Security certification. Google Cloud – Professional Cloud Security Engineer certification exam focuses on almost all of the Google Cloud security services with storage, compute, networking services with their security aspects only.

📋 Exam Update (2025-2026)

The Professional Cloud Security Engineer exam has been updated to include securing AI workloads (Vertex AI), software supply chain security, and VPC Service Controls as key topics. The exam now has 50-60 questions (previously 50) and costs $200. Approximately ⅓–¼ of the exam now covers Vertex AI security, VPC Service Controls, and private/public endpoint configurations.

Google Cloud – Professional Cloud Security Engineer Certification Summary

  • Has 50-60 questions to be answered in 2 hours.
  • Registration fee: $200 (plus tax where applicable)
  • Available in English and Japanese
  • Can be taken online-proctored or at a testing center
  • Covers a wide range of Google Cloud services mainly focusing on security and network services
  • Recommended experience: 3+ years of industry experience including 1+ years designing and managing solutions using Google Cloud
  • As mentioned for all the exams, Hands-on is a MUST, if you have not worked on GCP before make sure you do lots of labs else you would be absolutely clueless about some of the questions and commands
  • Certification is valid for 3 years and can be renewed within the renewal eligibility period
  • The exam now covers five key domains:
    • Configuring Access (~25%)
    • Securing Communications and Establishing Boundary Protection (~22%)
    • Ensuring Data Protection (~23%)
    • Managing Operations (~19%)
    • Supporting Compliance Requirements (~11%)

Google Cloud – Professional Cloud Security Engineer Certification Resources

Google Cloud – Professional Cloud Security Engineer Certification Topics

Security Services

  • Google Cloud – Security Services Cheat Sheet
  • Cloud Key Management Service – KMS
    • Cloud KMS provides a centralized, scalable, fast cloud key management service to manage encryption keys
    • KMS Key is a named object containing one or more key versions, along with metadata for the key.
    • KMS KeyRing provides grouping keys with related permissions that allow you to grant, revoke, or modify permissions to those keys at the key ring level without needing to act on each key individually.
    • Supports Autokey (GA 2024) for automatic key provisioning and assignment to protect data at rest
    • Supports Cloud External Key Manager (EKM) for using keys managed in supported external key management partners
  • Cloud Armor
    • Cloud Armor protects the applications from multiple types of threats, including DDoS attacks and application attacks like XSS and SQLi
    • works with the external HTTP(S) load balancer to automatically block network protocol and volumetric DDoS attacks such as protocol floods (SYN, TCP, HTTP, and ICMP) and amplification attacks (NTP, UDP, DNS)
    • Cloud Armor Enterprise (formerly Managed Protection Plus) is the premium tier with advanced DDoS protection, Threat Intelligence, and Adaptive Protection features
    • Adaptive Protection uses ML to detect and mitigate L7 DDoS attacks automatically, trained locally on application traffic patterns
    • Hierarchical Security Policies (GA 2025) enable centralized control and delegation of security policy management across organizations
    • Enhanced WAF inspection now supports up to 64 KB request body inspection (up from 8 KB) for preconfigured WAF rules
    • with GKE needs to be configured with GKE Ingress
    • can be used to blacklist IPs
    • supports preview mode to understand patterns without blocking the users
  • Cloud Identity-Aware Proxy
    • Identity-Aware Proxy IAP allows managing access to HTTP-based apps both on Google Cloud and outside of Google Cloud.
    • IAP uses Google identities and IAM and can leverage external identity providers as well like OAuth with Facebook, Microsoft, SAML, etc.
    • Signed headers using JWT provide secondary security in case someone bypasses IAP.
    • IAP is a core component of Google’s BeyondCorp zero-trust model, now delivered through Chrome Enterprise Premium
  • Sensitive Data Protection (formerly Cloud Data Loss Prevention – DLP)
    • Cloud Data Loss Prevention (DLP) is now part of Sensitive Data Protection, a family of services designed to help discover, classify, and protect sensitive data.
    • The API name remains Cloud Data Loss Prevention API (DLP API)
    • provides two key features
      • Classification is the process to inspect the data and know what data we have, how sensitive it is, and the likelihood.
      • De-identification is the process of removing, masking, redaction, replacing information from data.
    • supports text, image, and storage classification with scans on data stored in Cloud Storage, Datastore, and BigQuery
    • supports scanning of binary, text, image, Microsoft Word, PDF, and Apache Avro files
    • Discovery service (data profiler) continuously monitors data resources and classifies data into infoTypes, assessing sensitivity and risk levels
    • Deeply integrated with Security Command Center Enterprise risk engine for continuous data monitoring
    • Supports automatic discovery of unencrypted secrets and data profiling across organizations, folders, or projects
  • Web Security Scanner
    • Web Security Scanner identifies security vulnerabilities in the App Engine, GKE, and Compute Engine web applications.
    • scans provide information about application vulnerability findings, like OWASP, XSS, Flash injection, outdated libraries, cross-site scripting, clear-text passwords, or use of mixed content
  • Security Command Center – SCC
    • is a Security and risk management platform that helps generate curated insights and provides a unique view of incoming threats and attacks to the assets
    • displays possible security risks, called findings, that are associated with each asset.
    • Available in three tiers:
      • Standard tier – Free, now automatically enabled for eligible customers; provides basic security and compliance management
      • Premium tier – Pay-as-you-go; includes Security Health Analytics, Event Threat Detection, Container Threat Detection, and VM Threat Detection
      • Enterprise tier – Subscription-based; extends protection across multiple clouds with Google SecOps integration and automated responses (Note: Enterprise tier shuts down May 21, 2027; organizations will move to Premium tier)
    • Premium and Enterprise tiers include Risk Engine for attack path simulation and toxic combination detection
  • Forseti Security
    ⚠️ DEPRECATED/ARCHIVED – Forseti Security repository was archived by Google on January 11, 2025 due to low community engagement and limited development activity. It is now read-only and no longer supported.

    Alternative: Use Security Command Center (SCC) for centralized security posture management, asset inventory, and compliance monitoring.
    • Was an open-source security toolkit for GCP resource inventory and policy enforcement
    • Kept track of the environment with inventory snapshots of GCP resources on a recurring cadence
  • Chrome Enterprise Premium (formerly BeyondCorp Enterprise)
    • BeyondCorp Enterprise was renamed to Chrome Enterprise Premium in April 2024
    • Provides zero-trust access security integrated directly within the Chrome browser
    • Enables granular access policies for personally-owned and managed devices
    • Combines threat protection, data protection, and zero-trust access in the browser
    • Works with Identity-Aware Proxy (IAP) and Access Context Manager for context-aware access
  • Access Context Manager
    • Access Context Manager allows organization administrators to define fine-grained, attribute-based access control for projects and resources
    • Access Context Manager helps reduce the size of the privileged network and move to a model where endpoints do not carry ambient authority based on the network.
    • Access Context Manager helps prevent data exfiltration with proper access levels and security perimeter rules
    • Works with VPC Service Controls to create security perimeters around Google Cloud resources
  • VPC Service Controls
    • Creates security perimeters that protect resources and data of explicitly specified services
    • Prevents data exfiltration by restricting the movement of data across perimeter boundaries
    • Critical for Vertex AI security – controls access to AI/ML endpoints and training data
    • Supports ingress and egress rules for fine-grained access policies
    • Major exam topic – understand perimeter configuration, access levels, and service restrictions

AI Security (New Exam Topic)

  • Securing Vertex AI Workloads
    • Approximately ⅓–¼ of the current exam covers Vertex AI security topics
    • Understand network security for AI endpoints (private vs public endpoint configurations)
    • Use VPC Service Controls to protect training data and model artifacts
    • Configure IAM roles for Vertex AI (roles/aiplatform.*) with least privilege
    • Understand Customer-Managed Encryption Keys (CMEK) for AI data encryption
    • Secure model serving endpoints with authentication and authorization
  • Confidential Computing
    • Provides hardware-based memory encryption for data-in-use protection
    • Confidential VMs encrypt data while processing, offering protection from cloud operator access
    • Supports secure collaboration and federated learning without revealing individual data
    • Available for Compute Engine, GKE, and AI/ML workloads

Software Supply Chain Security (New Exam Topic)

  • Binary Authorization
    • Deploy-time security control that ensures only trusted container images are deployed on GKE or Cloud Run
    • Enforces signature verification policies before deployment
  • Artifact Registry
    • Universal package manager for container images and language packages
    • Supports vulnerability scanning with Artifact Analysis
    • Replaces Container Registry (deprecated)
  • Software Delivery Shield
    • End-to-end software supply chain security solution
    • Covers source code, build, deploy, and runtime phases
    • Integrates Cloud Build, Artifact Registry, Binary Authorization, and GKE security features

Compliance

  • FIPS 140-2 Validated
    • FIPS 140-2 Validated certification was established to aid in the protection of digitally stored unclassified, yet sensitive, information.
    • Google Cloud uses a FIPS 140-2 validated encryption module called BoringCrypto in the production environment. This means that both data in transit to the customer and between data centers, and data at rest are encrypted using FIPS 140-2 validated encryption.
    • BoringCrypto module that achieved FIPS 140-2 validation is part of the BoringSSL library.
    • BoringSSL library as a whole is not FIPS 140-2 validated
  • PCI/DSS Compliance
    • PCI/DSS compliance is a shared responsibility model
    • Egress rules cannot be controlled for App Engine, Cloud Functions, and Cloud Storage. Google recommends using Compute Engine and GKE to ensure that all egress traffic is authorized.
    • Antivirus software and File Integrity monitoring must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats including containers
    • For payment processing, the security can be improved and compliance proved by isolating each of these environments into its own VPC network and reduce the scope of systems subject to PCI audit standards
  • Assured Workloads
    • Enables compliance and sovereignty controls for regulated workloads on Google Cloud
    • Supports FedRAMP, IL4, CJIS, ITAR, and regional compliance requirements
    • Automatically applies organization policy constraints and resource location restrictions

Networking Services

  • Refer Google Cloud Security Services Cheat Sheet
  • Virtual Private Cloud
    • Understand Virtual Private Cloud (VPC), subnets, and host applications within them
    • Firewall rules control the Traffic to and from instances. HINT: rules with lower integers indicate higher priorities. Firewall rules can be applied to specific tags.
    • Know implied firewall rules which deny all ingress and allow all egress
    • Understand the difference between using Service Account vs Network Tags for filtering in Firewall rules. HINT: Use SA over tags as it provides access control while tags can be easily inferred.
    • VPC Peering allows internal or private IP address connectivity across two VPC networks regardless of whether they belong to the same project or the same organization. HINT: VPC Peering uses private IPs and does not support transitive peering
    • Shared VPC allows an organization to connect resources from multiple projects to a common VPC network so that they can communicate with each other securely and efficiently using internal IPs from that network
    • Private Access options for services allow instances with internal IP addresses can communicate with Google APIs and services.
    • Private Google Access allows VMs to connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM’s network interface.
    • Private Service Connect provides private connectivity between VPCs and services, including Google APIs and third-party services, without exposing traffic to the public internet
    • VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.
    • Firewall Rules Logging enables auditing, verifying, and analyzing the effects of the firewall rules
  • Hybrid Connectivity
    • Understand Hybrid Connectivity options in terms of security.
    • Cloud VPN provides secure connectivity from the on-premises data center to the GCP network through the public internet. Cloud VPN does not provide internal or private IP connectivity
    • Cloud Interconnect provides direct connectivity from the on-premises data center to the GCP network
  • Cloud NAT
    • Cloud NAT allows VM instances without external IP addresses and private GKE clusters to send outbound packets to the internet and receive any corresponding established inbound response packets.
    • Requests would not be routed through Cloud NAT if they have an external IP address
  • Cloud DNS
    • Understand Cloud DNS and its features
    • supports DNSSEC, a feature of DNS, that authenticates responses to domain name lookups and protects the domains from spoofing and cache poisoning attacks
  • Cloud Load Balancing
    • Google Cloud Load Balancing provides scaling, high availability, and traffic management for your internet-facing and private applications.
    • Understand Google Load Balancing options and their use cases esp. which is global, internal and does they support SSL offloading
      • Network Load Balancer – regional, external, pass through and supports TCP/UDP
      • Internal TCP/UDP Load Balancer – regional, internal, pass through and supports TCP/UDP
      • HTTP/S Load Balancer – regional/global, external, and supports HTTP/S
      • Internal HTTP/S Load Balancer – regional/global, internal, and supports HTTP/S
      • SSL Proxy Load Balancer – regional/global, external, proxy, supports SSL with SSL offload capability
      • TCP Proxy Load Balancer – regional/global, external, proxy, supports TCP without SSL offload capability

Identity Services

  • Resource Manager
    • Understand Resource Manager the hierarchy Organization -> Folders -> Projects -> Resources
    • IAM Policy inheritance is transitive and resources inherit the policies of all of their parent resources.
    • Effective policy for a resource is the union of the policy set on that resource and the policies inherited from higher up in the hierarchy.
  • Identity and Access Management
    • Identify and Access Management – IAM provides administrators the ability to manage cloud resources centrally by controlling who can take what action on specific resources.
    • A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.
    • Service Account, if accidentally deleted, can be recovered if the time gap is less than 30 days and a service account by the same name wasn’t created
    • Understand IAM Best Practices
      • Use groups for users requiring the same responsibilities
      • Use service accounts for server-to-server interactions.
      • Use Organization Policy Service to get centralized and programmatic control over the organization’s cloud resources.
    • Domain-wide delegation of authority to grant third-party and internal applications access to the users’ data for e.g. Google Drive etc.
    • Workforce Identity Federation allows external identities (from Azure AD, Okta, etc.) to access Google Cloud resources without needing Google Cloud credentials
    • Workload Identity Federation allows external workloads to access Google Cloud resources without using service account keys
    • IAM Conditions enable attribute-based access control (ABAC) for fine-grained, conditional permissions
  • Cloud Identity
    • Cloud Identity provides IDaaS (Identity as a Service) and provides single sign-on functionality and federation with external identity providers like Active Directory.
    • Cloud Identity supports federating with Active Directory using GCDS (Google Cloud Directory Sync) to implement the synchronization

Compute Services

  • Compute services like Google Compute Engine and Google Kubernetes Engine are lightly covered more from the security aspects
  • Google Compute Engine
    • Google Compute Engine is the best IaaS option for compute and provides fine-grained control
    • Managing access using OS Login or project and instance metadata
    • Compute Engine is recommended to be used with Service Account with the least privilege to provide access to Google services and the information can be queried from instance metadata.
    • Shielded VMs provide verifiable integrity of instances through Secure Boot, vTPM, and integrity monitoring
    • Confidential VMs provide hardware-based memory encryption for data-in-use protection
  • Google Kubernetes Engine
    • Google Kubernetes Engine, enables running containers on Google Cloud
    • Understand Best Practices for Building Containers
      • Package a single app per container
      • Properly handle PID 1, signal handling, and zombie processes
      • Optimize for the Docker build cache
      • Remove unnecessary tools
      • Build the smallest image possible
      • Scan images for vulnerabilities using Artifact Analysis
      • Restrict using Public Image
      • Managed Base Images
      • Use Binary Authorization to enforce deployment policies
    • GKE Security Posture dashboard provides visibility into security configurations and vulnerabilities
    • Workload Identity is the recommended way to access Google Cloud services from GKE pods (replaces node SA)

Storage Services

  • Cloud Storage
    • Cloud Storage is cost-effective object storage for unstructured data and provides an option for long term data retention
    • Understand Cloud Storage Security features
      • Understand various Data Encryption techniques including Envelope Encryption, CMEK, and CSEK. HINT: CSEK works with Cloud Storage and Persistent Disks only. CSEK manages KEK and not DEK.
      • Cloud Storage default encryption uses AES256
      • Understand Signed URL to give temporary access and the users do not need to be GCP users
      • Understand access control and permissions – IAM (Uniform) vs ACLs (fine-grained control)
      • Bucket Lock feature allows configuring a data retention policy for a bucket that governs how long objects in the bucket must be retained. The feature also allows locking the data retention policy, permanently preventing the policy from being reduced or removed
      • Object Versioning and Soft Delete for protection against accidental deletion

Monitoring

  • Google Cloud Monitoring (formerly Stackdriver)
    • provides monitoring, alert, error reporting, metrics, diagnostics, debugging, trace.
  • Google Cloud Logging (formerly Stackdriver Logging)
    • Audit logs are provided through Cloud Logging using Admin Activity and Data Access Audit logs
    • VPC Flow logs and Firewall Rules logs help monitor traffic to and from Compute Engine instances.
    • log sinks can export data to external providers via Cloud Pub/Sub, BigQuery, Cloud Storage, or third-party SIEM solutions
    • Cloud Audit Logs include Admin Activity, Data Access, System Event, and Policy Denied audit logs
  • Google Security Operations (formerly Chronicle)
    • Cloud-native SIEM and SOAR platform for threat detection, investigation, and response
    • Built on Google infrastructure for petabyte-scale security telemetry analysis
    • Integrated with Security Command Center Enterprise tier
    • Note: There is a separate Professional Security Operations Engineer certification (launched Sept 2025) for deep SecOps specialization

All the Best !!

Access Context Manager – VPC Service Controls

~ Last updated on : ~ jayendrapatil

Google Cloud Access Context Manager

  • Access Context Manager allows Google Cloud organization administrators to define fine-grained, attribute-based access control for projects and resources in Google Cloud.
  • Access Context Manager is the zero trust policy engine of Chrome Enterprise Premium (formerly BeyondCorp Enterprise), enabling context-aware access control for applications and Google Cloud resources.
  • Access Context Manager helps prevent data exfiltration.
  • Access Context Manager helps reduce the size of the privileged network and move to a model where endpoints do not carry ambient authority based on the network.
  • Access Context Manager helps define desired rules and policy but isn’t responsible for policy enforcement. The policy is configured and enforced across various points, such as VPC Service Controls.
  • Access Context Manager is an integral part of Google’s BeyondCorp zero trust effort.

Access Policies

  • An access policy is an organization-wide container for access levels and service perimeters.
  • Administrators first define an access policy, then configure access levels and service perimeters within it.
  • Scoped Policies (GA – March 2022)
    • To delegate administration, you can create access policies scoped to specific folders or projects.
    • Delegated administrators can manage only their scoped policy, not the organization-level policy.
    • Useful for decentralized management of VPC Service Controls perimeters and access levels.
  • An access policy is versioned using an etag to prevent unintended overwrites and conflicts when multiple sources modify it.

Access Levels

  • Access levels are used for permitting access to resources based on contextual information about the request.
  • Access is granted based on the context of the request, such as device type, user identity, IP address, and more, while still checking for corporate network access when necessary.
  • Access Context Manager provides two ways to define access levels: basic and custom.
    • Basic Access Level
      • is a collection of conditions that are used to test requests.
      • Conditions are a group of attributes to be tested, such as device type, IP address, user identity, or geographic region.
      • Conditions can be combined using AND (all must be true – default, stricter) or OR (any one must be true – less restrictive).
      • Supports internal IP addresses when specifying IP address ranges (GA – June 2024).
    • Custom Access Levels
      • are created using a subset of Common Expression Language (CEL).
      • helps to permit requests based on data from third-party services.
      • In addition to the request context used for basic access levels, custom access levels can evaluate data from external sources.
  • Access levels can be nested—one access level can depend on another (e.g., “High_Trust” requires “Medium_Trust” plus additional conditions).
  • Access levels support the following attributes:
    • IP address – specified as CIDR blocks; supports both public and internal (private) IP ranges
    • Device type – uses Endpoint Verification to gather OS, device type, encryption status, admin approval, and corp-owned status
    • User identity – specific users or service accounts (useful with VPC Service Controls)
    • Geographic regions – request origin region
    • Time and date conditions – restrict access to specific time windows

Service Perimeters

  • Service perimeters define sandboxes of resources that can freely exchange data within the perimeter but are not allowed to export data outside of it.
  • Service perimeters are used with VPC Service Controls to protect Google Cloud resources and prevent data exfiltration.
  • Ingress and Egress Rules (GA – April 2021)
    • Ingress rules control calls from services outside a perimeter to resources inside the perimeter.
    • Egress rules control calls from inside the perimeter to resources outside the perimeter.
    • Access levels can be used by ingress policies but cannot be used by egress policies (egress policies use contextual information directly).
  • Individual VPC Networks (GA – February 2023)
    • You can now add individual VPC networks as members of a perimeter (previously the entire VPC host project was added).
    • You can create ingress rules to authorize individual VPC networks to access a perimeter.
  • Dry Run Mode – allows testing changes to perimeters before enforcing them, helping identify potential impact without disrupting access.

Context-Aware Access

  • Context-Aware Access is a security approach where you control users’ access based on authentication strength, device posture, network location, geographic location, or other attributes.
  • Access Bindings apply access policies to user groups, enabling enforcement of context-aware access for specific groups of users.
  • App Allowlist (GA – October 2024)
    • You can create an access binding with a map of applications to access levels.
    • This allows applying access levels to specific applications, avoiding unintended effects on other applications.
  • Certificate-Based Access (CBA)
    • Uses mutual TLS (mTLS) to verify device certificates before granting access.
    • Can be enforced for user groups, with VPC Service Controls, for client applications, web applications, and VMs.
    • Supports enterprise certificates and Endpoint Verification certificates.
  • Chrome Browser Attributes
    • Zero trust policies can verify that the user’s browser has Chrome Enterprise Premium threat and data protection capabilities turned on.
    • Chrome attributes are only effective for browser-based traffic and have no effect on requests from gcloud CLI or Google Cloud SDKs.
  • Session Controls – configure re-authentication requirements for ongoing sessions.
  • Credential Strength Policy – enforce specific authentication strength (e.g., multi-factor authentication).

Policy Enforcement Points

  • Access Context Manager defines policies; enforcement happens at various integration points:
    • VPC Service Controls – enforces service perimeters and ingress/egress rules for Google Cloud APIs
    • Identity-Aware Proxy (IAP) – enforces context-aware access for web applications and VMs
    • Context-Aware Access for Google Workspace – controls access to Google Workspace applications
    • Identity and Access Management (IAM) Conditions – uses access levels as conditions in IAM policies

Custom Organization Policies (GA – March 2025)

  • Access Context Manager now supports custom organization policies.
  • Organization Policy administrators can define custom constraints for Access Context Manager resources.
  • Custom constraints allow more granular control over the specific fields that are restricted in access policies.
  • Built-in managed constraints are available, but custom constraints provide finer control.

Bulk Operations

  • The Access Context Manager Bulk API can replace all of your organization’s access levels in one operation.
  • Useful for large-scale access level management and policy migrations.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to prevent data exfiltration from their Google Cloud environment. They need to ensure that data within a set of projects cannot be accessed from outside the organization, even by users with valid IAM permissions. Which combination of services should they use?
    1. Access Context Manager and Cloud IAM only
    2. VPC Service Controls with service perimeters defined using Access Context Manager
    3. Cloud Armor and Identity-Aware Proxy
    4. Organization Policy Service with resource location constraints

    Answer: b. VPC Service Controls with service perimeters prevent data exfiltration even from authorized users by restricting data movement outside the perimeter boundary.

  2. An organization wants to grant access to sensitive resources only when requests come from corporate-managed devices running an approved OS version AND from the corporate network IP range. How should they configure Access Context Manager?
    1. Create two separate basic access levels and use OR combining
    2. Create a single basic access level with multiple conditions using AND combining (default)
    3. Create a custom access level with CEL expressions only
    4. Use IAM conditions without Access Context Manager

    Answer: b. A basic access level with AND combining (the default) requires all conditions to be true, ensuring both device posture and IP range are verified.

  3. A multinational organization wants to delegate VPC Service Controls administration to regional teams managing their own folders. Which Access Context Manager feature enables this?
    1. Custom access levels with CEL
    2. Nested access levels
    3. Scoped access policies
    4. Access bindings with app allowlists

    Answer: c. Scoped policies allow creating access policies scoped to specific folders or projects, enabling delegated administration to folder-level administrators.

  4. Which of the following statements about Access Context Manager is correct? (Choose TWO)
    1. Access Context Manager directly enforces access control policies
    2. Access Context Manager is the zero trust policy engine of Chrome Enterprise Premium
    3. Custom access levels can use data from third-party services
    4. Access levels can be used in both ingress and egress policies equally
    5. Access Context Manager requires a VPC network to function

    Answer: b, c. ACM defines policies but does not enforce them (a is incorrect). ACM is the zero trust engine of Chrome Enterprise Premium (b is correct). Custom access levels use CEL and can evaluate third-party data (c is correct). Access levels can only be used by ingress policies, not egress (d is incorrect).

  5. A company wants to apply different access levels to different SaaS applications accessed through Chrome Enterprise Premium. Some applications should require stricter device posture than others. What feature should they use?
    1. Service perimeters with VPC Service Controls
    2. Access bindings with a map of applications to access levels
    3. Multiple organization-level access policies
    4. IAM conditions with resource-level granularity

    Answer: b. The app allowlist feature (GA October 2024) allows creating access bindings with a map of applications to access levels, applying different access levels to specific applications.

  6. An organization needs to verify that users accessing sensitive resources through a browser have Chrome Enterprise Premium threat protection enabled. Which Access Context Manager feature should they configure?
    1. Basic access levels with device attributes
    2. Chrome browser attributes in access levels
    3. Certificate-based access with enterprise certificates
    4. Custom access levels with endpoint verification data

    Answer: b. Chrome browser attributes allow setting zero trust policies that verify the browser has threat and data protection capabilities enabled. Note: these attributes only apply to browser-based traffic.

See also: Google Cloud Security Services Cheat Sheet

References

Building Containers – Distroless, Buildpacks & AR

~ Last updated on : ~ jayendrapatil

Google Cloud Building Containers Best Practices

Package a single app per container

  • An “app” is considered to be a single piece of software, with a unique parent process, and potentially several child processes.
  • A container is designed to have the same lifecycle as the app it hosts, so each of the containers should contain only one app. When a container starts, so should the app, and when the app stops, so should the container. for e.g. in the case of the classic Apache/MySQL/PHP stack, each component must be hosted in a separate container.

Properly handle PID 1, signal handling, and zombie processes

  • Linux signals are the main way to control the lifecycle of processes inside a container.
  • The app within the container should handle the Linux signals, as well as the best practice of a single app per container should be implemented.
  • Process identifiers (PIDs) are unique identifiers that the Linux kernel gives to each process.
  • PIDs are namespace, i.e. the containers PIDs are different from the host and are mapped to the PIDs on the host system.
  • Docker and Kubernetes use signals to communicate with the processes inside containers, most notably to terminate them.
  • Both Docker and Kubernetes can only send signals to the process that has PID 1 inside a container.
  • For Signal handling and Zombie processes following can be followed
    • Run as PID 1 and register signal handlers
      • Launch the process with the CMD and/or ENTRYPOINT instructions in the Dockerfile, which would give the PID 1 to the process
      • Use the built-in exec command to launch the process from the shell script. The exec command replaces the script with the program and the process then inherits PID 1.
    • Enable process namespace sharing in Kubernetes
      • Process namespace sharing for a Pod can be enabled where Kubernetes uses a single process namespace for all the containers in that Pod.
      • Kubernetes Pod infrastructure container becomes PID 1 and automatically reaps orphaned processes.
    • Use a specialized init system
      • Init system such as tini created especially for containers that can be used to handle signals and reaps any zombie processes

Optimize for the Docker build cache

  • Images are built layer by layer, and in a Dockerfile, each instruction creates a layer in the resulting image.
  • Docker build cache can accelerate the building of container images.
  • During a build, when possible, Docker reuses a layer from a previous build and skips a potentially costly step.
  • Docker can use its build cache only if all previous build steps used it.

Use Multi-Stage Builds

  • Multi-stage builds allow separating the build environment from the runtime environment in a single Dockerfile using multiple FROM statements.
  • Build tools, compilers, and development dependencies are isolated in early stages and only the final artifacts are copied into the minimal runtime image.
  • This significantly reduces the final image size and attack surface.
  • Google Cloud Build supports multi-stage Dockerfiles natively and recommends separating building of the application from assembling its runtime container.
  • Example pattern: use a full SDK image to compile, then copy binaries into a distroless or minimal base image for production.

Use Distroless or Minimal Base Images

  • Distroless images (maintained by Google at gcr.io/distroless/) contain only the application runtime and its dependencies — no package managers, shells, or other programs.
  • Distroless images drastically reduce the attack surface and result in smaller image sizes with fewer CVE findings.
  • Available for multiple runtimes: Java, Python, Node.js, Go (static), .NET, and base/CC variants.
  • For cases where a shell is needed for debugging, consider using the :debug tag variants in non-production environments only.
  • Alternative minimal base images include Alpine Linux, Debian Slim, and Google’s managed base images.

Remove unnecessary tools

  • Remove unnecessary tools helps reduce the attack surface of the app by removing any unnecessary tools.
  • Avoid running as root inside the container: this method offers the first layer of security and could prevent attackers from modifying files
  • Launch the container in read-only mode using the --read-only flag from the docker run or by using the readOnlyRootFilesystem option in Kubernetes.
  • Apply seccomp profiles to containers to restrict system calls to the kernel — GKE supports the default containerd seccomp profile and custom profiles for additional hardening.
  • Use GKE Sandbox (gVisor) to run untrusted workloads with an additional kernel-level isolation layer that intercepts system calls.

Build the smallest image possible

  • Smaller image offers advantages such as faster upload and download times
  • To reduce the size of the image, install only what is strictly needed
  • Use multi-stage builds to separate build dependencies from runtime dependencies
  • Prefer distroless or scratch-based images for compiled languages (Go, Rust)
  • Combine RUN commands with && to reduce the number of layers and avoid leftover files from intermediate steps

Scan images for vulnerabilities

  • For vulnerabilities, as the containers are supposed to be immutable, the best practice is to rebuild the image, patches included, and redeploy it
  • As containers have a shorter lifecycle and a less well-defined identity than servers, a centralized inventory system would not work effectively
  • Artifact Analysis (formerly Container Analysis) can scan images for security vulnerabilities in publicly monitored packages, including OS, Java, Go, Python, and Node.js packages
  • Artifact Analysis provides both automatic scanning (triggered on every push to Artifact Registry) and on-demand scanning (manual scans of local or registry images)
  • Generate Software Bill of Materials (SBOM) for your container images to track all dependencies and license compliance
  • Integrate vulnerability scanning into CI/CD pipelines using Cloud Build and Binary Authorization to enforce that only verified, signed images are deployed

Using public image

  • Consider before using public images as you cannot control what’s inside them
  • Public image such as Debian or Alpine can be used as the base image and building everything on top of that image
  • Use Assured Open Source Software (Assured OSS) from Google for curated and tested open source packages
  • Pin images using SHA256 digest references (e.g., image@sha256:abc123...) rather than mutable tags like :latest to ensure reproducibility

Managed Base Images

  • Managed base images are base container images that are automatically patched by Google for security vulnerabilities, using the most recent patches available from the project upstream
  • Google provides Container-Optimized OS (cos) for running containers on Compute Engine and GKE nodes, which is automatically updated with security patches

Store Images in Artifact Registry

  • Container Registry was shut down on March 18, 2025 — all container images must now be stored in Artifact Registry
  • Artifact Registry supports both container images and non-container artifacts (Maven, npm, Python packages, etc.)
  • Artifact Registry provides integrated vulnerability scanning through Artifact Analysis, IAM-based access control, and regional/multi-regional storage options
  • Automatic migration tools are available to migrate existing gcr.io endpoints to Artifact Registry without downtime

Use Cloud Native Buildpacks

  • Google Cloud’s buildpacks transform application source code into production-ready OCI container images without requiring a Dockerfile
  • Buildpacks automatically detect the application language and framework, install dependencies, and produce optimized images following container best practices
  • Supported languages include Go, Java, Node.js, Python, .NET, Ruby, and PHP
  • Buildpacks produce reproducible builds and automatically apply security patches to the builder stack
  • Integrated with Cloud Build, Cloud Run, and App Engine for seamless source-to-production workflows
  • The default builder uses Ubuntu 24 as of 2025 (gcr.io/buildpacks/builder)

Supply Chain Security

  • Binary Authorization ensures that only trusted, signed container images are deployed to GKE, Cloud Run, or Distributed Cloud environments
  • Implement SLSA (Supply chain Levels for Software Artifacts) framework to establish provenance and verify the integrity of build artifacts
  • Software Delivery Shield provides an end-to-end software supply chain security solution across Google Cloud, covering source, build, artifacts, deployment, and runtime
  • Use attestations in CI/CD pipelines to cryptographically verify that images pass required checks (vulnerability scan, code review, testing) before deployment
  • Integrate with Security Command Center to view container vulnerability findings alongside other cloud security risks

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. When creating a secure container image, which two items should you incorporate into the build if possible?
    1. Use public container images as a base image for the app.
    2. Build the smallest image possible
    3. Use many container image layers to hide sensitive information.
    4. Package multiple applications in a container
  2. Your organization wants to ensure only signed and verified container images are deployed to your GKE clusters. Which Google Cloud service should you use?
    1. Artifact Analysis
    2. Cloud Armor
    3. Binary Authorization
    4. Container-Optimized OS
  3. Which Google Cloud service should you use to store and manage your container images now that Container Registry has been shut down?
    1. Cloud Storage
    2. Artifact Registry
    3. Container Registry (deprecated)
    4. Cloud Build
  4. You want to containerize your application without writing a Dockerfile. Which Google Cloud feature allows source-to-image transformation?
    1. Cloud Build triggers
    2. Cloud Native Buildpacks
    3. Container-Optimized OS
    4. Artifact Analysis
  5. Which type of base image is recommended by Google for production containers to minimize the attack surface?
    1. Ubuntu full image
    2. Alpine with development tools
    3. Distroless images
    4. CentOS base image
  6. Your team needs to automatically scan container images for OS and language package vulnerabilities every time an image is pushed to the registry. Which Google Cloud feature provides this?
    1. Cloud Build steps
    2. Binary Authorization attestations
    3. Artifact Analysis automatic scanning
    4. GKE Security Posture dashboard

References