Comprehensive understanding of cloud computing platforms and core infrastructure concepts. Candidates should know service models including Infrastructure as a Service, Platform as a Service, and Software as a Service, and be familiar with major providers such as Amazon Web Services, Google Cloud Platform, and Microsoft Azure. Core technical knowledge includes compute models, storage systems, networking fundamentals such as domain name system and load balancing, virtual private networks and network segmentation, virtualization, containerization for example Docker, orchestration with Kubernetes, serverless architectures, and microservices. Candidates should be able to evaluate trade offs between managed services and self managed solutions with respect to cost, reliability, operational burden, scalability, performance, security, and vendor lock in, and reason about when to choose platform managed services versus building custom infrastructure. The topic also covers system design considerations for high availability and fault tolerance, capacity planning and autoscaling, monitoring and observability, deployment strategies, and operational practices such as infrastructure as code and continuous integration and continuous delivery. This knowledge is critical for backend engineers, site reliability engineers, and DevOps roles and is increasingly relevant across many engineering positions.
MediumTechnical
43 practiced
You must recommend a database strategy: managed relational service (RDS Cloud offering) versus self-managed PostgreSQL on VMs. Evaluate the trade-offs across cost, reliability, operational burden, performance tuning, backup/recovery, and vendor lock-in for a customer expecting 1000 writes/sec.
Sample Answer
Clarifying constraints: 1000 writes/sec sustained, expected data size growth (GB → TB), RTO/RPO targets, peak concurrency, read/write ratio, budget sensitivity, compliance needs. Recommendation below compares Managed RDS (e.g., Amazon RDS for PostgreSQL / Aurora) vs self-managed Postgres on VMs.High-level recommendation: choose a managed RDS offering (prefer Aurora or RDS with read replicas and provisioned IOPS) unless you have strict custom extension requirements or a very low-cost, mature SRE team. Managed accelerates time-to-market, lowers operational burden, and can meet 1k writes/sec with right configuration.Trade-offs- Cost - Managed: higher unit cost (instance + managed fees) but less headcount/OPEX. Easier to justify for business velocity. - Self-managed: potentially lower infra cost but higher SRE staffing and tooling expenses long-term.- Reliability / HA - Managed: automated multi-AZ failover, automated minor upgrades, SLA-backed. - Self-managed: flexible HA topologies (Patroni, repmgr) but requires team expertise and runbooks; higher risk if not practiced.- Operational burden - Managed: backups, patching, failover handled; less day-to-day ops. - Self-managed: full lifecycle ownership—monitoring, backups, OS/PG tuning, security hardening.- Performance tuning - Managed: limited kernel/IO tunables; good for standard workloads; Aurora offers better write scaling via distributed storage. - Self-managed: full control (custom extensions, shared_buffers, kernel params) to squeeze latency and throughput; necessary for unusual workloads.- Backup & recovery - Managed: automated snapshots, point-in-time recovery, snapshot export. - Self-managed: flexible but you must implement consistent backups (pg_basebackup, WAL archiving) and test restores.- Vendor lock-in - Managed: some lock-in (proprietary features, snapshot formats); cross-cloud migration effort. - Self-managed: higher portability; easier to move between clouds/on-prem.Sizing and configuration notes for 1k writes/sec- Start with high-IO instances (nvme/EBS-optimized), provisioned IOPS or Aurora provisioned capacity.- Use connection pooling (pgbouncer), batching, partitioning, and async writes where possible.- Consider write scaling: sharding or logical partitioning if single-node limits reached.- Monitor and test with realistic workload (pgbench) and failover drills.Decision criteria- Choose Managed RDS/Aurora if you want faster delivery, lower ops risk, SLA-backed HA, and the team size is limited.- Choose Self-managed if you require custom extensions, absolute cost minimization with a strong SRE org, or full control over tuning and recovery.Final: for most customers with 1000 writes/sec and typical constraints, managed RDS/Aurora provides the best balance of reliability, lower operational burden, and predictable scaling—opt for managed and plan architectural mitigations (connection pooling, partitioning, appropriate instance class) to meet write throughput.
HardSystem Design
45 practiced
Design a disaster recovery (DR) plan for an application with terabytes of data that must have an RTO of under 30 minutes and RPO of under 5 minutes. Describe replication strategy, backup/restore approach, automated failover testing, and the cost implications of your choices.
Sample Answer
Requirements & constraints:- RTO < 30 minutes, RPO < 5 minutes, terabytes of data, probable transactional workloads and large objects. Cross-region DR desirable.High-level approach:- Active-passive multi-region architecture with near-synchronous replication for critical data and async for bulk/archive. Use automated failover orchestration and frequent immutable backups.Replication strategy:- For transactional DBs: use synchronous replication within primary region (multi-AZ) and semi-synchronous cross-region replication with apply lag <5 min. Implement Change Data Capture (CDC) stream (e.g., Debezium / cloud DB replication) to stream binlogs into the DR region; apply via consumer with ordering guarantees.- For object storage (blobs): replicate via incremental cross-region replication (e.g., S3 Replication) with multi-part uploads and metadata replication. Use versioning and object lifecycle.- For caches & ephemeral state: rebuild on failover; keep cache warming scripts.Backup & restore:- Continuous incremental backups via WAL shipping + periodic consistent snapshots (crash-consistent and application-consistent). Snapshot cadence: full daily, incremental every 5 minutes (WAL segments or change-sets) to meet RPO.- Store backups in immutable, geo-redundant storage with retention policy and periodic test restores.- Restore plan: automated orchestration (IaC templates + orchestration scripts) to spin up compute, attach latest snapshot + replay WAL to target point-in-time within 5 minutes, run health checks, switch DNS/load balancer.Automated failover testing:- Scheduled automated DR drills using blue/green switch in sandbox DR account. Steps automated: 1. Provision DR stack from IaC 2. Promote replica as primary (apply final WAL) 3. Run smoke tests and data integrity checks 4. Run traffic cutover simulation and measure RTO- Integrate with CI/CD to run quarterly and after major changes. Use chaos testing to simulate network partition and region failure. Maintain runbooks and automated rollback paths.Operational concerns & monitoring:- End-to-end monitoring of replication lag, WAL backlog, snapshot success, and orchestration metrics. Alert thresholds (e.g., replication lag >1 min). Regular audits.Cost implications (trade-offs):- Cross-region semi-sync replication + frequent WAL shipping increases network egress and storage costs. Synchronous cross-region would minimize RPO but at high latency and cost; semi-sync chosen to balance RTO/RPO and performance.- Frequent incremental backups and retention increases storage cost; mitigate by compressing deltas and tiering older backups to colder storage.- DR standby resources: hot standby (pre-warmed instances) reduces RTO substantially but costs more; warm standby (replicas idle but not full compute) reduces cost but increases RTO. To meet <30 min, use warm standby with pre-provisioned IaC to scale CPU quickly, or a small hot control plane plus warm data nodes.- Automated testing incurs test environment costs but prevents latent failures; include in budget.- Estimate: expect additional 20–50% of prod compute+storage as baseline for warm DR, plus network egress and snapshot storage. Provide client optional tiers: Full hot-active multi-region (higher cost, lowest RTO/RPO) vs warm standby (balanced).Trade-offs & justification:- Achieves RPO <5 min via CDC/WAL shipping; RTO <30 min via warm standby + orchestration. Cost tuned by mixing warm/hot resources and snapshot frequency. Prioritize business-critical datasets for stricter replication; archive less-critical data with longer RPO to save cost.
HardTechnical
30 practiced
A client has unpredictable, highly spiky traffic with short bursts. Compare serverless (FaaS), containers with autoscaling, and pre-warmed VM pools. Analyze cost, cold-start latency, control, and operational complexity and recommend an architecture.
Sample Answer
Requirements & constraints (clarify):- Highly spiky, unpredictable short bursts (seconds–minutes).- Cost-sensitive but must meet tight latency SLAs (cold-starts unacceptable above X ms).- Dev teams prefer standard runtimes; ops team size limited.Comparison (serverless FaaS, containers with autoscaling, pre-warmed VM pools)1) Serverless (FaaS)- Cost: Excellent for sporadic traffic — pay-per-invocation reduces idle costs.- Cold-start latency: Can be problematic for heavy runtimes or VPC-attached functions; mitigations (provisioned concurrency) raise cost.- Control: Limited OS/network control, limited custom runtimes, constrained execution time.- Operational complexity: Low — provider handles scaling, patching, and infra.- Fit: Best if short-lived stateless functions, tolerant of occasional cold starts or willing to pay for provisioned concurrency.2) Containers with autoscaling (Kubernetes/ECS + HPA/Cluster Autoscaler)- Cost: Moderate — faster start than VMs, but baseline cluster headroom or rapid node scaling costs exist.- Cold-start latency: Better than VMs; container cold starts typically seconds. With image caching and lightweight images, latency can be sub-second.- Control: High — full runtime, custom libraries, tuned networking.- Operational complexity: Higher — manage cluster, autoscaler tuning, node provisioning, and metrics-driven scaling.- Fit: Good when you need control, stateful sidecars, or complex runtimes and can tolerate second-level start times.3) Pre-warmed VM pools (always-on instances or warm pools)- Cost: Highest idle cost (reserved/spot can reduce but adds complexity).- Cold-start latency: Lowest — near-zero for warm pools; ideal for strict latency SLAs.- Control: Maximum — full OS, custom NIC, GPU, specialized drivers.- Operational complexity: Medium — simpler than cluster ops but needs pool management, lifecycle automation, and scaling policies.- Fit: Best when latency is critical and cost is secondary.Recommendation (hybrid, role-appropriate)- Use a hybrid architecture: - Primary: Container-based services on managed Kubernetes/ECS with aggressive autoscaling and small (fast-start) images, image pre-pulling, and node-provisioning optimizations to handle most bursts with acceptable latency and good cost/control balance. - Supplement: Serverless functions for intermittent, highly parallelizable tasks (e.g., lightweight event handlers) to avoid overprovisioning. - Critical low-latency path: Maintain a small pre-warmed VM/pool (or provisioned concurrency for FaaS) for the hottest, latency-sensitive endpoints.- Operational plan: Implement predictive autoscaling (metrics + short-term forecasting), fast image registries in same region, warm-up probes, and cost monitoring/alerting.- Trade-offs: Hybrid increases operational complexity but optimizes cost vs latency vs control. Recommend PoC to validate cold-start times and cost models with real traffic for 4–8 weeks, then iterate.
MediumSystem Design
32 practiced
Design a secure VPC architecture in the cloud for a multi-tenant web application that hosts public APIs, an admin console, and a private database. Include subnets, NAT or egress strategy, bastion/management access, and how you would isolate tenants at network and application layers.
Sample Answer
Requirements & constraints (clarify first): multi-AZ HA, public APIs, admin console (restricted), private DB, tenant isolation, auditability, least privilege, scale and cost trade-offs.High-level architecture (multi-AZ):- One or more VPCs split across 3 AZs for HA.- Subnets per AZ: - Public subnets: API/ALB, NAT Gateway (one per AZ). - Private app subnets: application servers / containers (no direct inbound). - Private management subnet (restricted): bastion / jump, centralized ops tools. - DB subnets (private, isolated): RDS/Aurora in multi-AZ private DB subnets (no IGW).ASCII flow: Internet → ALB (public subnet) → App services (private app subnets) → DB (private DB subnets)Network controls:- Internet Gateway (IGW) on VPC for public subnets.- NAT Gateway(s) in public subnets for outbound egress from private subnets (one per AZ for resilience). Alternatively use centralized NAT + egress VPC if many VPCs.- Route tables: public subnets route 0.0.0.0/0 → IGW; private subnets route 0.0.0.0/0 → NAT Gateway in same AZ.- Security groups (stateful) per layer: ALB SG allows 443 from 0.0.0.0/0; app SG allows only ALB SG; DB SG allows only app SG (and admin SG).- NACLs as defense-in-depth (deny wide ranges) but keep permissive rules to avoid complexity.- Flow logs + VPC endpoints for S3/Secrets Manager to avoid internet egress for credentials/logging.Bastion / management:- Prefer Session Manager (SSM) to avoid open bastion SGs. If bastion required: place in management private subnet with tightly scoped inbound (IP allowlist + MFA) and no persistent SSH keys; require jump via SSO and MFA; use short-lived certificates/SSH sessions; log all sessions to CloudTrail/CloudWatch.- Admin console: host behind a separate ALB with WAF + client certs or IP allowlist and IAM auth (OIDC) for stronger control.Egress strategy:- NAT Gateways per AZ for scalability/fault-tolerance.- Centralized egress inspection: optionally route outbound through an egress VPC with firewall/IDS (Transit Gateway) for deep inspection and DLP.- Use proxy with authentication for outbound artifacts and patching.Tenant isolation (network + app):- Network-level isolation options (choose based on tenants' risk/compliance): 1. Shared VPC (cost-efficient): single set of app services but strict multi-tenant metadata controls. Use Security Groups per service only (not per tenant). Enforce tenant isolation at application layer. 2. VPC-per-tenant (strong isolation): create a VPC per high-risk tenant and connect via Transit Gateway, or use separate accounts in org for strict isolation. Best for PCI/regulated tenants. 3. Hybrid: shared VPC for low-risk tenants, dedicated VPC/accounts for high-risk tenants.- Application-layer isolation (required even in shared VPC): - Authentication & Authorization: OAuth2/OIDC, tenant-scoped tokens and RBAC. - Multi-tenant data separation strategies: - Separate DB instances per tenant (strongest), or - Shared DB with separate schemas per tenant, or - Shared schema with tenant_id column and row-level security (RLS) enforced by DB (Postgres RLS) — good balance of cost & security. - Enforce tenant-aware service mesh or middleware that injects tenant context, validates ownership on every request. - Per-tenant rate limiting, quotas, and WAF rules.Operational & security controls:- WAF in front of ALBs for OWASP protections, API Gateway for public APIs with throttling and IAM or Lambda authorizers.- TLS everywhere (ALB terminates with strong ciphers; upstream mututal TLS if needed).- Secrets: use Secrets Manager / KMS for encryption keys; DB encryption at rest.- Centralized logging/monitoring: VPC Flow Logs, ALB logs to S3, app logs to central logging (ELK/CloudWatch), SIEM, GuardDuty, Security Hub.- CI/CD with infra-as-code; automated security scans; vulnerability scanning for container images.- Audit & compliance: CloudTrail enabled across accounts; immutable logs; alerting on abnormal patterns.Trade-offs:- VPC-per-tenant increases ops cost & complexity but gives strong network isolation.- Shared infra with app-level separation reduces cost but demands rigorous application enforcement, RLS, and more testing.Why this design:- Defense-in-depth: network controls, WAF, auth, DB-level RLS/instance separation.- Resilient: AZs, NAT per AZ, managed services for HA.- Flexible: supports low-cost shared model and high-assurance per-tenant VPCs via Transit Gateway/account isolation.This architecture meets availability and security goals while offering clear paths to scale and stricter isolation for regulated tenants.
HardTechnical
22 practiced
You need to migrate terabytes of nightly batch data to a managed cloud data warehouse without impacting query SLAs. Describe a migration plan including data ingestion patterns, schema evolution, ETL orchestration, throttling, verification, and rollback paths.
Sample Answer
Requirements & constraints:- Migrate terabytes/nightly into a managed cloud DW (e.g., Snowflake/BigQuery/Redshift Serverless) without impacting existing query SLAs; zero/near-zero data loss; ability to rollback; support schema evolution; predictable throughput.High-level plan (phased, safe migration):1. Pilot & dual-write- Start with a small subset (1–5% of data, non-critical partitions). Implement dual-write or CDC so source writes both current DW and new cloud DW. Validate ingestion, latency, and query behavior without affecting production.2. Ingestion patterns- Use partitioned, incremental bulk loads per source file/partition using cloud-native bulk loaders (COPY/LOAD) for throughput.- For change-data: use CDC streams (Debezium / cloud replication) into message bus (Kafka / PubSub) then micro-batches to DW for transactional freshness.- Use staging area on object storage (S3/GCS) with manifest files for idempotent loads.3. Schema evolution- Use versioned schemas and column-additive changes. Abstract queries via views/materialized views to hide schema shifts.- Maintain a schema registry; implement nullable new columns, backfill via asynchronous jobs, and use compatibility checks before promoting schema.4. ETL orchestration- Orchestrate with workflow engine (Airflow/Cloud Composer/Dataflow) running DAGs: extract → transform (in staged compute or pushdown SQL) → load.- Break ETL into small tasks per partition/time window to allow parallelism and controlled retry.- Implement unit & integration tests in CI for transformations.5. Throttling & resource control- Rate-limit ingestion by controlling concurrency, batch size, and using DW resource monitors/quotas.- Monitor query latency SLA; dynamically reduce load concurrency when SLA breaches using circuit-breaker pattern.- Use workload isolation: separate warehouses/slots for ingestion vs BI queries; autoscale ingestion cluster but cap resource assignment to not starve queries.6. Verification & validation- Row-level reconciliation using checksums/row counts per partition (pre/post-load).- Hash-based data validation and sample query comparisons between source and target.- Latency and SLA dashboards (Prometheus/GCP/CloudWatch + alerts). Run canbooked compare jobs and data quality checks pre-release.7. Cutover & rollback paths- Gradual traffic shift: after confidence, switch read-only queries to cloud DW for non-critical workloads, then to critical ones.- Maintain dual-write for a soak period. If anomalies, rollback by: - Repointing read traffic to original DW (DNS/connection string toggle). - For writes, resume single-write to source DW; replay or backfill later from staging logs.- Keep immutable load manifests and CDC offsets to resume/backfill deterministically.Trade-offs & risks- Dual-write complexity vs zero-downtime: choose CDC + replay if dual-write infeasible.- Backfill cost and time: mitigate via parallel backfill and prioritizing hot partitions.Success criteria & metrics- Query SLA maintained (p95 latency within target)- Data completeness (>99.99% rows), consistency checks pass- Controlled ingestion throughput (MB/s) with automated throttling- Clean rollback within defined RTO (e.g., <15 minutes for read traffic)This phased, observable approach ensures throughput, schema stability, orchestration reliability, and safe rollback while protecting query SLAs.
Unlock Full Question Bank
Get access to hundreds of Cloud Platforms and Infrastructure interview questions and detailed answers.
