Google Cloud Platform Deep Dive Questions

In depth coverage of Google Cloud Platform services across compute, networking, storage, orchestration, and platform integrations. Areas include Compute Engine instance management and machine type selection, Google Kubernetes Engine concepts for container orchestration, managed databases such as Cloud SQL and Firestore, Cloud Storage features including versioning and lifecycle, networking components including Virtual Private Cloud, VPN and load balancing, content delivery with Cloud CDN, eventing and messaging with Pub/Sub, and analytics with BigQuery. Candidates should demonstrate design decisions, operational practices, scaling strategies, security and identity considerations, and service limits and trade offs for production deployments.

HardTechnical

37 practiced

Propose a key management and encryption strategy using Cloud KMS and External Key Manager to meet PCI-DSS requirements on GCP. Address CMEK vs CSEK, HSM-backed keys, key rotation, separation of duties, audit logging, and how to prove compliance during a customer security review.

Sample Answer

Requirements:- Encrypt cardholder data (CHD) at rest and in transit per PCI-DSS.- Customer control of keys, HSM-backed key material, rotation, separation of duties, full audit trail, and demonstrable evidence for audits/reviews.

High-level approach:- Use Google Cloud KMS (Cloud KMS) with external key manager (EKM) appliance or partner-managed HSM (e.g., Cloud HSM or a validated BYOK with EKM) so keys are under customer control and backed by FIPS 140-2/3 HSMs.- Prefer CMEK (Customer-Managed Encryption Keys) for GCP services (BigQuery, GCS, etc.) where Cloud KMS supplies keys to Google services. Use EKM integration for keys that must never leave customer HSM boundary (CSEK/Bring Your Own Key via EKM for disk-level encryption when strict key custody is required).

CMEK vs CSEK:- CMEK: Easier integration, Google manages crypto operations but customer controls key lifecycle and IAM; use when audit requires customer-managed but cloud-operated keys.- CSEK/EPK via EKM: Use when policy requires cryptographic operations to happen only in customer/partner HSM or key material must not be exportable. More operational complexity and limited service coverage.

Key lifecycle & rotation:- Enforce automated rotation policy (e.g., 90–365 days) via Cloud KMS key versions. Use KMS to create new key versions, rewrap data keys using envelope encryption to minimize data re-encryption windows.- Maintain a documented rotation schedule, automated key promotion, and secure archival/destruction procedures aligned with PCI retention rules.

Separation of duties:- Implement least-privilege IAM roles: separate key administrators (can create/rotate keys) from key usage roles (can encrypt/decrypt), and separate from audit/ops. Use VPC Service Controls and Organization Policies to restrict access.- Require multi-party approval workflows (e.g., Cloud Functions + Pub/Sub + IAM approvals) for sensitive ops like key destruction.

Audit logging & monitoring:- Enable Cloud Audit Logs for KMS, EKM gateway logs, Cloud HSM logs, and Data Access logs. Forward logs to a tamper-evident, immutable destination (Cloud Storage with Object Versioning + CMEK, or BigQuery with restricted access).- Integrate with SIEM (Chronicle, Splunk) and set alerts for anomalous key usage, unauthorized IAM changes, or failed EKM responses.

Proving compliance in customer review:- Provide architecture diagram showing key flow, HSM boundaries, and services using CMEK/CSEK.- Deliver artifacts: KMS key policies, IAM role matrices, rotation schedules, audit log extracts (redacted as needed), HSM certificates (FIPS 140-2/3), EKM SLA and attestation, and penetration/controls test reports.- Offer a demo: live or recorded walkthrough showing key creation, restricted access, rotation operation, and retrieval of immutable audit logs.- Supply mapping to PCI-DSS controls (e.g., 3.5/3.6 key management, 10 logging) and an evidence index for each control.

Trade-offs:- EKM/CSEK gives stronger custody guarantees but increases latency and reduces service coverage; CMEK is more integrated and operationally simpler. Choose based on contractual/regulatory requirements.

This design meets PCI-DSS by enforcing customer-controlled, HSM-backed keys, automated rotation, strict separation of duties, comprehensive immutable logs, and packaged evidence to satisfy customer audits.

MediumTechnical

43 practiced

A customer wants to enforce organization-wide naming, network, and security conventions automatically. Compare using Terraform enterprise policies, Organization Policy Service, and Policy Controller (OPA) and propose a layered approach that enforces constraints at commit-time and runtime.

Sample Answer

High-level comparison- Terraform Enterprise policies (Sentinel and Policy Sets): best for commit/plan-time governance in Terraform workflows. Enforces org conventions before apply (naming, allowed regions, resource sizes) and integrates with VCS/CI to block merges or applies. Policy-as-code, easy to tie to workspace lifecycle, but only covers infrastructure managed by Terraform.- Organization Policy Service (GCP Org Policy): cloud-native, declarative guardrails that are evaluated at runtime for GCP resources (preventing creation of disallowed APIs, regions, or IAM bindings). Enforced across all provisioning paths (console, APIs, IaC). Good for coarse-grained, account-wide constraints.- Policy Controller (OPA/Gatekeeper on GKE) : Kubernetes-level admission controller using Rego for fine-grained, runtime enforcement inside clusters (pod security, labels, network policy compliance). Strong for workloads running on K8s; not for non-K8s resources.

Proposed layered approach (commit-time + runtime)1. Pre-commit / developer feedback - Add linters and policy-as-code (tflint, tfsec, conftest with OPA/rego) in developer toolchain and CI to give fast feedback. Example: conftest tests Terraform plan JSON with Rego to enforce naming patterns.2. Plan-time / centralized IaC enforcement - Enforce Terraform Enterprise Sentinel/Policy Sets on VCS PRs and workspace runs to block non-conforming plans (naming, network CIDR ranges, required labels, allowed machine types). This prevents bad config from reaching cloud.3. Apply-time / cloud-wide guardrails (runtime) - Configure GCP Organization Policy for immutable constraints: restrict regions, enforce allowed service accounts, disable risky APIs. These protect against any provisioning path.4. Cluster/workload runtime enforcement - Deploy Policy Controller (Gatekeeper) with Rego constraints for pod-level, network, and security rules (required labels, disallow hostPath, enforce seccomp profiles). Use Config Sync to keep constraints in GitOps.5. Monitoring, drift detection, remediation - Use Cloud Asset Inventory + Config Validator or Forseti/Policy Scanner to detect drift. Integrate alerts into ticketing and automations (Cloud Run Cloud Functions) for auto-remediation where safe.6. Governance lifecycle - Store policies as code in a central repo, version, review, and test them. Provide a matrix: which policy lives where (developer > Terraform policy > Org Policy > Gatekeeper).

Why this is effective- Commit/plan-time policies stop most mistakes early and provide developer feedback.- Org Policy enforces coarse-grained, mandatory constraints across all provisioning paths.- Policy Controller enforces fine-grained runtime rules for Kubernetes workloads.- Combined, they create defense in depth: shift-left prevention plus immutable runtime guardrails and monitoring for drift.

EasyTechnical

43 practiced

Compare the core GCP compute offerings — Compute Engine, Google Kubernetes Engine (GKE), Cloud Run, and App Engine. For each service, list primary use cases, operational trade-offs, scaling model, cost considerations, and provide one concrete example workload that best fits it. As a Solutions Architect, explain how you would present these options to a customer during a sales discussion.

Sample Answer

Compute Engine (IaaS)- Primary use cases: lift-and-shift VMs, custom OS/kernel, stateful workloads, legacy apps, HPC.- Operational trade-offs: full control => more ops (patching, scaling, imaging).- Scaling model: manual or managed instance groups (horizontal autoscaling based on metrics).- Cost: pay-per-VM (sustained use discounts, committed use discounts), additional infra costs (storage, networking).- Example workload: Database replica requiring specific kernel tuning.

Google Kubernetes Engine (GKE)- Primary use cases: containerized microservices, complex CI/CD, multi-container apps, service mesh.- Operational trade-offs: orchestration complexity, need for Kubernetes expertise; offers flexible control and add-ons.- Scaling model: pod autoscaling (HPA/VPA), cluster autoscaler, node pools; supports multi-cluster.- Cost: cluster control plane often free (standard mode), pay for nodes (use preemptible/spot), operational overhead.- Example workload: Multi-service e-commerce platform with canary deploys and autoscaling.

Cloud Run (managed)- Primary use cases: stateless containers, HTTP-driven services, event-driven APIs, developer velocity.- Operational trade-offs: limited runtime control, short-lived stateless processes, less cold-start tuning than Functions.- Scaling model: rapid automatic scale-to-zero and scale-out per request concurrency.- Cost: pay-per-request CPU/memory; cost-effective for spiky/low-traffic services.- Example workload: Public REST API for a mobile app with unpredictable traffic.

App Engine (PaaS)- Primary use cases: rapid app development with minimal ops, standard web apps, opinionated runtimes.- Operational trade-offs: less control over runtime and system libs (standard); flexible env gives more control but more ops.- Scaling model: automatic scaling (basic, manual, or automatic) with scale-to-zero in some configs.- Cost: pay for instances, scaling model impacts cost predictability; reduced ops saves engineering cost.- Example workload: MVP web app or internal dashboard built in supported runtime.

How I'd present to a customer:- Start with requirements: control vs dev velocity, stateful vs stateless, expected traffic patterns, team skills, compliance.- Map needs to trade-offs visually (matrix): Control/Isolation ↔ Operational burden; Speed to market ↔ Flexibility; Cost predictability ↔ Elasticity.- Recommend options: - If they need full control, legacy lift-and-shift, or special networking => Compute Engine. - If they have containerized microservices and DevOps maturity => GKE. - If they want fast deployment of stateless services with minimal ops and unpredictable traffic => Cloud Run. - If they prioritize developer productivity in supported runtimes => App Engine.- Provide a phased approach: start with Cloud Run/App Engine for new services to validate product-market fit, use GKE for growing microservice complexity, and migrate stateful or legacy workloads to Compute Engine or managed DBs.- Discuss cost examples and runbook/skills needed; offer a PoC to validate performance and cost.

EasyTechnical

34 practiced

Describe GCP Identity and Access Management (IAM) fundamentals: difference between primitive, predefined and custom roles, service accounts vs user accounts, and the principle of least privilege. As an architect, how would you propose an IAM model for cross-team collaboration while minimizing blast radius?

Sample Answer

GCP IAM fundamentals:- Roles: Primitive roles (Owner/Editor/Viewer) are broad, legacy and not recommended for fine-grained access. Predefined roles are Google-managed, granular and suited to common job functions. Custom roles let you combine specific permissions when predefined roles are too coarse.- Accounts: User accounts represent humans (G Suite/Cloud Identity) and are used for interactive access. Service accounts are identities for workloads/services; they should be used by apps, not humans, and follow least-privilege patterns.- Principle of least privilege: Grant only required permissions at the lowest scope (resource → project → folder → org), prefer role aggregation and short-lived credentials, and regularly review access.

Proposed IAM model for cross-team collaboration (as a Solutions Architect):1. Organizational structure: Use Organization → Folders per business domain → Projects per team or workload to isolate blast radius.2. Access patterns: - Centralized security/IAM team owns org-level Owner roles; avoid broad primitive roles. - Use Google-managed predefined roles for common tasks; create audited custom roles only when necessary. - Assign team members to Google Groups and grant roles to groups (not individuals) for easier lifecycle management.3. Service accounts: One per service/component, minimal roles, enforce Workload Identity Federation or Workload Identity for GKE, avoid long-lived keys; store keys in Secret Manager if needed and rotate frequently.4. Cross-team collaboration: Use shared projects or Shared VPC where network resources are centralized; grant narrow IAM roles on specific resources (e.g., BigQuery DataViewer on dataset) rather than project-wide roles. Use IAM Conditions to limit by time, request attributes, or resource tags.5. Hardening: Enable Audit Logs, use VPC Service Controls for data exfiltration protection, implement IAM Recommender and periodic access reviews, and enforce deny policies for high-risk actions.

This model minimizes blast radius by isolating workloads into projects/folders, enforcing group-based least-privilege access, and centralizing sensitive controls and auditing.

MediumTechnical

46 practiced

A SaaS vendor asks how to structure networking for per-customer isolation: options include Shared VPC with per-customer projects, separate VPCs per customer with VPC peering, or separate organizations. Compare these approaches in terms of operational overhead, security isolation, cross-project management, and billing visibility.

Sample Answer

Situation: A SaaS vendor must isolate customer networks on GCP and is evaluating three patterns: Shared VPC with per-customer projects, separate VPC per customer with VPC peering, and separate Organizations per customer.

Comparison (operational overhead | security isolation | cross-project management | billing visibility):

1) Shared VPC with per-customer projects- Operational overhead: Moderate. Single host project for network ops; many service projects to manage IAM and resources. Easier to enforce org-wide policies.- Security isolation: Logical isolation via IAM and subnet scoping; good for tenant separation but weaker against lateral network misconfigurations because a central host project owns networks.- Cross-project management: Simple—centralized firewall, routing, and peering controls; easier to deploy shared services (logging, monitoring).- Billing visibility: Per-project billing is straightforward; cost attribution per customer aligns with service projects.

When to choose: SaaS with many tenants wanting centralized network controls and operational efficiency.

2) Separate VPC per customer with VPC peering- Operational overhead: Higher. Each VPC is independent; peering matrix grows O(n^2) if many interconnections; more network objects to manage.- Security isolation: Stronger network-level isolation since each customer has its own VPC; accidental cross-tenant access less likely.- Cross-project management: Harder—managing global routing, shared services, and firewall consistency across many VPCs is more complex; lacks transitive peering.- Billing visibility: Clear if each VPC maps to a project; billing per project/VPC gives good visibility.

When to choose: Strong isolation required for regulatory reasons and fewer tenants or automated provisioning tooling exists.

3) Separate Organizations per customer- Operational overhead: Very high—separate orgs mean distinct IAM, admin processes, networking, and support boundaries. Onboarding and governance scaled per org is costly.- Security isolation: Highest. Complete administrative and policy separation; ideal for customers requiring full tenancy (e.g., MSP or sovereign customers).- Cross-project management: Difficult—cross-org integrations require explicit trust, shared VPC is not available across orgs; centralized shared services are almost impossible without complex interconnects.- Billing visibility: Cleanest for customer-paid models—totally separated billing and contractual boundaries.

When to choose: Enterprise customers demanding full tenancy, compliance, or contractual separation.

Trade-offs & recommendation:- For typical multi-tenant SaaS with many customers: Shared VPC + per-customer projects balances operational efficiency and acceptable isolation while enabling centralized security controls and per-customer billing.- If regulatory/compliance demands strict network separation: Use separate VPC per customer (or per-project VPCs) and automate provisioning to reduce overhead.- For a small number of large, sensitive customers: Offer a separate Organization option as a premium, jointly managed deployment.

Also consider: automation for provisioning and policy-as-code, organization policies, VPC Service Controls, IAM best practices, and using billing export + labels to maintain cost visibility across models.

Unlock Full Question Bank

Get access to hundreds of Google Cloud Platform Deep Dive interview questions and detailed answers.

Join thousands of developers preparing for their dream job.