Cloud and Infrastructure Architecture Questions

Design of cloud and infrastructure solutions from simple cloud applications to end to end cloud systems and large scale infrastructure. Topics include stateless versus stateful design, VPC and networking basics, security groups and firewalls, multi environment management, deployment topology, capacity planning, global distribution, cloud native services, infrastructure as code, and operational concerns for sustaining large scale cloud environments.

EasyTechnical

56 practiced

Design a VPC/networking baseline for a three-tier web application across two availability zones. Your answer should list required components and explain: Internet access for public subnets, NAT for private subnets, route tables, security groups vs network ACLs, and how you would provide secure admin access. Include diagrams or bullet lists to illustrate logical layout.

Sample Answer

**High-level summary**Design a VPC spanning 2 AZs with a three-tier app: Public (ALB), Application (App servers), Data (DB). Use public and private subnets per AZ, Internet Gateway, NAT Gateways, route tables, Security Groups (SG) for stateful fine-grain rules and Network ACLs (NACLs) for coarse stateless protection. Provide Bastion + bastion jump + session logging for secure admin access.

**Logical layout (ASCII)**VPC├─ AZ-a│ ├─ Public subnet A (ALB, NAT-GW-A)│ ├─ Private app subnet A (App servers)│ └─ Private data subnet A (DB replicas)├─ AZ-b│ ├─ Public subnet B (ALB, NAT-GW-B)│ ├─ Private app subnet B (App servers)│ └─ Private data subnet B (Primary DB / failover)

**Required components**- VPC with CIDR (e.g., 10.0.0.0/16)- Public subnets in each AZ (10.0.1.0/24, 10.0.3.0/24)- Private app subnets in each AZ (10.0.2.0/24, 10.0.4.0/24)- Private data subnets in each AZ (10.0.5.0/24, 10.0.6.0/24)- Internet Gateway (IGW)- NAT Gateways (one per AZ for high availability)- Route Tables: Public RT -> IGW; Private app/data RT -> NAT-GW (for app) or no NAT for DB- Security Groups: ALB SG (allow 80/443 from 0.0.0.0/0), App SG (allow from ALB SG on app port), DB SG (allow from App SG on DB port)- Network ACLs: optional stateless deny lists per subnet (limit broad ranges, block bad IPs)- Bastion host / Systems Manager Session Manager + MFA + centralized logging (CloudTrail/SSM/Jumpbox)

**Internet access for public subnets**- Public subnets have route table with 0.0.0.0/0 -> IGW. Instances need public IP or use ALB.

**NAT for private subnets**- Deploy NAT Gateway in each AZ; private route table points 0.0.0.0/0 -> NAT-GW in same AZ for AZ isolation and no single point of failure. DB subnet typically has no outbound internet; use VPC endpoints for S3/ECR.

**Route tables**- One public RT (associated with all public subnets)- One private app RT per AZ pointing to local NAT-GW (or shared with AZ-aware NAT)- Optionally separate DB RTs with no internet routes

**Security Groups vs Network ACLs**- Security Groups: stateful, apply to ENIs, recommended for allow-listing service-to-service traffic (use SG references to avoid IP drift)- NACLs: stateless, subnet-level, good for additional perimeter filtering or blocking IP ranges. Do not rely on NACLs for fine-grained access.

**Secure admin access**- Prefer AWS Systems Manager Session Manager (no bastion public IP). Enforce IAM + MFA and SSM IAM role.- If bastion required: place in public subnet with tight SG (SSH only from corporate IP), use ephemeral keys, OS hardening, logging to CloudWatch and session recording; enforce IP allow-list, MFA, and Just-In-Time access via automation.

**HA / Resilience notes**- Place NAT-GW per AZ, ALB across AZs, DB with multi-AZ failover, use health checks and automated scaling for app layer.

This baseline enforces least privilege, AZ redundancy, auditable admin access, and separation of concerns across tiers.

EasyTechnical

50 practiced

An internal team asks you to estimate capacity for an initial cloud deployment of a new API expected to handle 1,000 concurrent users with unpredictable growth. Describe a basic capacity planning approach: what metrics you collect, how to size resources (CPU/memory), and how to plan safety margins and scaling policies before the first production release.

HardTechnical

51 practiced

Design a governance and IaC pipeline to detect and prevent infrastructure drift, enforce policy, and manage multi-account infrastructure changes. Include tooling choices (policy-as-code, OPA/Gatekeeper, Sentinel), testing stages (unit, integration, staging), and how to automate remediation when drift is detected.

Sample Answer

**Clarify goals & constraints**- Prevent/repair drift, enforce policy-as-code, safe multi-account change promotion, auditability, minimal blast radius, cloud-agnostic where possible.

**High-level architecture**- Central GitOps repo per environment + org-level policy repo.- CI/CD pipeline per account OU using GitHub Actions / GitLab CI / Azure DevOps + cross-account runners or CodeBuild with IAM roles.- State backend: remote state (Terraform Cloud/Enterprise or S3 + DynamoDB for locking) with workspaces per account/module.

**Tooling**- IaC: Terraform or Pulumi.- Policy-as-code: OPA (rego) + Gatekeeper for Kubernetes; Sentinel for Terraform Enterprise where used; Conftest for pre-apply checks.- Drift detection: HashiCorp Sentinel/Terraform Cloud drift checks + periodic reconcilers using Terraform plan/apply or AWS Config rules / Azure Policy.- Orchestration: Flux/ArgoCD for k8s; for infra, use GitOps flows with PR-based promotion.

**Pipeline stages**1. Unit (local lint & security): tflint, terraform validate, fmt, conftest/opa tests.2. Integration: apply to ephemeral sandbox account (automated ephemeral environments), run end-to-end tests.3. Staging: apply to staging account with manual approval gates, policy enforcement (OPA/Sentinel).4. Prod: gated deployment with multi-signature approvals and automated canary.

**Drift detection & automated remediation**- Continuous reconcilers: scheduled Terraform plan against remote state; AWS Config / Azure Policy detect resource drifts and trigger alerts.- When drift found: - Create automated PR with proposed terraform changes (using Atlantis or Terraform Cloud run triggers) including plan output. - If drift is non-critical, run automated remediation via controller (e.g., Terraform apply in maintenance window) or invoke self-healing lambda/operator. - For sensitive changes, open an incident with automated rollback + manual approval.- Maintain audit logs of detection, PRs, approvals, and apply via CloudTrail, Terraform Cloud runs, and OPA/Gatekeeper audit.

**Governance & compliance**- Central policy repo, versioned; policies tested in pipeline; policy evaluation at pre-merge (conftest/opa), admission (Gatekeeper), and pre-apply (Sentinel).- RBAC + least privilege, resource tagging enforcement, cost guardrails.- Metrics & alerts: compliance dashboards, drift rate, time-to-remediate.

**Trade-offs**- Sentinel tight integration with Terraform Cloud vs OPA vendor neutrality. Combine: use OPA for org-wide policies and Sentinel for deep Terraform checks where Terraform Cloud used.

This design provides layered enforcement (pre-merge, admission, runtime), safe multi-account promotion, automated detection + safe remediation, and auditability suitable for enterprise governance.

MediumTechnical

50 practiced

Design a caching strategy for a read-heavy product catalog service used globally. Cover cache placement (edge vs regional), TTL strategies, cache warming, invalidation on product updates, and handling cache stampedes under high load.

Sample Answer

**Approach summary**Design a multi-layer cache: CDN edge for global low-latency reads, regional read-replicas/in-memory caches for heavier data and write-awareness, and a strong origin cache (DB + cache-aside or write-through) for correctness.

**Cache placement**- Edge (CDN): serve mostly static product pages, images, localized pricing; TTLs short-to-medium (30s–5m) for dynamic fields.- Regional caches (Redis/Memcached in each region): store product JSON, availability, personalization; TTLs medium (1–10m).- Origin: authoritative DB and cache layer with longer persistence and transactional consistency.

**TTL strategy**- Use field-level TTLs: immutable attrs (images, description) long TTL (hours/days); volatile attrs (inventory, price) short TTL (seconds–minutes).- Staggered TTLs with jitter to avoid synchronized expiration.

**Cache warming**- Proactively preload hot SKUs after deploys or traffic spikes using background jobs and predictive models (top N by region).- Use async bulk refresh endpoints and CDN prefetch for major launches.

**Invalidation**- Event-driven invalidation: on product update, publish to a message bus (Kafka/SNS) with SKU and changed fields.- Regional services subscribe to invalidate or refresh relevant keys; CDN supports soft-purge by cache-key and surrogate-control headers for selective purge.- For critical updates (price/inventory), perform synchronous invalidation + read-through refresh.

**Handling cache stampedes**- Use request coalescing / singleflight at regional cache layer so only one backend fetch per miss.- Serve stale-while-revalidate: return slightly stale object while background refresh occurs.- Use probabilistic early refresh (refresh when TTL < threshold) and exponential backoff on retries.- Protect origin with rate limits and circuit breakers.

**Trade-offs**- Edge improves latency but increases complexity for fine-grained invalidation.- Regional caches reduce origin load and enable coalescing but require cross-region invalidation design.

This balances low latency, global scale, correctness for critical fields, and resilience under load.

HardBehavioral

45 practiced

Tell me about a time you led a large-scale cloud migration program across multiple teams. Describe the approach you used to prioritize workloads, how you handled technical debt, how you measured progress, and one significant challenge you faced and how you resolved it. Use the STAR format.

Sample Answer

**Situation**I was the Cloud Architect leading a 12-month migration of 200+ apps from on-prem to a multi-account AWS landing zone across 8 product teams and two data centers. Executive goal: reduce ops cost and enable faster feature delivery.

**Task**Define migration strategy, prioritize workloads, manage technical debt, measure progress, and resolve cross-team blockers while minimizing customer impact.

**Action**- Prioritization: I created a weighted scorecard (business impact, risk, effort, compliance, ROI). We ranked apps into Quick Wins, Strategic, and Legacy. Quick Wins (low effort, high business value) seeded early wins to fund the program.- Technical debt: Instituted a “migrate-and-modernize” policy — every migration included a debt assessment, mandatory remediation thresholds, and a backlog owned by each team. We used strangler pattern for monoliths, containerization for modular apps, and platform guardrails (IaC, shared CI/CD, security baselines) to prevent new debt.- Measurement: Built a dashboard tracking % workloads migrated, production incidents, deployment frequency, mean time to recovery (MTTR), cost delta vs baseline, and compliance posture. Weekly executive scorecards and team OKRs aligned incentives.- Governance & enablement: Created reusable landing zone modules, migration runbooks, and a central Migrations Guild for cross-team knowledge.- Challenge & resolution: A major challenge was data consistency for a core billing service with low RPO/RTO. I led a cross-team design using dual-write with change-data-capture (AWS DMS + Kafka), performed end-to-end reconciliation tests in a staging mirror, and executed a carefully scripted cutover (canary, traffic-shift, rollback hooks). That prevented revenue-impacting inconsistencies.

**Result**We migrated 85% of targeted workloads in 10 months, reduced infrastructure costs by 22%, improved deployment frequency by 2x, and lowered production incidents by 35%. The governance model and guardrails reduced post-migration technical debt growth and accelerated future cloud adoption.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.