Skip to main content

Module 5: Cloud and Access

You will eventually need access to something in Azure or Azure DevOps — a database, a resource group, a repository, a board. This module covers the shape of Wasteology's cloud footprint and, more importantly, the two separate systems that govern who can do what, so you request the right kind of access instead of the wrong one.

Three subscriptions, three roles​

Wasteology's Azure resources live across three subscriptions in one tenant:

SubscriptionRole
DevelopmentDev/CI resources — development databases, dev-side pipeline execution, source container registries
ProductionAlways-on platform apps, production databases, the bulk of always-running pipeline execution
OrbitA dedicated subscription for a separate, multi-client work-order platform — kept isolated from the primary Dev/Prod pair

The point of the split isn't bureaucracy — it's blast-radius containment. Dev work shouldn't be able to accidentally touch production data, and the Orbit platform (built for external clients) is deliberately isolated onto its own subscription rather than living alongside internal-only workloads.

Two independent access planes​

This is the part that trips people up: Azure access and Azure DevOps access are two entirely separate systems. Holding a role in one grants you nothing in the other.

Azure RBAC (the cloud resources themselves)​

Governs who can manage or read an actual Azure resource — a database, a storage account, a resource group. It's inherited from subscription or resource-group scope down to the individual resource, and it's granted by someone holding an elevated role (a User Access Administrator, who can grant roles to others, or an Owner).

Azure DevOps access (repos, boards, work items)​

Completely separate from the above. An Azure Contributor or Owner role grants nothing in Azure DevOps, and an ADO admin role grants nothing in Azure — this is the single most common category error people make when requesting access. ADO access itself is two-dimensional:

  • An org-level license tier (a board-only tier with no repo access, or a tier that includes repos).
  • A per-project group membership (a read-only role, a contributor role that can push code, or an administrator role for that specific project).

Both dimensions matter: someone could have the "right" license tier but the wrong project group, or vice versa, and end up with access that doesn't match what they actually need.

Wastey says

External contractors are handled distinctly from internal staff: they're typically invited into an isolated ADO project scoped to just their engagement, as time-boxed guests, rather than added to the shared project everyone else works in. If you're onboarding a contractor rather than yourself, don't assume the same request path applies — ask whoever manages ADO access to set it up correctly the first time.

Requesting access the right way​

The common mistake is asking an informal "can someone give me access to X" in chat, which produces access nobody can later audit or explain. The sanctioned pattern instead:

  1. Know which plane you need. Is this an Azure resource (a database, a resource group) or an ADO artifact (a repo, a board)? The answer determines who can even grant it.
  2. Request the narrowest scope that works. A resource-level grant instead of a subscription-level one, a single-repo grant instead of org-wide, etc. — least privilege isn't a slogan here, it's the default ask.
  3. Go to the right grantor. Azure RBAC changes require a User Access Administrator or Owner; Azure DevOps grants are typically self-served by whoever holds the org's Project Collection Administrator role. Your onboarding buddy or manager can point you to the specific person for your team if you don't already know.
  4. Expect it to be tracked. Access changes here are meant to be auditable — granted deliberately, for a stated reason, not applied ad hoc in the Azure or ADO portal without a record of why.

Hands-on lab​

You're not requesting real access in this lab — you're locating the process so you know exactly what to do when you actually need something.

  1. Think of one piece of access you expect you'll need soon (a specific database, a specific repo, or a specific resource group).
  2. Decide which plane it falls under: Azure RBAC, or Azure DevOps access. Say why.
  3. Find (by asking your onboarding buddy, checking your team's onboarding material, or searching a relevant repo's lat.md/ for a cloud-governance or access-request document) who the right grantor is for that specific request.
  4. Write down the narrowest scope you'd actually ask for — not "give me admin on everything," but the smallest grant that lets you do your job.

Explore the three subscriptions​

Click each subscription to see its role and why it's kept separate.

Three subscriptions, and two independent access planes — Azure RBAC vs. ADO access.
Three subscriptions, and two independent access planes — Azure RBAC vs. ADO access.
Wasteology's three Azure subscriptionsInteractive

Click any step to see what happens and who's responsible.

Decide: which access plane do I need?​

Answer one question and find out which system governs the access you're about to request, and who can grant it.

Choose your pathAzure RBAC vs. ADO access

Is what you need an actual Azure resource — a database, a storage account, a resource group?

Knowledge check​

Why does Wasteology split its Azure resources across Dev, Prod, and Orbit subscriptions?
If someone holds an Owner role on an Azure subscription, what does that grant them in Azure DevOps?
What are the two dimensions of Azure DevOps access?

Next up: the Capstone — put all five modules together.