50 Advanced Google Cloud Interview Questions for Experienced Developers

• GKE Standard: You manage the cluster’s underlying nodes (the control plane is managed by Google). You are responsible for configuring node pools, scaling, and performing node upgrades. This provides maximum flexibility and control.
• GKE Autopilot: A fully managed mode where Google manages the entire cluster infrastructure, including the nodes. You only define your pods and their resource requests, and Autopilot provisions and scales the necessary nodes automatically. You pay per pod resource usage.

Choose **Standard** for maximum control, custom machine types, or running specific daemons. Choose **Autopilot** for simplicity, reduced operational overhead, and a consumption-based pricing model that can be more cost-effective for certain workloads.

Read the GKE Autopilot overview.

Concurrency is the number of simultaneous requests that can be handled by a single container instance. You can configure this value (default is 80).

Scaling is driven by incoming requests.

• Scale-up: When the number of incoming requests exceeds `(current instances * concurrency)`, Cloud Run rapidly launches new instances up to your configured maximum.
• Scale-down: If an instance has no active requests, it is kept idle for a period. If it remains idle, it will be shut down. You can configure `min-instances` to keep a certain number of instances warm to reduce cold starts. Cloud Run can scale down to zero.

Read the documentation on Cloud Run Concurrency.

Cloud Functions (2nd gen) is actually built on top of Cloud Run and Eventarc. The distinction is about the developer experience and use case:

• Cloud Functions: An event-driven, function-as-a-service (FaaS) platform. You write a single function that is triggered by an event (e.g., an HTTP call, a Pub/Sub message). It’s designed for small, single-purpose pieces of logic.
• Cloud Run: A container-as-a-service platform. You package your application as a container image. It can run a full web server and handle multiple HTTP routes. It’s more flexible and suitable for running entire microservices.

Essentially, Cloud Functions provides a simpler, more abstract FaaS experience, while Cloud Run provides more power and flexibility by being container-based.

Preemptible VMs are short-lived, low-cost compute instances with a fixed price up to 80% cheaper than standard VMs. The catch is that Compute Engine can terminate (“preempt”) them at any time with a 30-second warning. They have a maximum lifetime of 24 hours.

Their primary use case is for fault-tolerant, stateless, or batch processing workloads that are not time-critical and can handle interruptions gracefully. Examples include big data analysis with Spark/Hadoop, scientific computing, and CI/CD build agents.

• App Engine Standard: Runs applications in a language-specific, sandboxed environment. It offers extremely fast scaling (including scaling to zero) and is very simple to use. However, it’s restrictive: you can’t use custom runtimes, write to the local filesystem, or run background processes.
• App Engine Flexible: Runs your application inside a Docker container on a Compute Engine VM. This provides much more flexibility—you can use any language, run background processes, and access the local disk. However, scaling is slower, and it cannot scale to zero (a minimum of one instance is always running).

Workload Identity is the recommended way for workloads running inside GKE to access Google Cloud services. It allows you to bind a Kubernetes service account to a Google Cloud IAM service account. Pods running with the Kubernetes service account can then automatically authenticate as the IAM service account to access Google APIs, without needing to manage or store service account keys. It provides a more secure and manageable way to handle authentication from within a GKE cluster.

Cloud Spanner is a globally distributed, strongly consistent relational database service. What makes it unique is that it combines the benefits of a relational database (ACID transactions, SQL, schemas) with the horizontal scalability of a NoSQL database.

Its key features are:

• Global Distribution: It can span multiple regions and continents.
• Strong External Consistency: Achieved through its TrueTime API, which uses atomic clocks to ensure transactions are correctly ordered globally.
• Horizontal Scalability: It automatically splits and shards data as it grows, allowing for massive scale.

It’s designed for mission-critical applications that require both strong consistency and global scale.

Read the introduction to Cloud Spanner.

Firestore can operate in two modes, and you choose one when you create the database.

• Native Mode: The newer, more advanced offering. It has a stronger consistency model, provides real-time updates via listeners, and has a more advanced query engine. It’s the recommended choice for new mobile and web applications.
• Datastore Mode: Provides a system that is backward-compatible with the original Google Cloud Datastore. It’s designed for backend services that require the Datastore API’s behavior, such as eventual consistency for some queries and transactions that are not limited to 25 entity groups.

The Cloud SQL Auth Proxy is a small client-side process that provides secure, encrypted access to a Cloud SQL instance without needing to whitelist IP addresses or configure SSL manually.

It works by creating a secure tunnel using IAM credentials. Your application connects to the proxy on `localhost`, and the proxy forwards the traffic over an encrypted connection to the Cloud SQL instance. This is the recommended way to connect from environments like GKE, App Engine, or a local machine because it provides strong authentication via IAM and encrypts traffic by default.

Read about the Cloud SQL Auth Proxy.

Cloud Bigtable is a petabyte-scale, wide-column NoSQL database. It’s not a general-purpose database. You should choose it for:

• Large-scale Analytical and Time-Series Data: Such as IoT sensor data, financial market data, or large analytics logs.
• High-throughput Workloads: It excels at very high write and read throughput, especially for large analytical scans.
• Integration with the Hadoop Ecosystem: It’s compatible with the HBase API.

You would not choose it for transactional applications or small datasets, where Cloud SQL or Firestore would be a better fit.

Cloud Storage offers different classes based on data access frequency and retrieval time:

• Standard: For “hot” data that is frequently accessed, offering the highest availability and lowest latency.
• Nearline: For data accessed less than once a month. Lower storage cost but has a small data retrieval fee.
• Coldline: For data accessed less than once a quarter. Even lower storage cost, higher retrieval fee.
• Archive: For long-term archival and disaster recovery. The cheapest storage cost, but with the highest retrieval fees and a retrieval time of hours.

A signed URL is a URL that provides limited, time-bound permission to perform an action on a Cloud Storage object. You generate it using cryptographic keys from a service account. It allows a user or application without Google credentials to temporarily access a specific private object. For example, you can generate a signed URL that allows a user to upload a file directly to a bucket for 15 minutes, or to download a private image.

• VPC Network Peering: Connects two VPC networks, allowing them to communicate privately using internal IP addresses. The networks must not have overlapping IP ranges.
• Cloud VPN: Creates a secure connection between your on-premises network and your GCP VPC over the public internet, using an IPsec VPN tunnel.
• Cloud Interconnect: Provides a highly available, low-latency, dedicated physical connection between your on-premises network and Google’s network. It offers much higher bandwidth than Cloud VPN and is the preferred choice for large-scale enterprise hybrid cloud setups.

Google Cloud offers several types, broadly categorized by scope and traffic type:

• Global External Load Balancers: For distributing HTTP(S), SSL Proxy, and TCP Proxy traffic from the internet to backends in multiple regions.
• Regional External Load Balancers: For distributing external traffic to backends within a single region.
• Internal Load Balancers: For distributing traffic *within* your VPC network, used for internal service-to-service communication.

A Serverless VPC Access connector provides a bridge between your serverless environment (like Cloud Run, App Engine Standard, or Cloud Functions) and your VPC network. It allows your serverless applications to access resources inside your VPC that have internal IP addresses, such as a Cloud SQL instance or a Memorystore cache, without exposing those resources to the public internet.

Read the documentation on Serverless VPC Access.

Cloud Armor is Google’s network security service that provides protection against Distributed Denial of Service (DDoS) attacks and acts as a Web Application Firewall (WAF). It works with the Global External HTTP(S) Load Balancer to help you defend your applications from common web attacks and enforce security policies, such as IP-based allow/deny lists or filtering based on geographic origin.

• Push Subscription: Pub/Sub actively sends messages to a pre-configured subscriber endpoint (e.g., a public webhook). Pub/Sub controls the rate of delivery. This is simpler to set up but requires a publicly accessible endpoint and can overwhelm the subscriber if not configured properly.
• Pull Subscription: The subscriber application is responsible for asking Pub/Sub for new messages. The subscriber controls the rate of consumption and can be located anywhere, even behind a firewall. This is the more common and robust pattern for backend services.

Pub/Sub can provide exactly-once delivery guarantees through a feature available in some client libraries (like Java and Go). It’s not a simple configuration flag but a protocol between the client and the service. The service assigns a unique ID to each message. The client library keeps track of the sequence of messages and handles acknowledgements in a transactional manner. If a message is sent but the acknowledgment is lost, the client will resend, but the service can use the message ID to deduplicate it, thus achieving an exactly-once effect for the subscriber.

Read the guide on Exactly-Once Delivery.

While both can be used for asynchronous processing, they serve different purposes.

• Use **Pub/Sub** when you need to decouple services and broadcast events to multiple independent subscribers (a fan-out pattern). It’s for event-driven architectures.
• Use **Cloud Tasks** when you need to execute a specific task at a specific time or need more control over the execution rate. It’s designed for explicit task invocation, providing features like scheduled delivery, rate limiting, and configurable retries. It’s essentially a managed cron service and task queue combined.

Cloud Workflows is a fully managed orchestration service that allows you to link a series of serverless tasks together in a specific order. You define your workflow in YAML or JSON. It’s designed to orchestrate sequences of calls to other Google Cloud services (like Cloud Functions and Cloud Run) or external HTTP APIs. It handles retries, error handling, and passing data between steps, making it ideal for building complex, resilient business processes without managing a state machine yourself.

• Primitive Roles (`Owner`, `Editor`, `Viewer`): These are broad, project-level roles that grant coarse-grained access. They are legacy roles and should be avoided in favor of more specific roles to follow the principle of least privilege.
• Predefined Roles: A curated set of granular roles managed by Google that provide permissions for a specific service (e.g., `roles/pubsub.publisher`, `roles/storage.objectAdmin`). This is the recommended choice for most use cases.
• Custom Roles: Roles you create by bundling a specific set of permissions to meet your organization’s exact needs when predefined roles are not sufficient.

IAM Conditions allow you to define attribute-based, conditional access control for Google Cloud resources. You can add a condition to a role binding that will only grant the permission if the condition evaluates to true.

A great use case is granting a user temporary access. You could create a condition that only grants a role if the current timestamp is before a specific expiration date: `request.time < timestamp("2025-12-31T23:59:59Z")`. Other conditions can be based on the resource name, type, or other request attributes.

Read the overview of IAM Conditions.

IAP is a service that lets you manage access to applications running on GCP based on a user’s identity and the context of their request, instead of using a traditional VPN. It acts as an authentication and authorization layer that sits in front of your application. When a user tries to access an IAP-secured application, IAP intercepts the request, authenticates the user with their Google identity, and checks if they have the correct IAM role to access the application. This enforces zero-trust security for your web apps.

Read the IAP Concepts Overview.

Envelope encryption is a security practice where data is encrypted with a Data Encryption Key (DEK), and the DEK itself is then encrypted with a Key Encryption Key (KEK). Cloud KMS manages the KEKs. This pattern is highly secure because the master KEK never leaves the KMS, and you can efficiently re-key your data by just re-encrypting the small DEK instead of the entire large dataset. This is how many Google Cloud services (like Cloud Storage) encrypt data at rest.

The best practice is to use **Secret Manager**. You store your secrets (like API keys or database passwords) in Secret Manager and then grant your application’s service account a specific IAM role (e.g., `roles/secretmanager.secretAccessor`) to access those secrets at runtime. This avoids hard-coding secrets in source code, configuration files, or environment variables, and provides a central place to manage and rotate secrets with fine-grained access control.

A multi-region HA design would involve:

• Load Balancing: Use a Global External HTTP(S) Load Balancer to route users to the closest healthy region.
• Compute: Deploy your application (e.g., on GKE or Managed Instance Groups) in multiple regions.
• Data: Use a multi-region database like Cloud Spanner or a Cloud SQL instance with cross-region read replicas. For object storage, use a multi-region Cloud Storage bucket.
• DNS: Use Cloud DNS with health checks to configure DNS failover between regions if one becomes completely unavailable.

• Cloud Logging (formerly Stackdriver Logging): A centralized log management service. It collects, searches, analyzes, and alerts on log data from GCP services and custom applications.
• Cloud Monitoring (formerly Stackdriver Monitoring): Collects metrics, events, and metadata from GCP services. It provides dashboards, charts, and an alerting system to notify you when performance metrics cross a defined threshold.

Together, they form the core of observability on Google Cloud.

Cloud Trace is Google Cloud’s distributed tracing system. It helps you understand the latency of requests as they travel through a distributed system, such as a microservices architecture. It collects trace data, analyzes it, and displays it in near real-time, allowing you to pinpoint performance bottlenecks and understand the interactions between your services for a single request.

• Cloud Deployment Manager: Google’s native, declarative Infrastructure as Code service. You define resources in YAML templates. It is specific to Google Cloud.
• Terraform: An open-source, declarative IaC tool that is cloud-agnostic. It uses its own configuration language (HCL). It is far more popular and has a much larger community and ecosystem. It manages state, allowing it to track the resources it has created.

Most teams prefer Terraform due to its multi-cloud capabilities, mature ecosystem, and robust state management features.

Cloud Build is a fully managed Continuous Integration (CI) service on Google Cloud. It allows you to define a series of build steps in a configuration file (e.g., `cloudbuild.yaml`). Each step runs in a Docker container. You can use it to fetch source code, run tests, build artifacts like Docker images, and push those artifacts to a registry (like Artifact Registry). It can be triggered by code pushes to a repository or be invoked manually.