Google Cloud interview questions covering compute, storage, networking, IAM, GKE, Cloud Run, BigQuery, observability, and security.
Google Cloud Platform, or GCP, is a set of cloud services for running applications, storing data, analyzing events, training AI models, securing workloads, and operating infrastructure. In an interview, explain it as more than virtual machines: a production GCP system usually combines identity, networking, compute, storage, observability, automation, and cost controls. For example, an API might run on Cloud Run, store files in Cloud Storage, publish events to Pub/Sub, write reports to BigQuery, and use Cloud Monitoring for alerts.
The resource hierarchy is Organization, Folders, Projects, and Resources. The organization represents the company boundary. Folders group departments, environments, or business units. Projects are the main boundary for APIs, IAM, billing, quotas, logs, and resources. Resources are services such as VMs, buckets, databases, and topics. A good answer should mention that policies applied higher in the hierarchy can be inherited by lower resources, which is useful for governance but dangerous if a broad policy is applied carelessly.
Projects are important because they isolate resources, billing, API enablement, IAM bindings, quotas, and operational ownership. Teams often create separate projects for development, staging, and production so risky experiments do not affect production. A practical design might use one production project for the application, one shared networking project, and one logging or analytics project. Interviewers usually expect you to say that project naming, labels, budgets, and audit logs should be planned before resources are created.
gcloud projects list
gcloud config set project my-prod-project
gcloud services enable run.googleapis.com storage.googleapis.com pubsub.googleapis.comFolders help group projects by environment, department, region, compliance boundary, or product line. For example, a company may create folders named Production, NonProduction, Data, and Sandbox. Organization policies and IAM roles can be assigned at folder level so each group follows common rules. The tradeoff is inheritance: if a restrictive policy is applied to a parent folder, child projects may break unexpectedly. Always document folder-level policies and test them in a lower environment before applying them broadly.
Identity and Access Management controls who can do what on which resource. A binding connects a principal, such as a user, group, service account, or workload identity, to a role on a resource. Roles contain permissions. Strong GCP answers emphasize least privilege, groups over individual users, service accounts for applications, conditional access where useful, and regular access reviews. Avoid giving broad roles like Owner or Editor to normal users or workloads.
Primitive roles are broad legacy roles such as Owner, Editor, and Viewer. Predefined roles are service-specific roles managed by Google, such as Cloud Run Admin or BigQuery Data Viewer. Custom roles are user-defined sets of permissions for cases where predefined roles are too broad or too narrow. In production, prefer predefined roles first, use custom roles for clear least-privilege gaps, and avoid primitive roles except for tightly controlled administrative cases.
A service account is an identity used by an application, VM, function, build job, or other non-human workload. Instead of sharing user credentials, assign a service account to the workload and grant only the required roles. For example, a Cloud Run service that reads one bucket should receive storage object viewer access for that bucket, not project-wide owner access. Rotate away from downloaded keys where possible and prefer attached service accounts or workload identity federation.
gcloud iam service-accounts create api-runner \
--display-name="Cloud Run API identity"
gcloud projects add-iam-policy-binding my-prod-project \
--member="serviceAccount:api-runner@my-prod-project.iam.gserviceaccount.com" \
--role="roles/logging.logWriter"Service account keys are long-lived credentials that can be copied outside Google Cloud. If a key is leaked through a repository, laptop, CI log, or ticket, an attacker can use it until it is revoked. Better options are attached service accounts for GCP workloads, Workload Identity for GKE, Workload Identity Federation for external systems, and short-lived tokens. If keys are unavoidable, store them in a secret manager, rotate them, audit usage, and alert on unexpected authentication events.
Workload Identity Federation lets external workloads access Google Cloud without storing service account keys. Instead of downloading a JSON key, an external identity provider such as GitHub Actions, Azure AD, or an on-prem identity system exchanges a trusted token for a short-lived Google credential. This is common in CI/CD because it reduces secret leakage risk. In an interview, mention trust configuration, provider conditions, least-privilege service accounts, and audit logging.
A Virtual Private Cloud network is a global private network that contains regional subnets. It controls private IP addressing, routes, firewall rules, peering, VPNs, NAT, and private connectivity. Unlike many clouds where a VPC is regional, a GCP VPC is global and subnets are regional. A good answer includes CIDR planning, separate networks or projects for environment isolation, private access to managed services, and clear firewall policy.
Subnets are regional IP ranges inside a VPC. Resources such as Compute Engine VMs and GKE nodes are placed into subnets. You can use auto mode networks for simple labs, but custom mode networks are preferred in production because they make IP planning explicit. For GKE, remember that secondary IP ranges may be needed for pods and services. Poor subnet planning can cause overlapping ranges, migration pain, and private connectivity failures.
Firewall rules allow or deny traffic based on direction, protocol, port, source or destination, priority, and targets. Rules can target all instances, network tags, or service accounts. Lower priority numbers win. A secure design avoids broad inbound rules such as 0.0.0.0/0 for SSH or databases, uses Identity-Aware Proxy or VPN for administration, and logs firewall decisions for sensitive paths. In interviews, explain both ingress and egress control.
Cloud NAT lets private instances reach the internet for outbound connections without having public IP addresses. It is useful when VMs or GKE nodes need to download packages, call third-party APIs, or reach external services while staying private. Cloud NAT does not allow unsolicited inbound traffic. You should monitor NAT port allocation, connection errors, and egress cost, especially for high-throughput workloads.
Cloud Load Balancing distributes traffic across backends such as instance groups, Cloud Run services, GKE services, or backend buckets. Google Cloud has global external HTTP(S) load balancing for web traffic, regional load balancers for internal or regional traffic, and TCP/UDP options. A strong interview answer mentions health checks, backend services, URL maps, SSL certificates, Cloud Armor integration, CDN integration, and how load balancing supports high availability.
Cloud CDN caches static and cacheable content close to users at Google edge locations. It reduces latency, origin load, and sometimes egress cost. Use it for images, JavaScript, CSS, downloads, and cacheable API responses. The tricky part is cache correctness: configure cache-control headers, invalidation strategy, signed URLs or cookies for protected content, and metrics for hit ratio. Do not cache personalized responses unless the cache key safely separates users.
Choose Compute Engine when you need VM-level control: custom agents, specialized operating systems, lift-and-shift applications, GPUs, stateful software, or workloads that do not fit serverless constraints. The tradeoff is operational responsibility. You must patch images, configure startup scripts, manage disks, monitor health, and plan autoscaling. For new stateless web services, Cloud Run or GKE may reduce operations, but Compute Engine remains useful for controlled infrastructure scenarios.
Managed instance groups run identical VM instances from an instance template and provide autoscaling, autohealing, rolling updates, and load balancer integration. They are useful for stateless VM-based services. A production answer should mention health checks, update policies, regional managed instance groups for zone failure tolerance, and immutable templates. Stateful applications need extra care because replacing an instance may affect local data or sessions.
App Engine is a platform service for applications with opinionated runtimes and versions. Cloud Run runs containers on a serverless platform and is flexible for HTTP services, jobs, and event-driven workloads. Cloud Functions runs small event-driven functions with less container and server management. In modern interviews, Cloud Run is often the preferred answer for portable containerized services, while Functions is good for focused triggers and App Engine is common in older or highly managed applications.
Build or provide a container image, choose a region, configure environment variables, attach a service account, set ingress and authentication, and deploy. Cloud Run creates a revision for each deployment, so rollbacks are straightforward. In production, avoid default service accounts, restrict unauthenticated access unless the service is public, set concurrency and min instances intentionally, and monitor latency, errors, cold starts, and CPU or memory usage.
gcloud run deploy orders-api \
--image=us-docker.pkg.dev/my-prod-project/apps/orders-api:1.4.2 \
--region=us-central1 \
--service-account=orders-api@my-prod-project.iam.gserviceaccount.com \
--no-allow-unauthenticatedA Cloud Run revision is an immutable snapshot of service configuration and container image. Every deployment creates a new revision. Traffic can be split between revisions for canary releases, gradual rollouts, or quick rollback. The key interview point is that revisions make deployment history explicit, but database migrations and external dependencies still need safe rollout planning. Do not assume revision rollback can undo data changes.
Google Kubernetes Engine is Google Cloud's managed Kubernetes service. Choose it when you need Kubernetes APIs, multi-container orchestration, custom networking, service mesh, workload portability, complex scheduling, or a platform shared by many teams. The tradeoff is complexity: you must understand clusters, node pools, upgrades, autoscaling, RBAC, network policies, workload identity, and observability. For a single stateless service, Cloud Run may be simpler.
GKE Standard gives more control over node pools, machine types, daemonsets, and cluster configuration. GKE Autopilot manages more infrastructure for you and bills closer to requested pod resources. Autopilot is attractive for teams that want Kubernetes without node management, while Standard suits advanced networking, specialized nodes, or deeper platform control. In an interview, compare operational effort, flexibility, cost predictability, and security defaults.
Use least-privilege Kubernetes RBAC, Workload Identity instead of service account keys, private clusters where appropriate, network policies for pod-to-pod restrictions, Binary Authorization or admission controls for image policy, regular upgrades, and separate namespaces for ownership boundaries. Also configure logging and metrics, avoid privileged containers, scan images, and restrict who can create cluster-admin bindings. Security in GKE is both Kubernetes security and Google Cloud IAM security.
Cloud Storage stores objects such as images, backups, logs, exports, static assets, machine learning datasets, and data lake files. It is not a POSIX file system; objects are stored in buckets and addressed by name. Design decisions include location type, storage class, lifecycle rules, retention policy, uniform bucket-level access, public access prevention, encryption, and versioning. For web assets, it often integrates with a load balancer and Cloud CDN.
gcloud storage buckets create gs://tl-prod-assets \
--location=US \
--uniform-bucket-level-access
gcloud storage cp ./logo.png gs://tl-prod-assets/images/logo.pngStandard is best for frequently accessed data. Nearline, Coldline, and Archive are cheaper for storage but designed for less frequent access and may have retrieval or minimum storage duration considerations. A common design uses lifecycle rules to move old logs or backups to cheaper classes. Do not choose Archive for data that operations teams need during an urgent incident unless restore time and retrieval cost are acceptable.
Cloud SQL is a managed relational database service for MySQL, PostgreSQL, and SQL Server. Google handles much of provisioning, backups, patching, replication, and monitoring, but you still design schemas, indexes, connection pooling, availability, backups, and security. In production, prefer private IP where possible, avoid opening databases to the public internet, configure automated backups, test restores, and monitor CPU, storage, locks, slow queries, and connections.
Cloud Spanner is a globally distributed relational database with horizontal scaling and strong consistency. It is useful when a business needs relational semantics, high availability, large scale, and regional or multi-regional distribution. Cloud SQL is usually simpler and cheaper for normal relational workloads. Choose Spanner when Cloud SQL limits become a real problem, not just because the system might grow one day.
Firestore is a managed NoSQL document database commonly used for web, mobile, and serverless applications. It stores documents in collections and supports real-time sync patterns. Interviewers expect you to understand document modeling, query indexes, transaction limits, security rules for client access, and cost behavior based on reads, writes, deletes, and storage. Do not model Firestore like a relational database with heavy joins.
BigQuery is a serverless data warehouse for analytics over large datasets. It is designed for SQL-based analysis, reporting, data marts, dashboards, and batch or streaming analytics. A good answer mentions partitioning, clustering, query cost, slots or on-demand pricing, schema design, data governance, and separating transactional systems from analytical workloads. BigQuery is not a replacement for low-latency OLTP databases.
SELECT
DATE(order_created_at) AS order_date,
COUNT(*) AS orders,
SUM(total_amount) AS revenue
FROM `analytics.orders`
WHERE order_created_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY order_date
ORDER BY order_date;Control cost by partitioning tables, clustering frequently filtered columns, selecting only required columns, previewing bytes processed, using table expiration for temporary data, materializing repeated heavy transformations, and setting budgets or custom quotas. Avoid SELECT * on large tables. In interviews, connect cost to design: analytics tables should be shaped around common questions so users do not scan unnecessary data repeatedly.
Pub/Sub is a managed messaging service for asynchronous event delivery. Publishers send messages to topics, and subscribers receive them through push or pull subscriptions. It helps decouple services, smooth traffic spikes, and connect event-driven systems. A good answer mentions at-least-once delivery, idempotent consumers, acknowledgement deadlines, dead-letter topics, ordering keys when needed, retries, and monitoring message age or undelivered messages.
gcloud pubsub topics create order-events
gcloud pubsub subscriptions create order-worker --topic=order-events
gcloud pubsub topics publish order-events \
--message='{"orderId":"A1001","status":"paid"}'Pub/Sub can deliver messages more than once, so consumers should be idempotent. Use a unique event ID, store processed IDs where appropriate, make updates conditional, and design side effects such as email sending or payment capture carefully. Acknowledging too early risks losing work after a crash; acknowledging too late increases duplicates. Monitor retry counts, dead-letter topics, and processing latency to detect unhealthy consumers.
Dataflow is a managed service for Apache Beam pipelines. It processes batch and streaming data and is commonly used for ETL, event enrichment, aggregations, and moving data between Pub/Sub, Cloud Storage, BigQuery, and other systems. Choose Dataflow when transformation logic, windowing, late events, or scale requirements exceed a simple Cloud Function or scheduled job. Interviewers may ask about windows, triggers, watermarks, and exactly-once-style processing behavior.
Secret Manager stores secrets such as API keys, database passwords, and webhook tokens with versioning, IAM, audit logs, and encryption. Environment variables can still be used to inject secret values at runtime, but the source of truth should be managed and auditable. In interviews, explain that secrets need least-privilege access, rotation, separation by environment, no logging, and an incident plan for compromised values.
printf "super-secret-value" | gcloud secrets create payment-api-key \
--data-file=-
gcloud secrets add-iam-policy-binding payment-api-key \
--member="serviceAccount:payments@my-prod-project.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"Cloud Key Management Service manages cryptographic keys used to encrypt, decrypt, sign, and verify data. Many Google services can use customer-managed encryption keys when compliance or control requires it. A strong answer covers key rings, keys, versions, rotation, IAM separation, audit logs, and blast radius. Losing access to a key can make protected data unusable, so key administration must be handled carefully.
Artifact Registry stores build artifacts such as Docker images, language packages, and Helm charts. It replaces older Container Registry patterns for many modern projects. A production setup should use regional repositories close to deployment targets, vulnerability scanning where available, IAM-limited push and pull permissions, retention cleanup, and image promotion across environments. Do not let every developer or build job push directly to production repositories.
Cloud Build is a managed CI service for building, testing, packaging, and publishing artifacts. A build can run from source repositories, triggers, or manual invocation. In a good answer, mention build steps, service account permissions, secrets, artifact provenance, caching, test stages, image tagging, and deployment handoff. The build identity should have only the permissions needed for that pipeline, not broad project editor access.
steps:
- name: gcr.io/cloud-builders/docker
args: ["build", "-t", "us-docker.pkg.dev/my-project/apps/api:$SHORT_SHA", "."]
- name: gcr.io/cloud-builders/docker
args: ["push", "us-docker.pkg.dev/my-project/apps/api:$SHORT_SHA"]
images:
- us-docker.pkg.dev/my-project/apps/api:$SHORT_SHATerraform defines Google Cloud resources as code, allowing reviews, repeatable environments, drift detection, and safer changes. Use the Google provider, remote state, service accounts with limited permissions, modules for repeated patterns, and separate state for environments or ownership boundaries. Avoid manual console changes after Terraform manages a resource. In review, check IAM blast radius, networking changes, deletion plans, and provider version changes.
provider "google" {
project = "my-prod-project"
region = "us-central1"
}
resource "google_compute_network" "app" {
name = "app-vpc"
auto_create_subnetworks = false
}
resource "google_compute_subnetwork" "web" {
name = "web-us-central1"
ip_cidr_range = "10.10.0.0/20"
region = "us-central1"
network = google_compute_network.app.id
}Cloud Logging collects logs from Google Cloud services, applications, and infrastructure. Good logs include request IDs, user or tenant context where safe, severity, operation names, and structured fields. Avoid logging secrets or sensitive personal data. For production, create log-based metrics for important failures, route long-term or compliance logs to BigQuery or Cloud Storage, and define retention based on operational and legal needs.
Cloud Monitoring collects metrics, dashboards, uptime checks, and alerting policies. A practical answer focuses on service-level symptoms: latency, error rate, traffic, saturation, queue age, database connections, CPU, memory, and availability. Good alerts are actionable and tied to user impact. Avoid alerting on every noisy metric. Use dashboards for diagnosis, alerts for urgent action, and SLOs to align operations with business expectations.
VPC Service Controls creates security perimeters around supported Google Cloud services to reduce data exfiltration risk. For example, a company can restrict BigQuery and Cloud Storage access so data cannot be copied to an unauthorized project. It is powerful but can break legitimate workflows if not planned carefully. Interviewers expect you to mention dry-run mode, access levels, perimeter bridges, service limitations, and careful rollout.
Cloud Armor is a web application firewall and DDoS protection service integrated with Google Cloud load balancing. It can enforce IP allowlists or denylists, geo rules, rate limiting, preconfigured WAF rules, and custom expressions. It is not a replacement for secure application code, but it reduces exposure at the edge. A strong answer includes testing rules in preview, monitoring false positives, and protecting public HTTP(S) endpoints.
Identity-Aware Proxy protects access to applications or administrative endpoints based on user identity and context, without requiring a traditional VPN for every case. It is commonly used to secure internal web tools and SSH access to VMs. A good answer explains that IAP checks identity before traffic reaches the resource, but application-level authorization may still be required for business permissions inside the app.
Organization policies enforce governance constraints across the resource hierarchy. Examples include disabling service account key creation, restricting allowed regions, requiring shielded VMs, or blocking public IP usage. They are useful for compliance and consistency, but they can surprise teams if applied without communication. Test policies in lower folders or dry-run style workflows when possible, document exceptions, and assign ownership for policy changes.
Use budgets and alerts, billing export to BigQuery, labels, committed use discounts where stable, autoscaling, lifecycle rules, rightsizing recommendations, log volume controls, and regular cleanup of idle resources. Tie cost to teams or products so owners can act on it. A strong answer separates guardrails from shutdown automation: budgets alert by default, while automatic shutdown should be used carefully because it can cause outages.
Choose regions based on user latency, data residency, service availability, cost, and disaster recovery requirements. Use multiple zones in a region for high availability when the service supports it. Multi-region designs improve resilience but add complexity, data replication concerns, and cost. Do not blindly deploy everywhere. Start with clear recovery time objective, recovery point objective, compliance rules, and expected traffic geography.
A typical design uses a global external HTTPS load balancer, Cloud Armor, Cloud CDN for static content, serverless or multi-zone compute, a managed database with high availability, private networking, Secret Manager, Cloud Logging, Cloud Monitoring, and automated deployments. Static assets may live in Cloud Storage. Events can go through Pub/Sub. The important interview skill is explaining failure points and how each component continues or recovers when a zone, instance, or revision fails.
Users
-> HTTPS Load Balancer + Cloud Armor
-> Cloud Run service or GKE service
-> Cloud SQL with HA / Firestore / Spanner
-> Pub/Sub for async work
-> Cloud Storage for objects
-> Cloud Logging + Cloud Monitoring for operationsStart with RTO and RPO. Then configure database backups, object versioning or retention, infrastructure-as-code, cross-region replication where needed, and documented restore runbooks. Test restores regularly because a backup that has never been restored is only an assumption. For critical systems, rehearse regional failure scenarios, keep deployment artifacts available, and ensure IAM and encryption keys are recoverable by the right emergency process.
Common mistakes include granting Owner or Editor broadly, using downloaded service account keys, exposing databases publicly, opening SSH to the internet, leaving buckets public, mixing production and development in one project, ignoring audit logs, storing secrets in source code, and forgetting egress paths. A strong answer pairs each mistake with a fix: least privilege, private networking, IAP, Secret Manager, organization policies, monitoring, and regular review.
A complete pipeline starts when code is committed. CI runs tests, builds a container, scans it, and stores it in Artifact Registry. CD promotes that exact image through staging and production using Cloud Deploy, Terraform, or a controlled release process. The runtime service uses a dedicated service account and emits logs and metrics. Rollback means returning traffic to a previous safe revision or release, while database changes require backward-compatible migration planning.
Explore 500+ free tutorials across 20+ languages and frameworks.