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.

EasyTechnical

51 practiced

A client serves global static websites. Explain when to use a CDN and describe the benefits and limitations. Include cache-control strategies, TTLs, and how you would handle instant content invalidation after a content update from the client's CMS.

Sample Answer

When to use a CDN- Use a CDN whenever you serve static assets (HTML, CSS, JS, images, videos, fonts) to a global audience to reduce latency, offload origin traffic, improve availability, and scale under load (traffic spikes, DDoS mitigation).

Benefits- Latency: content served from edge PoPs close to users → lower RTT and faster TTFB.- Scalability & reliability: CDN absorbs spikes and provides failover.- Cost: reduced egress and origin compute.- Security: WAF, TLS termination, bot mitigation at edge.

Limitations- Cache staleness risk for frequently changing content.- Cache consistency across PoPs — propagation delays.- Dynamic content or personalized pages still require origin or edge logic (SSR, cookies).- Complexity: invalidation costs, configuration, debugging cache headers.

Cache-control strategies & TTLs- Immutable assets (content-hashed filenames): Cache-Control: public, max-age=31536000, immutable.- Versionable static assets: long TTLs + filename versioning.- Frequently updated assets (e.g., site shell): Cache-Control: public, max-age=60–300 depending on update frequency.- HTML pages with slight personalization: Cache-Control: public, s-maxage=60, stale-while-revalidate=30 to serve fast while refreshing in background.- Use s-maxage for CDNs separate from browser max-age; use Vary/Cache-Control carefully for cookies/auth.

Instant invalidation after CMS update- Preferred: Use atomic versioning/deployment — publish assets with content-hashed URLs or a version prefix (no invalidation needed).- If same URL must be updated: - Trigger CDN cache purge API per path or by tag immediately from the CMS publish hook. - Use CDN “surrogate keys” or tags to group assets and issue one purge by tag. - For critical HTML, set short s-maxage and leverage stale-while-revalidate to avoid cold misses. - As fallback, increment a global cache-busting query param (e.g., ?v=timestamp) injected by the CMS.

Operational best practices- Automate purge on CMS publish with retries and monitoring; verify purge via CDN headers (X-Cache).- Measure TTL hit/miss ratio and tune; prefer immutable long TTLs + versioning.- Document costs/limits for purge quotas with chosen CDN and design for them.

MediumTechnical

42 practiced

Global website needs cache invalidation and origin failover. Design CDN cache invalidation strategies for content updated frequently (e.g., product pages) and propose an origin failover plan if the primary origin becomes unavailable. Consider consistency, performance, and cost.

Sample Answer

Situation & goal: We need a global CDN strategy that keeps frequently-updated pages (product pages, pricing, inventory) reasonably consistent while minimizing latency and cost, and provides robust origin failover when the primary origin is down.

Cache invalidation strategy (consistency vs cost tradeoffs)- Cache-control + short TTLs: Serve product pages with Cache-Control: public, max-age=60–300s plus stale-while-revalidate to reduce origin load while keeping ~1–5 min freshness.- Conditional requests: Use ETag/Last-Modified so CDN/origin can validate quickly (304) instead of full payloads.- Origin-push notifications (recommended): On product update, publish an invalidation event to CDN via API or a pub/sub webhook (regional edge invalidation). Use targeted invalidation (by URL or surrogate-key) rather than full-pop to save cost.- Surrogate-keys / tagging: Attach keys like product:{id} to responses so you can invalidate all related objects with a single API call (e.g., update product image + page).- Progressive invalidation: First invalidate edge POPs closest to user segments affected, or invalidate low-traffic POPs less aggressively to save cost.- Read-through cache for dynamic fragments: Keep heavy static fragments cached long, assemble pages at edge using short-lived dynamic tokens (Edge Side Includes or edge compute) to balance performance and freshness.

Origin failover plan- Health checks + routing: Configure active health checks from CDN to primary origin; on failure, switch to secondary origin via CDN origin pool or via DNS with short TTL and health-aware load balancing.- Tiered origins: Primary origin (write-enabled) + read-replica origin(s) in multiple regions. Serve reads from replicas; writes go to primary via API gateway.- Stale-while-revalidate + serve-stale-on-error: If origin is down, allow CDNs to serve stale cached content (configurable TTL) to preserve availability; display a banner indicating potential stale data.- Data sync strategy: Use asynchronous replication from primary to read replicas with minimal lag (streaming/event-driven). For critical consistency (inventory), implement a fallback check: when serving stale content for checkout, validate inventory at checkout time via a direct origin call to a highly-available inventory microservice.- Failback: Once primary recovers, run reconciliation jobs and invalidate affected keys (surrogate-key) to ensure freshness.

Operational & cost considerations- Minimize global full invalidations; prefer surrogate-key and targeted invalidations.- Monitor metrics: cache hit ratio, origin-request rate, invalidation count/cost, failover frequency.- Safety valves: rate-limit automated invalidation requests; batch updates for high-volume changes (queue + debounce).- Playbooks & testing: Regularly run chaos tests for origin failover and rehearse invalidation flows.

This approach balances consistency (ETag, short TTLs, targeted invalidation), performance (edge caching, stale-while-revalidate, read replicas), and cost (avoid full purges, use surrogate-keys and short TTLs strategically).

MediumTechnical

48 practiced

Design a virtual network layout for a multi-AZ cloud deployment of a multi-tier application. Include VPC/VNet, public and private subnets, NAT/egress design, route tables, and security group recommendations. Explain how you would limit blast radius and provide secure administrative access while minimizing cross-AZ data transfer costs.

Sample Answer

Situation: Design a secure, cost-conscious multi-AZ virtual network for a multi-tier app.

Design (high level)- VPC/VNet: Single VPC spanning 3 AZs with a /20 CIDR (e.g., 10.0.0.0/20) subdivided per AZ.- Subnets (per AZ): - Public subnet (10.0.A.0/24): ALB, NAT if needed; route to Internet GW. - Private app subnet (10.0.B.0/24): application servers (autoscaling), no public IPs. - Private data subnet (10.0.C.0/24): databases, caches — highly restricted. - Optional isolated management subnet for jump hosts/SSM endpoints.- Route tables: - Public RT: 0.0.0.0/0 → Internet Gateway. - Private RTs: default → NAT Gateway in same AZ (see NAT design). DB subnets have no 0.0.0.0/0 to IGW.- NAT / egress: - Prefer one NAT Gateway per AZ to avoid cross-AZ egress charges and single-AZ outage risk. If cost is critical, a centralized NAT (single AZ) reduces NAT costs but increases cross-AZ traffic and outage risk—document the trade-off. - Use VPC endpoints (S3, DynamoDB) and Interface endpoints (Secrets Manager, ECR) to remove NAT for those services and reduce cost.- Security groups (examples): - ALB-SG: allow inbound 80/443 from 0.0.0.0/0. Outbound to App-SG on app ports. - App-SG: inbound from ALB-SG (port 8080), outbound to DB-SG on DB port. - DB-SG: inbound only from App-SG (3306/5432), outbound restricted. - Management-SG: allow SSH/RDP only from corporate VPN IP CIDR and/or SSM. Deny wide inbound.- Network ACLs: Optional stateless layer to block known bad IP ranges; keep permissive rules for subnet-level debugging.

Limiting blast radius- AZ isolation: place app and DB instances in AZ-local private subnets and prefer AZ affinity in the app layer so inter-tier traffic stays intra-AZ when possible.- Least privilege SGs and separate subnets for different trust levels.- Use separate VPCs/Accounts for prod vs non-prod and transit VPC/peering or Transit Gateway.- Use DB read-replicas in other AZs but write-primary in one AZ to limit writes’ cross-AZ traffic where appropriate.

Secure administrative access- Don't open SSH/RDP to internet. Use AWS Systems Manager Session Manager (SSM) for shell access (agent + IAM), or a highly restricted bastion host in each AZ that requires MFA and client certs.- Provide admin network access via VPN or AWS Client VPN with MFA, or SAML-based access to console.- Centralize logs: Flow logs, VPC Flow Logs to S3/CloudWatch, GuardDuty, and Config for auditing.

Minimize cross-AZ data transfer costs- One NAT per AZ prevents NAT cross-AZ egress.- Use VPC endpoints to keep traffic to S3/Dynamo/other services within AZ or region free of NAT.- If possible, design app to prefer AZ-local read/write: use ALB target group with AZ-aware routing and instance registration per AZ so client connections and subsequent app→DB calls stay within same AZ.- Use regional-managed services (RDS with Multi-AZ for HA but be mindful of cross-AZ replication costs) — if cost-sensitive, consider single-AZ RDS with read replicas in same AZ groups or async replication.

Trade-offs & summary- High availability + low blast radius: per-AZ NAT + per-AZ subnets + VPC endpoints — higher cost, lower risk and lower cross-AZ egress.- Cost-optimized: fewer NATs, more use of endpoints, but accept cross-AZ egress and single-AZ NAT single point of failure.This layout balances security, availability, and cross-AZ cost by combining per-AZ isolation, least-privilege security groups, endpoint usage, and SSM-based admin access.

EasyTechnical

54 practiced

Define high availability (HA) and disaster recovery (DR). As a Solutions Architect advising a mid-size e-commerce client, explain RTO and RPO and provide two HA patterns and two DR patterns suitable for their checkout service with an availability target of 99.95%. Include quick trade-offs.

Sample Answer

High availability (HA) means designing systems to remain operational with minimal downtime by removing single points of failure and enabling automatic failover. Disaster recovery (DR) is the set of processes, sites, backups and runbooks to recover from large-scale failures (region outage, data corruption, catastrophic events).

RTO (Recovery Time Objective): maximum acceptable time to restore service after an outage. RPO (Recovery Point Objective): maximum acceptable data loss (how far back backups can be) measured in time.

For a checkout service targeting 99.95% availability (~4.38 minutes downtime/month), two HA patterns:

1) Active-active multi-AZ deployment- Description: Deploy identical checkout instances across multiple availability zones behind a load balancer; use replicated session store (Redis) and a strongly consistent DB with cross-AZ replicas.- Trade-offs: Low latency failover and near-continuous availability; higher cost and complexity (cross-AZ replication, distributed cache consistency).

2) Blue-green with automated failover- Description: Maintain two production environments; route traffic to green; if green degrades, switch to blue via load balancer/DNS with health checks.- Trade-offs: Fast rollback and testing; requires duplicate infrastructure (cost) and careful database migration strategy.

Two DR patterns:

1) Warm-standby in another region- Description: A smaller but running instance of the checkout stack in a different region with continuous data replication (async or near-sync); scale up on failover.- Trade-offs: Faster recovery (RTO minutes to hours) and lower cost than hot; potential data loss depending on replication (RPO depends on replication lag).

2) Backup & restore (cold DR)- Description: Regular full and incremental backups stored offsite (object storage), infrastructure as code to rebuild in target region, restore DB from backups when needed.- Trade-offs: Lowest cost; longer RTO (hours to days) and higher RPO (depends on backup frequency) — acceptable for non-critical data but risky for checkout.

Recommendation: For checkout with 99.95% SLA, combine active-active HA across AZs + warm-standby DR in another region. Set RTO target <= 5 minutes and RPO <= 1 minute for payments/session-critical flows; accept longer RTO/RPO for non-essential analytics. Implement automated health checks, runbooks, regular DR drills, and continuous replication monitoring.

HardTechnical

52 practiced

For a petabyte-scale analytics platform, compare managed columnar warehouses (e.g., Redshift, BigQuery, Snowflake) versus running a self-managed Hadoop/Spark cluster on VMs. Focus on cost predictability, performance tuning, operational effort, durability and data ingestion patterns. Make a recommendation for a client that needs ad-hoc queries and scheduled ETL.

Sample Answer

Requirements clarification:- Petabyte-scale data, ad-hoc SQL queries + scheduled ETL, prioritize cost predictability, performance, low ops overhead, durability, varied ingestion (stream + batch).

Comparison summary:

1) Cost predictability- Managed warehouses: predictable pricing models (storage separate from compute in Snowflake/BigQuery), pay-per-use for ad-hoc spikes; easier to forecast but can surprise with heavy egress or long-running interactive queries.- Self-managed Spark/Hadoop: more predictable fixed VM/cluster costs if always-on, but utilization variability wastes money; autoscaling helps but adds complexity.

2) Performance tuning- Managed: automatic optimizations (vectorized columnar execution, automatic stats, materialized views, adaptive caching). Good for ad-hoc SQL; fewer knobs.- Self-managed: fine-grained control (custom executors, shuffle tuning, specialized formats like ORC/Parquet, custom caching), potentially better for complex ETL and ML but requires expert tuning.

3) Operational effort- Managed: minimal ops — backups, upgrades, scaling mostly handled. Faster time-to-value.- Self-managed: significant ops — cluster provisioning, patching, HDFS durability concerns, monitoring, and tuning.

4) Durability and data ingestion- Managed: strong durability guarantees, built-in replication, easy streaming ingestion (native connectors), transactional ingestion patterns vary by vendor.- Self-managed: flexible ingestion pipelines (Kafka → Spark), can guarantee end-to-end exactly-once with effort; durability depends on storage choice (HDFS vs object store).

Recommendation:For a client needing petabyte analytics with ad-hoc queries plus scheduled ETL and wanting low ops and predictable performance, choose a managed columnar warehouse (Snowflake or BigQuery). Rationale: best trade-off for fast ad-hoc SQL, automatic performance optimizations, low operational burden, and scalable storage/compute separation to control costs. Use object storage (S3/GCS) as raw landing zone, ETL with serverless or managed Spark (Dataproc/EMR on demand) for heavy transformations into optimized columnar tables, and leverage partitioning/clustering and cost controls (query quotas, materialized views) to limit spending. Opt for self-managed only if you require deep custom processing, specialized ML workloads, or strict cost controls and have an experienced ops team.

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.