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.

HardTechnical

25 practiced

Design an HTAP (Hybrid Transactional/Analytical Processing) architecture that supports OLTP for customer-facing services and near-real-time OLAP analytics updated within seconds. Consider storage choices, streaming replication (CDC), materialized views, indexing strategies, and trade-offs between latency and cost.

Sample Answer

Requirements (clarify):- Strong OLTP for customer-facing APIs: sub-10ms p99 writes/reads, ACID for payments- Near-real-time OLAP: analytical updates within seconds (<=5s)- Scale to millions of customers, multi-region reads- Cost-sensitive but tolerates moderate infra complexity

High-level architecture:- Primary OLTP DB: distributed, strongly consistent RDBMS (e.g., Amazon Aurora, CockroachDB, or YugabyteDB) serving transactional workloads.- Change-data-capture (CDC) pipeline: Debezium (CDC connector) -> Kafka (or managed streaming like MSK / Confluent / Confluent Cloud) with topic partitioning by tenant/key.- Streaming processing layer: Kafka Streams / Flink / ksqlDB that consumes CDC, enriches events, computes incremental aggregates, maintains materialized views.- Analytical store(s): - For fast point/time-series queries and materialized OLAP reads: a columnar store optimized for low-latency reads (e.g., ClickHouse, Snowflake with materialized views, or ClickHouse cluster colocated in same VPC). - Optionally a real-time OLAP cache (Redis/Elasticache or RocksDB via materialized-view endpoints) for sub-10ms dashboard reads.- APIs and BI: read-only analytic API layer that queries materialized views or analytical store; dashboards connect to same.

Data flow:1. App writes to OLTP DB.2. CDC publishes change events to Kafka within <1s.3. Stream processors apply transformations, incremental aggregations, update MV tables in analytic store (upserts/merge).4. Analytic queries read precomputed MVs or query columnar store with low latency.

Materialized views & indexing:- Maintain two MV types: - Near-real-time incremental MVs in streaming layer (windowed aggregates, top-K, counters) persisted to analytic store via upsert. - Heavier batch MVs computed hourly for deep aggregates.- Indexing: keep OLTP indexes minimal (PK + necessary FK + high-cardinality lookups). Offload analytic indexes to columnar store: sort/primary key by timestamp, partition by date, secondary compression; use Bloom filters for high-cardinality joins.- Use partial indexes or expression indexes for frequent filters.

Scaling & HA:- Scale OLTP vertically for latency-critical shards; horizontally via partitioning/tenant-sharding if needed.- Kafka topic partitions scaled to throughput; stream processors run as consumer groups for parallelism.- Analytical store scaled for read replicas; colocate compute near Kafka to reduce egress.

Consistency/latency trade-offs:- Eventual vs synchronous: fully synchronous replication to analytic store keeps strong consistency but increases OLTP latency; recommended: asynchronous CDC + stream processing to keep OLTP performance and achieve seconds-level freshness.- Tuning knobs: Kafka retention/acks, batch size, stream operator parallelism, connector flush interval — smaller batches reduce latency but raise throughput and cost.- Cost vs freshness: sub-second freshness requires more compute (more consumers, smaller micro-batch), higher network/IO costs. Aim for 1–5s target as sweet spot.

Operational considerations:- Idempotency: use event keys + versioning to ensure exactly-once or at-least-once semantics (use Kafka transactions or Flink exactly-once).- Schema evolution: use Avro/Protobuf with schema registry.- Observability: latency SLOs for CDC-to-MV lag, end-to-end tracing.- Backfill: use snapshot+CDC pattern to rebuild analytic store.

Recommendation:- Start with Aurora (OLTP) + Debezium -> Kafka -> Flink for streaming + ClickHouse for OLAP materialized views. Configure streaming to produce incremental MVs updated every 1–5s, minimal OLTP indexes, and monitor CDC lag. Revisit stricter consistency if business requires synchronous analytics.

EasySystem Design

21 practiced

Design a VPC/network layout for a single-region three-tier web application: public web tier, private application tier, and private data tier. Specify the number of subnets per AZ, route table separation, NAT usage, security group segmentation, and recommended CIDR sizing to allow future growth and multi-AZ expansion.

Sample Answer

Requirements (clarified): single region, three-tier (public web, private app, private data), multi-AZ resilience, future growth.

High-level design:- VPC CIDR: 10.0.0.0/20 (4096 addresses). This supports multiple AZs and future expansion; can be grown by using larger CIDR at creation (e.g., /16 if allowed) or planning additional VPCs with VPC peering/Transit Gateway.- AZs: use 3 AZs for high availability.

Subnets:- Per AZ: 3 subnets → public (web), private-app (application), private-data (database/replica). So total subnets = 3 AZs × 3 = 9 subnets.- Subnet sizing per AZ: public /26 (64 addresses) per AZ; app /24 (256) per AZ; data /25 (128) per AZ. Example allocation across 10.0.0.0/20: - AZ1: 10.0.0.0/26 (public), 10.0.1.0/24 (app), 10.0.2.0/25 (data) - AZ2/AZ3 similar with subsequent blocks.

Route tables:- One route table for public subnets (routes to IGW).- One route table for private-app subnets (default route to NAT).- One route table for private-data subnets (no NAT; only access to app subnets and to backup endpoints). Keep DB subnets isolated — no direct route to IGW.

NAT usage:- Use NAT Gateways in each AZ for private-app subnets to access the internet (patching, external APIs). Place a NAT Gateway in each AZ's public subnet and configure private-app route table to use the NAT in same AZ for AZ-aware routing and cross-AZ resiliency (or use central NAT + cross-AZ failover as a trade-off).- Databases should not require outbound internet; if needed for updates, route via a controlled proxy in app tier.

Security groups & segmentation:- Web SG: allow inbound 80/443 from internet; outbound to app SG on app ports.- App SG: allow inbound from web SG on application ports; outbound to DB SG on DB ports and to external endpoints via NAT.- DB SG: allow inbound only from app SG on DB port (e.g., 5432/3306); restrict outbound to backups/monitoring IPs.- Management/ Bastion host: place in a separate public subnet with restricted IP allowlist; or use Session Manager (recommended).- Network ACLs: keep default permissive; only add NACLs for additional hardening (stateless rules).

Additional recommendations:- Use private hosted zone and internal DNS for service discovery.- Use AWS Bastion alternatives (SSM) to avoid open SSH.- Centralized logging, flow logs, and VPC endpoints for S3/DynamoDB to avoid internet egress.- Document IP plan to reserve blocks for future AZs or peering.

Trade-offs:- Per-AZ NAT gateways increase cost but give better availability and avoid cross-AZ bandwidth. Central NAT saves cost but adds cross-AZ traffic and single point complexity.

MediumSystem Design

21 practiced

Design a GitOps-based Infrastructure-as-Code and CI/CD workflow to manage cloud infrastructure across dev, staging, and prod. Include how you would handle remote state, secrets, plan/apply validations, rollbacks, and promoting changes between environments when using Terraform and Kubernetes.

Sample Answer

Requirements (implicit): manage infra as code across dev/staging/prod, enforce review and policy, safe remote state and locking, secrets handling, plan/apply validation, easy promotion path, automated rollback and observability.

High-level architecture:- Git repos per environment (or mono-repo with dirs): infrastructure/terraform and apps/k8s.- GitOps controllers: Argo CD or Flux for Kubernetes manifests; CI runners (GitHub Actions/GitLab/CircleCI) for Terraform runs or use Terraform Cloud/Enterprise.- Remote state: S3 (or GCS/Azure Blob) + DynamoDB locking (or CloudStorage + Locking) for safe concurrent applies. Enable encryption and fine-grained IAM roles.- Secrets: HashiCorp Vault for dynamic secrets + ExternalSecrets operator or sealed-secrets for k8s; never store raw secrets in git.

Workflow / CI-CD & Promotion:1. Developer creates feature branch or changes infra in dev/ directory and opens a PR.2. CI pipeline runs: terraform fmt, validate, init (with remote state), plan (against dev workspace), and policy checks (OPA/Rego, Sentinel, custom checks). Report plan as PR comment/artifact.3. For dev: auto-apply via pipeline or allow GitOps to reconcile. Use short-lived service account credentials scoped to dev.4. After QA, merge to staging branch: pipeline repeats with staging remote state and stricter policy (more tests, cost estimate). Apply requires approval (codeowners or CI manual approve).5. Promote to prod by merging to prod branch or creating release tag. Prod apply requires multi-person approval (2-step) and runs in a controlled runner/service account, with immutable logs stored.

Plan/apply validations & safety:- Require terraform plan in CI and attach plan file; prevent blind apply.- Gate applies with Policy-as-Code (OPA/Rego) to block risky changes (public S3, wide security groups, instance size thresholds).- Use drift detection: scheduled pipelines compare state and alert; GitOps controller reports divergence.

Rollbacks:- Infra rollback = revert the git commit that introduced the change and merge; CI runs plan to show reverse delta and apply. For k8s, ArgoCD/Flux can roll back to previous manifest revision immediately.- Keep automated snapshots/backups: state versioning in backend (S3 versioning), AMI/snapshots for DB, and k8s resource history (ArgoCD).- For emergency quick rollback: run pre-approved rollback pipeline to restore last known good state.

Secrets & Access:- Use short-lived creds from Vault, cloud KMS for encrypting state at rest.- CI uses OIDC to assume least-privilege IAM roles; no long-lived cloud keys in runners.- Store only encrypted references in git; reconcile operators pull secrets at runtime.

Observability & Audit:- Central logging for CI and gitops controller; alerting on failed applies, drift, policy violations.- Audit logs in cloud + Terraform plan/apply audit events.

Trade-offs:- Per-environment repos simplify isolation and RBAC but add duplication; mono-repo simplifies DRY but needs strict path-based protections.- Terraform Cloud/Enterprise reduces custom CI complexity (remote runs, state, policy) at licensing cost.

Why this works:- Git is the single source of truth; PRs + CI enforce validation; remote state + locking prevent corruption; Vault + operators secure secrets; ArgoCD/Flux provide continuous reconciliation and fast Kubernetes rollbacks; approvals and policy gates protect prod.

MediumTechnical

20 practiced

Evaluate managed database options (e.g., Amazon RDS, Google Cloud Spanner, Amazon DynamoDB) for a global leaderboard application that requires low-latency reads and linearizable writes. Discuss consistency guarantees, horizontal scalability, schema flexibility, pricing, and operational complexity for each option.

Sample Answer

Summary recommendation: For a global leaderboard that needs low-latency reads and linearizable (strong) writes, Cloud Spanner is the simplest managed fit for global, strongly-consistent writes at scale. DynamoDB can also meet requirements with careful design (single-partition leader or transactional patterns) and lower operational overhead/cost at scale. RDS is easiest for relational features but becomes operationally complex and costly to get global linearizable writes.

Amazon RDS (MySQL/Postgres/Aurora)- Consistency: Strong within a single primary; cross-region reads are eventually consistent unless using single-write primary or synchronous replicas (Aurora Global has low-latency replicas but writes remain single-primary).- Scalability: Vertical scale or read replicas; write scale is limited by primary. Not truly global write-scalable.- Schema: Relational schema, ACID, rich querying — good for complex queries and joins.- Pricing: Moderate to high (I/O and read-replica costs); multi-region HA increases cost.- Operational complexity: Moderate — managed but you must handle backups, replicas, failover, and cross-region replication tuning.

Google Cloud Spanner- Consistency: Global strong (external) consistency and linearizable reads/writes across regions.- Scalability: Horizontally scalable for both reads and writes; designed for global scale with automatic split/reshard.- Schema: Relational schema with SQL, but limited advanced RDBMS features (e.g., limited per-row transactions compared to full Postgres extensions).- Pricing: Higher base cost (nodes/instance); predictable but can be expensive for small workloads.- Operational complexity: Low — fully managed global replication, automatic splitting, schema changes online.

Amazon DynamoDB- Consistency: Offers eventual and strongly consistent reads (within a region). Global tables provide multi-region replication but cross-region writes require conflict resolution; DynamoDB transactions are ACID per-region; linearizable global writes are not native.- Scalability: Excellent horizontal scale for reads/writes per partition key; virtually unlimited if you design keys well.- Schema: NoSQL key-value/document model — flexible but limited ad-hoc querying and complex aggregations require secondary indexes or downstream analytics.- Pricing: Pay-per-request (provisioned or on-demand), global replication and DAX (cache) add cost. Generally cost-effective at high scale.- Operational complexity: Low — serverless, but designing partition keys, hot-key mitigation, and achieving global linearizability adds design complexity.

Design notes and trade-offs:- If you truly need global linearizable writes (single logical ordering across regions), Spanner is the clearest fit. DynamoDB can approximate with a single region primary for writes + global reads, or use a leader-shard pattern with conditional writes for linearizability per-shard.- For ultra-low read latency, add edge caching (CDN or DAX/Redis) with short TTLs and invalidate on writes; be careful to preserve linearizability guarantees (use cache-aside with write-through/invalidate).- If relational queries/joins matter, prefer RDS/Aurora for simpler development, but accept single-primary write bottleneck.- Cost/performance decision: small-to-medium scale with predictable access -> RDS/Aurora; global, strongly-consistent, high-throughput -> Spanner; massive scale with simple access patterns and cost sensitivity -> DynamoDB with careful key design.

Recommended next step: run a short spike comparing Spanner and DynamoDB with representative workload (write/read TPS, key distribution, latency SLOs) including cache layer to validate latency and cost.

HardTechnical

27 practiced

Compare leader-based replication and leaderless (gossip-style) replication models for distributed key-value stores. Discuss trade-offs in write/read latency, conflict resolution, availability under partitions, and operational complexity. Provide examples of workloads where each model is appropriate.

Sample Answer

Clarifying: leader-based = single primary for a partition (master-slave, Raft/Paxos), leaderless = multi-writer, anti-entropy/gossip (e.g., Dynamo/Cassandra-style).

Summary comparison:- Write/read latency - Leader-based: writes converge at leader — low write latency if client is near leader; reads can be served from leader or followers (stale reads possible). Strong consistency modes (sync replicate to majority) increase write latency due to quorum/consensus. - Leaderless: clients may write to any replica and return quickly (low local write latency) but durability often depends on N,R,W quorum settings — read latency can be low if read from closest replica but achieving consistent reads (W+R>N) raises latency.

- Conflict resolution - Leader-based: leader serializes updates; conflicts are avoided or resolved deterministically by leader logic — simpler application model. - Leaderless: concurrent writes produce divergent versions; resolution via vector clocks, last-write-wins, or application reconciliation increases complexity and risk of lost updates.

- Availability under partitions - Leader-based: leader loss or network split can make partition without leader unavailable for writes (sacrifices availability for consistency) unless you accept multiple leaders (risk of conflicts). - Leaderless: more available — any reachable replica can accept writes (AP in CAP), so higher write availability during partitions, at cost of consistency.

- Operational complexity - Leader-based: requires leader election, consensus tuning, handling leader failover, but easier to reason about correctness and debugging. - Leaderless: simpler per-node logic but requires robust anti-entropy, tombstone handling, compaction, and conflict-resolution monitoring; harder to reason about data correctness and to diagnose divergence.

Workload fit examples:- Leader-based (use when consistency and simpler semantics matter): financial transactions, inventory systems, user account/profile stores where serializability or linearizability is required.- Leaderless/gossip (use when availability and low-latency geo-distribution matter): global session stores, user timeline ingestion, metrics/telemetry, caching layers where occasional conflict or eventual consistency is acceptable.

Trade-offs summary: choose leader-based for strong consistency and simpler conflict semantics at cost of availability and potentially higher write latency under sync replication; choose leaderless for higher availability and geo-scale with more complex conflict resolution and operational overhead.

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.