TL;DR: Three mechanical differences: provider capacity is available through APIs without buying each server, capacity can expand within available quotas, and failure is your problem at the application layer because the provider only guarantees components. The economic difference: ownership costs shift toward service charges, with accounting treatment depending on the arrangement with its own failure modes.
How to approach it
Resist listing service names. Name the structural differences and give one concrete consequence of each. If you can explain what becomes easier and what becomes harder, you pass; if you recite "on-demand self-service, broad network access", you do not.
A strong answer
Provisioning is an API call. A virtual machine, a database, a network, all created and destroyed programmatically in minutes. The real consequence is not speed for its own sake: infrastructure becomes software. It can be version-controlled, code-reviewed, tested and rolled back like application code, which is why Terraform and GitOps exist. An on-premises private cloud can provide the same API workflow within installed capacity; adding physical capacity still requires procurement.
Capacity is elastic. Add twenty instances for two hours during a sale and delete them after, paying for what burned. The consequence cuts both ways: no more sizing for peak year-round, but also no natural brake on waste. An idle on-premise server costs what it cost; an idle cloud fleet costs continuously, which is why cost discipline is a core engineering skill now rather than a finance afterthought.
The responsibility line moved, deliberately. The provider guarantees components: disks replicate, racks have power, the hypervisor isolates tenants. It does not guarantee your application survives an AZ outage, a quota limit, or your own misconfigured security group. Multi-AZ means the building blocks are redundant in different buildings; whether your traffic actually fails over is your architecture's problem. Candidates who believe "it is in the cloud so it is highly available" fail loops on this alone.
Economically, owning hardware is replaced by service charges under a mix of usage, subscription and commitment terms. Billing units and accounting treatment vary; neither five-year depreciation nor per-second billing is universal. This buys optionality: experiments cost hours of usage instead of hardware purchases. It also introduces bill shock, egress fees and reserved-capacity decisions that need analysis, so the finance conversation moves into engineering.
The honest counterpoint worth offering: none of this is free. Cloud trades operational control for convenience, can add latency when compute, users and data are separated, and at steady, predictable scale the premium can exceed hardware costs. Companies at very large scale (and regulated ones with data-locality constraints) run their own machines for exactly this reason. Knowing when the model stops paying for itself is a senior signal.
NIST cloud definition documents the provider or model boundaries used here.
What interviewers probe next
"So should everything be in the cloud?" No. Workloads with stable, high utilisation, strict locality rules or exotic hardware often stay on-premise or colo. Say the conditions rather than picking a side.
"Which difference changes how teams are organised?" Elasticity plus APIs: infrastructure work becomes software work, so platform teams build self-service instead of filing tickets, and reviews happen in pull requests.
"Where does 'the cloud is just someone else's computer' get it wrong?" It ignores the API layer, the component-level redundancy and the managed services. A managed database is not a database on someone else's computer; it is a database with automated backups, patching and failover you did not build.
Common mistakes
Defining by vendor slogans. Interviewers hear a candidate who has read a landing page.
Listing services instead of explaining the model. EC2 and S3 names prove familiarity; they say nothing about understanding.
Claiming the provider handles availability. The provider handles components; you handle architecture. That confusion has caused real outages.