The Startup That Only Has Cloud Concepts (and One Big Deadline)
A 12-person startup has been approved for a 6-month pilot of a public cloud, but the finance team only understands two things: "we do not want to buy servers" and "we need it to be cheaper than the $4,000/month we pay our colocation provider." The engineering lead wants to run a stateful relational database, a batch analytics job that runs once per night, and a public-facing web tier. Compliance has said that customer data must stay in a specific region, and the CEO wants the ability to scale instantly during a product launch. The team has no cloud architects and has never used infrastructure-as-code. They have 30 days before the colocation contract auto-renews for a year.
1. Which cloud concepts should the team use to frame their decision, and what trade-offs should they explicitly document before committing?
Read the worked answer
The team should frame the decision around elasticity vs. predictability, operational responsibility (managed vs. self-managed), capital expense vs. variable expense, and region/availability boundaries. Elasticity is the reason for the pilot: launch traffic can be absorbed without buying hardware, but the database is stateful and cannot be treated like the web tier. They should document that the nightly batch job is a good fit for variable expense (pay only when it runs), while the database is a steady-state cost that may not beat colocation unless they use a managed service and account for operational labor. The compliance constraint pins the region, which also affects latency and service availability. Finally, because no one knows infrastructure-as-code, they should record that manual console changes create drift and make the 30-day exit harder; a short pilot should favor managed services and a documented rollback plan.
2. The CFO asks whether the cloud is "just someone else's computer." How should the engineering lead explain the shared responsibility model in plain terms, and what does the startup still own?
Read the worked answer
The lead should explain that the provider owns security of the cloud - physical facilities, hardware, hypervisor, and the managed-service software layer - while the startup owns security in the cloud - their data, identities, access policies, network configuration, patching of anything they run themselves, and encryption choices. In plain terms: the provider guards the building and the machines; the startup guards who can log in and what data leaves. The startup still owns IAM users and roles, least-privilege policies, key management, backup and retention decisions, and the configuration of any self-managed database. This matters for the compliance requirement: the provider's region certification does not automatically make the startup's workload compliant; the startup must prove its own controls, logging, and data-residency configuration.
3. What single decision most reduces the risk of the 30-day auto-renewal trap?
Read the worked answer
The highest-leverage decision is to avoid a one-way migration and instead run a time-boxed parallel pilot with a documented exit. Concretely: keep the colocation contract for the pilot period but negotiate or confirm the renewal terms before day 30; migrate only the stateless web tier and the nightly batch job first, since both are easy to move back; leave the stateful database in colocation until the pilot proves cost and compliance. This gives the team a real cost comparison without betting the company on an untested platform, and it keeps the exit path cheap. The trade-off is that they do not get a full cloud-native architecture in month one, but they do get evidence before the renewal decision, which is the actual constraint.