A clean Azure setup begins with protected identities, an understood tenant and subscription, consistent resource organization, registered providers, and cost alerts.
Daily administration should use named Microsoft Entra identities with MFA and role-based access. Shared accounts and permanent high privilege make auditing and incident response unnecessarily difficult.
Before deploying a workload, decide its subscription, resource group, Region, tags, budget owner, and diagnostic destination.
Verify who owns the tenant, who can manage billing, and which subscription will contain the workload. Keep emergency access accounts documented and separate from normal administration.
Define resource-group boundaries, naming rules, required tags, allowed Regions, and deletion ownership before teams create resources independently.
Select the intended subscription explicitly, configure safe defaults, and verify the current account. Register only the providers required by planned services and wait for registration to finish before deployment.
Create a budget with forecast and actual-spend alerts. Confirm Activity Log access and configure diagnostic settings where longer retention or centralized analysis is required.
A Microsoft Entra tenant is the identity and trust directory used to authenticate people, applications, and managed identities. An Azure subscription is a billing, quota, resource, policy, and Azure Resource Manager access scope associated with one tenant. Several subscriptions can trust the same tenant, but moving a subscription between tenants changes important identity relationships and requires a planned migration.
Confirm the tenant ID, subscription ID, billing ownership, support contacts, and technical owners before deployment. Subscription display names are helpful but not unique authority. Automation and runbooks should use stable IDs and should fail when the active context differs from the intended environment.
Separate production, nonproduction, platform connectivity, security, and sandbox workloads into subscriptions when their ownership, policy, quota, or risk requires a stronger boundary. A small lab can use one subscription, but its broad contributor assignment and shared resources should not become the production model by accident.
Normal administrators should use named Entra identities, phishing-resistant MFA where the organization supports it, Conditional Access, and time-bounded privileged activation. Keep permanent Global Administrator, Privileged Role Administrator, Owner, and User Access Administrator assignments to the smallest justified set. Entra directory roles and Azure resource roles control different planes and must both be reviewed.
Create cloud-only emergency access identities that are independent of ordinary federation and Conditional Access dependencies, then secure, monitor, and test them through a documented two-person process. An emergency account that has never been tested may be blocked by the same outage it is meant to solve. Every use should create an alert and post-incident access review.
Protect tenant recovery domains, billing contacts, support authority, app-registration ownership, and management-group administrators as account-level controls. Remove access promptly after staff changes and preserve enough independent ownership that one unavailable employee cannot prevent recovery.
Management groups organize subscriptions for inherited Azure Policy and selected RBAC. Keep the hierarchy shallow and based on governance needs such as platform, online, corporate, sandbox, and decommissioned workloads rather than copying every department and Region. Changes high in the tree can affect many subscriptions, so root-scope assignments need exceptional review.
A landing zone is the governed environment into which a workload subscription is placed. It includes identity, management-group placement, policy, networking, security, monitoring, cost, and automation decisions. A subscription-vending process should apply the baseline consistently and record exceptions instead of asking each application team to reproduce platform controls manually.
Use Policy to audit, deny, modify, or deploy supported configuration according to the assigned definition and effect. Policy does not grant a person access. Test initiatives and remediation in a nonproduction scope, account for existing resources, and provide a controlled exemption process with owner and expiry.
Choose Regions from latency, data residency, service and SKU availability, Availability Zone support, recovery, network transfer, capacity, and price. A service name may exist in a Region while the required feature, runtime, disk type, or tier does not. Verify the exact deployment combination before architecture approval.
Azure resource providers expose resource types through Resource Manager and may require registration in a subscription. Registration is a control-plane prerequisite, not permission to use every resource. Register intentionally through the platform workflow, monitor failures, and avoid granting broad registration privilege to application identities without need.
Quotas and regional capacity can limit virtual CPUs, public addresses, networking, storage, databases, and managed services. Record required capacity, inspect current usage, request increases early, and define a fallback. A successful template validation does not reserve deployment capacity.
Use `az account show` to verify tenant, subscription, and signed-in principal, then set the intended subscription explicitly. Commands should include resource group and location where ambiguity matters. Azure Cloud Shell is convenient for interactive administration, while production pipelines should use a dedicated workload identity with narrow federated credentials or another approved non-secret authentication method.
Service principals represent application identities in a tenant and can authenticate through certificates, secrets, or workload identity federation. Prefer federation or managed identity so a static client secret is not distributed to the build system. Scope the pipeline role to its deployment resources and separate it from the applications runtime identity.
Treat local defaults, environment variables, Azure CLI token caches, and selected cloud as part of context. A script should print safe context, reject an unexpected subscription, use noninteractive output, and return a failing exit code when an operation fails. Do not let a previous lab login determine a production target silently.
Create budgets at the useful billing scope with actual and forecast thresholds and a monitored action group or recipient. A budget reflects processed cost data and does not impose a real-time cap. Define required tags such as application, environment, owner, and cost center, while planning allocation for shared or untaggable charges.
The Azure Activity Log records subscription control-plane events for its retention window. Export it through diagnostic settings or data collection architecture when longer, centralized, or cross-subscription analysis is required. Resource data-plane access and application behavior need service diagnostic logs, audit logs, metrics, and traces; the Activity Log alone is not a complete audit design.
Run a readiness drill: sign in normally, verify context, list a harmless resource, perform one expected denied action from a read-only role, locate the control-plane event, confirm budget recipients, and identify who can respond. A subscription should not host production until identity, governance, evidence, cost, and recovery ownership are demonstrably working.
Hand the subscription to a workload team with a recorded owner, management-group placement, policy baseline, deployment identity, network connection, diagnostic destination, budget, quota review, and decommission path. Require the receiving team to verify each control instead of treating subscription creation as the end of onboarding.
Set a working subscription, default resource group, and confirm the provider needed for later web labs is registered before you create resources.
az account set --subscription "Azure Subscription 1"
az configure --defaults group=rg-cloud-lab location=eastus
az provider register --namespace Microsoft.Web
az provider show --namespace Microsoft.Web --query registrationState -o tsvA production subscription is handed from a project team to platform operations.
Constraints: Emergency access, billing ownership, tenant ownership, and audit export must not depend on one employee.
Decision: Assign least-privilege groups at the correct scope, test an emergency account, lock critical resources, and record ownership contacts.
Verification: Access reviews show named owners, emergency sign-in is alerted, and activity logs reach protected storage.
Failure test: Remove the project lead account and prove billing, deployment, and recovery still work.Expected evidence: Access reviews show named owners, emergency sign-in is alerted, and activity logs reach protected storage.Explore 500+ free tutorials across 20+ languages and frameworks.