Cloud Platform Experience Questions

Personal account of hands on experience using public cloud providers and the concrete results delivered. Candidates should describe specific services and patterns they used for compute, storage, networking, managed databases, serverless and eventing, and explain their role in architecture decisions, deployments, automation and infrastructure as code practices, continuous integration and continuous delivery pipelines, container orchestration, scaling and performance tuning, monitoring and incident response, and cost management. Interviewees should quantify outcomes when possible with metrics such as latency reduction, cost savings, availability improvements or deployment frequency and note any formal training or certifications. This topic evaluates depth of practical experience, ownership, and the ability to operate and improve cloud systems in production.

EasyBehavioral

38 practiced

Describe a runbook you authored for a frequent high-severity incident. Include the initial detection criteria, step-by-step remediation commands or actions, safety checks, expected outputs, escalation points, and how you validated the runbook under real incident conditions.

Sample Answer

Situation: Our payment processing service would intermittently report "payment timeout" errors during peak load, causing high-severity alerts and customer impact ~2×/month.

Task: I authored a runbook for the “Payment Gateway Latency Spike” incident so first responders could detect, mitigate, and escalate reliably.

Action:- Detection criteria (what triggers runbook): - PagerDuty alert: payment_error_rate > 1% for 5m AND p99_latency > 2s for 3m - Grafana dashboard: sustained rise in queue depth- First triage (commands & expected outputs): - Check service health and pods:

bash

kubectl get pods -n payments -l app=payment-gateway
kubectl logs -n payments <pod> --since=10m | grep -i timeout

- Expected: healthy pods, few timeout traces. If error traces high, continue.- Quick mitigation steps: - Scale replicas (safety-checked):

bash

kubectl scale deployment payment-gateway --replicas=6 -n payments

- Verify: `kubectl get hpa -n payments` shows CPU/RPS stable; p99 should drop within 2–5m. - If DB connection pool exhausted: toggle read-only cache:

bash

curl -X POST https://config-service/feature-toggle -d '{"key":"payment_cache_read_only","value":true}'

- Safety checks: confirm deploy permissions, rate-limit toggles, and run mitigation in staging prior if unsure.- Rollback/Stop criteria: if errors increase after scaling or toggles, revert changes immediately and note in incident.- Escalation points: - After 10 minutes with no improvement: notify on-call SRE lead and DB engineer; after 30 minutes, page engineering manager and product owner.- Post-incident: - Capture diagnostics: heap dumps, flamegraphs, and increase retention for traces. - Runbook validation: I ran yearly fire-drill during on-call rotation—simulated load using k6 against a staging copy, triggered alerts, executed the runbook steps end-to-end, measured p99 improvements, and updated commands/thresholds based on lessons learned.

Result: Runbook reduced mean time to mitigation from ~28 to ~9 minutes and became standard for the team’s incident playbooks. Learned to include exact command examples, permission notes, and escalation timing.

MediumTechnical

31 practiced

Outline a step-by-step migration plan to move a stateful transactional service from on-premise VMs to a managed cloud platform with minimal downtime. Include data replication strategy, schema changes, version compatibility, cutover plan, fallbacks, testing strategy, and the people and communication steps required during cutover.

Sample Answer

Goal: Move a stateful transactional service from on-prem VMs to managed cloud with minimal downtime and safe rollback.

1. Clarify constraints & success criteria- RPO ≤ X minutes, RTO ≤ Y minutes, throughput targets, regulatory constraints, maintenance window windows.

2. Preparation & architecture- Choose managed services (DB as managed, load balancer, autoscaling, VPC peering/IPSEC for hybrid during cutover).- Design network, security, IAM, monitoring, and backups.

3. Data replication strategy- Use continuous logical replication (e.g., CDC via Debezium, native replica) from on‑prem primary to managed read replica.- Ensure transactional ordering and non-lossy delivery; monitor lag.- Initial full snapshot (consistent backup/restore) then start CDC.

4. Schema & version compatibility- Implement backward/forward compatible schema changes (expand-only, nullable columns, dual-write tolerant).- Deploy version compatibility matrix; release application versions that can read old and new schemas.- Use feature flags and migration table version column if needed.

5. Staged rollout & testing- Deploy cloud service in parallel in read-only mode; run synthetic and shadow traffic (traffic mirroring) to validate behavior.- Perform end-to-end functional, performance, and failover tests against replica.- Validate monitoring, SLOs, and alerting.

6. Cutover plan (minimal downtime)- Quiesce writes briefly: switch application to maintenance mode or route writes to a single master (short window).- Promote managed replica to primary (or enable write routing to cloud DB).- Run final WAL sync; pause writes, ensure zero lag, promote, redirect application traffic via DNS/load balancer shift or LB weight ramp.- Resume writes; monitor closely for errors and performance.

7. Fallbacks & rollback- Pre-script automated rollback: demote cloud master, re-enable on‑prem primary, revert routing.- Keep transaction sequence numbers/checkpoints to avoid splits.- Plan for partial rollback (application only) vs full DB rollback; prefer returning to on-prem if issues.

8. People & communication- Pre-cutover runbook distributed to SREs, DBAs, App owners, Network, Security, and on-call.- Assign roles: Runbook owner, DB promoter, Network switcher, Observability lead, App owner.- Establish communication channels: dedicated conference bridge, Slack channel, status board.- Schedule blackout window with stakeholders and escalation path.

9. Post-cutover validation & hardening- Verify consistency checks, reconcileledgers, run business smoke tests, traffic ramp, monitor errors and latencies for N hours.- Remove replication and hybrid networking when stable.- Archive rollback artifacts, perform post-mortem, update runbooks.

Key risk mitigations: CDC with verified low lag; schema compatibility practices; automated, tested rollback; clear people roles and communication; thorough pre-cutover testing including shadow traffic.

EasyTechnical

38 practiced

Describe the managed database services you have operated in the cloud such as RDS, Cloud SQL, DynamoDB, or Spanner. For each, explain tradeoffs you considered around availability modes, read replicas, scaling approaches, consistency, operational overhead, and common failure modes. Give one example where your database choice materially affected reliability or cost.

Sample Answer

I’ve operated AWS RDS (MySQL/Postgres), GCP Cloud SQL, DynamoDB, and Spanner. For each I weighed availability, scaling, consistency, ops overhead, and failure modes.

RDS (MySQL/Postgres)- Availability modes: single-AZ vs multi-AZ (synchronous primary-standby). Multi-AZ gives automated failover but doubles cost and has failover lag.- Read replicas: async replicas for read scaling; risk of replication lag and stale reads.- Scaling: vertical for instance size; read scaling via replicas; vertical scaling causes downtime unless using read-replica swap.- Consistency: strong on primary, eventual on replicas.- Ops: moderate—patching, backups, parameter tuning still needed.- Failures: storage I/O saturation, long-running queries, replication lag, failover storms.

Cloud SQL- Similar to RDS with managed backups/patching and cross-region replicas. Trade-offs align with RDS; GCP-specific advantages in integration with IAM and Stackdriver.

DynamoDB- Availability modes: fully managed, multi-AZ by default.- Read replicas: global tables for multi-region replication (eventual).- Scaling: horizontal via provisioned or on-demand capacity; auto-scaling minimizes ops but requires good capacity policies.- Consistency: eventually consistent by default; strongly consistent reads possible per-region with higher latency/cost.- Ops: low—no servers, backups automated.- Failures: hot-partition throttling, underestimated capacity causing 5xxs, GC-like hiccups with large item sizes.

Spanner- Availability: designed for global strong consistency and high availability via Paxos/TrueTime.- Read replicas: configurable; reads can be served with strong or stale reads.- Scaling: horizontal with shards; transparent rebalancing but higher cost.- Consistency: strong across regions — best for cross-region transactional consistency.- Ops: minimal but cost and schema design (primary keys, interleaving) matter.- Failures: regional network partitions increase latency; mis-sharding or hotspots impact performance.

Example impactAt a payments service, we initially chose RDS Multi-AZ Postgres with async read replicas. During a seasonal traffic spike, replication lag caused stale balances shown to users and an incident. Switching critical balance reads to the primary (and later migrating high-read, low-consistency paths to DynamoDB for caching) reduced incidents. That change increased RPS on the primary (requiring a larger instance) but eliminated customer-facing inconsistency; overall cost rose 15% but reduced outage/incident costs and improved SLOs materially.

EasyBehavioral

43 practiced

Which cloud certifications or formal trainings do you hold such as AWS/GCP/Azure certifications, Kubernetes CKA, or Terraform Associate, and how have they concretely improved your day-to-day SRE work? Provide examples tied to incidents, automation, or architecture decisions.

EasyBehavioral

42 practiced

Walk me through a concrete cloud project you personally led or contributed to. Specify the cloud provider, the key services you used for compute, storage, networking, managed databases, and serverless or eventing components. Describe your role, the architecture decisions you influenced, and one measurable outcome such as latency reduction, cost savings, availability improvement, or increased deployment frequency. Include numbers and timeframes where possible.

Unlock Full Question Bank

Get access to hundreds of Cloud Platform Experience interview questions and detailed answers.

Join thousands of developers preparing for their dream job.