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

49 practiced

Explain the difference between stateless and stateful application design in cloud environments. Give concrete examples of each (web front-end, caches, session stores, databases), describe implications for horizontal scaling, failover, backup and restore, and outline steps to convert a small stateful component into a stateless design.

EasyTechnical

63 practiced

What is Infrastructure as Code (IaC)? Describe core principles, benefits, and common tools (Terraform, CloudFormation, ARM templates). Explain how IaC improves reproducibility, testing, and team collaboration for cloud infrastructure.

HardTechnical

79 practiced

Design an enterprise Terraform strategy for a multi-account cloud organization: include provider management, remote state with locking, workspaces vs separate state per account, policy-as-code (Sentinel/OPA), drift detection, CI gating, and how you'd handle secrets and sensitive outputs.

Sample Answer

**High-level approach (goal)** Provide safe, auditable, scalable Terraform for a multi-account org: immutable modules, pinned providers, one remote state per logical boundary, automated policy checks + CI gating, continuous drift detection, and secrets managed out-of-band.

**Provider & module management**- Pin provider and module versions in root modules and CI (provider lockfiles). Use Terraform Registry / private module registry for curated modules.- Use provider aliases for cross-account or multi-region resources; configure provider injection in modules (avoid hard-coded providers).

**Remote state & locking (AWS example)**- Use a remote backend with server-side encryption + locking. For AWS:

hcl

terraform {
  backend "s3" {
    bucket         = "tf-state-myorg"
    key            = "accounts/${var.account_id}/${var.env}/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "tf-state-locks"
  }
}

- One state file per account/environment/concern (e.g., account/networking-prod, account/app-staging). Avoid overloading workspaces for multi-account separation — prefer separate state per account to get clear ownership, IAM boundaries, and parallel apply independence.

**Workspaces vs separate states**- Use workspaces for simple per-environment variations inside a single account only. For multi-account, use separate state backends (different keys/buckets or distinct backend configs) to isolate IAM and blast radius.

**Policy-as-code**- Implement OPA/Gatekeeper or Sentinel (Terraform Enterprise) policies enforced in CI and on any remote plan/apply. Examples: deny public S3, require tags, enforce approved AMIs.- Run policy checks against the plan JSON (terraform plan -out=plan && terraform show -json plan) so policies see intended changes.

**CI gating**- Pipeline steps: terraform fmt -> terraform validate -> terraform init -> terraform plan (save plan) -> policy-as-code validation against plan -> security scans -> manual approval for prod -> terraform apply (remote or via pipeline). Store state locking and service principals in CI with short-lived credentials.

**Drift detection**- Schedule periodic “plan only” jobs (daily) per account; alert on non-empty plans. Integrate cloud-native drift tools (AWS Config, Azure Policy, GCP Forseti) to detect config drift and feed into ticketing.- For allowed drift, create automated remediation plays using IaC workflows (create plan and auto-apply with approvals for low-risk fixes).

**Secrets & sensitive outputs**- Never store secrets in plaintext in Terraform code or backend. Use external secret stores: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault. Inject secrets at runtime via data sources or CI environment with short-lived tokens.- Mark outputs as sensitive in Terraform. Avoid outputting secrets; if necessary, write them to secure secret store (Vault) instead of state.- Encrypt state at rest (backend encryption) and restrict S3/DynamoDB access via tight IAM policies and IAM roles per-account. Enable MFA and CloudTrail for state-bucket access.

**Access control & audit**- Least-privilege IAM roles for each pipeline and human operator. Use assume-role per account. Enable CloudTrail, alert on state-bucket access, and audit plan/apply events.

**Example operational practices**- Centralized “platform” account holds shared modules, state backend, and CI. Per-account repos reference modules and backends.- GitOps model: PR triggers plan + policy checks; merges to protected branches trigger apply with required approvals for prod.- Regularly rotate provider/module versions, run dependency scanning, and rehearse recovery (state restore from encrypted backups).

This strategy balances safety, isolation, and developer velocity: separate per-account state for clear boundaries, strong policy enforcement in CI using plan JSON, Vault-backed secrets, automated drift detection, and strict backend locking and encryption.

EasyTechnical

62 practiced

Compare Security Groups and Network ACLs (NACLs) in AWS: explain how each works, example use cases, default behaviors, order of evaluation, and when you would choose one over the other to implement network-level security.

HardTechnical

66 practiced

Compare serverless (e.g., FaaS) versus container-based architectures for a large-scale streaming application that requires stateful processing (per-user windows, exactly-once guarantees). Provide pros/cons, scaling considerations, cost and operational trade-offs, and an example hybrid architecture using both.

Sample Answer

**Situation & scope** Comparing FaaS (serverless) vs container-based for a large-scale stateful streaming app with per-user windows and exactly-once semantics.

**Serverless (FaaS) — Pros / Cons**- Pros: Fast dev velocity, automatic scaling to zero, managed infra, pay-per-invocation. Good for bursty stateless functions and lightweight event enrichment.- Cons: Short-lived execution limits, cold starts, limited memory/CPU, no built-in durable local state—hard to implement per-user windows and exactly-once without external durable systems. Concurrency limits and provider throttles complicate high-throughput streams.

**Containers (Kubernetes / managed container services) — Pros / Cons**- Pros: Full control of runtime, long-lived processes, colocated state stores (embedded or sidecars), affinity for stateful streaming engines (Flink, Kafka Streams). Easier to guarantee exactly-once with checkpointing, state backends, bounded latency.- Cons: Operational overhead (cluster management, autoscaling tuning), cost for always-on nodes, more complex deployments.

**Scaling considerations**- FaaS: scale-to-zero for idle; scale bursts quickly but may hit per-account concurrency. Requires external durable state (Redis, DynamoDB, RocksDB via durable store) to maintain windows.- Containers: scale pods with HPA/VPA and custom metrics (lag, throughput). Stateful apps need careful partitioning and rebalancing to avoid checkpoint restarts.

**Cost & ops trade-offs**- Use FaaS to reduce baseline cost for intermittent workloads; but external durable stores and orchestration for exactly-once raise cost/complexity.- Containers cost more baseline but simplify deterministic performance, observability, and stricter SLAs.

**Hybrid example architecture**- Ingress: Kafka / Kinesis for durable, ordered ingestion.- Processing: - Stateful core: Apache Flink on Kubernetes (KNative optional) in containers for per-user windows, checkpointing to S3 and RocksDB state backend—provides exactly-once. - Serverless layer: Lambda/GCF for lightweight enrichment, auth checks, or fan-out to downstream APIs.- State/coordination: Kafka Streams or Flink handles local keyed state; external durable store (DynamoDB/Redis) for cross-service lookup with idempotency tokens.- Autoscaling: K8s HPA based on Kafka lag + pod CPU; serverless on events.- Observability & ops: Prometheus, Grafana, distributed tracing, automated backup of checkpoints.

**Recommendation**Prefer container-based stateful engines for primary streaming processing to meet per-user windows and exactly-once. Use serverless for auxiliary, stateless tasks to optimize cost and developer velocity.

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.