CH02-06: Global Bank Governance Scenario

Goal

This section applies the Chapter 2 governance model to a realistic enterprise scenario.

The point is not to produce the only possible bank design. The point is to show how landing zones, Azure RBAC, Azure Policy, tags, budgets, resource locks, and central security visibility work together.

By the end of this section, you should be able to explain a governance model in a practical architecture discussion rather than listing governance features one by one.

Scenario

A global bank has 20 business units. Each business unit owns multiple applications. The bank wants business units to deliver quickly, but it also needs strong controls because many workloads are regulated and business-critical.

The governance model must support:

• Business-unit autonomy.

• Central security oversight.

• Regulatory compliance.

• Cost ownership and reporting.

• Production and non-production separation.

• Consistent policy enforcement.

• Safe shared platform services.

• Evidence for audit and operational review.

The design challenge is not central control versus team freedom. A strong design needs both.

The durable idea is:

Enterprise governance works when central teams own guardrails and workload teams own delivery inside them.

Restating the Architecture Problem

Before choosing controls, translate the scenario into architecture questions:

• Where should shared platform services live?

• How should 20 business units receive their own workload boundaries?

• How should production be separated from non-production?

• Where should common compliance policies be assigned?

• How can central security inspect risk without owning every application?

• How can finance map spend to business units and applications?

• How can application teams deploy without waiting for central approval for every normal change?

• Which resources need extra protection from accidental deletion or modification?

These questions map directly to the governance concepts from this chapter.

Proposed Management Group and Subscription Model

One possible structure is:

Microsoft Entra Tenant
  |
  +-- Root Management Group
      |
      +-- Management Group: Platform
      |   |
      |   +-- Subscription: Connectivity
      |   +-- Subscription: Management
      |   +-- Subscription: Security
      |
      +-- Management Group: Landing Zones
          |
          +-- Management Group: Business Unit 01
          |   |
          |   +-- Subscription: BU01 Production
          |   +-- Subscription: BU01 Non-Production
          |
          +-- Management Group: Business Unit 02
          |   |
          |   +-- Subscription: BU02 Production
          |   +-- Subscription: BU02 Non-Production
          |
          +-- Management Group: Business Unit 20
              |
              +-- Subscription: BU20 Production
              +-- Subscription: BU20 Non-Production

This is a starting model, not a final enterprise blueprint. A real bank may add more levels for geography, regulatory boundary, workload criticality, or operating model. But the structure shows the key separation.

The Platform management group contains subscriptions for shared services. The Landing Zones management group contains business-unit workload subscriptions. Each business unit has separate production and non-production subscriptions.

Why Separate Platform and Workloads

Platform services support many workloads. They should not be casually changed by individual application teams.

Examples include:

• Shared connectivity and routing.

• Hybrid connectivity to data centers.

• Central monitoring and logging foundations.

• Security posture and investigation tooling.

• Shared automation or management services.

Putting platform services in separate subscriptions allows the platform team to manage them with stricter access and change control. Workload teams can consume the foundation without owning it.

This separation protects both sides. The platform is safer because fewer teams can change it. Workload teams move faster because they do not need to design shared foundations from zero.

Why Separate Production and Non-Production

Production and non-production have different risk profiles.

Production usually needs:

• Stricter access.

• Stronger policy enforcement.

• Better monitoring and alerting.

• Clearer change control.

• Stronger audit evidence.

• More careful cost and capacity review.

Non-production needs governance too, but it often allows more flexibility for development and testing.

Separate subscriptions make those differences easier to express. A business unit can have broader contributor access in non-production while production changes go through controlled deployment identities and operational procedures.

Governance Control Map

The table below connects each governance responsibility to a possible Azure control.

The important design pattern is responsibility placement. Each control has a home.

Access Model

Azure RBAC should reflect the bank's operating model.

One possible access model is:

This model avoids giving every central team Owner access everywhere. Central visibility is not the same as central ownership. Security may need broad visibility, but application teams still own workload delivery and operations inside governed boundaries.

Policy Model

Azure Policy should express the bank's shared standards.

The bank might define several initiatives:

Useful policy rules may include:

• Allowed regions for regulated workloads.

• Required tags for owner, cost center, environment, application, and data classification.

• Deny or audit public access for sensitive services.

• Require or audit diagnostic settings for supported production resources.

• Audit or deny unapproved resource types.

• Enforce or audit encryption-related settings where appropriate.

• Require private networking patterns for sensitive data services where the design calls for it.

The bank should be careful with deny effects. For new subscriptions, deny may be appropriate from the start. For existing workloads, audit first may be safer so teams can understand and fix non-compliance before enforcement blocks deployments.

Tagging and Cost Ownership

A bank with 20 business units needs cost ownership to be visible and consistent.

A practical required tag set might include:

The bank can use Azure Policy to require or audit these tags. It can use budgets and cost alerts at subscription or business-unit scopes. Finance can then report spend by business unit, application, environment, and cost center.

This is not only about billing. If a production workload suddenly becomes expensive, the owner tag and budget alert tell the organization who should investigate.

Resource Locks

The bank should use resource locks selectively.

Good candidates include:

• Shared connectivity resources.

• Central monitoring workspaces.

• Critical production databases.

• Important key vaults.

• Resource groups that contain high-impact shared platform components.

Locks should not be applied everywhere. A broad read-only lock can break normal operations. Even delete locks can interfere with infrastructure-as-code replacement patterns or cleanup workflows.

For each lock, the bank should know:

• Why the lock exists.

• Who owns the locked resource.

• How approved changes are made.

• How emergency changes are handled.

• How the lock is reviewed over time.

Locks reduce accidental damage. They do not replace RBAC, backup, recovery, monitoring, or change control.

Workload Onboarding Flow

Now imagine Business Unit 07 wants to deploy a new loan-processing application.

A governed onboarding flow might look like this:

1. The business unit requests production and non-production workload environments.

2. The platform team creates or assigns subscriptions under the Business Unit 07 management group.

3. The subscriptions inherit global and environment-specific policy initiatives.

4. Microsoft Entra groups are mapped to Azure RBAC roles for developers, operators, auditors, security, and deployment identities.

5. Required tags, budgets, and cost alerts are configured.

6. Network connectivity follows the approved landing zone pattern.

7. Logs, metrics, and security signals flow to central monitoring and security tools.

8. The workload team deploys application resources through approved pipelines.

9. Policy compliance, cost, access, and monitoring are reviewed as part of production readiness.

This flow gives the workload team a clear place to build. It also gives central teams evidence that required controls are present.

Trade-Offs

Every governance model has trade-offs.

A strong design does not pretend these trade-offs disappear. It makes them explicit and chooses the model that fits the organization's risk, scale, and operating maturity.

Common Mistakes

• Building one subscription per business unit and mixing everything inside it. Production, test, shared services, and unrelated workloads become harder to govern.

• Making the management group tree mirror the org chart too literally. Governance structure should follow policy, ownership, and operating needs, not every reporting line.

• Giving central teams broad Owner access everywhere by default. Visibility and ownership are different responsibilities.

• Letting each business unit invent its own policy and tags. Local autonomy still needs shared standards.

• Applying deny policies without rollout planning. Strong policy enforcement can break legitimate deployments if teams are not ready.

• Forgetting non-production governance. Development and test environments still create cost, risk, and data exposure concerns.

• Using locks everywhere. Locks should protect selected high-impact resources, not freeze normal operations.

• Waiting until audit time to gather evidence. Policy compliance, activity logs, access records, monitoring, and cost reports should exist continuously.

If Someone Asks You

If someone asks, "How would you design Azure governance for a global bank with 20 business units?" a clear answer is:

I would use a management group structure that separates shared platform services from business-unit landing zones. Platform subscriptions would hold shared connectivity, management, and security foundations. Each business unit would receive separate production and non-production workload subscriptions. Azure RBAC would give central security broad visibility without making it the owner of every workload, while business-unit teams would receive scoped delivery permissions. Azure Policy initiatives would enforce common requirements such as approved regions, required tags, diagnostics, and public exposure controls. Tags, budgets, and cost alerts would support cost ownership. Selective resource locks would protect critical shared and production resources.

This answer shows how governance controls work together rather than listing them as isolated features.

What You Should Remember

Enterprise governance is responsibility placement.

The most important idea is this:

Central teams own guardrails. Workload teams own delivery inside them.

For a large organization, Azure governance should make autonomy safe. Management groups organize inherited rules. Subscriptions separate ownership, environments, cost, and risk. Azure RBAC grants scoped access. Azure Policy enforces and audits standards. Tags and budgets make ownership visible. Locks protect selected high-impact resources. Evidence shows whether the model is working.

Questions to Check Your Understanding

1. Why should platform subscriptions be separated from workload subscriptions?

2. How can central security have visibility without owning every workload?

3. Why is production and non-production separation important in a bank?

4. Which policies would you assign at a management group rather than one subscription at a time?

5. What trade-offs come with creating many subscriptions?

6. How would you explain this governance model in an architecture discussion?