Cloud Platform Engineering · Chapter 9 of 9
How a service actually gets adopted in an enterprise
Services are not just switched on. They are blocked by default and walked through a sequence of gates — and knowing that sequence is what a platform interview is really asking about.
Every other chapter in this book is about what the providers sell. This one is about why you cannot use most of it — and it is the chapter that maps most directly onto what a platform, cloud or solutions architect is actually asked in a GCC or an enterprise.
The organising idea
A cloud provider offering a service does not make it available to you. Enterprises run an allow-list: everything is denied by default and services are enabled one at a time, for specific accounts, after somebody walks them through a process. And it is enforced in policy rather than in a wiki page — AWS Service Control Policies, Azure Policy, GCP Organization Policy, OCI Security Zones. If you propose using a service that is not on the list, the API call fails; it does not merely violate a standard.
The gates that actually kill things
Security review is not a checklist question, it is three specific ones. Does the service integrate with your identity provider for both humans and workloads, or does it require a static key — because a static key is a secret to rotate, store and audit forever, and it is the single most common reason a service is refused. Does it emit logs your SIEM — the Security Information and Event Management system that centralises logs — can actually ingest, in a format it understands? And can you hold the keys — customer-managed encryption, or bring-your-own-key?
And the thing almost everyone gets wrong: the shared-responsibility line moves per SERVICE, not per provider.
People learn one diagram — “the provider secures the cloud, you secure what is in it” — and then apply it uniformly. It is not uniform. On a virtual machine you own the guest OS, patching and everything above it. On a managed database you own schema, access and backups-you-configured but not the engine. On a serverless function you own the code, the permissions it runs with — its IAM role, for identity and access management — and effectively nothing else.
Being able to draw the line for the specific service under discussion — rather than reciting the generic diagram — is one of the clearest seniority signals in a cloud interview.
Compliance is where a service dies quietly. For a regulated Indian entity the binding constraints are the RBI's directions on outsourcing of IT services: a regulator right-to-audit clause in the contract, a documented exit and portability plan, and data residency. None of these is something an engineering team can satisfy on its own, and a proposal that reaches this gate without them does not get refused so much as it stops moving.
Three things that stop more proposals than security does
Preview versus GA
Most enterprises will not allow a preview service at all, and this kills more good proposals than any security finding.
The three questions are: is it generally available, is it covered by our support agreement, and is it in the data processing agreement. A preview service typically fails all three — there is no SLA to breach, support will not take a ticket on it, and legal has not papered it.
Which means the answer to “can we use the new thing announced last week” is almost always no, and the useful follow-up is when it goes GA and whether anyone has asked for an exception before.
Generally available does not mean available in your region. A launch announcement describes a service, not its footprint. Whether it exists in ap-south-1, Central India or asia-south1 is a separate question with a separate answer, and it is a constant, concrete frustration for engineers building in India — the reference architecture works, the region does not have the service, and the workaround is either cross-region traffic you now have to justify on both latency and residency grounds, or a different design.
And there is always an exception process. How it works tells you what kind of organisation you have joined: who can grant one, whether it is time-boxed, whether anyone tracks the debt it creates. Ask about the exception process in an interview and you learn more about the engineering culture than any question about the stack.
Honest timelines, and the failure mode
| Situation | Realistic elapsed time |
|---|---|
| A pre-approved service in an existing landing zone | Days. This is the whole point of the paved road |
| A new service in an already-approved category | Weeks |
| A genuinely new service class — first of its kind in the estate | Months, because security, legal and procurement are all first-time |
| Anything in a regulated entity touching customer data | Longer, and the constraint is rarely engineering |
The failure mode worth naming, because you will meet it.
A cloud centre of excellence that behaves as a gate rather than an enabler gets routed around. Not defied — routed around. Shadow IT, someone's personal account, a SaaS bought on a corporate card, a workload quietly deployed in a region nobody is watching.
The measure of a platform team is not how much it blocks; it is how short the path is to doing the right thing. If the compliant route takes three months and the non-compliant one takes an afternoon, you have not built a control — you have built an incentive.
Check yourself