Learn Cloud & Infrastructure

Infrastructure is everything your laptop was quietly providing for free, made explicit, paid for, and owned by someone. It is derived from a workload — never selected from a catalogue of product names.

Q · What is infrastructure for, and how do I decide what a given workload actually needs?

A method: application requirement → infrastructure requirement → component. Running it in the other direction — component first, justification later — is how teams end up operating systems nobody chose.

Q · How do I get from what the application does to what infrastructure it needs, without a product name appearing early?

The full progression, one forced problem at a time: a laptop, then one remote server, then a real production topology, then multi-region. Every component earns its place by naming the concrete failure that created it.

Q · What is the actual sequence of problems that turns an application on a laptop into a production system, and what does each one force you to add?

Not a migration pitch. Seven dimensions on which the two genuinely differ — capital structure, provisioning speed, control, operational burden, elasticity, geographic reach and vendor dependence — and the workloads for which owning hardware is still the better engineering answer.

Q · When is renting infrastructure the right answer, and when is owning it — and what actually differs between the two?

A region is a geography and a jurisdiction; a zone is a failure domain. Confusing the two produces designs that look redundant on a diagram and share a single power feed in reality.

Q · What is a region, what is an availability zone, and which failures does each one actually contain?

Application → runtime → container or VM → host OS → physical compute → network and storage → data centre. Every incident lives at exactly one layer, and most debugging time is spent looking at the wrong one.

Q · What sits between my application code and the electricity, and which layer is a given failure actually coming from?

The provider secures the cloud; you secure what you put in it. The line moves with the service model, and nearly every publicly reported cloud breach happened on the customer's side of it.

Q · When I adopt a managed service, exactly which obligations transfer to the provider and which stay mine?

Complexity must be justified by the workload and by the organization that has to run it. Adopting the architecture of a company a thousand times your size gives you their operational burden and none of their problems.

Q · How do I tell infrastructure that solves a real problem from infrastructure that was adopted because it is what serious companies use?

You are not renting a machine. You are renting a bounded share of CPU, memory, local storage and network bandwidth, on a processor architecture you chose, with a lifecycle that can end without asking you.

Q · What am I actually buying when I choose an instance size, and which of its dimensions will constrain my workload first?

Stop thinking "a server" and start thinking "a box with four walls". The mental shift matters because each wall has a different enforcement mechanism, and hitting one is nothing like hitting another.

Q · What happens at each boundary of the resources a workload has been allocated, and why do the boundaries behave so differently?

A compute instance is born, becomes eligible for traffic, serves, drains and dies — and every one of those transitions is a place where requests get dropped if the application does not participate.

Q · What states does a compute instance pass through, and at which of them can it silently lose the requests it was supposed to serve?

Virtual machine, container, managed container platform, or functions. Six questions decide it, and every answer must come with why, what it costs, and what you would use instead.

Q · Which execution model fits this workload, and what am I giving up by choosing it?

A rented machine is a slice of someone else's machine: a guest operating system on virtual hardware, held apart from every other tenant by a hypervisor. You get a complete OS and the strongest ordinary isolation boundary on offer, and you inherit every obligation of running one.

Q · What am I actually getting when I rent a machine that is not a machine, and what do I owe in return?

The hypervisor is the component that divides one physical machine between strangers. Understanding what it multiplexes explains both why a VM boundary is stronger than a container's and why your latency can double while your CPU graph stays flat.

Q · Who divides one physical machine among many tenants, and what does sharing that machine cost me?

Provision, boot, configure, run, patch, restart, terminate. Each state has a characteristic way of failing, a signal that reveals it and usually a signal that reassures you while it happens — and the two states teams skip planning for are patch and terminate.

Q · What states does a virtual machine pass through from request to destruction, and how would I notice when it fails in each of them?

Either you log into machines and change them, or you build an image and replace them. The first is faster today and produces servers nobody can reproduce; the second costs a build pipeline and pays for itself the first time you have to scale out or recover in a hurry.

Q · Should I fix a running server or replace it, and when does the difference actually matter?

Vertical scaling is one instruction and no new concepts, right up to the instance size that does not exist. Horizontal scaling removes the ceiling and the single failure domain, and charges you statelessness, a load balancer, and a fleet to keep identical.

Q · Should this workload run on one large virtual machine or several smaller ones, and what does each choice cost me?

What containerizing a workload actually changes for the people who run it: one immutable artifact carries the application, its runtime and its dependencies, so the bytes that passed CI are the bytes production starts.

Q · What does packaging a workload as a container actually change for the team that has to run it in production?

A VM virtualizes hardware and boots its own kernel; a container is an isolated process on a kernel it shares. That single difference sets startup time, density, portability — and the strength of the security boundary, which is the axis people skip.

Q · When does a workload need its own kernel, and when is an isolated process on a shared kernel enough?

An image is an ordered stack of read-only layers plus a metadata document. Understanding that stack explains build caching, why images share disk, why a rebuild changes bytes you did not touch, and why anything written into a layer is permanent.

Q · What is actually inside a container image, and why does its internal structure change how you build and ship?

Dockerfile, build, image, container, registry, volume, network, published port: eight nouns that cover almost everything a team does day to day. They are the vocabulary of one popular toolchain, not the definition of containers.

Q · What is the minimum working vocabulary for operating containers, and which parts of it are Docker rather than containers?

Source → Dockerfile → build → image → registry → deployment. Six states, each with its own failure mode, its own identity, and one rule that holds them together: build the artifact once and promote the same bytes.

Q · How does a commit become the exact artifact that production runs, and where does that chain usually break?

A large image is slower to pull, slower to deploy, more expensive to move, and carries more software an attacker can use. The one that hurts most is the one nobody attributes to it: new capacity arrives late because it is still downloading.

Q · What does an extra gigabyte of image actually cost, and where does that cost land?

The registry is the boundary between "built" and "deployable", and the one component every host in the fleet pulls from. Tags are mutable pointers, digests are the artifact, and :latest in a production manifest is the classic finding.

Q · Where do images live between build and deployment, and how do you know the thing production pulled is the thing you tested?

Application Image + Environment Configuration = Running Workload. One artifact promoted through every environment, with configuration injected at start — and never a secret in a layer, because a layer is forever and docker history reads it back.

Q · What belongs inside the image, what is injected at start, and where do secrets actually live?

A container is a replaceable compute unit with a disposable filesystem. Anything that must survive a restart, a rescheduling or a node failure lives outside it — in a volume, a managed database or an object store.

Q · Where is a workload allowed to write, and what happens to everything else it writes?

A hundred containers across twenty machines is not a bigger version of one container on one machine. Placement, restart, health, networking, rollout and discovery each stop being decisions a human can make in time — and the thing that makes them instead is an orchestrator.

Q · Once a workload is a hundred containers spread across twenty machines, who decides what runs where — and who puts it back when it dies at 03:00?

Desired: ten API containers. Actual: eight running, two crashed. Somebody has to notice and restore the difference. Kubernetes is the answer to that question generalized into a control loop — and the loop, not the YAML, is the thing worth learning.

Q · When actual state drifts away from desired state, who notices, and what exactly do they do about it?

Desired state → control plane → scheduler and controllers → worker nodes → pods. Five boxes, one direction of flow, and everything else in Kubernetes is a detail hanging off one of them.

Q · What are the moving parts of a Kubernetes cluster, and which one is responsible when something does not run?

Ten object kinds cover almost everything. Learn them as answers to problems — "pod IPs change", "config must differ per environment", "this job must not run twice" — and the API stops being a vocabulary test.

Q · Which Kubernetes objects actually matter, and what problem does each one exist to solve?

A pod is not "a container with extra steps". It is a boundary around processes that must live and die together and share one network identity — which is a rare requirement, and the reason most pods should hold exactly one container.

Q · What is the unit Kubernetes actually schedules, and when does more than one container legitimately belong inside it?

You do not create pods. You declare a replica count and an image, and a two-level controller chain creates, replaces and gradually rolls over the pods that satisfy it.

Q · How do I go from "I want three copies of this image running" to three actual pods, and what happens when I change the image?

Desired 3, Pod B dies, the controller sees 2 and creates a replacement. That mechanism is genuinely valuable and genuinely narrow: it restores counts, and it cannot tell the difference between a dead process and a broken deployment.

Q · What exactly does an orchestrator repair on its own, and which failures does it dutifully make worse?

Pods get an IP address they did not choose and lose it on every replacement. A Service is the indirection that gives a changing set of pods one name, one address and one place to make routing decisions.

Q · If every pod's IP address changes whenever it is replaced, how does anything ever find anything?

Internet → load balancer → ingress controller → Service → pods. One external entry point, one place where host and path routing and TLS termination live, and N internal services behind it instead of N public load balancers.

Q · How does a request from the public internet reach the right pod, with TLS terminated and without one load balancer per service?

Configuration and credentials both come from outside the image, and Kubernetes offers two objects for them. The difference is smaller than the names suggest: a Secret is base64-encoded, not encrypted, and readable by anyone with namespace access.

Q · Where does environment-specific configuration come from, and does putting a credential in a Secret object actually protect it?

A stateless replica is interchangeable and disposable. A database replica has an identity, a disk, a position in a replication stream and a startup order — and running one on Kubernetes is a real decision with a real bill, usually payable in your own time.

Q · What changes when a workload owns data, and should that workload be running in the cluster at all?

A pod says it needs 500 millicores and 1 GiB. The scheduler eliminates every node that cannot satisfy that or violates a constraint, scores the survivors, and binds. When nothing survives the filter, the pod says Pending and the events say exactly why.

Q · Which machine does this pod land on, and what do I read when the answer is "none of them"?

A request is what the scheduler reserves for you. A limit is the ceiling the kernel enforces. They are not the same number, and CPU and memory behave fundamentally differently when the ceiling is reached — one throttles, the other kills.

Q · What do I actually promise when I write `requests` and `limits`, and why do CPU and memory behave so differently at the boundary?

The two ways a container hits its ceiling look nothing alike. Memory exhaustion kills the process loudly and leaves a restart count. CPU throttling leaves no restart, no error and an unremarkable CPU graph — just latency that tripled.

Q · A service got slower with no restarts and no CPU spike. What is actually happening, and how would I prove it?

Traffic rises, a metric rises, the controller computes more replicas, the scheduler places them, images pull, the application warms up. Every one of those steps takes time, which is why autoscaling never arrives during the spike that needed it.

Q · How does replica count follow demand automatically, and how late is the capacity when it finally arrives?

Two engineers, one API, one hundred requests per second. Do they need Kubernetes? No. This lesson makes that answer defensible: what a cluster actually costs, what the simpler options give you, and the small number of conditions that genuinely change the answer.

Q · This system is two engineers, one API and a hundred requests per second. Does it need Kubernetes?

Not "no servers" — a different unit of allocation. Code is registered with a platform, an event causes an execution environment to exist, the code runs, and the environment is reclaimed. Everything surprising about serverless follows from that last clause.

Q · What actually happens between an event arriving and my code running, when there is no instance I provisioned?

Cold starts, wall-clock limits, enforced statelessness, concurrency ceilings, thin observability and a bill that is linear in traffic. The honest sheet — including why "serverless is always cheaper" is a red flag rather than a summary.

Q · What am I actually giving up when I move a workload onto a function platform?

The arithmetic that breaks the first serious serverless deployment: 20 app servers held 20 connections; 1000 concurrent function environments want 1000, against a database that accepts 100. The proxy is the answer, and it is not free.

Q · Why does a function that worked perfectly in staging exhaust the database the first time real traffic arrives?

This module does not re-teach IP, subnetting, routing or TCP — those live in the Networking domain. It teaches what a provider hands you on top of them, and why a packet needs five separate things to agree before it arrives.

Q · Which cloud constructs sit between the internet and my workload, and what does each one actually decide?

A logically isolated network you own inside someone else's data center: an address range, subnets, routes, gateways and firewall rules. Two of those decisions are effectively permanent, and one of them is made in the first five minutes.

Q · What exactly do I get when a provider gives me a "network", and which of its properties can I never change?

The difference is one line in a route table, not a property of the subnet. Which is why the useful question is not "is this subnet public" but "does this workload need a public address at all" — and for most workloads the answer is no.

Q · Which workloads need to be addressable from the internet, and what changes for the ones that do not?

Destination → target, evaluated by longest prefix match, attached to a subnet. Three columns and a handful of rows that decide whether anything in your network can reach anything at all — and whose failure mode is always a hang.

Q · When a packet leaves a workload, what decides where it goes next — and why does the wrong answer produce silence instead of an error?

The door between a virtual network and the internet — and only the door. Attaching one is necessary for reachability and nowhere near sufficient, which is why "it has an internet gateway and still cannot reach the internet" is the most reliable lab in this module.

Q · What does attaching an internet gateway actually give me, and what else has to be true before a packet arrives?

How a workload with no public address still reaches the internet — and why the component that grants it is a shared, metered, surprisingly fragile choke point.

Q · How does a workload in a private subnet call an external API without becoming reachable from the internet?

Source → protocol/port → destination, evaluated per resource, allow-only, and stateful — the reply to an allowed request is always permitted. The single most useful property is that a rule can name another group instead of an address range.

Q · What is allowed to reach this specific resource, and what is it allowed to reach in return?

Subnet-level, ordered, allow-and-deny, and stateless — which means the return traffic needs its own rule. That one word, stateless, is the entire lesson and the source of every incident this construct causes.

Q · When is a coarse, stateless, subnet-wide filter worth adding on top of stateful per-resource rules?

Peering, private endpoints, service endpoints and transit hubs — four ways to reach something without traversing the public internet. They exist for exposure reasons and they usually pay for themselves by taking traffic off the NAT meter.

Q · How does a private workload reach another network or a provider service without a path to the internet?

api.example.com → DNS → load balancer → application. In cloud, DNS is not just a lookup table: it is a routing layer with health checks, geography and weights — and a cache you do not control that makes every change slower than it looks.

Q · How do clients find my infrastructure, and what does DNS decide that a load balancer cannot?

The Architecture domain argues why you need one. This lesson is about running it: external versus internal, L4 versus L7, health checks that tell the truth, TLS termination, and target registration that has to keep up with a deploy.

Q · What does a load balancer own in a deployment, and which of its settings turns a rolling deploy into an outage?

User → edge → origin. From the deployment side a CDN is three things at once: a latency reduction, an origin shield that absorbs traffic your infrastructure never sees, and a cache-invalidation problem you now own.

Q · What changes in my infrastructure when an edge network sits in front of it?

Three storage contracts, not three products: a blob you address by key and replace whole, a raw device your operating system formats, and a filesystem several machines mount at once. Choosing the wrong contract is the expensive mistake — the vendor is a footnote.

Q · Which storage contract does this data need — a whole-blob namespace, a raw device, or a filesystem several machines share?

A bucket, a key and a blob of bytes with metadata attached — effectively unbounded, reachable from anywhere with credentials, and priced per request as well as per gigabyte. It is the right home for uploads, backups and static assets, and it is not a replacement for a relational database.

Q · Where do large, immutable files live when they must be durable, cheap and reachable from every part of the system?

The application decides who may upload and where, then gets out of the way: the client sends the bytes straight to object storage with a short-lived signed authorization. Your servers authorize the transfer without ever carrying it.

Q · How does a client upload a 500 MB video without that traffic passing through — and tying up — the application servers?

A virtual disk attached to one instance: fixed-size blocks, random writes, a filesystem on top and a database on top of that. It is the only contract that gives a storage engine what it needs — and the only one that can fill up.

Q · What kind of storage does a database need, and why can it not be a bucket or a network share?

A real filesystem, exported over a network, mounted by several machines at once. It is the contract you choose when software demands a path and you cannot change the software — and every filesystem operation is now a network call.

Q · When several machines must see the same files at the same time, what does a shared filesystem actually give you and what does it charge?

Four questions decide it: do you need filesystem semantics, raw disk-like access, massively scalable blobs, or several machines sharing files? Each answer comes with what it costs you, because a recommendation without a trade-off is not a recommendation.

Q · Given how this data is written and read, which storage contract is right — and what does that choice cost me?

The provider runs the process, the volume, the backups, the patching and the failover. You still own the schema, the queries, the indexes, the access control, the instance size and the bill. Managed moves the boundary; it does not remove your half.

Q · When I use a managed database, which operational work has actually gone away — and which work is still mine?

Less infrastructure burden against more control and more operational responsibility. The decision turns on expertise, customization needs, cost at your scale and how much operational risk the team can absorb — and there is no universal winner.

Q · Should this database run as a managed service, or on infrastructure we operate ourselves?

Four nouns explain every access decision in cloud infrastructure: an identity performs an action on a resource, and a policy says whether that is allowed. Everything else — roles, groups, conditions, boundaries — is a way of managing those four at scale.

Q · When a request reaches a cloud service, what exactly decides whether it is allowed?

Applications should not borrow human credentials. A developer's access key in an environment variable gives the application the developer's permissions, records the developer as the actor in every audit log, and takes production down the day that developer is offboarded.

Q · Whose identity should an application present when it calls a cloud service?

Take one workload, write down what it actually needs, then read what its policy actually grants. The gap between those two lists is the lesson — and the blast radius is how you measure it.

Q · How do I read a policy and tell, in under a minute, whether it grants more than the workload needs?

The measure is not how clean the policy looks. It is what an attacker can do in the first ten minutes after they hold this credential. Ask the blast-radius question out loud, for every identity, before it reaches production.

Q · What is the blast radius if this identity is compromised?

A workload should receive a credential that expires in minutes, not hold one that never does. A leaked one-hour token is an incident with an end time; a leaked long-lived key is an unbounded one that may already be years old.

Q · Why is a short-lived role credential a fundamentally different security object from a long-lived access key?

The secrets that genuinely cannot be roles — third-party keys, database passwords, signing material — need one place that answers five questions: where it is stored, who may read it, how it rotates, who read it last, and how fast it can be revoked.

Q · Where does a credential live when the workload cannot get one from an identity provider?

Data is encrypted with a data key; the data key is encrypted by a key you never see, held in a key management service. What you actually operate is not cryptography — it is the policy on that key, and the answers to who can decrypt, what deletion means, and what rotation really re-encrypts.

Q · If everything is encrypted at rest by default, what is actually left for me to decide?

Infrastructure defined in files under version control and applied by a tool rather than by a human in a console — so the environment can be rebuilt, diffed, reviewed and explained six months after the person who built it left.

Q · How do I make the infrastructure that runs production reproducible, reviewable and recoverable instead of a shape that exists only inside one account?

Desired state against a sequence of operations. Declarative tools converge and can preview; imperative scripts execute and cannot. Neither is universally right — a one-off operational task is a script, and pretending otherwise produces the worst code in the repository.

Q · Should I describe the infrastructure I want, or the steps that produce it — and when is the sequence actually the better model?

Resource, provider, variable, output, module, state, plan, apply. Seven of these eight words exist in every declarative IaC tool; learn them as concepts and Terraform becomes the worked example rather than the subject.

Q · What are the actual moving parts of a declarative IaC tool, and which of them are Terraform-specific rather than universal?

State is the map from declared resources to real ones. Without it the tool cannot tell "create" from "already exists". With it you own a lock, a backup, a plaintext secret store, and the only artifact whose corruption can make production unmanageable while it is still running.

Q · Why does a declarative tool need a state file at all, what exactly is in it, and what happens when two engineers apply at the same time?

A plan is a contract for what is about to happen to production. Learning to read it — especially the difference between ~ update in place and -/+ destroy and recreate — is the highest-value hour in this module.

Q · What exactly does a plan tell me, and which line in it means production is about to be destroyed and rebuilt?

The configuration says three servers; there are two, because someone deleted one during an incident. Or there are four, because someone added one by hand — and the next apply will delete it. Drift is not an anomaly; it is the normal consequence of production being touchable.

Q · What happens when someone changes infrastructure outside the tool, and how do I detect and reconcile it before the next apply makes the decision for me?

A module is a named boundary with an interface — a web service as load balancer plus compute plus identity plus alarms, instantiated four times. It earns its place when it removes a decision. A module that wraps one resource and exposes twenty variables is worse than the resource.

Q · When does grouping resources behind an interface make infrastructure clearer, and when is it just a second syntax for the same resource?

Environments must match in the ways that make a test meaningful — topology, deployment path, IAM shape, configuration mechanism — and must differ in the ways that make them affordable and safe: size, data, redundancy, access. A staging that is an exact full-scale copy of production is a bill, not a guarantee.

Q · Which properties of production must my lower environments reproduce, and which ones must they deliberately not?

Git push → CI → test → build → artifact → deploy → production. The part people skip: the pipeline holds production credentials, so it is a production system with a production identity, and it is the most attractive target in the estate.

Q · What actually happens between a commit and running code, and what does the machinery in the middle have permission to do?

The artifact that passed staging must be the artifact that reaches production — the same image digest, not a rebuild from the same tag. Rebuilding per environment means staging tested something that no longer exists.

Q · If staging passed, what exactly did it prove — and is that thing the same thing that reaches production?

Recreate, rolling, blue/green and canary. They differ on rollout speed, rollback speed, capacity cost, risk exposure and what compatibility they demand of your code and schema — and the compatibility column is the one that decides most real arguments.

Q · Which rollout strategy fits this workload, and what does each one demand from the code and the database in return?

V1 V1 V1 V1 → V2 V1 V1 V1 → V2 V2 V1 V1 → V2 V2 V2 V2. Capacity stays flat and there is no window — in exchange, both versions serve traffic against one database, so every change must be backward compatible for at least one release.

Q · What must be true about my code and my schema before replacing instances a batch at a time is actually safe?

Blue is what is serving. Green is the new version, fully built and verified while nobody is looking. The switch is a load balancer change and rollback is the same change in reverse — which is why it is the fastest rollback there is, and why the database, which does not switch, is the part that ruins it.

Q · How do I get a rollback measured in seconds, and what does the database do while the application environment is being swapped underneath it?

95% to the current version, 5% to the new one, then increase — but only if the metrics say so. The strategy has the smallest blast radius of the four and one hard prerequisite: without per-version metrics you can decide on, a canary is just a slow rolling deploy that cost you a routing layer.

Q · How do I expose a new version to real production traffic while limiting the damage a bad one can do — and what has to exist before that is more than theatre?

Shipping the code and turning the behaviour on can be two separate operations, minutes or months apart. That decoupling is the most powerful risk-management tool in delivery — and it buys itself with flag debt, a combinatorial test surface, and a second control plane nobody treats as production.

Q · What changes when the decision to run new code and the decision to expose new behaviour stop being the same event?

Deployment starts → stop accepting new traffic → finish in-flight work → close resources → terminate. Skip the middle and every deploy drops the requests that were in progress, producing a small, regular spike of 502s that gets explained away as "just the deploy".

Q · What must a process do between being told to stop and actually stopping, so that no request in progress is lost?

Capacity that follows demand instead of a human. Horizontal, vertical, scheduled and metric-based scaling, what each one actually changes — and why every one of them reacts to load that has already arrived.

Q · How does the amount of capacity running follow the amount of demand arriving, without a human watching a graph?

Scale on the signal that represents workload pressure. CPU is the default and it is frequently the wrong answer — an I/O-bound service saturates its connection pool at 30% CPU while the scaler reports everything is fine.

Q · Which measurement should decide how much capacity is running — and why is the easiest one to read usually the wrong one?

New capacity does not appear when you ask for it. Decompose the delay — metric window, decision, provisioning, image pull, runtime boot, warm-up, health check — and the reason autoscaling always looks late stops being mysterious.

Q · Why does capacity requested now start serving traffic minutes from now, and which part of that delay can I actually shorten?

The mechanism that decides which instances receive traffic. A check that only proves the web framework is running proves nothing; a check that verifies every dependency turns one slow dependency into a total outage.

Q · How does the load balancer decide which instances are allowed to receive requests, and what should that check actually verify?

Two probes answering two different questions. Liveness asks whether the process is alive enough to continue; readiness asks whether it can serve traffic right now. Confusing them turns a database blip into a fleet-wide crash loop.

Q · What is the difference between "restart this process" and "stop sending it traffic", and why does confusing them cause outages?

Reliability is four questions asked of every component: when this fails, is there a redundant one, is traffic rerouted, is state preserved, and how do we get back? A "yes" that has never been demonstrated is a "no".

Q · When a piece of this infrastructure dies, what happens next — and who or what makes it happen?

The standard shape: one region, an application spread across two zones, a load balancer in front. What it protects against, what it does not, and why database redundancy is a separate problem with a separate answer.

Q · What is the smallest topology that survives losing a host or a zone without a customer noticing?

The ladder from process to region, and the one question that finds most reliability bugs: are all the replicas actually in the same failure domain? Three replicas on three VMs in one zone is one failure domain wearing a disguise.

Q · When something fails, what else fails with it — and are my replicas genuinely independent or only visually separate?

Spreading a workload across the independent facilities inside one region. The reliability is real, the latency is small but not zero, the data placement is subtle, and the cross-zone transfer meter is the line item nobody predicted.

Q · What does spreading a workload across zones inside one region actually buy, and what does it charge for?

Running in more than one geographic region. It is the answer to latency, to regional failure and to data-residency law — and "multi-region" on its own says nothing about availability. A multi-region deployment with one primary database in one region is single-region availability with a bigger bill.

Q · What does a second region actually buy, and which of those things does it fail to buy unless you also solve the data problem?

One region serves; another waits. Simple, cheap compared with active-active, and built entirely around a failover path that almost nobody tests — which is why the standby so often fails on the one day it is needed.

Q · If one region serves everything and another waits, what exactly happens at the moment the first one fails?

Both regions serve traffic at the same time. It removes failover from the critical path and replaces it with a permanent distributed-data problem: conflicts, ordering, routing and consistency, all live, all the time.

Q · What does it take for two regions to serve traffic simultaneously, and what problem do you take on permanently in exchange?

What you do when redundancy was not enough: backup, restore, failover, and the two numbers that decide which of them you need. DR is the plan for the failures that take the whole environment, including the ones you caused yourself.

Q · When the environment itself is gone — a region, an account, a deletion nobody meant to run — what is the documented path back, and how long does it take?

Two numbers that turn "we need it to be reliable" into an architecture. RPO is how much data you can afford to lose; RTO is how long you can afford to be down. Derive the design from the numbers, never the numbers from the design.

Q · How much data may we lose, and how long may we be down — and what does each answer force us to build?

A backup is only a backup if it is in a separate failure domain. Same account, same region, deletable by the same credentials that just got compromised — that is a copy, and it does not survive the most common causes of data loss.

Q · Where does the second copy live, who can delete it, and how far back can it take us?

A backup you have never restored is not proven recovery. It is a file with a hopeful name. The only way to know whether you can recover is to recover, on a schedule, with a stopwatch.

Q · How do you know your backups work — and what is the only answer that is not a guess?

Not a second observability course. The signals that belong to the platform rather than the application — resource envelope, instance and pod health, autoscaling behaviour, load-balancer target health, provider service errors and the bill — and which of them stays reassuringly green through an outage.

Q · Which signals tell me the platform underneath the application is healthy, and which one lies?

Five log streams your application never writes — audit, access, load balancer, control-plane and deployment — and the specific question each one is the only source for. Plus the reason they are a top-five line item on the bill.

Q · When the application log says nothing useful, which infrastructure log stream holds the answer?

Who changed this infrastructure, what did they change, when, and from where? The four questions an audit log exists to answer — plus the two honest caveats: the log is worthless if nobody reads it, and the identity in it is meaningless if six services share one key.

Q · Who changed this infrastructure, what did they change, when, and from where?

Every infrastructure diagram in this domain gets a second reading. The overlay highlights seven things — public exposure, private networks, identities, secrets, encrypted links, privileged resources and trust boundaries — and turns "here is our architecture" into "here is what an attacker can reach and what they get".

Q · What does this infrastructure diagram look like when you read it the way an attacker would?

A scanner that flags every public endpoint is useless. The skill is judging which exposure is the design and which is the finding: a load balancer on 443 is the front door, a database on 5432 is an incident waiting, and a public bucket is either a website or a data breach depending entirely on what is in it.

Q · This resource has a public address — is that the design working, or is it the finding?

Five places where trust changes hands — internet to edge, edge to application, application to data, CI to production, provider to you — and the specific control that has to enforce each one. Most incidents are a boundary that was assumed rather than enforced.

Q · Where in this system does trust change hands, and what actually enforces it there?

Source → build identity → artifact → registry → what production actually pulls. Every hop is a place to substitute something. The two questions that matter: can you prove the running image came from your source, and who else could have put something there?

Q · What exactly is running in production right now, and can you prove it came from your source?

Cost is a design constraint, not a monthly report. The ten drivers that actually move an infrastructure bill, why the ones nobody predicts are always the ones that move bytes rather than store or compute on them, and how to make spend a signal an engineer reads.

Q · What does this architecture cost to run, and which line item is the one nobody predicted?

An always-on instance bills for existing; a serverless invocation bills for happening. The crossover between those two shapes decides which one is cheaper, it moves with traffic, and nobody can tell you where it sits for your workload without measuring — which is why every number here is illustrative.

Q · Does this component bill me for existing or for being used, and at what traffic does the answer flip?

Allocated 100 CPU, using 12. The naive reading is that 88 units are wasted; the honest reading is that some of them are the reliability budget. Telling the two apart — and cutting only the second — is the difference between a saving and an outage at the next spike.

Q · We are paying for 100 units of capacity and using 12 — how much of that gap is waste, and how much is keeping us up?

A 32 GiB instance with 4 GiB in use looks like an obvious eight-fold over-provision. It sometimes is. But average use is not a sizing input: size for the peak, then for what happens when a zone fails and its traffic lands on the survivors.

Q · This instance is far larger than its average usage — how much smaller can it safely be?

Breaking the bill down by service turns "infrastructure costs too much" into a conversation someone can act on. The mechanism is tagging, the hard part is the shared resources that resist attribution, and the honest output is an allocation rule everybody agreed to rather than a precise truth.

Q · Which service is responsible for which part of the bill, and who can act on it?

The line item that surprises everyone. Storing a terabyte is cheap; serving it repeatedly is not, and the meters sit on paths an architecture diagram draws as plain arrows — internet egress, cross-region replication, cross-zone chatter and the NAT you forgot processes every outbound byte.

Q · Which arrows on this diagram have a meter on them, and how much data crosses each one?

Data gets colder with age and almost nothing deletes itself. Lifecycle policies move objects down the tiers automatically — and the archive tiers hide a trap, because they charge to read the data back, charge again if you delete it early, and take hours to return it.

Q · This data has not been read in eight months — where should it live, and what does it cost to get it back?

An agent run is a long-lived job with external dependencies, privileged credentials and untrusted tool output. The infrastructure that supports it is a queue, a worker pool, a sandbox and a trace — not a bigger web server.

Q · What does a model or agent workload need from infrastructure that an ordinary request/response service never asked for?

An optional advanced module. GPU instances are rented by the hour and bill identically whether they are saturated or idle, so utilization and batching are the entire cost story — and the model fitting in memory is the binding constraint, not raw throughput.

Q · When does a workload need an accelerator, and what changes about scheduling, memory and cost when it does?

Four provider-neutral categories for running a model, compared on cost shape, latency, control, data boundary and scaling — and an honest account of which one a team of five should actually pick.

Q · Should this workload call a hosted model API, deploy to managed inference, self-host on our own compute, or run a dedicated accelerator cluster?

Running on two providers does not make a system more reliable by itself. It duplicates networking, identity, observability and expertise, and it is only justified by a business requirement you can name in one sentence.

Q · What concrete business requirement would justify running this system on more than one cloud provider?

On-premises and cloud connected by private links, run as one system. A legitimate and common architecture — for legacy systems, compliance, data locality and gradual migration — with a network seam that becomes the most important thing you operate.

Q · When should some of the system stay on-premises, and what does connecting the two halves actually commit us to?

Inventory, dependency mapping, strategy, pilot, gradual move, validation. Migrations do not fail at the cutover — they fail at the inventory, on the undocumented cron job running on the server nobody owns.

Q · How do we move an existing production system to the cloud without discovering its real dependencies during the cutover?

Rehost, replatform, refactor, retain, retire — five decisions about what to do with a component, each with a different effort, risk and payoff. Retire is frequently the one with the highest return, and nobody puts it on the plan.

Q · For this specific component, is the right move to lift it, adjust it, rewrite it, leave it, or delete it?

A deliberately crude, simulated score that makes "we added Kubernetes, a mesh and multi-region" visible as a decision with an ongoing price — measured in on-call surface, upgrade cadence, required expertise and how hard debugging becomes.

Q · How much operational complexity has this architecture actually committed the team to, and which parts of it does the workload require?