Will Percey — Portfolio

Azure Resource Hierarchy

domainTenantIdentity Boundary

→

account_treeManagement GroupsGovernance Scope

→

credit_cardSubscriptionsBilling Boundary

→

inventory_2Resource GroupsLifecycle Container

→

memoryResourcesAzure Services

Microsoft Entra ID Tenant

A tenant is a dedicated instance of Microsoft Entra ID (formerly Azure Active Directory) that an organization receives when signing up for a Microsoft cloud service. It represents your organization and serves as the top-level security and identity boundary.

Key Characteristics

One tenant per organization (typically)
Contains users, groups, and applications
Default domain: *.onmicrosoft.com
Can have custom domains added
Global unique identifier (Tenant ID)

Tenant vs Directory

Tenant: The overall container/organization
Directory: The Entra ID instance within the tenant
Often used interchangeably
A tenant always has exactly one directory
Multi-tenant apps can span tenants

Custom Domains

Add your organization's domain (e.g., contoso.com)
Requires DNS verification (TXT or MX record)
Primary domain for user sign-in
Multiple custom domains supported
Federated domains for SSO

Exam Focus Points

Trust relationships between tenants
B2B collaboration (guest users)
B2C for customer identities
Tenant-level settings affect all subscriptions
Cannot move resources between tenants easily

Management Groups

Management Groups provide a level of scope above subscriptions for organizing subscriptions into containers and applying governance conditions. All subscriptions within a management group automatically inherit the conditions applied to the management group.

Max Depth

6 Levels

(excluding root & subscription)

Max Management Groups

10,000

per directory

Direct Children

Unlimited

subscriptions or groups

Root Management Group

Automatically created for each directory
Called "Tenant Root Group"
All management groups and subscriptions fold up to root
Global policies and RBAC can be applied here
Cannot be moved or deleted

Inheritance

Azure Policy - inherited down the hierarchy
RBAC roles - inherited by child resources
Cost management - aggregate at group level
Child groups can have additional policies
Deny assignments block inheritance

Common Design Patterns

Enterprise-Scale / Landing Zone

Platform (Identity, Connectivity, Management)
Landing Zones (Corp, Online)
Sandbox (Dev experimentation)
Decommissioned (Archived subscriptions)

Environment-Based

Production
Pre-Production / Staging
Development
Sandbox / POC

Business Unit Based

By department or team
By geography/region
By project or workload
By regulatory requirement

Subscriptions

An Azure subscription is a logical container used to provision resources in Azure. It serves as both a billing boundary and an access control boundary. Resources deployed within a subscription are billed to the payment method associated with that subscription.

Billing Boundary

Separate invoices per subscription
Different payment methods
Cost tracking and chargeback
Budget alerts per subscription

Access Control Boundary

RBAC scoped to subscription
Subscription-level policies
Resource isolation between subs
Security boundary enforcement

Quotas & Limits

vCPU limits per region
Storage accounts per region
VNets, NICs, Load Balancers
Quota increase requests

Subscription Types

Type	Best For	Key Features
Pay-As-You-Go	Individuals, small projects	Credit card billing, no commitment
Enterprise Agreement (EA)	Large enterprises	Volume discounts, monetary commitment, Azure Prepayment
Microsoft Customer Agreement (MCA)	Organizations of all sizes	Simplified purchasing, billing profiles, invoice sections
Cloud Solution Provider (CSP)	Partner-managed customers	Managed by Microsoft partners, bundled support
Free/Trial	Evaluation, learning	$200 credit, 12 months free services
Visual Studio / Dev Essentials	Developers	Monthly credits, dev/test pricing

Moving Resources

Resources can be moved between subscriptions
Both subscriptions must be in the same tenant
Not all resource types support move
Check Move-AzResource for compatibility
Locks prevent moves

Exam Notes

Know when to recommend multiple subscriptions:

Different billing requirements
Regulatory compliance isolation
Hitting subscription quotas
Environment separation (prod/dev)

Resource Groups

A Resource Group is a logical container that holds related resources for an Azure solution. It allows you to manage and organize resources based on lifecycle, permissions, or project structure.

Key Rules

Every resource must be in exactly one RG
Resources can span regions within an RG
RG location is for metadata only
RGs cannot be nested
Deleting RG deletes all resources within

Tags & Organization

Apply tags for cost allocation
Environment tags (prod, dev, test)
Owner/team tags for accountability
Project/application tags
Tags are NOT inherited by default

Resource Locks

CanNotDelete - Prevent deletion
ReadOnly - Prevent modification
Locks are inherited by resources
Even Owner role cannot bypass locks
Must remove lock before action

Design Strategies

By lifecycle - Resources deployed together
By application - All resources for one app
By resource type - All VMs, all storage, etc.
By environment - Separate prod/dev RGs
By billing - Cost center alignment

Resources & Azure Resource Manager

Resources are the manageable items available through Azure (VMs, storage accounts, web apps, databases, etc.). All resource operations go through Azure Resource Manager (ARM), which provides a consistent management layer.

Azure Resource Manager

Deployment and management service
All requests go through ARM
Consistent API layer (Portal, CLI, SDK, REST)
Handles authentication & authorization
ARM templates for IaC

Resource Providers

Services that supply resource types
Must be registered to use resources
Format: Microsoft.Compute/virtualMachines
Some auto-registered, others manual
Provider determines available operations

Resource Naming & IDs

Resource ID Format

/subscriptions/{subscription-id}
/resourceGroups/{resource-group}
/providers/{provider}
/{resource-type}/{resource-name}

Naming Best Practices

Use consistent naming convention
Include: type, workload, env, region
Example: vm-app-prod-eastus-001
Check naming rules per resource type
Some names must be globally unique

Resource Dependencies

Some resources depend on others
VM depends on VNet, NIC, Disk
ARM handles deployment ordering
Explicit vs implicit dependencies
Consider dependencies when deleting

Exam Focus

Infrastructure as Code:

ARM Templates (JSON)
Bicep (DSL for ARM)
Terraform (HashiCorp)
Deployment modes: Incremental vs Complete

Role-Based Access Control (RBAC)

Azure RBAC is the authorization system that manages who has access to Azure resources, what they can do, and at what scope. RBAC assignments inherit down the resource hierarchy - a role assigned at a Management Group applies to all child subscriptions, resource groups, and resources.

Key Concepts

Security Principal - Who (user, group, service principal, managed identity)
Role Definition - What they can do (Owner, Contributor, Reader, custom)
Scope - Where it applies (MG, subscription, RG, resource)
Role Assignment - The combination of all three

Inheritance & Best Practices

Permissions inherit down the hierarchy
Assign at the highest appropriate scope
Use groups over individual assignments
Prefer built-in roles over custom

arrow_forwardDeep Dive: Azure RBAC

Quick Reference

Level	Purpose	RBAC Scope	Policy Inheritance
Tenant	Identity & security boundary	Tenant-wide (Entra ID roles)	N/A (not Azure Policy)
Management Group	Organize subscriptions, governance	Inherited to all child MGs & subs	Yes - cascades down
Subscription	Billing & access control boundary	Inherited to all RGs & resources	Yes - cascades down
Resource Group	Logical container, lifecycle mgmt	Inherited to resources in RG	Yes - cascades down
Resource	Individual Azure service instance	Resource-level only	Yes - applies to resource