Cloud Platform Fundamentals Questions

Comprehensive understanding of core public cloud services and the primary trade offs when selecting among them across major providers such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform. Candidates should know compute options including virtual machines, managed compute, containers and serverless functions; storage types including object, block and file storage and lifecycle and archival strategies; managed database offerings for relational, non relational, and data warehouse workloads; networking fundamentals including virtual private networks, subnets, routing, load balancing, content delivery networks, and private connectivity; messaging and integration services such as message queues and event streaming; identity and access management and secrets management; monitoring, logging, and observability; autoscaling, elasticity, high availability, and basic disaster recovery patterns; and cost and pricing considerations. The topic also covers the trade offs between managed services and self managed infrastructure in terms of consistency, latency, cost, operational overhead, and durability, and the ability to map common workload requirements to the right service categories.

MediumTechnical

54 practiced

Compare managed Kubernetes services (EKS/GKE/AKS) to serverless container platforms (Fargate, Cloud Run). For each option list operational responsibilities, typical use cases, cost implications, scaling behavior, and how vendor lock-in and portability are affected. Recommend choices for bursty API services vs long-running stateful workloads.

Sample Answer

**Overview**Below compares managed K8s (EKS/GKE/AKS) vs serverless containers (Fargate, Cloud Run) across responsibilities, use cases, cost, scaling, portability, and recommendations.

**Operational responsibilities**- Managed K8s (EKS/GKE/AKS) - Cluster control plane managed; you manage node pools, CNI, ingress, RBAC, Helm, upgrades, autoscaling, monitoring, backup. - Responsible for pod scheduling, storage classes, CSI drivers, network policies.- Serverless containers (Fargate / Cloud Run) - Provider manages infra, OS, scaling, patching. You supply container image and config (concurrency, memory, env). - Limited platform ops (observability, IAM, CI/CD).

**Typical use cases**- Managed K8s: complex microservices, stateful apps (Databases, Kafka), custom networking, multi-workload clusters, infra requiring CRDs/operators.- Serverless containers: stateless HTTP APIs, event-driven jobs, ephemeral workers, webhooks, simple background tasks.

**Cost implications**- Managed K8s: pay for control plane (sometimes), and provisioned nodes (VMs) — may be inefficient at low utilization but good for high steady load via reserved/spot VMs.- Serverless containers: pay-per-use (CPU/memory-per-second). Often cheaper for bursty/low-utilization workloads; can be expensive for constant high CPU/memory.

**Scaling behavior**- Managed K8s: fine-grained control (HPA, VPA, Cluster Autoscaler). Can scale horizontally but node provisioning can add latency; can use node pools with mixed instance types and scale-to-zero is not native without addons.- Serverless containers: rapid autoscale including scale-to-zero (Cloud Run) and near-instant concurrency scaling (Cloud Run supports multiple requests per instance). Fargate scales fast but often has higher cold-starts and per-task latency.

**Vendor lock-in & portability**- Managed K8s: high portability (K8s API standard). Workload portability across clouds is strong; cluster configs, operators may reduce portability. More surface area but easier to move.- Serverless containers: higher lock-in to platform behaviors (request timeouts, IAM, logging, scaling semantics). Container image portability exists, but operational model often ties you to provider.

**Recommendations**- Bursty API services: prefer serverless containers (Cloud Run / Fargate) for rapid scale-to-zero, pay-per-use, simpler ops. Use Cloud Run for HTTP-heavy with concurrency needs; Fargate when deeper AWS integration or VPC-required.- Long-running stateful workloads: prefer managed K8s to run statefulsets, operators, persistent volumes, and custom networking. Optimize cost with reserved instances/spot and node autoscaling.

**Notes / Trade-offs**- Hybrid: run control-plane on K8s and front APIs on serverless for best of both worlds.- Consider observability, security posture, and compliance when choosing.

HardTechnical

42 practiced

After migrating an API to the cloud you observe median latency unchanged but the 95th percentile has spiked significantly. Provide a systematic troubleshooting plan: which metrics and traces you would inspect, how to correlate logs across LB, app, DB, and downstream services, and what short-term mitigations and long-term fixes you might deploy.

Sample Answer

**Situation summary & goal**Median latency stable but p95 jumped after cloud migration — focus: find high-tail causes, correlate across LB → app → DB → downstreams, apply mitigations to restore SLAs and plan fixes.

**Metrics & traces to inspect**- Load balancer: per-AZ connection counts, queue length, active connections, backend healthy/3xx/5xx, TLS handshake times.- App hosts: request rate, p50/p95/p99, CPU, memory, GC pauses, thread pool/utilization, accept queues, container restarts.- Network: packet drops, retransmits, ENI/bandwidth, cross-AZ latency, NAT/GW metrics.- DB: query p95, locks, slow queries, connection pool saturation, CPU/io wait, replication lag.- Downstream services: call latency, error rates, retry storms.- Traces: end-to-end distributed traces (sample p95), span duration distribution, dependency maps.

**How to correlate logs/traces**- Ensure a consistent trace-id propagated from LB (X-Request-ID / traceparent) through app to DB and downstreams.- Use structured logs with request_id, span_id, timestamps and host/instance-id.- Query traces at p95: find common slow spans (DB, external HTTP, GC, network).- Cross-match LB access logs (with request start) to trace-id to identify affected clients/AZs.

**Short-term mitigations**- Increase concurrency/timeouts (gracefully) to avoid queueing; enable circuit breakers and reduce retries.- Shift traffic away from noisy AZ/instance group (weighted LB routing / scale down unhealthy nodes).- Raise DB read replicas or enable caching (Redis) for hot endpoints.- Roll back recent infra changes (if indicative) or deploy temporary autoscaling policies.

**Long-term fixes**- Implement end-to-end distributed tracing and synthetic p95 monitoring.- Right-size instance types, tune GC/connection pools, and move latency-sensitive components to same AZ or use provisioned network throughput.- Optimize slow queries and add appropriate indexes; add caching layers.- Harden CI/CD to include performance regression tests and chaos testing for cross-AZ/network failures.

**Validation**- After fixes, measure p95 over rolling window, run load tests, and set alerts on p95/p99 with playbook entries for future incidents.

EasyTechnical

53 practiced

Describe the typical phases and high-level steps for migrating an on-premises monolithic web application to a public cloud. Cover discovery and assessment, choosing a migration pattern (rehost, replatform, refactor), data migration strategies, cutover/validation, and rollback considerations.

MediumTechnical

53 practiced

A microservices architecture needs asynchronous communication. Compare message queues (SQS, Azure Queue Service) with event streaming platforms (Kafka, Pub/Sub). Discuss delivery semantics, ordering, retention, consumer scaling, latency, and scenarios where each pattern is preferable.

HardTechnical

49 practiced

Compare serverless-managed databases (e.g., Aurora Serverless, Cloud SQL serverless) versus provisioned database clusters for highly spiky workloads. Discuss connection management, cold-warm scale behavior, cost predictability, pooling strategies (proxies), and architectural patterns to mitigate connection storms and latency spikes.

Sample Answer

**Approach summary**Compare managed serverless DBs vs provisioned clusters across connection management, cold/warm scaling, cost predictability, pooling/proxies, and architectural mitigations for spiky workloads — from a cloud engineer’s operational perspective.

**Connection management**- Serverless (Aurora Serverless v2 / Cloud SQL serverless): supports rapid horizontal capacity changes but historically limited concurrent connections per compute unit; connection creation can trigger scaling. - Provisioned clusters: fixed capacity and max_connections determined by instance size; connections are predictable but require right-sizing.

**Cold–warm scale behavior**- Serverless: cold starts when scaling from zero or small capacity -> added latency; v2 reduces granularity and latency vs v1 but spikes can still cause brief warm-up. - Provisioned: no cold-start; latency stable until CPU/memory saturation, then performance degrades.

**Cost predictability**- Serverless: pay-per-use reduces cost for infrequent spikes, but unpredictable burst volume can cause surprising bills. - Provisioned: steady predictable monthly cost; may be wasteful under low-utilization.

**Pooling strategies / proxies**- Use connection multiplexing/proxy (RDS Proxy, Cloud SQL Proxy, PgBouncer) to: - Reduce open connections to DB - Buffer bursts and reuse connections - Maintain long-lived pooled connections to avoid scale triggers- RDS Proxy for Aurora integrates with IAM and handles failover; recommend for Lambda + serverless DB combos.

**Architectural patterns to mitigate storms & latency spikes**- Client-side backpressure & retry with jitter and exponential backoff. - Queueing: put writes behind durable queues (SQS, Pub/Sub) to level spikes and apply worker pools. - Read scaling & caching: use read replicas + Redis/Cloud Memorystore for hot reads. - Warm pools / pre-warmed capacity: keep minimal provisioned instances or provisioned Aurora capacity units to avoid cold starts. - Circuit breaker and bulkhead patterns to avoid cascading failures. - Connection multiplexers (server-side or proxy) + controlled pool sizes in app containers/Lambdas to avoid connection storms.

**Practical recommendation**- For highly spiky but infrequent load: serverless DB + RDS Proxy + queueing + caching. - For sustained high peak with predictable traffic: provisioned cluster sized appropriately, read replicas, and connection pooling. - Monitor metrics (connections, scaling events, latency, cost), set alerts and run load tests to validate behavior.

Unlock Full Question Bank

Get access to hundreds of Cloud Platform Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.