About this interactive
Deployment models are not a vocabulary list — they decide who replaces a failed disk at 3am, who signs the compliance attestation, and which line of the budget the bill lands on. Every one of the thirteen scenarios is sorted by three questions, asked in order: who owns the hardware, whose building is it sitting in, and does it behave like a cloud at all — pooled, virtualized, provisioned on demand? Public cloud is the easy end. The provider owns the hardware, it is in the provider's building, and you share it with strangers: a startup running everything on AWS pay-as-you-go on shared physical infrastructure, and a SaaS company on Azure virtual machines with no dedicated hardware in a multi-tenant environment. Both sentences say the quiet part out loud — shared — and that word is doing the work, not the vendor name. On-premises is the other easy end, and it is defined by an absence. The company that buys dedicated hardware, puts it in its own on-site datacenter and manages it entirely owns everything and has built no cloud layer on top; the manufacturer running an air-gapped control network with no internet connectivity is the industrial version of the same answer. Air-gapping is a security control, not a sixth deployment model. It is tempting to treat "no internet" as exotic, but it only makes the classification more emphatic: hardware you own, in your building, reachable by nobody. The sharpest pair in the whole set is that first on-premises item against the bank that builds a virtualized environment on hardware it owns and operates in its own facility. Read those two sentences side by side and one word separates them: virtualized. Both organizations own the hardware. Both run it in their own facility. On-premises describes WHERE the hardware is; private cloud describes HOW it is consumed. Racking twenty servers and handing one to each department is on-premises. Pooling those same twenty behind a hypervisor so departments provision from the pool on demand is a private cloud — and it is still on-premises hardware, which is exactly why the two are not opposites and why private clouds so often sit in the company basement. The government agency running OpenStack on dedicated servers it controls, reachable only over VPN, is the same shape: a named cloud platform, dedicated hardware, one tenant. Private cloud against colocation is the distinction this activity exists to force, and ownership will not settle it, because in both the organization owns every server. The discriminator is the building first and the layer on top second. Colocation is a real-estate, power and connectivity arrangement: shipping your own servers to Equinix and renting rack space, power and cooling; owning the hardware but placing it in a third-party datacenter with redundant internet uplinks; putting your own trading servers inside an exchange's facility because the speed of light through fibre is the actual constraint. In all three the organization still owns and administers every machine — what it bought was floor space, electricity, cooling and a cross-connect. Nothing is pooled, nothing is elastic, nobody provisions anything on demand. The honest complication, worth knowing because it appears in real architecture reviews, is that a private cloud can live inside a colocation cage. The two words answer different questions, so they are not mutually exclusive in the world; this set keeps them apart by naming only one property per item. Every colocation item talks about space, power, cooling, uplinks, latency and facilities, and neither private cloud item mentions a building it rents. When a real scenario names both, take the property the question is testing. Hybrid cloud carries the single most common misconception in this topic: that hybrid means more than one cloud provider. It does not. That is multi-cloud, and it is not one of these five bins. Hybrid means at least two different KINDS of environment, connected so that data or workloads move between them — cloud plus non-cloud, or public cloud plus private cloud. The retailer processing payments in a private datacenter and bursting to AWS for Black Friday is cloud bursting, the textbook shape. The healthcare organization keeping patient records on-premises for compliance while running analytics in Azure is the compliance-driven split: the regulated data never leaves, the workload that needs elasticity goes out. The third one is the one that catches people, because neither half is on-premises — an enterprise keeping sensitive data in a private cloud while using Google Workspace for collaboration. Private cloud on one side, public SaaS on the other: two different kinds of environment, so still hybrid. Two AWS regions would not be hybrid at all, and two different providers would be multi-cloud. The reliable tell is a conjunction. Every hybrid item names two environments in one sentence — "but", "and also", "bursts to" — and nothing else in the set does. The last item names a defense contractor running a dedicated-tenancy AWS deployment reserved for its own compliance workloads, with hardware never shared outside the company — and it exists to catch the reflex of hearing "AWS" and reaching for Public Cloud. What decides the bin is never the vendor name; it is WHO IS ALLOWED TO BE A TENANT. This activity's own term bank, a few inches up the page, defines private cloud as dedicated to a SINGLE ORGANIZATION — and "never shared outside the company" is that definition stated in the scenario's own words. A major provider can host a private cloud on its own hardware, provisioned exclusively for one customer; the provider's logo on the invoice does not make it public. Contrast this with GovCloud-style offerings that serve many separate agencies and contractors under one shared compliance umbrella — under NIST SP 800-145 that shared-tenant, shared-community shape is a distinct model, community cloud, which sits outside this five-bin set entirely. The tell that keeps the two apart is exclusivity: one tenant only, versus a vetted community of tenants. Getting the five models cold is worth the effort because they are how responsibility gets assigned. Public cloud moves hardware failure to the provider and leaves configuration with you. On-premises and colocation leave the hardware entirely yours and differ only in whose power bill it is. Private cloud buys you cloud consumption without cloud tenancy, at the cost of building it yourself. And hybrid, the model most enterprises actually run, means owning two answers at once and the connection between them.