Cloud Computing Expert

IaaS delivers ready-made applications, PaaS provides virtual machines to configure, and SaaS exposes the operating system layer for full control

IaaS handles application logic, PaaS manages billing only, and SaaS provisions the physical servers that customers rack and maintain themselves

IaaS runs functions on demand, PaaS supplies bare storage buckets, and SaaS gives you kernel-level access to the underlying host machine

IaaS gives raw compute and networking to manage, PaaS abstracts the runtime for deploying code, and SaaS delivers finished applications to end users

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

CapEx and OpEx both mean depreciation of hardware over time; cloud eliminates all spending categories and makes infrastructure completely free after initial setup

CapEx is recurring monthly usage cost, OpEx is a one-time asset purchase; cloud shifts spending from operating fees toward big upfront capital investments

CapEx is upfront spending on owned assets, OpEx is ongoing usage cost; cloud shifts spending from large capital purchases toward pay-as-you-go operating expenses

CapEx is the tax on operating profit, OpEx is the tax on capital gains; cloud shifts a firm from paying income tax toward paying only sales tax

Automated backups, global routing, shared licensing, vertical scaling, and guaranteed uptime service

On-demand billing, private networking, dedicated hardware, manual scaling, and fixed monthly service

Self-hosting, limited access, single tenancy, static capacity, and unmetered flat-rate service

On-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service

It is an application that runs exclusively offline on local desktops and connects to the cloud purely for occasional data backup tasks

It is designed to exploit cloud models using microservices, containers, and automation to scale and recover in dynamic environments

It is a legacy monolith simply moved onto a single virtual machine without changing its original architecture or scaling behavior

It is any software that can only run on one specific vendor's proprietary hardware and cannot be deployed anywhere else at all

On-demand delivery of IT resources over the internet with pay-as-you-go pricing.

A private network connecting office computers to share files and printers locally.

Permanent ownership of physical servers housed in a company's own data center.

Software installed locally on each user's machine and licensed per device yearly.

Each customer receives a dedicated physical server that no one else can ever use.

Providers serve many tenants from shared physical resources allocated on demand.

Resources are copied to every region so each user gets a full local hardware set.

Idle servers are powered off nightly and rebuilt fresh from backups each morning.

A hardware standard letting servers from different vendors share one common chassis.

A pricing tier where every service is bundled into one flat monthly subscription fee.

Delivering any capability as an internet service, such as FaaS or DBaaS offerings.

A framework forcing all workloads to use exactly the same runtime and language stack.

It began with public cloud, then added virtualization, and finally reached mainframes.

It started with smartphones, moved to laptops, and later introduced shared servers.

It progressed from grid and utility computing through virtualization to modern cloud.

It emerged fully formed from a single vendor's data center release in the year 2015.

Public cloud removes all security duties from the customer and needs no configuration.

On-premises scales automatically with demand, whereas cloud requires manual purchasing.

On-premises always costs less at any scale while offering unlimited instant elasticity.

On-premises means upfront capital cost and control; cloud offers elastic pay-per-use.

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.

Object storage exposes a shared directory hierarchy, block storage stores objects with rich metadata for archives, and file storage provides raw low-latency volumes ideal for transactional relational database workloads

Object storage holds data as flat objects with metadata for media and backups, block storage offers raw volumes for databases and VM disks, and file storage exposes a shared hierarchy for multiple clients

Object storage keeps mounted volumes for databases, block storage stores flat objects for backups and media, and file storage handles raw disk blocks attached directly to a single virtual machine instance

Object storage provides raw disk volumes for VMs, block storage exposes a shared network file hierarchy, and file storage stores immutable flat objects accessed over HTTP for large media libraries

Defining infrastructure in declarative files that can be versioned and repeated, giving consistent, reproducible environments and avoiding error-prone manual clicking

Defining infrastructure by clicking through the console once and saving screenshots, giving a documented setup that teammates can follow and reproduce manually when needed

Writing application business logic that provisions its own servers at runtime, giving each request the ability to scale hardware without any predefined configuration files

Storing server credentials and network diagrams in a shared wiki page, giving operators a single reference so they can rebuild environments by hand consistently later

Containers emulate hardware for each app, so they are heavier than VMs but much more portable overall

Containers run a full guest OS per instance, giving them stronger isolation but far slower startup times

Containers share the host OS kernel and bundle only the app, so they start fast and use fewer resources

Containers and VMs both virtualize hardware, but containers require a dedicated hypervisor layer to run

Authentication verifies who you are, while authorization determines what actions you are allowed to perform

Authentication assigns permitted roles to a user, while authorization confirms the password matches what is stored

Authentication determines what you can access, while authorization verifies the identity of a requesting user

Authentication encrypts credentials while in transit, while authorization stores those credentials safely at rest

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

Residency is the physical location where data is stored, while sovereignty means the data is subject to the laws of the country it resides in, so Region choice affects legal compliance

Residency is the set of laws governing the data, while sovereignty is simply the physical location of storage, so Region choice mainly affects network latency and replication throughput speeds

Residency and sovereignty both refer to encryption standards applied at rest, so Region choice only matters for selecting which key management service and cipher suite your application will use

Residency is a backup retention policy while sovereignty is an access control model, so Region choice determines how long snapshots persist and which IAM roles can read the data

Zero Trust removes all authentication to speed up internal calls, whereas perimeter security relies purely on continuous identity verification for every user and device that connects

Zero Trust and perimeter security are identical models, both trusting internal traffic while blocking external requests using a hardened firewall placed at the edge of the corporate network

Zero Trust assumes no request is inherently trusted and verifies every one, whereas perimeter security trusts anything already inside the network boundary once it passes the firewall

Zero Trust trusts all internal traffic to reduce overhead, whereas perimeter security individually authenticates every single request regardless of whether it originates inside or outside the network

They express the guaranteed uptime percentage; adding a nine increases allowed downtime, so it lets you cut redundancy and reduces both the cost and complexity of the design

They express the average request latency in milliseconds; adding a nine tightens the latency budget, so it requires faster hardware but has little effect on redundancy or cost

They express the percentage of data durability guaranteed; adding a nine improves replication factors, so it mainly affects storage spend without changing availability or overall complexity

They express the guaranteed uptime percentage; adding a nine shrinks allowed downtime dramatically, so it demands more redundancy and raises cost and complexity significantly

Servers are continuously patched and updated in place after deployment, treating each one as a unique disposable unit that is rebuilt from scratch on every configuration change

Servers are manually configured once and then frozen from all monitoring, treating them as irreplaceable pets that must be individually backed up before any code deployment

Servers are never modified after deployment; changes mean replacing instances entirely, treating them as disposable cattle rather than carefully patched, hand-nursed pets

Servers share a single mutable image edited live across the fleet, treating the whole cluster as one pet that is upgraded gradually to avoid replacing running instances

Provider-managed keys cannot be rotated, while customer-managed keys are automatically rotated by the cloud vendor

Provider-managed keys give full customer control, while customer-managed keys are handled entirely by the vendor

Provider-managed keys are simpler to operate; customer-managed keys give more control but add operational burden

Provider-managed keys are always less secure, while customer-managed keys remove all compliance responsibility

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.

Purchase premium hardware and support plans so failures never occur in production.

Assume components will fail and build redundancy so the system recovers automatically.

Prevent outages entirely by running the whole application in a single strong region.

Eliminate all failures by testing code thoroughly before deploying it to production.

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

Cost is unrelated to RTO/RPO because each strategy relies on the same standby capacity and differs only in the region chosen

Cheaper strategies like active-active give the lowest RTO/RPO, while pricier backup-and-restore trades speed for stronger data durability

Higher spend on always-running standby infrastructure buys higher RTO/RPO, moving from active-active down to plain backup-and-restore

Higher spend on always-running standby infrastructure buys lower RTO/RPO, moving from backup-and-restore up to active-active

You pay a fixed monthly subscription fee, so you architect to provision maximum capacity upfront since additional usage incurs no extra charges at all.

You prepay for a capacity reservation, so you architect around long-lived static instances that stay running to guarantee availability during peak times.

You pay only for resources actually consumed, so you architect to release idle capacity and scale down when demand is low to reduce cost.

You pay based on the number of users, so you architect around user quotas and design systems that limit account creation to control the overall spend.

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

Charges for data entering the cloud; route all inbound uploads through a single region and disable caching to reduce transfers

Charges for storing archived data long-term; move objects to colder storage tiers frequently to reduce the recurring transfer fees

Charges for API request counts on services; batch calls together and add more compute nodes to reduce the per-request transfer fees

Charges for data leaving the cloud; keep traffic within the same region and use caching or CDNs to reduce transfers

TCO counts only upfront hardware purchases; bills grow because providers must recover the cost of the datacenter buildings they own

TCO counts only the monthly compute charge; bills grow because cloud CPUs are always inherently slower than owned physical hardware

TCO counts staffing salaries alone; bills grow chiefly because cloud contracts require paying for unused capacity you never provisioned

TCO counts all direct and indirect costs; bills grow from data transfer, managed services, and idle over-provisioned resources

FinOps is a billing negotiation process with vendors; showback and chargeback both mean forecasting future costs based on historical consumption trends.

FinOps is a discipline for cloud cost accountability; showback reports each team's costs for visibility, while chargeback actually bills teams for their usage.

FinOps is a security compliance framework; showback bills each team directly, while chargeback only reports usage to teams for internal visibility purposes.

FinOps is an automated scaling technique; showback allocates unused credits to teams, while chargeback reserves capacity in advance to reduce total spend.

Horizontal upgrades disk capacity; vertical upgrades network bandwidth. Vertical is preferred in the cloud because a single node is far simpler to manage.

Horizontal adds more machines; vertical adds power to one machine. Horizontal is preferred in the cloud for resilience and near-limitless growth.

Horizontal and vertical both add more machines to a pool. Horizontal is preferred in the cloud because it keeps all state on a single powerful server node.

Horizontal adds power to one machine; vertical adds more machines. Vertical is preferred in the cloud because it avoids the need for load balancing entirely.

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.

The provider secures the underlying infrastructure; in IaaS the customer manages the OS, apps and data, while in SaaS the provider handles nearly everything.

The customer is fully responsible for security in both models; in IaaS and SaaS the provider merely supplies hardware and leaves all software to the customer.

The provider is fully responsible for security in both models; in IaaS and SaaS the customer only ever manages user passwords and their own billing settings.

The customer secures the underlying infrastructure; in IaaS the provider manages the OS and data, while in SaaS the customer handles nearly everything.

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.

It caches content on edge servers near users, cutting latency and offloading traffic from the origin.

It replaces the origin server entirely by generating dynamic pages inside every user's local web browser.

It compresses all database queries at the origin server, so responses reach distant users much more quickly.

It encrypts every request end to end, which reduces round trips and thereby speeds up content delivery.

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.

Latency from encrypting the first request; disabling TLS on internal endpoints avoids it completely.

Latency from a full server reboot on deploy; adding more memory to each function removes it entirely.

Latency caused by database connection pooling; caching every query result eliminates it across regions.

Latency to initialize a new function instance; provisioned concurrency or keep-warm calls reduce it.

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

Rehost when you want to fully re-architect the app to gain elasticity and cost savings

Rehost only when the application must be rebuilt to use managed cloud-native services first

Rehost when the legacy application should be retired and replaced with a SaaS product

Rehost when speed matters and the app can move as-is; refactor later once value is proven

Dependence on a single billing contract; reserved instances and spot pricing help to reduce it

Dependence on one region's data centers; multi-zone replication and failover fully eliminate it

Dependence on legacy hardware vendors; virtualization and hypervisor tuning largely eliminate it

Dependence on one provider's proprietary services; abstraction layers and open standards reduce it

Hybrid mixes private and public; multi-cloud uses several public providers to avoid lock-in

Hybrid uses several public providers; multi-cloud mixes private and public to boost security

Hybrid means SaaS plus IaaS; multi-cloud means running only containers across data centers

Hybrid and multi-cloud both mean one provider spanning many regions for lower latency

Cloud-native means virtual machines only; cloud-agnostic means serverless functions on any provider

Cloud-native means on-premises only; cloud-agnostic means using exclusively public cloud offerings

Cloud-native stays portable across providers; cloud-agnostic embraces one provider's managed services

Cloud-native embraces one provider's managed services; cloud-agnostic stays portable across providers