Top Cloud Architect & Engineer Interview Questions 2026

IaaS (Infrastructure as a Service) provides virtualised compute, storage, and networking — you manage the OS and up (e.g. EC2, GCE). PaaS (Platform as a Service) provides a managed runtime; you manage your application and data but not the infrastructure (e.g. AWS Elastic Beanstalk, Google App Engine, Heroku). SaaS (Software as a Service) is a fully managed application delivered over the web — you just use it (e.g. Salesforce, Gmail, Jira). The tradeoff: more control vs less operational burden as you move from IaaS to SaaS.

A VPC is an isolated virtual network. Subnets divide it into segments — public subnets have a route to an Internet Gateway (IGW); private subnets do not. Route tables control where traffic flows: the public subnet's route table has a 0.0.0.0/0 → IGW entry. Private instances needing outbound internet access route through a NAT Gateway in the public subnet (NAT Gateway has an Elastic IP). Security groups are stateful firewalls at the instance level — they track connections, so return traffic is allowed automatically. Network ACLs are stateless and apply at the subnet level, useful for broad DENY rules.

CAP theorem states a distributed system can guarantee only two of three properties: Consistency (every read gets the latest write), Availability (every request gets a response), Partition tolerance (the system works despite network partitions). Since network partitions are unavoidable in distributed systems, the real choice is between CP (consistency at the cost of availability — e.g. HBase, Zookeeper) and AP (availability at the cost of consistency — e.g. Cassandra, DynamoDB in eventual consistency mode). Relational databases on a single node are CA but sacrifice partition tolerance. Choose based on whether stale reads or downtime is more acceptable for your use case.

Deploy to at least two regions (active-active or active-passive). Global load balancing (AWS Route 53 latency routing or Global Accelerator) routes users to the nearest healthy region. Each region: multi-AZ application tier (ECS or EKS) behind an ALB, multi-AZ RDS with read replicas (or Aurora Global Database for cross-region replication with <1s RPO). Shared state: DynamoDB Global Tables or Redis with cross-region replication. S3 Cross-Region Replication for static assets. Data consistency challenge: define which region owns writes (active-active requires conflict resolution) vs failover region (active-passive is simpler). Monitor with health checks; automate failover via Route 53 health checks. Define RTO and RPO targets upfront — they drive every technology decision.

Auto-scaling adjusts the number of compute instances or containers based on demand. In AWS, an Auto Scaling Group (ASG) monitors CloudWatch metrics and triggers scale-out or scale-in actions based on policies. Primary trigger metrics: CPU utilisation (simple but lags behind actual demand), request count per target (on ALB — best for web workloads), SQS queue depth (for worker fleets), custom metrics like active connections or latency percentiles. Set scale-out aggressively (trigger early) and scale-in conservatively (cooldown periods, protect recently launched instances) to avoid thrashing. For containers, Kubernetes HPA uses CPU/memory or custom metrics via the metrics API.

Security groups are stateful, instance-level firewalls — they track connection state, so if outbound traffic is allowed, the return traffic is automatically permitted. They support only ALLOW rules. Network ACLs (NACLs) are stateless subnet-level firewalls — you must explicitly allow both inbound and outbound for a connection to work, including ephemeral ports for return traffic. NACLs support both ALLOW and DENY rules, evaluated in numerical order. Best practice: use security groups as the primary control; use NACLs for broad subnet-level blocks (e.g. blocking a known malicious IP range).

Investigation: (1) Open Cost Explorer — identify which service, region, and account drove the increase; filter by usage type to find the specific resource; (2) Common culprits: NAT Gateway data processing fees (often overlooked), S3 data transfer out, EC2 instances left running after a test, RDS storage autoscaling, accidental public S3 bucket being scraped, or a runaway Lambda in a loop. Remediation: immediately stop/terminate idle resources; set AWS Budgets alerts and anomaly detection alerts (Cost Anomaly Detection) to catch spikes within hours; review S3 bucket policies and server access logs; for NAT Gateway costs, check if traffic can route via VPC endpoints instead (S3 and DynamoDB have free gateway endpoints). Long-term: enforce tagging policy, implement guardrails with SCPs in AWS Organizations.

The Kubernetes scheduler assigns pods to nodes based on resource requests, node affinity/taints/tolerations, and available capacity. Resource requests are guarantees — the scheduler only places a pod on a node with at least that much unallocated CPU/memory; they determine QoS class. Resource limits cap usage — if a container exceeds CPU limit it is throttled; if it exceeds memory limit, the OOM killer terminates it. Always set both: without requests, the scheduler cannot make informed placement decisions; without limits, a noisy pod can starve others on the same node. Use Vertical Pod Autoscaler (VPA) to right-size requests based on actual usage over time.

Identity and Access Management (IAM) controls who can access which cloud resources and what actions they can perform. In AWS, IAM policies are JSON documents attached to users, groups, or roles that define Allow/Deny on specific actions and resources. The principle of least privilege means granting only the minimum permissions required to perform a task — no more. In practice: use IAM roles for EC2/Lambda instead of long-lived access keys, scope policies to specific resource ARNs rather than *, regularly audit unused permissions with IAM Access Analyzer, and use Service Control Policies (SCPs) in AWS Organizations to enforce organisation-wide guardrails.

RPO 1 hour means you can lose at most 1 hour of data; RTO 4 hours means you must restore service within 4 hours. A Warm Standby strategy fits: maintain a scaled-down version of your stack in a secondary region. Database: Aurora Global Database with cross-region replication (<1s lag, much better than the 1hr RPO); alternatively, RDS automated backups exported to S3 with cross-region replication (gives ~1hr RPO). Application: pre-deployed ECS/EKS cluster in DR region running at minimal capacity, ready to scale. In a DR event: (1) promote the DR database replica; (2) update DNS (Route 53) to point to the DR region — TTL should be pre-set to 60s; (3) scale the application tier. Test the runbook quarterly — an untested DR plan is not a DR plan.

A service mesh (e.g. Istio, Linkerd) is an infrastructure layer that handles service-to-service communication in a microservices architecture. It uses sidecar proxies (Envoy) injected alongside each service to handle: mTLS encryption between services, traffic management (canary releases, circuit breaking, retries, timeouts), and observability (distributed tracing, metrics per service pair). Use it when you have many services with complex inter-service communication requirements, especially when you need to enforce zero-trust networking or need fine-grained traffic control. The overhead (sidecar per pod, control plane complexity) is not worth it for smaller deployments with <10 services.

Structure with STAR. Highlight: the migration strategy used (lift-and-shift, re-platform, re-architect — and why that choice), how you handled data migration with minimal downtime (dual-write, CDC with DMS, blue-green cutover), how you assessed and managed risk (rollback plan, staging environment, traffic shifting), any cost or performance improvements achieved post-migration, and lessons learned. Quantify outcomes: "reduced infrastructure cost by 35%", "improved deployment frequency from monthly to daily", "eliminated the on-call burden of managing physical hardware."

Ingestion: sources push events to Kafka (or Kinesis for AWS-native) for durable, replayable streaming. Processing: Apache Spark on EMR or Databricks for batch transformations; Flink or Spark Structured Streaming for near-real-time. Storage: raw data lands in S3 in Parquet/ORC format (data lake); transformed data in a columnar warehouse (Redshift, BigQuery, Snowflake). Orchestration: Apache Airflow (MWAA on AWS) for DAG scheduling and dependency management. At 500GB/day (~6MB/s): Kafka with 3-6 partitions handles this comfortably; Spark on 4-8 m5.xlarge instances processes the batch in under an hour. Add data quality checks (Great Expectations or dbt tests) at each stage and alert on SLA breaches. Cost optimise: use S3 Intelligent-Tiering for raw data, Spot instances for Spark workers.

Terraform state (terraform.tfstate) maps your configuration to real cloud resources — it tracks resource IDs, dependencies, and metadata. By default it is stored locally, which is unsuitable for teams. Store it remotely in S3 with DynamoDB locking (or Terraform Cloud) to enable collaboration and prevent concurrent applies from corrupting state. Problems: (1) State drift — someone makes a manual change in the console; fix with terraform import or terraform refresh; (2) State corruption from concurrent applies — prevented by locking; (3) Sensitive values in state — encrypt the S3 bucket and restrict IAM access; (4) Large state files with many resources slowing plan times — use workspaces or module separation to partition state.

Vertical scaling (scale up) increases the size of an existing instance — more CPU, RAM, or disk on the same machine. It is simple but has a hardware ceiling and requires downtime for most instance types. Horizontal scaling (scale out) adds more instances behind a load balancer. It has no theoretical upper limit, enables fault tolerance (no single point of failure), and can be automated with auto-scaling. In cloud architecture, prefer horizontal scaling for stateless application tiers; vertical scaling is sometimes necessary for stateful systems like databases (though read replicas and sharding are horizontal alternatives).

Zero trust means "never trust, always verify" — no implicit trust based on network location. Implementation layers: (1) Identity — enforce MFA for all users; use IAM Identity Center (SSO) with short-lived role sessions; condition IAM policies on MFA (aws:MultiFactorAuthPresent: true); (2) Network — treat VPC boundaries as insufficient; add security groups at every tier; use VPC endpoints for AWS services so traffic never traverses the internet; implement micro-segmentation with fine-grained security group rules; (3) Workload — mTLS between services via service mesh or API Gateway mutual TLS; (4) Data — encryption everywhere (KMS-managed keys, envelope encryption for S3 and RDS); (5) Monitoring — enable CloudTrail, GuardDuty, Security Hub; alert on any access outside expected patterns; (6) Devices — for human access, enforce endpoint compliance checks via AWS Verified Access before granting console/API access.

A Service abstracts a set of pods behind a stable DNS name and IP, load balancing across healthy pods using kube-proxy (iptables or IPVS). Service types: ClusterIP (internal only), NodePort (exposes on every node's IP), LoadBalancer (provisions a cloud load balancer). An Ingress resource defines HTTP routing rules (host/path-based) in front of multiple services — it requires an Ingress Controller (nginx-ingress, AWS ALB Ingress Controller, Traefik) to implement the rules. The ALB Ingress Controller on EKS provisions an AWS Application Load Balancer natively, handling SSL termination, path routing, and target group management — more cost-effective than one LoadBalancer Service per microservice.

Reserved Instances (RIs) are a billing discount (up to 72%) in exchange for a 1- or 3-year commitment to a specific instance type and region. Use them for baseline steady-state workloads you are confident will run continuously (e.g. production database, always-on application servers). For variable or unpredictable workloads, on-demand or Spot Instances (up to 90% discount for interruption-tolerant workloads like batch jobs) are better. Savings Plans offer similar discounts with more flexibility (commitment is to a spend level, not a specific instance type). Best practice: cover your baseline with RIs or Savings Plans; handle spikes with on-demand; use Spot for batch and CI/CD workers.

API Gateway (HTTP API, lower latency and cost than REST API) fronts Lambda functions. At 10k req/sec, Lambda concurrency needs careful management: set reserved concurrency on critical functions to prevent noisy neighbours; use provisioned concurrency on the hot path to eliminate cold starts. Database: DynamoDB (serverless, auto-scales to millions of req/sec) with on-demand capacity mode — avoid RDS which has connection limits incompatible with Lambda's per-request connection model. Caching: API Gateway response cache or ElastiCache (Redis) via Lambda — reduces Lambda invocations for read-heavy endpoints. For background processing: SQS + Lambda (event source mapping), with DLQ for failed messages. Cost at 10k req/sec: ~$0.20/million Lambda requests + duration + API Gateway — typically 60-80% cheaper than equivalent EC2 at this scale. Monitor: Lambda Insights for duration/errors, CloudWatch alarms on throttles.

Structure your answer around a framework: (1) Visibility first — enable Cost Explorer, tag everything by team/env/project, set up anomaly detection alerts; (2) Right-sizing — use Compute Optimizer or Trusted Advisor recommendations to identify oversized instances; (3) Pricing model — move steady-state workloads to Reserved Instances or Savings Plans; batch/CI workloads to Spot; (4) Architecture — eliminate waste (idle resources, forgotten snapshots, orphaned volumes); route internal traffic through VPC endpoints instead of NAT Gateway; use S3 lifecycle policies for storage tiering; (5) Culture — make costs visible to engineering teams; build cost dashboards; include cost review in architecture decisions. Share a specific example with quantified savings.