69 Cloud Computing Interview Questions and Answers (2026)

They are the three classic cloud service models, distinguished by how much of the stack the provider manages versus you: IaaS gives raw infrastructure, PaaS gives a managed platform to run code, and SaaS gives finished software you just use.

• IaaS (Infrastructure as a Service):

  • Provider manages hardware, networking, virtualization; you manage OS, runtime, apps (e.g. EC2, Compute Engine).

  • Choose it when you need maximum control and flexibility (custom OS, legacy migration, lift-and-shift).

• PaaS (Platform as a Service):

  • Provider also manages OS, runtime, scaling; you deploy just code and data (e.g. App Engine, Heroku).

  • Choose it when you want fast development without ops overhead and can accept less control.

• SaaS (Software as a Service):

  • Provider manages everything; you consume the app via browser/API (e.g. Gmail, Salesforce).

  • Choose it when a ready-made solution fits and you want zero maintenance.

• Rule of thumb: more control and responsibility as you move IaaS -> PaaS -> SaaS gives less; pick the least you have to manage that still meets your requirements.

CapEx (capital expenditure) is large upfront spending on assets you own like servers and data centers; OpEx (operational expenditure) is ongoing pay-as-you-go spending. Moving to the cloud shifts IT spending from CapEx to OpEx: instead of buying hardware, you rent capacity and expense it as you consume it.

• CapEx:

  • Buy hardware up front, depreciate it over years, plan capacity ahead of demand.

  • Risk: over-provisioning (wasted spend) or under-provisioning (outages).

• OpEx:

  • Pay only for what you use, monthly; scale up or down with demand.

  • Lowers barrier to entry, no big upfront investment.

• The financial shift:

  • Frees capital, aligns cost with usage, and turns capacity planning into elastic scaling.

  • Caveat: OpEx can sprawl without governance (FinOps, tagging, budgets) since spending is easy and continuous.

NIST defines five essential characteristics that a service must have to be considered true cloud computing: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

• On-demand self-service: Provision resources automatically without human interaction from the provider.

• Broad network access: Available over the network via standard mechanisms, from any device.

• Resource pooling: Multi-tenant pooling of resources, dynamically assigned; customers are location-independent.

• Rapid elasticity: Capacity scales out and in quickly, appearing effectively unlimited to the consumer.

• Measured service: Usage is metered, monitored, and reported, enabling pay-per-use billing.

A cloud-native application is designed from the start to exploit cloud characteristics (elasticity, resilience, automation) rather than just being lifted onto a VM: it's typically built as loosely coupled services, packaged in containers, and deployed through automated pipelines onto managed platforms.

• Microservices / loose coupling: Small independently deployable services rather than one monolith, so parts scale and evolve separately.

• Containers and orchestration: Packaged with dependencies (Docker) and run on orchestrators like Kubernetes for portability and self-healing.

• Designed for failure and scale: Stateless where possible, horizontally scalable, resilient to instance loss (the twelve-factor mindset).

• Automation and DevOps: CI/CD, infrastructure as code, and observability make deployments frequent and reliable.

• Contrast: not just running old software in the cloud (lift-and-shift); cloud-native embraces the platform's elasticity and managed services.

Cloud computing is the on-demand delivery of IT resources (compute, storage, networking, services) over the internet with pay-as-you-go pricing, so you rent capacity instead of buying and running your own data centers.

• Core idea: Self-service, elastic resources managed by a provider (AWS, Azure, GCP); you consume via APIs or a console.

• Benefits:

  • No large upfront capital: shift CapEx to OpEx, pay only for what you use.

  • Elasticity: scale up/down in minutes to match demand.

  • Global reach and speed: deploy across regions quickly; the provider handles undifferentiated heavy lifting (hardware, patching).

• Drawbacks:

  • Cost unpredictability: pay-per-use can exceed on-prem for steady, predictable workloads.

  • Vendor lock-in: proprietary services make migration hard.

  • Reduced control and shared-responsibility risk: you depend on provider security, uptime, and compliance boundaries.

Resource pooling means the provider aggregates its physical compute, storage, and network into a shared pool that many tenants draw from, with resources dynamically assigned and reassigned on demand. Serving many customers from shared infrastructure is what unlocks economies of scale.

• How pooling works:

  • Multi-tenancy: many customers' workloads run on the same physical hardware, isolated by virtualization.

  • Location independence: customers don't know or control exactly which physical machine serves them.

• Why it enables economies of scale:

  • Higher utilization: pooling smooths out individual demand spikes, so expensive hardware sits idle less often.

  • Bulk purchasing: buying hardware, power, and bandwidth at massive volume lowers unit cost.

  • Amortized operations: staffing, patching, and cooling costs are spread across millions of tenants.

• Result: Lower per-unit prices passed to customers, plus elasticity because the shared pool absorbs bursts.

XaaS (Anything-as-a-Service) is an umbrella term for delivering virtually any IT capability as an on-demand, subscription cloud service, not just the classic three layers. The idea is that almost any function can be abstracted and consumed remotely instead of owned.

• The classic three: IaaS (infrastructure), PaaS (platform), SaaS (software): the spectrum from raw VMs to fully managed apps.

• Examples beyond the big three:

  • FaaS (Function-as-a-Service): run code without managing servers (AWS Lambda).

  • DBaaS (Database-as-a-Service): managed databases (Amazon RDS).

  • DaaS (Desktop-as-a-Service): virtual desktops delivered remotely.

  • CaaS (Containers-as-a-Service): managed container orchestration.

  • Other niches: Storage-as-a-Service, Security-as-a-Service, Communications-as-a-Service.

• Common thread: Provider manages the underlying complexity; you consume via API/subscription and pay for usage.

Modern cloud is the culmination of decades of ideas: the notion of computing as a utility, the pooling model of grid computing, and the hardware abstraction of virtualization that finally made it economical and self-service.

1. Utility computing (concept, 1960s onward): John McCarthy's vision of computing sold like electricity or water, metered and on demand; time-sharing mainframes were an early form.

2. Grid computing: Networked, often geographically distributed machines pooled to work on large jobs; introduced shared, distributed resource pools.

3. Virtualization (the enabler): Hypervisors let one physical server run many isolated VMs, driving high utilization and rapid, automated provisioning.

4. Modern public cloud (mid-2000s onward):

   • AWS launched S3 and EC2 (2006), packaging virtualization + utility pricing + self-service APIs into true on-demand IaaS.

   • Evolution continued upward: PaaS, SaaS, containers, and serverless (FaaS) abstracting ever more of the stack.

On-premises means you own and operate the infrastructure for maximum control at high upfront cost; public cloud means you rent shared, managed infrastructure for elasticity and speed while ceding some control. The right choice depends on workload predictability, compliance, and cost profile.

• Cost model:

  • On-prem: large CapEx, but potentially cheaper for steady, predictable long-term workloads.

  • Cloud: OpEx pay-per-use, great for variable demand but can get expensive at constant high scale.

• Scalability and speed:

  • On-prem: scaling means buying and racking hardware (weeks/months).

  • Cloud: near-instant elastic scaling via API.

• Control and security:

  • On-prem: full control over hardware, data locality, and compliance; you bear all maintenance.

  • Cloud: shared responsibility model; provider handles infrastructure but you trust their controls.

• Maintenance: On-prem: you patch, cool, power, and staff; cloud offloads that undifferentiated work.

They differ in how data is addressed and structured: object storage handles data as flat, self-contained objects; block storage exposes raw volumes split into fixed blocks; file storage presents a hierarchical filesystem shared over the network.

• Object Storage:

  • Data stored as objects (data + metadata + unique ID) in a flat namespace, accessed via HTTP APIs (e.g. S3).

  • Massively scalable and cheap; not editable in place (you replace whole objects).

  • Use for: backups, media, static assets, data lakes, unstructured data.

• Block Storage:

  • Raw volumes attached to a single VM, formatted with a filesystem by the OS (e.g. EBS).

  • Low latency, high IOPS; typically one attachment at a time.

  • Use for: databases, boot disks, transactional workloads needing fast random read/write.

• File Storage:

  • Hierarchical files/folders shared over protocols like NFS or SMB (e.g. EFS).

  • Multiple clients mount and share it concurrently.

  • Use for: shared drives, content management, legacy apps expecting a POSIX filesystem.

Infrastructure as Code is the practice of defining and provisioning infrastructure (networks, VMs, databases, permissions) through machine-readable declarative files kept in version control, rather than clicking through a console. It makes environments reproducible, reviewable, and automatable.

• How it works:

  • Declarative tools (e.g. Terraform, CloudFormation) describe the desired end state; the tool reconciles reality to match.

  • Often idempotent: applying the same config repeatedly yields the same result.

• Why it beats manual config:

  • Reproducibility: spin up identical dev/staging/prod, avoiding drift and "works on my environment."

  • Version control: changes are reviewed via pull requests, audited, and rolled back like code.

  • Speed and scale: rebuild an entire environment or DR site in minutes.

  • Documentation: the code itself is the source of truth for what's deployed.

• Caveat: Manual changes outside IaC cause state drift; enforce that all changes go through the code.

Both provide isolated environments to run software, but VMs virtualize hardware (each carries a full guest OS) while containers virtualize the OS (they share the host kernel and package only the app and its dependencies). Containers are lighter, faster, and more portable, which aligns with cloud-native elasticity.

• Virtual Machines:

  • A hypervisor runs multiple guest OSes on one physical host; each VM has its own kernel, so isolation is strong.

  • Heavier: gigabytes in size, boot in seconds to minutes, more resource overhead per instance.

• Containers:

  • Share the host kernel; isolated via namespaces and cgroups rather than a separate OS.

  • Lightweight: megabytes, start in milliseconds, higher density per host.

• Why containers are more cloud-native:

  • Fast start and small footprint enable rapid autoscaling and packing many workloads per node.

  • Immutable images give consistent behavior across dev, test, and prod.

  • They pair naturally with orchestration (Kubernetes) and microservices patterns.

• Trade-off: weaker kernel-level isolation than VMs, so multi-tenant security may still use VMs underneath or hardened runtimes.

Authentication (AuthN) verifies who you are; authorization (AuthZ) determines what you are allowed to do. Authentication always comes first, then authorization decides access to specific resources.

• Authentication (who you are):

  • Proves identity via credentials: passwords, keys, tokens, certificates, or MFA.

  • Result is a verified principal (a user, role, or service).

• Authorization (what you can do):

  • Evaluates policies/permissions to allow or deny actions on resources.

  • Implemented through models like RBAC (roles) or ABAC (attribute-based), following least privilege.

• Order and analogy:

  • Like an airport: your passport authenticates you; your boarding pass authorizes you onto a specific flight.

  • You can be authenticated but not authorized (valid login, access denied).

Pay-as-you-go (also called measured or metered service) means you are billed only for the resources you actually consume, metered by units like compute-seconds, GB stored, or requests, instead of paying a fixed price for fixed capacity.

• What it means:

  • The provider meters usage and charges per unit; idle capacity you shut down stops costing money.

  • Shifts spend from CapEx (buy hardware upfront) to OpEx (variable operating cost).

• How it changes architecture:

  • Design to scale down: turn off dev/test environments, scale to zero where possible (serverless).

  • Cost becomes a design constraint: chatty APIs, over-provisioned instances, and unbounded data egress directly raise the bill.

  • Favor event-driven and serverless models (e.g. functions) where you pay per invocation rather than for always-on servers.

  • Watch metered dimensions that surprise you: network egress, API request counts, storage read/write operations.

• Trade-off: per-unit rates are higher than committed capacity, so steady predictable load may be cheaper on reserved/committed pricing.

Horizontal scaling (scale out/in) adds or removes instances of a resource; vertical scaling (scale up/down) makes a single instance bigger or smaller. Cloud-native systems generally prefer horizontal scaling because it offers near-limitless growth and better fault tolerance.

• Vertical scaling:

  • Add more CPU/RAM to one machine; simple, no app changes, but bounded by the largest machine available.

  • Often requires downtime to resize and remains a single point of failure.

• Horizontal scaling:

  • Add more machines behind a load balancer; capacity scales almost linearly and one node failing doesn't take the system down.

  • Enables elasticity and rolling deploys with zero downtime.

• Why cloud-native prefers horizontal:

  • Better resilience, effectively unlimited scale, and it matches commodity/ephemeral instances.

  • Requirement: the workload should be stateless (externalize session/state) so any instance can serve any request.

The Shared Responsibility Model divides security duties between the cloud provider and the customer: the provider secures the cloud (underlying infrastructure), while the customer secures what they put in the cloud (data, access, configuration). Exactly where the line falls depends on the service model.

• Always the provider: Physical data centers, hardware, host virtualization, and the network backbone.

• Always the customer: Their own data, identity and access management (who can do what), and correct configuration of the services they enable.

• IaaS (e.g. virtual machines): Provider handles hardware and hypervisor; customer manages the OS, patching, runtime, applications, and data.

• SaaS (e.g. a hosted email app): Provider manages nearly the whole stack including the application; customer's responsibility shrinks to their data, user access, and app-level settings.

• Rule of thumb: The more managed the service (IaaS → PaaS → SaaS), the less the customer owns, but data and access control are never the provider's job.

A CDN is a geographically distributed network of edge servers that cache and serve content close to users, cutting latency and offloading the origin. Instead of every request traveling to one origin server, users hit a nearby edge node.

• Reduces latency by proximity: Content is served from an edge location near the user, so round-trip time drops.

• Offloads the origin: Cached responses are served by the edge, so the origin handles far fewer requests and scales better under spikes.

• Caches static (and cacheable dynamic) content: Images, JS, CSS, video are ideal; freshness is controlled with headers like Cache-Control and TTLs.

• Network and protocol optimizations: Persistent connections, TLS termination at the edge, HTTP/2, and optimized backbone routing to the origin.

• Resilience and security: Absorbs traffic surges and DDoS at the edge, and can serve stale content if the origin is down.

FaaS lets you deploy individual functions that the provider runs and scales on demand, billing only for actual execution: it's the compute model behind serverless (e.g. AWS Lambda). Unlike PaaS, there is no always-on app or server you provision.

• Event-driven and ephemeral: Functions run in response to triggers (HTTP, queue, file upload) and terminate when done.

• Scale to zero: No traffic means no running instances and no cost; PaaS typically keeps at least one instance alive.

• Granular billing: You pay per invocation and execution time (ms), not for reserved capacity.

• Difference from PaaS:

  • PaaS deploys a whole app/process you still think of as running; FaaS deploys stateless functions the platform spins up per event.

  • Trade-offs: cold starts, execution time limits, and statelessness force external stores for state.

These deployment models differ by who owns the infrastructure and who shares it: public cloud is shared multi-tenant infrastructure owned by a provider, private cloud is dedicated to a single organization, and hybrid combines both with connectivity between them.

• Public cloud: Provider-owned, multi-tenant, pay-as-you-go (AWS, Azure, GCP); elastic and low upfront cost.

• Private cloud: Single-tenant infrastructure, on-prem or hosted; more control, security, and customization, higher cost.

• Hybrid cloud: Mix of both, letting sensitive workloads stay private while bursting or scaling to public.

• When to choose private over public:

  • Strict regulatory/data-residency needs (healthcare, banking, government) or data that legally cannot sit on shared infrastructure.

  • Predictable heavy workloads where owned hardware is cheaper long-term, or a need for full control over security and configuration.

A community cloud is infrastructure shared by several organizations that have common concerns (security, compliance, mission), sitting conceptually between private and public: costs are shared across the group but access is limited to its members.

• Shared by a defined community: Multiple organizations with the same regulatory or operational requirements pool a common environment.

• Governed by shared policy: Managed by the members, a third party, or jointly; tailored to the community's compliance rules.

• When it's used:

  • Government agencies sharing a compliant platform, hospitals under the same health regulations, or banks meeting common financial standards.

  • Attractive when private cloud is too costly for one org alone but public cloud can't meet the shared compliance bar.

Managed (PaaS) services are capabilities where the provider handles the operational heavy lifting (provisioning, patching, scaling, backups, high availability) so you consume the feature via an API rather than running it yourself: examples are RDS, DynamoDB, or managed Kafka.

• What you offload: Undifferentiated ops: OS patching, version upgrades, failover, backups, capacity planning.

• Benefits: Faster time to market, less ops staff, built-in reliability and scaling.

• Trade-offs:

  • Less control: limited config, versions, or tuning knobs the service doesn't expose.

  • Cost can exceed self-hosting at large scale, and pricing is opaque.

  • Vendor lock-in via proprietary APIs and features.

• Rule of thumb: managed unless you have a strong reason (extreme scale economics, deep customization, or portability) to self-manage.

A hypervisor (or Virtual Machine Monitor) is software that creates and runs virtual machines by abstracting physical hardware and allocating it among multiple isolated guest VMs. Type 1 runs directly on the hardware; Type 2 runs on top of a host operating system.

• Type 1 (bare-metal):

  • Installed directly on physical hardware, acting as a thin OS itself (examples: VMware ESXi, Xen, KVM, Microsoft Hyper-V).

  • Better performance, isolation, and security; used by cloud providers for production workloads.

• Type 2 (hosted):

  • Runs as an application on top of a host OS (examples: VirtualBox, VMware Workstation).

  • Easier to set up but incurs extra overhead from the host OS layer; suited to development and desktop use.

• Key difference: It's about the layer below the hypervisor: Type 1 sits on hardware, Type 2 sits on an OS, which affects speed and overhead.

Encryption at rest protects data stored on disk (databases, object storage, backups) so a stolen drive is useless; encryption in transit protects data moving over a network (typically via TLS) so it can't be sniffed or tampered with. In managed cloud services the provider usually handles the encryption mechanics, but who controls the keys is configurable.

• Encryption at rest:

  • Data encrypted when written to storage, decrypted on read; defends against physical theft and improper disk disposal.

  • Often uses symmetric algorithms like AES-256.

• Encryption in transit: Data encrypted while crossing networks using TLS/HTTPS; defends against eavesdropping and man-in-the-middle attacks.

• Key management:

  • By default the provider manages keys transparently via a key service (AWS KMS, Azure Key Vault, Cloud KMS).

  • For more control you can use customer-managed keys (CMK) or bring-your-own-key (BYOK) to own rotation and revocation.

The Principle of Least Privilege says every user, service, or process should be granted only the minimum permissions needed to do its job, and nothing more. In IAM this shrinks the attack surface: a compromised credential can do only limited damage.

• Core idea: Default deny: start with no access, then grant specific, scoped permissions as needed.

• How it's applied in IAM:

  • Fine-grained policies: allow specific actions on specific resources, not broad wildcards like "*".

  • Roles over long-lived keys: apps assume temporary, scoped roles (IAM roles) instead of embedding permanent credentials.

  • Group and role-based assignment: attach permissions to roles/groups for consistency, not ad hoc to individuals.

• Ongoing practice:

  • Regularly audit and prune unused permissions; use access analyzers to right-size grants.

  • Add just-in-time elevation for occasional privileged tasks rather than standing admin rights.

• Benefit: Limits blast radius of breaches, insider mistakes, and misconfigurations.

Durability is the probability your data won't be lost or corrupted over time; availability is the probability you can access it right now. Data can be perfectly durable yet temporarily unavailable, and vice versa.

• Durability:

  • "Will my data survive?" Measured in nines of retention (e.g. S3's 11 nines, 99.999999999%).

  • Achieved by replicating data across multiple devices/AZs and checksumming/self-healing.

• Availability:

  • "Can I read/write it right now?" Measured in uptime nines (e.g. 99.99%).

  • Affected by outages, network partitions, or throttling, even when data is intact.

• Why the distinction matters:

  • An archive tier can be extremely durable but low availability (retrieval takes hours).

  • They have separate SLAs: choose a storage class by both, not one.

Storage tiering places data in classes with different cost/performance trade-offs based on how frequently it's accessed: hot for frequent access, cold for infrequent, archive for rarely-touched long-term retention. You save money by matching data's access pattern to the cheapest tier that still meets your needs.

• Hot:

  • Highest storage price, lowest access cost and latency (milliseconds).

  • Use for: actively served data, live application content.

• Cold:

  • Cheaper to store, but higher retrieval fees and often a minimum storage duration.

  • Use for: backups, older logs, data accessed a few times a year.

• Archive:

  • Cheapest storage, retrieval may take minutes to hours and cost the most.

  • Use for: compliance/legal retention rarely read (e.g. Glacier).

• How it optimizes cost:

  • Lifecycle policies auto-transition objects as they age (hot then cold then archive).

  • Watch retrieval fees and minimum-duration charges: cheap-to-store isn't cheap if you read it often.

They are three layers of the same reliability story: an SLI is the measurement, an SLO is the internal target for that measurement, and an SLA is the external contract (with penalties) built around it.

• SLI (Service Level Indicator):

  • A quantitative measure of service behavior, e.g. request latency, error rate, or availability percentage.

  • The raw signal you actually collect from the system.

• SLO (Service Level Objective):

  • An internal target on an SLI, e.g. 99.9% of requests succeed over 30 days.

  • Drives engineering decisions and the error budget (how much unreliability you can spend).

• SLA (Service Level Agreement):

  • A formal contract with customers promising a level of service, with consequences (credits, refunds) if missed.

  • Usually set looser than the internal SLO so you have a safety margin before breaching the contract.

• Relationship: SLI is measured, SLO sets the goal, SLA is the promise. SLA is typically weaker than SLO by design.

They are sets of legal or industry standards that govern how data must be protected, processed, and audited. They matter because responsibility is shared: the provider certifies its infrastructure, but you remain accountable for how you use it, so a provider's certifications determine whether you can legally build compliant workloads on it.

• GDPR:

  • EU regulation on personal data: consent, right to erasure, breach notification, and data residency requirements.

  • Applies to anyone handling EU residents' data, regardless of company location.

• HIPAA:

  • US healthcare law protecting patient health information (PHI); requires safeguards and audit controls.

  • Providers must sign a Business Associate Agreement (BAA) for you to store PHI with them.

• SOC 2:

  • An audit report on controls for security, availability, confidentiality, processing integrity, and privacy.

  • Common evidence when vetting a SaaS vendor's trustworthiness.

• Why it drives provider choice:

  • Under the shared responsibility model, the provider covers infrastructure controls and offers compliant services/regions; you configure them correctly.

  • Missing certifications or region options can be an outright blocker for regulated industries.

Observability is the ability to understand a system's internal state from its external outputs, so you can answer questions you didn't anticipate (not just watch predefined dashboards). Its three pillars are logs, metrics, and traces, each answering a different question.

• Logs:

  • Discrete, timestamped event records; great for detailed context on what happened.

  • Best structured (JSON) so they're queryable; can be high volume and costly at scale.

• Metrics:

  • Numeric time-series aggregates (CPU, request rate, error rate, latency percentiles).

  • Cheap to store and ideal for dashboards and alerting on trends.

• Traces:

  • Follow a single request across services via a shared trace/span ID.

  • Reveal where latency and failures occur in distributed/microservice flows.

• Observability vs monitoring: Monitoring watches known failure modes; observability lets you explore unknown ones by correlating all three signals.

Container orchestration automates deploying, scaling, networking, and healing containers across a cluster of machines, so you declare the desired state and the platform (e.g. Kubernetes) continuously works to maintain it. It's valuable in the cloud because it turns many ephemeral containers on many nodes into one reliable, self-managing system.

• What it manages:

  • Scheduling: placing containers on nodes based on resources and constraints.

  • Self-healing: restarting failed containers and rescheduling off dead nodes.

  • Scaling: adding/removing replicas to match load.

  • Networking and service discovery: stable endpoints and load balancing across replicas.

  • Rollouts: rolling updates and rollbacks without downtime.

• Why it fits the cloud:

  • Declarative desired state matches elastic, disposable infrastructure where nodes come and go.

  • Abstracts underlying machines, improving utilization and portability across providers.

  • Reduces manual ops, enabling reliable operation of microservices at scale.

A stateless application keeps no client session data between requests: each request is self-contained, so any instance can handle it. A stateful application retains data locally across interactions, tying a client to a specific instance. The cloud favors stateless app tiers because they scale and recover far more easily.

• Stateless:

  • No memory of prior requests; any needed state is passed in or fetched from an external store.

  • Instances are interchangeable, so requests can be freely load balanced.

• Stateful:

  • Holds data locally (in-memory sessions, local files) that persists across requests.

  • Often needs sticky sessions and careful data replication (databases, caches are legitimately stateful).

• Why the cloud favors stateless app tiers:

  • Horizontal scaling: just add or remove identical instances behind a load balancer.

  • Resilience: losing an instance loses no session data, so self-healing and autoscaling work cleanly.

  • Pattern: push state outward to managed stores (databases, Redis, object storage) and keep compute stateless.

The Twelve-Factor App is a set of best practices for building software-as-a-service that is portable, scalable, and easy to deploy on cloud platforms. It emphasizes clean separation of config from code, statelessness, and disposability.

• Representative factors:

  • Codebase: one tracked repo, many deploys.

  • Config: store config in the environment, not in code.

  • Backing services: treat databases, queues, caches as attached resources swappable by URL.

  • Processes: run the app as stateless processes; persist state in backing services.

  • Port binding, concurrency, disposability: self-contained, scale out by process, start/stop fast.

  • Dev/prod parity and logs as event streams.

• Why it matters for the cloud:

  • Statelessness enables horizontal scaling and disposable instances (design for failure).

  • Config in the environment lets one artifact promote across dev/staging/prod.

  • It maps naturally to containers, orchestrators, and CI/CD pipelines.

Sticky sessions (session affinity) make a load balancer route a given user's requests always to the same backend instance, usually because that instance holds their session state in memory. This ties users to specific servers, which conflicts with cloud elasticity.

• How they work: The balancer pins a client to a node via a cookie or source IP so in-memory session data stays available.

• Why they're discouraged:

  • They make instances stateful: if that node dies, the user loses their session (violates design for failure).

  • Uneven load: long-lived users can pile onto a few nodes, hurting balancing.

  • Scaling friction: new instances get no existing sessions; removing instances drops sessions.

• The cloud-native fix: Externalize session state to a shared store (Redis, a database) or use stateless tokens like JWTs, so any instance can serve any request.

An API Gateway is a single entry point that sits in front of many microservices, routing requests and handling cross-cutting concerns so each service doesn't have to. It decouples clients from the internal service topology.

• Core responsibilities:

  • Routing: map incoming paths to the right backend service.

  • Cross-cutting concerns: authentication, rate limiting, throttling, TLS termination, request/response transformation.

  • Aggregation: combine calls to several services into one client response.

  • Observability: centralized logging, metrics, and tracing.

• Why it helps microservices:

  • Clients see one stable API instead of dozens of endpoints that may move or split.

  • Removes duplicated auth/rate-limit logic from every service.

  • Enables versioning and gradual migration behind the gateway.

• Caveat: It can become a single point of failure or bottleneck; run it highly available and keep it thin (no business logic).

Event-driven architecture and serverless fit together because functions are triggered by events and billed only while running: an event arrives, a function spins up, processes it, and stops. Both are reactive, stateless, and scale with demand.

• Natural alignment:

  • Functions are inherently trigger-based: a queue message, file upload, HTTP call, or schedule invokes them.

  • Both are stateless and short-lived, matching the discrete nature of events.

• Practical benefits:

  • Elastic scaling: each event can spawn a concurrent invocation, so bursts scale automatically.

  • Cost efficiency: pay per execution, nothing when idle (no always-on servers waiting for events).

  • Loose coupling: producers publish events without knowing which functions consume them.

• Example: An image uploaded to object storage emits an event that triggers a function to generate a thumbnail. No server runs between uploads.

Edge computing pushes processing close to where data is generated (devices, sensors, local nodes) instead of sending everything to a distant central cloud, reducing latency and bandwidth. Fog computing is an intermediate layer between the edge and the cloud that aggregates and pre-processes data from many edge devices.

• Edge computing:

  • Compute happens on or near the device (IoT gateway, local server, phone).

  • Great for low-latency and offline-capable use cases: autonomous vehicles, industrial sensors, video analytics.

• Fog computing: A middle tier (routers, local hubs) that coordinates and filters data from multiple edge nodes before forwarding to the cloud.

• Vs. centralized cloud:

  • Cloud offers near-unlimited compute/storage but adds round-trip latency and bandwidth cost.

  • Edge/fog trade raw capacity for proximity: filter and act locally, send only summaries or heavy workloads to the cloud.

RTO (Recovery Time Objective) is how quickly you must restore service after an outage; RPO (Recovery Point Objective) is how much data loss (measured in time) you can tolerate. Together they define how aggressive and expensive your disaster recovery strategy must be.

• RTO: time to recover: "How long can we be down?" An RTO of 1 hour means service must be back within an hour.

• RPO: acceptable data loss: "How much recent data can we lose?" An RPO of 5 minutes means backups/replication must be at most 5 minutes stale.

• How they shape DR strategy:

  • Backup and restore: cheap, but high RTO/RPO (hours).

  • Pilot light / warm standby: partial environment ready, moderate RTO/RPO.

  • Active-active / hot standby: near-zero RTO/RPO via continuous replication, but most expensive.

• Key trade-off: Tighter RTO/RPO means higher cost and complexity; set them from business impact, not aspiration.

A Region is a geographic location (e.g. us-east-1) containing multiple isolated data centers, while an Availability Zone (AZ) is one or more discrete data centers within a Region with independent power, cooling, and networking. You use AZs for fault tolerance within a Region and Regions for geographic isolation and latency.

• Region:

  • A broad geographic area; Regions are far apart and isolated from each other.

  • Chosen for latency to users, data residency/compliance, and service availability.

• Availability Zone:

  • Physically separate facility within a Region, connected by low-latency links.

  • Designed so a failure in one AZ (power, flood, hardware) doesn't affect others.

• Designing for High Availability:

  • Spread instances across multiple AZs behind a load balancer so one AZ failure doesn't take you down.

  • Use multi-AZ managed databases for automatic failover to a standby.

  • For disaster recovery or global scale, replicate across Regions (higher cost and complexity).

High Availability (HA) minimizes downtime by keeping a system running most of the time, tolerating some brief disruption; Fault Tolerance (FT) aims for zero interruption even when a component fails. Cloud providers expose Regions and Availability Zones as the physical building blocks to design for both.

• High Availability:

  • Designed to reduce downtime (e.g. 99.99%), but a failover may cause a short blip or reconnection.

  • Typically achieved with redundancy plus automatic recovery (health checks, auto-scaling, multi-AZ replicas).

• Fault Tolerance:

  • No perceptible interruption on failure: redundant components run in parallel and take over seamlessly.

  • More expensive because it requires full duplication of capacity, not just standby.

• Availability Zones (AZs): Isolated datacenters within a Region with independent power and networking; spreading instances across AZs survives a single-datacenter failure.

• Regions: Geographically separate; multi-Region deployments protect against large-scale disasters and reduce latency for global users.

• Rule of thumb: multi-AZ gives HA cheaply; true FT and disaster resilience require redundant capacity and often multi-Region.

A load balancer improves performance by spreading traffic across many instances, but its bigger availability role is detecting unhealthy targets and routing around them so a failed instance never receives requests.

• Performance contribution: Distributes requests so no single instance is overloaded, enabling horizontal scale-out.

• Availability contribution:

  • Health checks continuously probe targets and remove failing ones from rotation.

  • Routes across multiple AZs, so an AZ outage doesn't take down the service.

  • Provides a stable endpoint while instances are replaced or auto-scaled behind it.

• Key point for an interview: Performance is about doing more work; availability is about surviving failures. The LB does both, but the health-check-and-reroute behavior is what makes it an HA component.

Right-sizing is matching the provisioned capacity of a resource to its actual workload so you're not paying for idle headroom. You identify over-provisioning by comparing real utilization metrics against allocated capacity over a representative time window.

• What it means: Choosing the smallest instance type, disk, or throughput tier that still meets performance and headroom needs.

• Signals of over-provisioning:

  • Consistently low CPU and memory utilization (e.g. peak under 20-40%) across peak periods.

  • Provisioned IOPS or throughput far above measured usage.

  • Idle or zombie resources with near-zero traffic.

• How to do it safely:

  • Look at percentiles (p95/p99), not just averages, so you keep headroom for spikes.

  • Use provider tools (e.g. AWS Compute Optimizer, Azure Advisor) that recommend types from historical metrics.

  • Prefer auto-scaling or serverless when load is variable, so you right-size dynamically instead of guessing.

Spot (AWS) or Preemptible (GCP) instances are spare provider capacity sold at a steep discount (often 60-90% off), but the provider can reclaim them with little warning. The trade-off is a much lower price in exchange for no guarantee the instance keeps running.

• How they work: You run on unused capacity; when the provider needs it back (or the market price rises), your instance is interrupted, usually after a short warning (e.g. a 2-minute notice).

• The trade-off: Dramatically cheaper, but not durable: no SLA that the instance stays up.

• Good fits: Fault-tolerant, stateless, or restartable work: batch jobs, CI, big-data processing, rendering.

• Poor fits: Stateful databases or long single-run jobs that can't checkpoint or tolerate sudden termination.

These are three pricing models trading commitment and reliability for cost. On-Demand is pay-as-you-go with full flexibility; Reserved/Committed Use gives a big discount for a 1-3 year commitment; Spot/Preemptible is cheapest but can be reclaimed anytime. Spot is risky whenever your workload can't tolerate abrupt interruption.

• On-Demand: Highest per-hour price, no commitment, start/stop freely. Best for unpredictable or short-lived workloads.

• Reserved / Committed Use: Discount (often 30-70%) for committing to a term and/or capacity. Best for steady, always-on baseline load.

• Spot / Preemptible: Deepest discount from spare capacity, but can be reclaimed with minimal notice.

• When Spot is risky:

  • Stateful or non-checkpointable workloads, latency-critical production traffic, or anything with a hard deadline that can't absorb a mid-run kill.

  • Mitigate by mixing Spot with On-Demand/Reserved capacity and designing for graceful interruption.

Scalability is the ability to handle increased load by adding capacity; elasticity is the ability to add and remove that capacity automatically and quickly in response to real-time demand. Yes, a system can be scalable but not elastic.

• Scalability:

  • A property: the system's throughput can grow when you give it more resources (more nodes, bigger nodes).

  • Says nothing about speed or automation; scaling could be a manual, planned operation.

• Elasticity:

  • A behavior: capacity expands and contracts automatically to match a fluctuating workload, then releases resources when demand drops.

  • Optimizes cost by not paying for idle capacity; tightly tied to pay-as-you-go billing.

• Scalable but not elastic (the answer to the sub-question): Example: a cluster you can grow by manually adding servers scales, but if it can't shrink or auto-adjust to a traffic spike, it isn't elastic.

Cloud bursting is a hybrid-cloud technique where an application runs primarily in a private data center and 'bursts' extra workload into the public cloud only when local capacity is exceeded, so you rent peak capacity instead of owning it.

• How it works:

  • Baseline demand is served on-premises; when a threshold is hit, overflow is routed to public cloud resources spun up on demand.

  • When the spike subsides, the cloud resources are torn down.

• Ideal scenario:

  • Predictable, spiky demand: e.g. a retailer whose on-prem handles normal traffic but bursts to the cloud for Black Friday.

  • Batch jobs (rendering, analytics) that occasionally need far more compute than the data center holds.

• Caveats:

  • Best for stateless, loosely-coupled workloads; data gravity and network latency between on-prem and cloud can hurt performance.

  • Watch data egress costs and keep configuration consistent across both environments.

Auto-scaling automatically adjusts the number (or size) of resources based on real-time demand or a schedule, whereas provisioning for peak means permanently running enough capacity to handle your busiest moment. Auto-scaling matches capacity to load; peak provisioning pays for the maximum all the time.

• How auto-scaling works:

  • Metric-driven: scales out/in when a signal (CPU, request rate, queue depth) crosses a threshold.

  • Can also be scheduled (known business hours) or predictive (forecasted load).

• Provisioning for peak: Simple and always ready, but most of the time capacity sits idle and wasted, costing far more.

• Why auto-scaling wins in the cloud:

  • Cost efficiency (pay for what you use) plus resilience (replaces unhealthy instances).

  • Trade-off: reacting to demand takes time (instance startup/warm-up), so keep some headroom or use predictive scaling to avoid lagging behind sudden spikes.

Multi-tenancy is a model where a single instance of shared infrastructure or software serves many independent customers (tenants), with logical isolation keeping each tenant's data and workload separate. Its main risk is the 'noisy neighbor,' where one tenant's heavy usage degrades performance for others sharing the same physical resources.

• Multi-tenancy:

  • Shared physical resources (compute, storage, network) partitioned logically per tenant.

  • Enables the cloud's economics: high utilization and lower per-customer cost; opposite is single-tenant/dedicated.

• Noisy neighbor problem:

  • One tenant consuming excessive CPU, I/O, or bandwidth starves co-located tenants, causing latency and unpredictable performance.

  • A security concern too: weak isolation could risk cross-tenant data exposure.

• Mitigations:

  • Resource quotas, throttling, and limits per tenant to cap consumption.

  • Strong isolation via hypervisors/containers/namespaces; dedicated or reserved instances for demanding workloads.

Multi-tenancy is when a single physical infrastructure or software instance serves many independent customers (tenants), with each tenant's data logically isolated from the others. It is the economic engine of public cloud: shared hardware drives down cost, but shared resources create isolation risks.

• What it means:

  • One provider pool (compute, storage, DB) is partitioned logically so tenants don't see each other's data.

  • Contrast with single-tenancy (dedicated hardware per customer), which costs more but isolates fully.

• Security risks:

  • Data leakage: a misconfigured access control or query flaw exposes another tenant's data.

  • Noisy neighbor: one tenant's load degrades performance for others (availability, not confidentiality).

  • Side-channel attacks: shared CPU/cache/memory can leak information across VM boundaries (e.g. Spectre/Meltdown).

  • Escape/privilege escalation: breaking out of a VM or container to reach the host or peers.

• Mitigations:

  • Strong isolation (hypervisor, namespaces), per-tenant encryption keys, and resource quotas to bound the noisy neighbor.

  • Rigorous tenant-ID scoping in application queries so one tenant can never fetch another's rows.

A VPC is a logically isolated, private virtual network within a public cloud where you control IP ranges, subnets, routing, and firewall rules. Even developers who never touch infra need to understand subnets and security groups because they directly determine whether your app can reach its database, be reached by users, and stay secure.

• What a VPC is: Your own private slice of the cloud network with a defined CIDR block (e.g. 10.0.0.0/16), isolated from other tenants.

• Subnets:

  • Subdivisions of the VPC's IP range, typically public (internet-reachable via an internet gateway) or private (no direct inbound internet).

  • Developers place a web tier in public subnets and databases in private subnets: knowing this explains why your DB isn't publicly accessible.

• Security groups:

  • Stateful virtual firewalls attached to instances that allow traffic by port, protocol, and source.

  • Most 'connection refused/timeout' bugs are a missing rule: e.g. the app's security group isn't allowed on the DB's port 5432.

• Why the developer should care: You debug connectivity faster, request the right rules, and design apps that respect the network's security posture (least privilege).

A CDN is a distributed network of edge servers that cache content near users to reduce latency. Edge computing is the broader idea of running compute (not just caching) at those same edge locations: a CDN is effectively an early, cache-focused form of edge computing that has evolved to run code at the edge.

• CDN: caching at the edge: Its core job is storing and serving copies of content close to users to cut round-trip time and offload the origin.

• Edge computing: compute at the edge: Runs application logic near users rather than in a central region, for low latency and local processing (IoT, personalization).

• The relationship:

  • CDNs already have physical presence in hundreds of locations, so providers layer programmable compute on top of them.

  • Examples: Cloudflare Workers, Lambda@Edge run functions on CDN edge nodes to rewrite requests, authenticate, or render at the edge.

• Distinction to state in an interview: A CDN moves data closer to users; edge computing moves computation closer. A modern CDN does both.

DNS translates human-readable names into IP addresses, and in the cloud it doubles as a control point for directing traffic: by returning different answers based on health, geography, or policy, DNS becomes a key tool for failover and load distribution.

• Core role: name resolution: Maps names to endpoints (IPs, load balancers), so clients find your services without hardcoding addresses.

• Health checks and failover:

  • Managed DNS (e.g. Route 53) monitors endpoints and stops returning unhealthy ones, routing users to a standby region.

  • Low TTLs let failover propagate quickly, at the cost of more DNS lookups.

• Traffic routing policies:

  • Latency-based: send users to the region with the lowest latency.

  • Geolocation/geoproximity: route by user location for compliance or locality.

  • Weighted: split traffic by percentage for canary or blue-green releases.

  • Failover: primary/secondary active-passive routing.

• Caveat: DNS caching by resolvers and clients means changes aren't instant; TTL is a trade-off between agility and lookup volume.