Cloud Architecture Fundamentals Questions

Fundamental concepts and design patterns for cloud based systems and services. Topics include core service categories such as compute, storage, networking and databases, virtual machines and containers, serverless computing, managed services, and infrastructure as code. Understand deployment and service models including infrastructure as a service, platform as a service, and software as a service. Evaluate architectural patterns including monolithic, microservices, and serverless approaches, and how they influence scalability, availability, reliability, performance, security, and cost. For more senior roles include distributed systems concepts, consistency and partitioning models, trade off analysis, fault isolation, observability and operational practices in cloud native design.

EasyTechnical

22 practiced

Compare vertical scaling (scale-up) and horizontal scaling (scale-out) in cloud environments. Explain typical services or features that enable each (give provider examples), discuss limits and cost implications, and provide one concrete scenario where horizontal scaling is clearly better than vertical scaling.

EasyTechnical

23 practiced

What is Infrastructure as Code (IaC)? Name two popular IaC tools, describe one key benefit and one risk when using IaC in production, and outline a simple workflow for version-controlling and safely applying IaC across development, staging, and production.

HardTechnical

26 practiced

In a microservices ecosystem where each service owns its datastore, describe patterns to implement transactions across services: two-phase commit (2PC), saga orchestration, and choreography. For each pattern analyze failure modes, consistency guarantees, operational complexity, and approaches to idempotency and compensation.

Sample Answer

**Overview (context as Cloud Engineer)** In cloud-native microservices each service owns its datastore; cross-service transactions require patterns that trade consistency, availability, and operational complexity. I'll describe 2PC, Saga Orchestration, and Saga Choreography with failure modes, guarantees, ops cost, idempotency and compensation.

**Two-Phase Commit (2PC)** - Description: Coordinator asks participants to PREPARE, then COMMIT/ROLLBACK. - Consistency: Strong (atomic across services) if all support XA/transactional commit. - Failure modes: Coordinator crash blocks participants in PREPARED state; network partitions cause long locks; resource deadlocks. - Operational complexity: High — requires DBs or middleware supporting distributed transactions, firewall/latency tuning, monitoring for blocked prepares. - Idempotency/Compensation: Less emphasis on compensations; must implement idempotent commit/rollback RPCs and recovery daemon to resolve uncertain transactions.

**Saga — Orchestration** - Description: Central orchestrator issues forward steps; on failure invokes compensating actions in reverse order. - Consistency: Eventually consistent; business-level atomicity via compensations. - Failure modes: Orchestrator crash (replay on restart), partial failures in compensation, long-running sagas leading to resource constraints. - Operational complexity: Medium — implement orchestration service, durable saga state (e.g., DynamoDB, Cloud SQL), retries, dead-letter handling. - Idempotency/Compensation: Every step and compensating action must be idempotent; use unique saga IDs, causal versioning, and at-least-once delivery with dedup tables.

**Saga — Choreography** - Description: Services publish events; subscribers react and emit subsequent events; compensations published on failure. - Consistency: Eventually consistent; higher coupling via event contracts. - Failure modes: Missing or out-of-order events, silent failures causing orphaned state, complex failure reasoning across many services. - Operational complexity: Higher operational visibility needs — event broker (Kafka/SNS+SQS), schema registry, observability, tracing. - Idempotency/Compensation: Strong requirement for idempotent consumers, deduplication using event IDs, compensating events must be causal and reversible; implement saga correlation IDs and TTLs.

**Practical cloud recommendations** - Prefer sagas (orchestration if business workflow centralizes, choreography for decoupling) for cloud-native systems. - Use durable state stores (DynamoDB, Cloud SQL) for saga state, managed pub/sub (SNS/SQS, EventBridge, Pub/Sub, Kafka) for choreography. - Implement observability: distributed tracing, saga timelines, replayable logs. - Always design idempotent APIs, unique saga IDs, durable retry policies, and well-defined compensating actions.

MediumSystem Design

23 practiced

Design a backup and disaster recovery plan for a managed relational database (e.g., RDS) with Recovery Time Objective (RTO) of 2 hours and Recovery Point Objective (RPO) of 15 minutes. Include architecture elements, backup cadence, cross-region replication, failover steps, and how you would test DR readiness without risking production data integrity.

Sample Answer

**Clarify requirements & constraints**- RTO = 2 hours, RPO = 15 minutes, managed relational DB (e.g., AWS RDS). Assume multi-AZ supported, budget for cross-region replicas, compliance for encrypted backups.

**High-level architecture**- Primary: Multi-AZ RDS (synchronous within region) for HA.- DR: Asynchronous cross-region read replica in target region (encrypted, same instance class or scalable).- Backup store: Automated snapshots + transaction logs stored in S3 (or cloud-provider equivalent) with lifecycle and cross-region replication.- Orchestration: IaC (Terraform), Lambda/Runbook for failover, Route53 weighted/alias records for endpoint switch, IAM roles and KMS keys replicated.

**Backup cadence & retention**- Automated snapshots: daily full snapshots (retain 30 days).- Continuous WAL/transaction log shipping / point-in-time recovery enabled; logs available every 5–10 minutes to meet 15-minute RPO.- Manual snapshots before major changes; snapshot lifecycle policy to archive to cold storage after 90 days.

**Cross-region replication**- Continuous asynchronous read replica kept warm (promotable). Use native cloud RDS cross-region read replica or logical replication for minimal lag.- Monitor replica lag metric; set alert if lag > 1 minute / CPU/IO thresholds.

**Failover / recovery steps**1. Detect incident via monitoring (CloudWatch) and runbook triggered.2. Promote cross-region replica to primary (make writable).3. Update DNS (Route53) to point application to new endpoint; lower TTL preconfigured (e.g., 60s).4. Validate application connectivity and run smoke tests.5. If no replica, restore latest snapshot + apply logs to PITR up to T-15m; bring up scaled instance.6. Reconfigure replication once primary restored; re-establish cross-region replica.

**Testing DR readiness (without risking prod)**- Use snapshot-based isolated test: copy latest automated snapshot to DR region, restore into a sandbox VPC with network isolation and anonymized data if necessary.- Run fully automated failover drill: promote a copied replica, swap DNS in test Route53 zone, run application test suite against test endpoint.- Use blue/green staging mimic: periodically perform failover drill during maintenance windows; validate RTO measured and RPO validated by verifying last transaction timestamp.- Automate tests in CI/CD and ensure runbooks and IAM permissions are exercised.

**Monitoring, runbooks, and metrics**- Track Recovery Time (actual), Replica Lag, Snapshot success, PITR window, DNS propagation time.- Keep runbooks, playbooks, and run tabletop exercises quarterly.

Trade-offs: asynchronous replica keeps cost lower but introduces small lag; for stricter RPO consider multi-region synchronous solutions (higher cost/complexity).

HardTechnical

22 practiced

During a production outage you observe CPU spikes across autoscaled services, increased 5xx error rates, and elevated latencies. Describe a step-by-step incident response plan: triage actions, temporary mitigations (traffic-shaping, scale-up), rollback or traffic-shifting options, stakeholder communication, and post-incident root-cause analysis and remediation steps.

Sample Answer

**Situation & immediate goals**- Restore customer-facing service quickly, stop blast radius, preserve evidence for root cause.

**Triage (first 0–10 mins)**1. Confirm scope: check CloudWatch/Stackdriver/Monitor dashboards, 5xx distribution, affected regions, services (EC2 ASG, EKS pods, Lambda).2. Identify correlation: CPU spikes vs traffic spike, deploys, queue backlogs (SQS/Kafka), DB slow queries (RDS/Aurora).3. Capture state: take scaled-down snapshots of metrics, collect logs (ELK/CloudWatch Logs), save current autoscaling configs and deployment versions.

**Temporary mitigations (10–30 mins)**- Traffic-shaping: apply rate limits at API Gateway/WAF or ALB, enable request throttling.- Scale-up: increase ASG max/min or bump EKS HPA limits; prefer graceful scale-up with warm pools to avoid cold starts.- Backpressure: pause background jobs, increase queue visibility/consumer count carefully.- Quick fixes: toggle feature flags or circuit-breakers to disable nonessential heavy endpoints.

**Rollback / traffic-shift (30–60 mins)**- If recent deploy suspected: rollback to last known good revision via Blue/Green or Canary (shift traffic 100% to stable target group).- If infra misconfig: revert infra change or switch to previous launch template/AMI.- If region degraded: shift traffic with Route53 weighted records or global load balancer failover.

**Stakeholder communication**- Initial alert (within 10 mins): incident owner, on-call, SRE, product lead; state scope and immediate mitigations.- Regular updates every 15–30 mins with status, actions, ETA.- Post-incident summary and customer-facing note within SLA window.

**Post-incident RCA & remediation**1. Gather timeline, logs, metrics, config diffs, deployment artifacts.2. Root-cause analysis: surface causal chain (e.g., memory leak in new service causing CPU + retry storms + DB saturation).3. Remediations: code fixes, capacity controls, autoscaling tuning, circuit-breakers, better retries/exponential backoff, query optimization.4. Prevent recurrence: improve runbooks, add alerts for specific leading indicators, chaos tests, canary rules, and postmortem with action owners and deadlines.5. Verify fixes in staging, perform gradual rollout with observability gates before full production release.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.