There is a particular kind of frustration in having working, tested, reviewed code and no way to run it. Not a technical obstacle — a queue. Somebody in another organisation has to click something, and until they do, the sprint is a spectator sport.
This is the part of regulated cloud delivery that never appears in a demo, and it is the part that most reliably eats a schedule.
The chain, generalised
Every one of these bit us in sequence, each discovered only when the previous one cleared.
The guest identity itself. An external delivery team works through guest accounts in the client's directory. Those accounts are governed by access-review and security policies, which means they can be automatically disabled — and the policy does not know or care that you are mid-deployment. We lost time to an identity that had simply been switched off by a scheduled review while everyone assumed it was working.
First-run pipeline authorisation. A deployment service connection typically needs an explicit human authorisation on its first use. Reasonable control. Also a hard stop, at exactly the moment you have something to deploy.
Project administration rights. Without them, every subsequent settings change is another request to another person. With them, the delivery team can self-serve. This one is worth asking for early precisely because it eliminates a whole class of future requests.
Subscription-level resource-provider registration. This is the interesting one. Registering a resource provider is a subscription-scoped operation, which means a resource-group-scoped deployment identity structurally cannot do it — not as a policy choice, but as a consequence of the scoping you correctly chose. No amount of retrying the pipeline fixes it. A client administrator has to act.
RBAC escalation. The application needs data-plane role assignments. Something has to create them. If that something is the pipeline, the pipeline needs rights to assign roles — which is its own careful decision, covered in the next article.
Why it costs so much more than it should
Each item on that list is, in isolation, a two-minute action for the right person. The cost is not the action. It is the round-trip.
Discovered one at a time, each gate is: hit the failure, diagnose it, work out who can fix it, write the request, wait for that person to reach their queue, get it done, retry, hit the next one. The waiting is measured in days because the person on the other end has a job that is not your project.
Five of those in series is not five failures. It is most of a sprint.
The three things that actually fixed it
Write an access map before you write infrastructure. Every one of those five gates is predictable from the architecture. If you know you are deploying with a federated identity into a resource group in someone else's subscription, you know you will need provider registration and role-assignment rights. Sit down before the first line of Bicep and enumerate every permission the delivery will need, and who owns it. This takes an hour and is the single highest-return hour in the project.
Batch the requests. One message containing all five, rather than five messages over three weeks. Client administrators are not slow; they are busy, and they context-switch at the same cost you do. Giving them everything at once means they schedule one block of work instead of five interruptions — which is better for them as well as for you.
Write click-by-click guides, not jargon. This one surprised us with how much it mattered. A request that says "please register the Microsoft.App and Microsoft.OperationalInsights resource providers on the subscription" puts the burden of translation on someone who may not use the portal daily. A request with the portal path, the exact blade, the exact toggle, and a screenshot converts a two-day wait into a two-minute action. It is not condescending. It is respecting that the administrator's expertise is in their environment, not in your deployment.
We went from multi-day turnarounds to same-day almost entirely on the back of that third change.
Least-privilege is still right
It would be easy to read this as an argument for looser permissions. It is the opposite.
Every one of those gates exists because someone made a correct decision about not handing out standing broad access. That decision is right, and the friction it produces is the cost of it being right. The mistake is not having the controls — it is failing to plan for the request flow they imply, and then experiencing predictable friction as if it were bad luck.
This is worth saying plainly to delivery teams who find themselves blocked: the client is not being obstructive. The client is running the controls that a regulated organisation is supposed to run. Your plan should have had them in it.
What this means for planning
For the first sprint of a regulated cloud delivery, access is the plan. Not a risk on a register — the actual content of the first iteration.
That reframing changes what you do. You front-load the access map. You deploy a walking skeleton whose entire purpose is to walk the gauntlet early, while there is still schedule to absorb it. You report "built" and "deployed" as two separate things, because conflating them hides exactly this problem. And you treat the client administrator as a named dependency with a name, not as an abstraction called "the client".
How CloudNala can help
We have walked this chain enough times that we now write the access map as a standard first artefact, before any infrastructure code exists — every permission the delivery will need, who owns it, and a ready-to-send request for each. On engagements where the client is a government department or a large enterprise, this is usually the difference between a first sprint that delivers a deployed skeleton and one that delivers a status update explaining why nothing is deployed yet.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za