Cloud Architecture and Design Patterns Questions

Designing and evaluating cloud native architectures and common architecture patterns, with attention to service capabilities, limits, and operational and security implications. Topics include compute scaling models for virtual instances, managed compute, serverless functions and container orchestration; storage choice, object storage classes, lifecycle policies and caching strategies; managed relational database architectures with high availability patterns such as multiple availability zone deployments and read replicas; trade offs of serverless approaches including cold start and invocation limits; different load balancing approaches for application level and network level traffic; networking and identity boundary design including virtual networks, subnetting, routing, security groups and access control patterns; backup, recovery and disaster recovery planning; deployment patterns such as blue green and canary releases; scalability strategies, performance and latency considerations; vendor lock in, portability and total cost of ownership trade offs; and operational practices for monitoring, limits management and incident response. Candidates should be able to translate requirements into architecture decisions, justify trade offs, and design for resilience, scalability, performance, security and cost.

HardTechnical

50 practiced

You are building a SaaS product that currently uses many managed PaaS features (proprietary DB, messaging, serverless). Design a strategy to reduce vendor lock-in while balancing engineering cost and portability. Include abstraction layers, adapter patterns, data export/import guarantees, IaC portability, testing migration paths, and how to prioritize which services to decouple first.

Sample Answer

**Clarify goals & constraints**Reduce lock-in while minimizing engineering cost and preserving SLA/feature parity. Target 1–3 year runway where switching is feasible, not instantaneous.

**High-level strategy**- Introduce thin abstraction layers for platform services (DB, messaging, compute) exposing only required semantics.- Implement Adapter pattern: concrete providers implement an interface (e.g., MessageQueue.publish, MessageQueue.subscribe) so business logic depends on interfaces, not providers.- Keep provider-specific code isolated in small, well-documented modules.

**Data guarantees**- Enforce strong export/import contracts: schema migration manifests, canonical data formats (JSON/Avro), and point-in-time snapshots.- Regular automated exports (daily incremental + weekly full) and verify restores in isolated envs.- Use CDC pipelines to replicate data into portable stores (e.g., standardized Postgres, S3) for emergency failover.

**IaC portability**- Author infrastructure as modular Terraform (or Pulumi) with provider-agnostic modules and provider-specific implementations behind the module boundary.- Keep state backend swappable; version modules and policy-check (Sentinel/OPA).

**Testing migration paths**- Maintain a “canary” alternate stack: periodic smoke migrations that switch a small percentage of traffic to an alternate provider.- Automated migration playbooks exercised in DR drills; CI runs provider-compatibility tests (contract tests, latency, error semantics).

**Prioritization**1. Critical stateful services (proprietary DB) — highest risk, prioritize CDC and exportability.2. Messaging & async systems — moderate risk; adapter patterns reduce coupling.3. Serverless/platform functions — lower risk if wrapped; prioritize where business logic lives.Prioritize by risk = business impact × technical effort.

**Trade-offs**- Abstractions cost initial work and may hide provider features; favor pragmatic abstractions that cover 80% use cases and allow opt-outs for advanced features.

This approach balances short-term delivery with a practical path to portability and measurable migration readiness.

EasyTechnical

57 practiced

Define Recovery Time Objective (RTO) and Recovery Point Objective (RPO). As a Cloud Architect, show how you would translate a business requirement such as 'restore service within 4 hours and lose no more than 30 minutes of data' into an architecture: list backup/replication approaches, approximate cost/complexity trade-offs, and the monitoring/verification you would put in place to ensure the objectives are met.

Sample Answer

**Definitions**RTO: Maximum acceptable time to restore service after an incident. RPO: Maximum acceptable age of data after recovery (how much data loss is tolerable).

**Translate requirement**"Restore service within 4 hours and lose no more than 30 minutes of data" ⇒ RTO = 4 hours, RPO = 30 minutes. I’d design for slightly better targets to account for failover time (e.g., RTO 3 hours, RPO 15–30 minutes).

**Backup / replication approaches (with cost/complexity)**- Synchronous replication (primary → secondary in same region): RPO ≈ 0, RTO minutes. High cost, high latency/complexity; good for critical DBs.- Asynchronous cross-region replication (DB native like AWS RDS read-replica promoted): RPO near seconds–minutes depending on lag, RTO tens of minutes–hours. Moderate cost.- Continuous replication / CDC to object store (Debezium → Kafka → S3): RPO ≤ 30 min, recovery requires replay; medium complexity, lower cost.- Frequent incremental backups (snapshots every 15 min for storage/VMs; or database transaction log backups every 5–15 min): Lower cost, RPO configurable; RTO depends on restore time (can approach hours).- Multi-AZ + multi-region active-passive with automated failover: Balanced cost, meets 4-hr RTO if automation is tested.

**Recommended architecture**- Critical databases: asynchronous cross-region replicas with transaction log shipping every 1–5 minutes; automated failover playbook to promote replica.- Application tier: stateless in autoscaling groups across two AZs/regions; artifacts in object storage and CI/CD to redeploy quickly.- File/state: replicate to object storage (versioning) and backup snapshots every 15 minutes.- Orchestrate runbooks in IaC and automation for failover steps to meet 4-hr RTO.

**Cost vs complexity summary**- Synchronous: highest cost/complexity, best RPO/RTO.- Asynchronous replication + automation: medium cost, meets targets.- Periodic snapshots: lowest cost, riskier for tight RPO/RTO.

**Monitoring & verification**- Continuous replication lag metrics (DB replica lag) with alerts if > 5 minutes.- Snapshot/backup success metrics and retention checks; alert on failures.- Synthetic transaction monitoring to detect service degradation and measure RTO in drills.- Disaster Recovery runbooks and quarterly failover rehearsals (game days) with postmortems.- SLIs/SLOs dashboard showing RPO/RTO adherence, automated runbook invocation on incident.

This design balances cost and complexity while providing measurable mechanisms to ensure the 4‑hour RTO and ≤30‑minute RPO are met.

MediumTechnical

52 practiced

Architect a cost-optimized container platform for large batch workloads that can use spot (preemptible) instances while meeting job completion SLAs. Address cluster and node-pool design, scheduler policies, checkpointing and job resume, handling preemptions, mixed-instance types, autoscaling, and cost monitoring/alerts.

Sample Answer

**Situation & goals**Design a cost-optimized Kubernetes-based batch platform that maximizes spot (preemptible) capacity while guaranteeing job-completion SLAs.

**Cluster & node-pool design**- Multi-cluster / multi-zone control plane for availability; dedicated batch cluster(s) separated from latency-sensitive workloads.- Node pools: several spot-heavy pools (different instance families and sizes) + small on-demand/capacity-reserve pool for high-priority recovery and critical control-plane tasks.- Use instance diversification: mix x86/ARM families and sizes to improve spot availability.

**Scheduler & policies**- Use Kubernetes with Karpenter/custom autoscaler or Volcano for batch scheduling.- PriorityClasses + PodDisruptionBudgets: high-priority jobs allowed to evict lower-priority ones.- Binpack/affinity rules to reduce fragmentation; tolerations for spot taints.

**Checkpointing & resume**- Implement application-level checkpoints to object store (S3/GCS) and containerized sidecar for incremental snapshots.- For stateful workloads, use CRIU where applicable; use durable intermediate storage (FSx/EFS) for fast restart.

**Handling preemptions**- Listen to cloud preemption/termination notices to trigger graceful checkpoint and reschedule.- Preemption handler/controller: cordon node, evict with gracefulPeriod, persist metadata to queue (e.g., Kafka/SQS) so job controller resubmits.

**Autoscaling**- Reactive + predictive autoscaling: scale up on pending pods and use historical/ML forecasts to pre-warm capacity ahead of known peaks.- Scale policy prefers spot pools; fall back to on-demand when SLA at risk (e.g., pending time > threshold or retry budget exhausted).

**Cost monitoring & alerts**- Tagging and per-pool cost export to billing system; dashboards for spot vs on-demand spend, eviction rate, and cost per completed job.- Alerts: high eviction rate, pending-job SLA breach, sudden spot price spikes; automated policy to switch workloads to safer pools.

**Trade-offs**- Heaviest savings require robust checkpointing and tolerance of retry churn; budget trade-off: reserve small on-demand capacity to guarantee SLAs.

HardSystem Design

45 practiced

Propose an architecture and migration plan to move a petabyte-scale on-prem data lake to cloud object storage (e.g., S3) while minimizing downtime and preserving metadata, access controls, and data lineage. Cover data transfer techniques, parallelization, integrity verification, catalog synchronization, handling ACLs/permissions, lifecycle policies, and how to preserve read availability during cutover.

Sample Answer

**Clarify goals & constraints**- Preserve metadata, ACLs, lineage; target S3-compatible buckets; ≤ brief downtime; 1 PB data; heterogeneous on‑prem sources (HDFS, NFS, DB exports).

**High-level architecture**- Source connectors → Staging (VM/EC2 fleet with high-bandwidth NICs) → S3 (multi‑prefix) + AWS Glue/Athena catalog → IAM/CloudTrail & Lake Formation for permissions + Glue Data Catalog for lineage.

**Phased migration plan**1. Inventory & mapping: capture file paths, checksums, owners, ACLs, timestamps, data classification, lineage entries (ETL jobs, tables).2. Pilot: migrate representative subset, validate workflows.3. Bulk copy (initial sync): use parallel multipart transfers with tools (DistCp for HDFS → s3a, AWS Snowball for seeding if network constrained, or S3 Transfer Acceleration + parallel rclone/s3transfer). Shard by directory prefix and timestamp to maximize parallelism.4. Continuous sync: run incremental change capture (inotify/DFS audit logs, CDC) to replicate diffs until cutover.5. Cutover: freeze writes briefly (or dual-write), final delta sync, update catalog pointers, swap read endpoints.6. Post-cutover validation & decommission.

**Parallelization & throughput**- Horizontal workers (autoscaling) each handle independent prefixes.- Use multipart uploads, client-side parallelism, TCP window tuning, jumbo frames on VPN/direct connect, and S3 Transfer Acceleration for WAN.

**Integrity verification**- Compute and compare checksums (MD5/ETag or SHA256) per object; store provenance in metadata store.- Use manifest files and reconcile counts/sizes.- Automated sampling + full reconcile for final delta.

**Catalog & lineage synchronization**- Export existing metadata; map to Glue/Athena schema; preserve timestamps, tags, and column-level lineage.- Rehydrate lineage into a graph DB or Glue Lineage API; update ETL jobs to point to new S3 locations; run automated schema checks.

**ACLs/Permissions**- Translate POSIX/HDFS ACLs into IAM policies, S3 object ACLs, and Lake Formation permissions.- Preserve owner/group as metadata tags; recreate granular access via Lake Formation/resource policies and IAM roles; validate with role-based tests.

**Lifecycle & cost controls**- Apply S3 lifecycle rules per data tier: infrequent/GLACIER transition based on retention tags captured during inventory.- Apply object tagging for governance, encryption (SSE-KMS), and legal hold.

**Minimizing downtime / preserving read availability**- Dual-read strategy: during migration, maintain reads from on‑prem; use a proxy/abstraction layer (virtual path via DNS/load‑balancer) that can route reads to either on‑prem or S3.- Implement dual-write or CDC so new writes go both places or to on‑prem with async replication.- During cutover, perform short freeze (minutes) for final delta; verify checksums and catalog updates; flip the read endpoint to S3.

**Validation & rollback**- Staged validations, automated test suites, sample queries, access audits.- Keep rollback plan: retain on‑prem for a retention window and ability to route reads back.

**Trade-offs**- Snowball reduces network risk but adds lead time; dual-write increases complexity but reduces downtime; Lake Formation centralizes permissions but requires mapping effort.

This plan balances speed, data integrity, and minimal downtime while preserving metadata, ACLs, and lineage.

EasyTechnical

60 practiced

Explain differences between Layer 7 (application) load balancers and Layer 4 (network) load balancers from a cloud architecture perspective. Cover TLS termination, path and host routing, connection management, latency/throughput trade-offs, health checks, and examples: when to use L7 for microservices and when to use L4 for high-throughput TCP workloads.

Unlock Full Question Bank

Get access to hundreds of Cloud Architecture and Design Patterns interview questions and detailed answers.

Join thousands of developers preparing for their dream job.