Cloud Computing Mid

FaaS and PaaS are identical models, differing only in the marketing name that each cloud vendor chooses to assign to their offering

FaaS requires you to provision and patch the servers yourself, whereas PaaS abstracts everything including the code you write and deploy for events

FaaS hosts persistent always-on application processes billed hourly, whereas PaaS only executes single functions that terminate right after each request

FaaS runs short-lived event-triggered functions that scale to zero and bill per invocation, whereas PaaS keeps a platform running to host longer applications

Public shares infrastructure across many tenants, Private is dedicated to one organization, and Hybrid links both; a Private cloud suits strict data-control needs

Public and Private are the same shared model, and Hybrid means no cloud at all; a Private cloud is chosen mainly to cut every possible cost

Public runs on your own servers, Private runs on vendor servers, and Hybrid removes vendors; a Private cloud suits firms wanting elastic public scaling

Public is dedicated to one firm, Private is shared by many tenants, and Hybrid uses only on-premises hardware; a Private cloud suits low-budget startups

Infrastructure built from volunteer home computers donated freely, used when organizations need massive compute without paying any provider fees at all

Infrastructure owned by a single company for its own exclusive use, adopted when that firm wants total isolation from every other external tenant

Infrastructure open to the general public over the internet, chosen when organizations want the lowest cost and do not care about who shares it

Infrastructure shared by several organizations with common concerns such as compliance or mission, used when they have aligned regulatory and security requirements

The provider gives full source access and root control with no lock-in at all, while self-managing is always cheaper and simpler across every workload type

The provider only rents you hardware while you patch everything, which lowers control but avoids lock-in, whereas self-managing removes all operational responsibility entirely

The provider handles operations like patching and scaling, saving effort but reducing control and risking lock-in, while self-managing gives flexibility at higher operational cost

The provider guarantees zero cost and unlimited customization forever, whereas self-managing forces vendor lock-in and strips away any ability to tune performance

Type 1 emulates the full CPU in software; Type 2 passes instructions straight through.

Type 1 runs inside a browser tab; Type 2 runs as a background system service daemon.

Type 1 hosts only Linux guests; Type 2 hosts only Windows guests on the same box.

Type 1 runs directly on the hardware; Type 2 runs on top of a host operating system.

At rest protects moving data, in transit protects stored data; the user always holds keys.

Both modes protect only backups; keys are shared publicly so any tenant can decrypt data.

At rest encrypts passwords, in transit encrypts logs; no keys are needed for either mode.

At rest protects stored data, in transit protects moving data; the provider often holds keys.

Give each identity broad permissions but log every action taken for later security review.

Grant every identity full admin rights first, then remove access only after incidents.

Grant each identity only the minimum permissions required to do its intended task.

Assign all users to one shared role so permissions stay simple and easy to audit later.

Durability measures how quickly reads and writes complete, while availability measures the total number of copies the provider keeps replicated across separate physical data centers

Durability is the likelihood your data is not lost or corrupted over time, while availability is the likelihood you can access that data at any given moment

Durability is the likelihood you can access data at any given moment, while availability is the likelihood the data is never lost or corrupted over the entire storage lifetime

Durability measures the encryption strength protecting stored data, while availability measures the geographic spread of Regions where the provider is legally permitted to host it

Frequently accessed data sits in the archive tier with instant retrieval while rarely used data stays hot, cutting spend by keeping everything in the fastest storage class available

Frequently accessed data sits in cheaper-to-read hot tiers while rarely used data moves to colder tiers with lower storage cost, cutting spend by matching tier to access frequency

All data is duplicated equally across hot, cold, and archive tiers at once, cutting spend by spreading identical copies so any single tier failure never affects total availability

Data is tiered strictly by file size rather than access pattern, cutting spend by pushing large objects into hot storage and keeping small objects permanently in the archive tier

An SLI is a measured metric, an SLO is the target for it, and an SLA is the contractual promise with penalties

An SLA is the measured metric, an SLO is the signed contract, and an SLI is the internal target teams aim for

An SLI is the customer contract, an SLO is the raw metric, and an SLA is the informal engineering goal to hit

An SLO is the measured metric, an SLI is the penalty clause, and an SLA is the availability target that is set

They are open-source security tools that automatically encrypt data before it is uploaded to any provider

They are cloud pricing models that guarantee lower costs when workloads meet certain regional data rules

They are networking protocols that ensure encrypted data transfer between regions across cloud vendors

They are regulatory or audit standards for data handling; certified providers reduce your own compliance burden

Logs are discrete event records, metrics are numeric time-series, and traces follow a request across services

Logs are numeric aggregates, metrics are event records, and traces store raw text output from each service

Logs follow requests across services, metrics are discrete events, and traces are numeric measurements taken

Logs are request timelines, metrics are text records, and traces are periodic numeric samples of system health

It manages billing and cost allocation for containers running across multiple cloud provider accounts at once

It automates deployment, scaling, self-healing, and networking of containers across a cluster of machines

It replaces containers with virtual machines to improve isolation while scaling workloads across many regions

It compiles container images directly from source code and distributes them to a private registry on its own

Stateless apps store session data on each instance, which lets the cloud replicate them without any load balancer

Stateless apps keep no client session data locally, so any instance can handle a request and they scale easily

Stateless apps require sticky sessions bound to one instance, which makes horizontal scaling simpler in the cloud

Stateful apps hold no local session data, so the cloud can freely add or remove instances during traffic spikes

A set of best practices for building portable, scalable, stateless cloud-native apps.

A container orchestration standard defining how Kubernetes pods get scheduled.

A pricing model where cloud costs are split across twelve monthly billing factors.

A twelve-step security checklist every cloud deployment must pass before its release.

Binding a user to one server for their session; it hinders scaling and load balancing.

Caching static assets on the client so pages load faster across the whole session.

Sharing session state across all servers so any node can handle any request cleanly.

Encrypting session cookies so they cannot be read or tampered with by any attacker.

A single entry point that routes requests and handles auth and rate limiting.

A service mesh sidecar that encrypts internal traffic between all services directly.

A message broker that queues events and delivers them asynchronously between services.

A database proxy that caches queries and balances load across service data stores.

Functions run only when triggered by events, scaling automatically and billed per use.

Serverless demands a persistent connection so each function can hold user state locally.

Events require dedicated servers provisioned in advance for predictable throughput levels.

Functions poll a central server constantly for events, keeping resources always running.

Running all computation in one large data center to maximize resource pooling and reuse.

Processing data near its source to cut latency, versus in centralized data centers.

Distributing databases globally so every region holds an identical copy of all the data.

Storing backups at the network edge while all real processing stays in the main cloud.

Both measure system uptime percentages used to define availability service agreements.

RTO is max acceptable data loss; RPO is max acceptable downtime after an outage occurs.

RTO tracks recovery cost; RPO tracks the number of restore points kept in the backups.

RTO is max acceptable downtime; RPO is max acceptable data loss measured in time.

An AZ contains multiple regions; spread workloads across regions within one AZ for HA.

A region is a single data center; an AZ is a rack within it used for redundancy only.

A region contains multiple isolated AZs; spread workloads across AZs for availability.

Regions and AZs are identical; using either one alone guarantees full high availability.

High availability minimizes downtime through fast recovery, while fault tolerance keeps running with zero interruption during failures

High availability keeps running with zero interruption, while fault tolerance only restores service quickly after any component failure occurs

High availability and fault tolerance are identical, and both simply require deploying redundant servers within one single availability zone

High availability protects against data loss, while fault tolerance is only about scaling capacity to handle larger traffic spikes

It only distributes requests evenly across instances, so it improves throughput but never affects the overall system availability

It performs health checks and reroutes traffic away from failed instances, not only spreading load across healthy ones

It replicates the database across regions automatically, providing availability while performance depends entirely on the instance sizing

It caches responses at the edge so failed instances still serve stale data, guaranteeing availability without any health checks

Match resource size to real demand; consistently low CPU, memory, and network utilization signals it is over-provisioned

Always pick the cheapest instance tier; a rising monthly bill alone is the clearest signal that a resource is over-provisioned

Match resource size to real demand; sustained low CPU and memory utilization over time indicates that it is over-provisioned

Buy the largest instance available; frequent throttling and high latency under peak load indicate that it is over-provisioned

Dedicated capacity offered cheaply on a long contract that the provider guarantees, so workloads run without any interruption risk

Spare capacity offered cheaply that the provider can reclaim with little notice, so workloads must tolerate interruption

Spare capacity offered cheaply that runs on slower hardware, so the trade-off is reduced performance rather than sudden termination

Shared capacity offered cheaply with strict data limits, so the trade-off is capped storage and network rather than being reclaimed

On-Demand is flexible pay-as-you-go, Reserved discounts a commitment, Spot is cheapest but reclaimable; risky for stateful or critical work

On-Demand is cheapest, Reserved is reclaimable capacity, Spot discounts a commitment; risky whenever a workload can pause and resume freely

On-Demand and Reserved are identical flat rates, Spot is a premium tier; risky mainly because Spot always costs far more under peak demand

On-Demand needs a long commitment, Reserved is pay-as-you-go, Spot is cheapest and guaranteed; risky only for short-lived batch jobs

Scalability means handling more load; elasticity means handling less load. No, a system must always support both directions to be considered scalable at all.

Scalability is the ability to grow capacity; elasticity is doing so automatically in real time. Yes, a system can scale manually without being elastic.

Scalability relates only to storage growth; elasticity relates only to compute. Yes, a system can scale storage while keeping its compute completely fixed.

Scalability is automatic real-time adjustment; elasticity is the raw ability to grow. No, any scalable system is by definition also fully elastic too.

Splitting a workload evenly across two public cloud providers at all times, useful for avoiding vendor lock-in and negotiating better contract pricing.

Running normally in the public cloud and falling back to a private data center on outages, useful for guaranteeing uptime during provider failures.

Running normally in a private data center and overflowing to the public cloud during demand spikes, useful for handling seasonal traffic surges.

Rapidly deleting cloud resources when a budget threshold is exceeded, useful for controlling runaway costs during unexpected sustained traffic growth.

Auto-scaling adjusts resources dynamically to match demand, whereas peak provisioning keeps maximum capacity always running and paying for idle resources.

Auto-scaling and peak provisioning both size for maximum load, but auto-scaling spreads that capacity across multiple regions for redundancy purposes.

Auto-scaling manually resizes instances during maintenance windows, whereas peak provisioning automatically responds to real-time traffic fluctuations.

Auto-scaling keeps a fixed reserve of capacity ready at all times, whereas peak provisioning adds resources only after monitoring detects a demand increase.

Multiple customers share the same infrastructure; a noisy neighbor is a tenant that leaks data across boundaries and directly accesses others' private files.

Multiple customers share the same infrastructure; a noisy neighbor is a tenant consuming excess shared resources and degrading others' performance.

Each customer runs in a separate region; a noisy neighbor is a tenant located too far away geographically, adding network latency to shared API calls.

Each customer gets fully dedicated hardware; a noisy neighbor is a tenant sending too many support requests and slowing down the provider's response times.

A single application instance serves one client only, which eliminates any risk of cross-customer data exposure.

Tenants are billed separately but run isolated clouds, so noisy-neighbor and side-channel attacks are impossible here.

Multiple customers share pooled infrastructure with logical isolation; a flaw could expose one tenant's data to another.

Each customer receives dedicated physical hardware, so no isolation flaws can ever leak sensitive data between them.

A logically isolated virtual network in the cloud; subnets and security groups control reachability of your services.

A physical data center rented per customer; subnets and security groups only affect DNS resolution of endpoints.

A managed database cluster spanning regions; subnets and security groups define its automatic backup schedules only.

A shared public network for all tenants; subnets and security groups mainly set the billing tiers for developers.

A CDN encrypts static assets in transit; edge computing decrypts them only after reaching the origin server.

A CDN stores backups in one central region; edge computing moves those backups to a single cheaper zone.

A CDN caches content at edge locations; edge computing extends this by running compute close to users.

A CDN routes all traffic to the origin; edge computing simply renames that origin server as an edge node.

It balances traffic across servers by opening TCP connections and closing them when a health check fails.

It resolves names to addresses and can route or fail over traffic using health checks and routing policies.

It stores application session state and can reroute users by rewriting their cookies during regional outages.

It caches static web assets globally and can shift load by compressing responses when a region fails.

It provides secure, private connectivity between on-premises networks and cloud resources.

It caches cloud-hosted content within the local data center to reduce latency for users.

It replicates cloud databases onto on-premises servers over encrypted public internet links.

It automatically converts on-premises virtual machines into managed cloud serverless functions.

Functions run on demand in ephemeral instances; trade-offs include cold starts and execution time limits.

Functions require managing the OS and scaling manually; the trade-off is slower deployment of new code.

Functions run only inside long-lived containers; the trade-off is unpredictable billing and no autoscaling.

Functions run continuously on reserved servers; the main trade-off is paying for idle capacity constantly.

When every workload can scale elastically and needs no control over the physical infrastructure

When the goal is to spread identical workloads across several competing public cloud providers

When the company wants to fully eliminate all on-premises hardware and its maintenance costs

When data residency, latency, or legacy systems require some workloads to stay on-premises