GCP Core Services and Architecture Basics Questions
Core Google Cloud Platform services and architecture concepts, including Compute Engine, Kubernetes Engine (GKE), App Engine, Cloud Functions, Cloud Run, Cloud Storage, BigQuery, Pub/Sub, Cloud SQL/Spanner, and IAM. Covers foundational cloud architecture topics such as projects and resource organization, VPC networking (regions, zones, subnets), identity and access management, security considerations, and scalable design patterns for cloud-native applications on GCP.
EasyTechnical
80 practiced
A customer asks how to estimate GCP costs for a new project. Explain the approach you would take as a Solutions Architect, including which information you gather, tools you use (e.g., pricing calculator, billing exports), and how to present cost ranges and risks to a non-technical stakeholder.
Sample Answer
Approach (high level)- Start with requirements discovery: workload types, expected traffic (QPS, batch sizes), data volumes (ingress/egress, storage), SLAs (RTO/RPO, latency), regions, compliance, user growth timeline, retention and backup policies, and peak vs steady-state behavior.Information I gather- Application components (web/API, DB, analytics, ML), concurrency, average/peak CPU & memory, storage IOPS, network patterns, number of environments (dev/test/prod), expected retention, and third-party costs.Tools & process- Use GCP Pricing Calculator to model core services (Compute Engine, GKE, Cloud SQL, BigQuery, Cloud Storage, Pub/Sub, VPC egress). Build scenarios: minimal viable, typical, and peak. - Export pricing estimates into a spreadsheet to show monthly vs annual costs, include sustained use and committed use discounts (CUDs) or committed spend recommendations.- Use Billing Exports (BigQuery) for comparable historical projects / benchmarks if available.- Run cost simulations for autoscaling behavior and include network egress across regions.- Identify optimization levers: preemptible VMs, CUDs, resource rightsizing, custom machine types, lifecycle policies for storage, and reservation strategies.Presenting to non-technical stakeholders- Show 3 clear tiers: Low (MVP), Expected, High (peak) with monthly and yearly totals and top 5 cost drivers (e.g., DB, egress, analytics).- Use visuals: stacked bar chart and simple table; include per-user or per-transaction unit cost where possible.- Explain key assumptions plainly (traffic, retention, region) and sensitivity: “If traffic doubles, cost increases ~X%.”- Highlight controllable risks and mitigations (e.g., use CUDs to reduce compute by ~40%, storage lifecycle to cut cold data cost).- Recommend next steps: pilot with monitoring, enable billing exports and alerts, implement tagging for cost allocation, and revisit estimates after 30–90 days of telemetry.Example summary line for exec:“Estimated monthly range: $8k (MVP) — $32k (peak). Top risks: unexpected egress and unoptimized DB instances. Mitigations: CUDs, rightsizing, storage lifecycle — expected savings 20–40%.”
EasyTechnical
63 practiced
Compare Pub/Sub, Cloud Tasks, and Cloud Scheduler. For each service describe the primary use cases and guarantees offered. Provide an example scenario where Pub/Sub is preferred over Cloud Tasks and vice versa.
Sample Answer
Pub/Sub, Cloud Tasks, and Cloud Scheduler solve different orchestration/messaging needs. Below is a concise comparison with guarantees, primary use cases, and examples.Pub/Sub- Purpose: Asynchronous, scalable messaging/pub‑sub for event-driven architectures.- Use cases: Fan‑out event distribution, streaming telemetry, decoupling microservices, real‑time pipelines.- Guarantees: At‑least‑once delivery (clients must be idempotent), ordered delivery optionally via ordering keys, durable message storage, automatic retry until ack or message retention expires.- When preferred: Use Pub/Sub when you need broadcast to multiple independent subscribers or high throughput event ingestion.Cloud Tasks- Purpose: Managed distributed task queue for directed, ordered, retryable HTTP tasks.- Use cases: Offloading work to background workers, rate‑limited APIs, guaranteed single‑consumer processing, delayed/retryable jobs with configurable backoff.- Guarantees: Exactly‑once delivery semantics from client perspective if you design idempotent handlers and use task leasing; configurable retry schedules; tasks are targeted to a single worker (no fan‑out).- When preferred: Use Cloud Tasks when you need strict control over retries, scheduling per task, ordered processing, and one‑time work dispatch to a specific endpoint.Cloud Scheduler- Purpose: Cron-like scheduling to trigger HTTP endpoints, Pub/Sub topics, or App Engine jobs on a time schedule.- Use cases: Periodic batch jobs, maintenance tasks, triggering daily reports or scheduled pipelines.- Guarantees: Executes scheduled triggers; retries configurable for transient failures but not intended as a durable queue.Example scenarios:- Pub/Sub over Cloud Tasks: A telemetry service publishing sensor events to multiple analytics, monitoring, and alerting consumers simultaneously — Pub/Sub supports high throughput, fan‑out, and independent subscribers.- Cloud Tasks over Pub/Sub: Processing user-initiated image conversions where each image must be processed exactly once with controlled rate to avoid overwhelming a downstream API — Cloud Tasks provides single-consumer dispatch, per‑task retries, and rate controls.Trade-off summary:- Use Pub/Sub for scalable, decoupled pub/sub patterns and fan‑out.- Use Cloud Tasks for targeted, reliable, rate‑controlled work dispatch.- Use Cloud Scheduler to trigger either Pub/Sub or Cloud Tasks on a schedule.
HardTechnical
77 practiced
A customer is considering Anthos to run GKE on-prem and on GCP. Describe the benefits, architectural trade-offs, and operational considerations (networking, policy, security, licensing) when recommending Anthos for a hybrid strategy.
Sample Answer
Requirements & constraints:- Run consistent GKE workloads both on Google Cloud and on-prem (VMware/Bare metal) with unified policy, security, and lifecycle.- Support lift-and-shift + cloud-native modernization, low-latency on-prem services, regulatory data residency, and hybrid networking.High-level recommendation:Anthos provides a consistent control plane (Anthos Config Management, Service Mesh, GKE control plane integrations) to operate GKE clusters on GCP and on-prem. It’s a good fit when you need consistent APIs, centralized policy, and multi-cluster app lifecycle across environments.Key benefits:- Consistency: same Kubernetes APIs, CI/CD patterns, and Config Management (GitOps) across clusters.- Centralized policy & governance: Anthos Config Management enforces YAML/OPA (Gatekeeper) policies across clusters.- Networking & service mesh: Anthos Service Mesh for telemetry, traffic management and mutual TLS across cloud and on-prem.- Observability & operations: Cloud Operations (Stackdriver) integration for centralized logging/metrics/tracing.- Hybrid features: Migrate workloads via Fleet, Multi-cluster Ingress, and binary authorization.Architectural trade-offs:- Control plane topology: Managed GKE on GCP vs. on-prem GKE (GKE On-Prem or GKE Edge) — you’ll trade some managed convenience for on-prem autonomy and hardware dependency.- Latency & data gravity: On-prem clusters reduce latency to local systems but complicate centralized control unless network is optimized.- Complexity: Anthos centralizes control but adds operator/stack learning curve (Config Sync, Mesh, Policy Controller).- Vendor coupling: Anthos brings deep Google integrations; portability is still Kubernetes-native but some features (Managed control plane, Cloud Operations) are Google-specific.Operational considerationsNetworking:- Secure VPN/Interconnect or Direct Peering for control-plane, API, and telemetry traffic. Plan for bandwidth and egress costs.- Hybrid ingress: use Multi-Cluster Ingress with global LB on GCP and local LBs on-prem; design DNS and health checks accordingly.- CNI choice: on-prem networking constraints may require Calico/Flannel; ensure compatibility with Anthos Service Mesh (requires iptables rules, MTU tuning).- IP addressing: plan pod/service CIDR non-overlap across sites and route propagation between networks.Policy & config:- Use Anthos Config Management (GitOps) to push declarative configs and Gatekeeper for OPA policies. Organize repos per environment/team with hierarchical policies.- Define RBAC and namespace isolation patterns; automate policy promotion from dev→staging→prod.Security:- Identity: integrate with Google Cloud IAM + on-prem AD/LDAP; use Workload Identity or Service Accounts where supported.- Secrets: use Secret Manager (cloud) and connect to on-prem via connectors or external secret controllers; avoid storing secrets in Git.- Network security: mTLS via Anthos Service Mesh, network policies to restrict east-west traffic, and per-cluster firewall rules.- Compliance: enable audit logs centrally; ensure data residency and encryption-at-rest requirements met on-prem (HSM if needed).Licensing & cost:- Anthos is a paid subscription (per-vCPU model); budget for license, on-prem infra, connectivity, and egress costs. Managed GKE nodes incur GCP charges; on-prem clusters keep hardware and local ops costs.- Calculate TCO: compare operational savings from centralized management vs. license and connectivity expenses.Operational readiness:- Staff skill uplift: Kubernetes, GitOps, Istio/Service Mesh, and Anthos-specific ops.- Automation: CI/CD pipelines integrate with Config Sync; use infrastructure-as-code for network and infra provisioning.- Backup & DR: plan cluster backups, Velero for workloads, and disaster recovery for control-plane components.- Support model: define Google Anthos support plus internal runbook/incident process.When to recommend Anthos:- Recommend when the customer prioritizes unified operations, centralized policy across hybrid footprint, and is willing to accept licensing costs and some Google-specific integrations.- If customer wants zero vendor lock-in and minimal platform fees, consider upstream Kubernetes + open-source GitOps + cross-cloud tooling instead.Summary:Anthos offers strong hybrid consistency, policy, and service-mesh capabilities that shorten operational differences between cloud and on-prem. Balance those benefits against licensing, network design, on-prem operational effort, and partial vendor coupling. Provide a pilot: one application, proof-of-concept hybrid networking, config sync pipeline, and cost projection before broader rollout.
EasyTechnical
86 practiced
Compare GCP compute options: Compute Engine, GKE, App Engine (standard and flexible), Cloud Run, and Cloud Functions. For each service explain typical use cases, operational responsibilities, scaling characteristics, and trade-offs a customer should consider when choosing one for a web application backend.
Sample Answer
Compute Engine (VMs)- Typical use: Lift-and-shift, stateful services, custom OS/kernel needs, specialized hardware (GPUs).- Ops: You manage OS, patching, scaling, load balancers, and instance templates; use Managed Instance Groups for autoscaling.- Scaling: Vertical (resize) or horizontal via MIG autoscaler.- Trade-offs: Maximum control and flexibility but highest operational burden and slower developer velocity.GKE (Kubernetes)- Typical use: Microservices, complex deployments, multi-container apps, CI/CD, service mesh.- Ops: You manage cluster config, node pools (or use Autopilot), networking, and deployments; more platform complexity.- Scaling: Pod autoscaling (HPA/VPA), cluster autoscaler; fine-grained scaling policies.- Trade-offs: Powerful and portable but requires Kubernetes expertise; operational complexity vs. flexibility.App Engine Standard & Flexible- Typical use: Rapid web apps/APIs with minimal infra work.- Ops: Standard abstracts runtime and autoscaling; Flexible runs in containers on VMs (more control). Google handles many platform concerns.- Scaling: Standard fast scale-to-zero and instant instances; Flexible scales with VMs (warm-up).- Trade-offs: Standard has runtime restrictions but low ops; Flexible allows custom runtimes at cost of slower scaling and more resource use.Cloud Run- Typical use: Containerized stateless services, APIs, event-driven backends.- Ops: Fully managed; you provide container image. No infra ops; optional VPC connectors.- Scaling: Fast autoscale to zero and high concurrency per instance configurable.- Trade-offs: Best for stateless, request-driven loads; limited access to local state and longer-running background jobs need workarounds.Cloud Functions- Typical use: Lightweight event-driven functions, webhooks, simple APIs.- Ops: Fully managed, focus only on code and triggers.- Scaling: Scales automatically per event; scales to zero.- Trade-offs: Highest developer velocity for small tasks but limited runtime duration, language/runtime constraints, and harder to manage complex apps.Decision guidance: prefer Cloud Run/App Engine for stateless web backends needing quick delivery; use GKE for complex microservices needing portability/advanced networking; Compute Engine when full OS control or special hardware is required; use Functions for small event-driven pieces. Consider operational staff, latency & cold-start sensitivity, vendor lock-in, scaling profile, and cost model when choosing.
MediumTechnical
86 practiced
For a media processing pipeline that ingests high-resolution video, compare Cloud Storage, Filestore, and Persistent Disks as storage backends. Discuss throughput, POSIX compatibility, cost, and integration with GKE-based transcoders to determine the most suitable approach.
Sample Answer
Requirements & constraints:- High-resolution video ingestion (large files, sustained read throughput for transcoding)- GKE-based transcoders (containers), likely autoscaling, multiple pods may need concurrent access- Need POSIX semantics? (e.g., POSIX file locks / rename semantics for pipelines)- Cost sensitive vs performance-sensitive trade-offsComparison:1) Cloud Storage (object storage)- Throughput: High aggregate throughput; parallel composite reads/downloads; per-connection latency higher than block; good for streaming large files when clients download chunks (range requests).- POSIX: Not POSIX — eventual consistency for some operations; no native POSIX locks/rename semantics; SDKs and GCS Fuse add overhead.- Cost: Low storage cost, low/no per-GB IOPS; egress and operation costs for many small operations.- GKE integration: Native (gcsfuse) or client libraries. Best for ingest, long-term archive, and as source for transcoding when pods stream chunks. Works well when jobs are independent per file.2) Filestore (managed NFS)- Throughput: Good for many concurrency patterns; throughput scales by tier (Basic HDD/SSD, High scale). Good for POSIX workloads and many pods mounting same volume.- POSIX: Fully POSIX-compliant (locks, renames).- Cost: Higher cost per GB and higher per-throughput price; billed per provisioned capacity and throughput in higher tiers.- GKE integration: Pods mount via NFS (CSI). Ideal when multiple transcoders need shared access to same filesystem (intermediate files, manifests).3) Persistent Disk (PD) — zonal block storage (or regional)- Throughput: High per-disk IOPS and throughput; can attach to single node (ReadWriteOnce) or use multi-writer PD (ReadWriteMany via regional PD with limitations) or use PD with clustered filesystems. For high throughput, use SSD PD and striping (RAID) across multiple PDs on a node.- POSIX: Block device -> format with ext4/xfs; full POSIX semantics.- Cost: Mid-range; pay for provisioned size and IO characteristics; efficient for single-node heavy I/O.- GKE integration: Best when a pod runs on a node with attached PD. Not suited for many pods across nodes needing same writable filesystem.Recommendation (most suitable):- For scalable, cost-effective pipeline where each transcoder pod processes whole files independently: store source & output in Cloud Storage; transcoders stream from GCS (range reads) and write outputs back to GCS. Use local ephemeral SSD on pods (emptyDir with local ssd or PD attached to node) for high-throughput temporary storage during transcoding to avoid network overhead. This minimizes cost and simplifies scaling.- If multiple pods must concurrently read/write the same files with POSIX semantics (e.g., shared intermediate state, locking): use Filestore (choose high-scale tier) despite higher cost.- If a single-node transcoder needs maximum local throughput and low-latency POSIX access, attach SSD Persistent Disk (striped) to that node/pod.Additional considerations:- Use multipart uploads, parallel chunking, and transfer agents for GCS to optimize throughput.- Monitor network egress and choose regional buckets close to GKE cluster to reduce latency.- Consider lifecycle policies: archive originals to Cloud Storage Nearline/Coldline after processing.- Security: IAM for GCS, IAM + VPC peering for Filestore, and node IAM for PD.
Unlock Full Question Bank
Get access to hundreds of GCP Core Services and Architecture Basics interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.