Cloud Infrastructure Knowledge (AWS/GCP/Azure) Questions

Have working knowledge of at least one major cloud platform: common services (EC2/Compute Engine, RDS/Cloud SQL, S3/Cloud Storage, Load Balancers, VPCs, networking), typical failure modes, and how to troubleshoot within that platform. Understand concepts like availability zones, regions, and cross-region failover.

MediumTechnical

38 practiced

A high-volume API indicates an unexpected spike in network errors (5xx) for a subset of clients. Describe how you would triage whether this is an upstream cloud provider outage, networking misconfiguration, a load balancer bug, or a code regression. List which telemetry and tests you would run in order.

Sample Answer

**Situation & goal**Triage an unexpected spike in 5xx errors for a subset of clients to determine whether the root cause is upstream cloud provider outage, networking misconfiguration, load balancer bug, or code regression.

**High-level approach**1. Rapidly scope: identify affected clients, regions, services, and time window.2. Narrow blast radius: determine whether errors correlate with cloud provider metrics, networking layer, LB, or app logs.3. Run targeted telemetry queries and live tests to isolate component.

**Telemetry to check (priority order)**- Client-level: request IDs, client IPs, client version, User-Agent, geo/region, tenant IDs.- Edge/Load Balancer: LB request logs, error codes, backend health checks, connection resets, TLS handshake failures, LB metrics (5xx by backend/target), stickiness/session maps.- Network path: VPC flow logs, route table changes, NAT gateway/egress metrics, packet drops, retransmits, MTU issues.- Compute/service: instance/Pod CPU, memory, thread pools, recent deployments, JVM/GC logs, stack traces.- Cloud provider: provider status dashboard, API call failures, control-plane errors, regional outages, maintenance events.- Distributed tracing: trace from client to backend to find where 5xx generated.- Rate limiting/WAF: throttling logs, WAF blocks.

**Tests to run**- Synthetic requests: - From affected client IPs (or same region) and from unaffected regions to compare. - Vary payloads/endpoints to see if specific endpoints fail.- Health-check and direct backend hits: - Bypass LB to call backend instance/Pod directly (internal IP) to see if LB is involved.- LB configuration checks: - Check routing rules, target groups, timeouts, keepalive, max connections. - Reproduce with alternative LB or temporary rule to isolate.- Network diagnostics: - Ping/traceroute, tcpdump on frontends/backends, review VPC flow logs for RST/SYN issues.- Canary rollback/deploy: - If suspect regression, roll back recent deploy for subset and compare rates.- Provider verification: - Query provider status API, check service-specific incidents, confirm quotas or API throttles.

**How outcomes map to root causes**- Provider outage: provider status + widespread region metrics + control-plane errors.- Network misconfig: VPC flow logs show drops/RSTs, traceroute inconsistent, NAT/gateway errors.- LB bug: Direct backend OK but LB 5xx, LB logs show misrouted or connection errors; reproduces when LB in path.- Code regression: Traces show 5xx generated by app, errors rise after deploy, rollback fixes.

**Next steps**- Mitigate: route traffic away, increase capacity, temporary WAF rules, rollback.- Postmortem: timeline, root cause, monitoring gaps, runbooks and automated synthetic tests to catch recurrence.

HardTechnical

32 practiced

Architect an observability strategy for cloud infrastructure and microservices that correlates traces, metrics, logs and events. Explain data pipelines, sampling strategies, retention tiers, and how you would balance cost vs fidelity for production workloads.

Sample Answer

**Overview / goals**Design an end-to-end observability strategy that correlates traces, metrics, logs and events using OpenTelemetry (OTel), centralized ingestion, and layered retention to balance cost and fidelity for production cloud microservices.

**Data pipelines**- Instrument services with OTel SDKs (traces, metrics, logs) capturing resource attributes and a consistent trace_id for correlation.- Local agent (OTel Collector) for batching, enrichment (add Kubernetes/GCP/AWS metadata), sampling decisions, and exporting.- Export to managed backends: metrics → Prometheus remote-write / managed metrics (CloudWatch, GCM); traces/logs/events → vendor like Tempo + Loki/Elasticsearch or SaaS (Datadog, Honeycomb, New Relic) with object-store long-term archive (S3/GC Storage).

**Sampling strategies**- Head-based sampling default: 1–5% for traces to control volume.- Tail-based / adaptive sampling for errors/high-latency: keep 100% of traces with error tags, high p95 latency, or specific user transactions.- Dynamic sampling: increase fidelity during incidents via feature flags or on-demand trace retention (debug mode per service).- Metrics: high-cardinality metrics avoided; use aggregation at the Collector to reduce series.

**Retention tiers**- Hot (30d): full-resolution metrics, indexed logs, full traces for recent troubleshooting.- Warm (90d): downsampled metrics (1m → 5m), sampled traces, partial log indexes.- Cold/Archive (≥1yr): aggregated metrics and compressed logs/traces in object storage with metadata index for retrieval.

**Cost vs fidelity trade-offs**- Default low-sampling + preserve error/critical traces yields good signal-to-noise.- Aggregate metrics and use rollups to reduce Prometheus series costs.- Route verbose debug logs to separate lower-cost long-term storage; keep indexed logs only for hot window.- Use S3/Cloud Storage lifecycle policies and lifecycle rules for cost control.- Use alerts and automated runbooks to increase trace/log fidelity during incidents rather than globally.

**Correlation and use**- Ensure trace_id present in structured logs and metrics tags; enrich with cloud resource IDs, k8s pod, deployment, service version.- Provide quick pivot UI: trace → logs → metrics (via shared IDs and time windows).- Enforce schema and sampling config via CI to avoid uncontrolled cardinality.

**Example knobs / numbers**- Head sampling 2% global; preserve 100% of error traces and top 1% latency per-minute buckets.- Hot retention: metrics 30d, logs indexed 30d, traces 30d; warm: 90d aggregated; archive: 1+ year compressed.

This approach minimizes cost while keeping high-fidelity where it matters (errors/incidents), enables fast correlation, and scales across AWS/GCP production microservices.

HardTechnical

40 practiced

You have intermittent cross-AZ connectivity issues: instances in AZ-a can reach internet and other AZs' public endpoints, but cannot reach specific private services in AZ-b. Provide a deep troubleshooting checklist covering VPC configuration, route tables, subnet CIDRs, NACLs, security groups, instance kernel/network stack (MTU, iptables), and cloud provider control-plane issues to investigate.

Sample Answer

**Summary / approach**Systematically verify configuration from L3→L7 and control plane: confirm CIDR/routing, ACLs/security groups, instance OS/net stack, and provider-side issues. Work top-down and collect packet traces.

**VPC & AZ fundamentals**- Confirm correct VPC and peering/transit gateway attachments between AZs; ensure peering is active and routes propagated.- Verify overlapping CIDRs are not causing blackholes.

**Route tables**- Check route tables for subnets in AZ-a and AZ-b: explicit routes to destination CIDRs, next-hops (IGW, NAT, VGW, TGW, peering).- For peering/TGW: ensure no missing/filtered route propagation and no route priority conflicts.- Validate route table association per subnet (not default).

**Subnet CIDRs**- Ensure target private IPs are inside expected subnet CIDR.- Verify no overlapping or misassigned secondary CIDRs on ENIs.

**NACLs**- Inspect stateless NACLs on both source and destination subnets: - Confirm explicit allow entries for source/dest ports and ephemeral ranges. - Check rule ordering and explicit denies. - Validate both inbound and outbound directions.

**Security Groups**- Verify SGs on destination instances allow traffic from source CIDR/SG (for AWS, allow SG as source).- Check ephemeral port ranges for return traffic and stateful behavior.- Confirm no deny lists in cloud provider WAF/Network Firewall.

**Instance kernel / network stack**- On source and destination: - Check iptables/nftables for DROP rules, conntrack limits, and NAT rules. - Check sysctl (net.ipv4.ip_forward, rp_filter, net.core.rmem/wmem). - Inspect MTU mismatches (ping -M do -s) — look for fragmentation/drop across tunnels (VPN/TGW) or jumbo frames on ENIs. - Check interface statistics (ifconfig/ip -s link) for RX/TX errors, drops. - Review conntrack table size and TIME_WAIT exhaustion.

**Diagnostics / packet capture**- Use tcpdump/pcap on both ends and on transit appliances; capture SYN, SYN-ACK, ICMP unreachable.- Trace with traceroute/mtr (ICMP/TCP) to determine hop where flows stop.- Use cloud provider VPC flow logs / NSG flow logs to see accept/reject and 5-tuple records.

**Cloud control-plane & provider services**- Check provider status pages for regional/AZ incidents.- For managed routing (Transit Gateway, VPC peering, Azure vNets): verify attachment state, route propagation, ACLs at the gateway.- Inspect cloud audit logs for recent config changes (route, ACLs, security group updates, instance replacement).- If using ENI failover, confirm secondary ENIs’ attachment and MAC/IP assignments.

**Operational checks & remediation**- Reproduce with a bastion in same AZ as failing source and same AZ as working source to isolate AZ boundary.- Temporarily open NACLs/SGs to narrow fault, then reapply least-privilege.- If MTU implicated, lower MTU on interfaces or enable TCP MSS clamping on gateway.- Restart networking services, flush iptables/conntrack if safe.

**When to escalate**- If flow logs show accepted but packets drop mid-path — escalate to provider with timestamps, flow logs, packet captures, and traceroute output.

MediumTechnical

37 practiced

Design a caching strategy for a read-heavy database-backed API: choose cache hierarchy (edge, application cache, distributed cache), cache invalidation strategies (time-based, event-based, versioning), and approaches to prevent cache stampedes. Explain how you would measure cache effectiveness.

Sample Answer

**Approach summary**Design a multi-tier read cache: edge CDN for public, geo-cached responses → distributed cache (Redis Cluster/Elasticache) for shared app-level objects → in-process LRU for hot-per-request values. Use layered invalidation and stampede protections.

**Cache hierarchy**- Edge: CloudFront/Cloud CDN caching whole HTTP responses with cache-control + stale-while-revalidate for fast global reads.- Distributed: Redis cluster as primary shared cache for DB-derived objects (user profile, product catalog).- Application: local LRU (e.g., Caffeine) for microsecond access to very hot keys.

**Invalidation strategies**- Time-based TTL for most entries (shorter for volatile data).- Event-based eviction using DB change events: emit events (SNS/SQS or Redis keyspace notifications) on write; consumers invalidate/refresh cache.- Versioning: include data-version or ETag in key names for safe, atomic rollouts and to avoid racey invalidation.

**Preventing cache stampedes**- Cache-aside with single-writer lock (Redis SETNX with short TTL) so one process rebuilds while others serve stale.- Request coalescing: in-memory promise/future so concurrent requests wait for one load.- Probabilistic early refresh (refresh if TTL < 5% remaining) and add randomized jitter to TTLs to avoid synchronized expirations.- Serve slightly-stale data under heavy load (stale-while-revalidate) to keep latency bounded.

**How to measure effectiveness**- Metrics: cache hit/miss rate, origin requests/sec, p95/p99 latency for cache vs origin, error rate, backend DB QPS reduction, cost delta.- Instrumentation: export Redis INFO, CDN logs, application counters to CloudWatch/Prometheus; build dashboards and alerts (e.g., hit rate < 90%).- SLOs/KPIs: target hit rate, origin offload %, and p99 response time. Track stale-read percentage and eviction churn to tune TTLs.

Example: For product pages, use CloudFront 5-min TTL, Redis 10-min TTL with randomized jitter, update Redis on product edits via SNS event; use SETNX lock for rebuilds.

HardTechnical

29 practiced

You must optimize a high-throughput object storage workload that writes and reads hundreds of thousands of small objects per second. Explain strategies across client design, object key design (sharding/prefixes), batching, multipart requests, and consideration of choosing object storage vs block storage for specific patterns.

Sample Answer

**Approach summary**I’d optimize across three layers: client/service design, object key sharding, and request-level patterns (batching/multipart), and I’d choose storage type based on access pattern.

**Client design**- Use highly concurrent clients with connection pooling and HTTP/2 or gRPC where supported; keep sockets warm.- Implement exponential backoff with jitter for retries and circuit breakers to avoid thundering herd.- Rate-limit per-client to a target QPS and horizontally scale clients (stateless workers) behind a load coordinator.

**Object key design (sharding/prefixes)**- Ensure keys distribute across storage nodes: include high-cardinality entropy early (hash prefix, timestamp bucket + uid).- Avoid monotonically increasing prefixes (no timestamps-only as first token).- For S3: use pseudo-random first 2–4 chars or consistent hashing to even hot-spotting.- Monitor key distribution and adjust hash bucket count as throughput grows.

**Batching and multipart**- Aggregate small writes into larger payloads when possible (application-level bundling or protobuf/Avro blobs) to reduce object count.- Use server-side multipart uploads for larger logical objects: parallelize parts, tune part size (e.g., 8–64 MiB) to balance concurrency and overhead.- For reads, use range requests to pull only needed segments; cache at edge (CDN) or client-side.

**Choosing object vs block**- Use object storage for massive scale, eventual-consistency tolerant workloads, and infrequent small-object updates.- Use block storage (or distributed key-value/OPS like Redis, Cassandra, or a filesystem on EBS/EBS GP3) when low-latency, high IOPS for tiny random reads/writes and strong consistency are required.- Hybrid: store raw data in block/DB for hot small-item IOPS and tier to object storage for cold/archive.

**Operational**- Measure with CI load tests; monitor 99th-percentile latency, error rates, and storage node hot keys.- Automate dynamic sharding, client scaling, and lifecycle policies to control cost.

This combination balances throughput, latency, and cost for hundreds of thousands of small-object ops/sec.

Unlock Full Question Bank

Get access to hundreds of Cloud Infrastructure Knowledge (AWS/GCP/Azure) interview questions and detailed answers.

Join thousands of developers preparing for their dream job.