Run a mock round

Use the deployment history and activity log first, then drill into the resource.

1. Inspect the failed deployment operations to get the exact error code.

az deployment group show -g rg-app -n deploy-1 --query properties.error
az deployment operation group list -g rg-app -n deploy-1

1. Common causes include quota exceeded, an unsupported VM size in the region or zone, policy denial, name conflicts, or an invalid image.
2. Networking: check subnet capacity, NSG rules, and whether the NIC is attached.
3. If the VM was created but does not start, review boot diagnostics, the serial log, and the screenshot.
4. Failed extensions often block provisioning; review their status.
5. Redeploy with what-if to see planned changes, and validate the template before applying.

az vm boot-diagnostics get-boot-log --ids <vm-id>

Check quotas with az vm list-usage, and reproduce with a minimal template to isolate the failing resource.

A subscription is a billing and access boundary; a resource group is a logical container for related resources.

• Subscription: defines quotas, billing, and a trust boundary for RBAC and policy. You can have multiple subscriptions under a management group hierarchy for governance and cost separation.
• Resource group: groups resources that share a lifecycle, permissions, and deployment. Every resource belongs to exactly one resource group, and deleting the group deletes everything in it.

az group create --name rg-app-prod --location eastus
az deployment group create --resource-group rg-app-prod --template-file main.bicep

Good practice is to separate resource groups by environment or workload, apply tags for cost reporting, and scope RBAC at the narrowest level. Use management groups to apply policy across many subscriptions.

Microsoft Entra ID, formerly Azure AD, is a cloud identity provider using modern protocols such as OAuth 2.0, OpenID Connect, and SAML. On-premises Active Directory Domain Services is an LDAP-based directory with Kerberos and Group Policy for domain-joined machines.

Key differences:

• Entra ID is multi-tenant, internet-facing, and managed by Microsoft; AD DS runs on your own domain controllers.
• Entra ID has no OU hierarchy or Group Policy; it uses administrative units, RBAC, and Conditional Access.
• Devices can be Entra joined, hybrid joined, or registered rather than domain joined.
• Entra Connect or Cloud Sync replicates on-premises identities to the cloud.

Use Entra ID for SaaS apps, single sign-on, and MFA. Use AD DS for legacy applications that require Kerberos, LDAP, or domain joins. Many enterprises run both in a hybrid identity model.

A Virtual Network, or VNet, is an isolated private network in a region with its own address space. You divide it into subnets and control traffic with network security groups (NSGs).

• NSGs contain inbound and outbound rules with priority, source and destination, port, and protocol. Lower numbers win, and the first match applies.
• Rules can allow or deny. Default rules allow VNet-to-VNet and Azure Load Balancer traffic and deny the rest.
• NSGs can attach to subnets, network interfaces, or both, and both are evaluated.
• Traffic between subnets can be forced through an appliance using user-defined routes.

az network nsg rule create -g rg-app --nsg-name nsg-web \
  --name allow-https --priority 100 --access Allow \
  --protocol Tcp --destination-port-ranges 443

Use service tags and application security groups to keep rules readable, and Azure Firewall for centralised egress control.

Start with RTO and RPO, then choose a topology.

• Within a region, distribute workloads across availability zones, which are physically separate datacentres. Use zone-redundant services: zone-redundant App Service, AKS across zones, zone-redundant storage, and zone-redundant SQL or Cosmos DB.
• Load balancing: Azure Load Balancer for layer 4, and Application Gateway or Front Door for layer 7 and global routing.
• Across regions, use paired regions and Azure Front Door or Traffic Manager with health probes for failover.
• Data: Cosmos DB multi-region writes, Azure SQL auto-failover groups, and geo-redundant storage.

az sql failover-group create -g rg-db --server sql-primary \
  --partner-server sql-secondary --name fg-app

Test failover regularly, and watch for split-brain, replication lag, DNS TTL, and cost. Active-active is resilient but complex; active-passive is simpler but slower to recover.

Both can host code, but they optimise for different workloads.

Azure Functions is serverless and event-driven:

• Consumption or Premium plans scale to zero and bill per execution.
• Triggers and bindings cover HTTP, timers, queues, blobs, Event Grid, and Service Bus.
• Best for short, discrete tasks such as image processing, queue workers, scheduled jobs, and webhooks.
• Limits include maximum execution duration, cold starts on Consumption, and statelessness by default.

App Service is a fully managed web host:

• Runs long-lived web apps, REST APIs, and background workers in containers or native runtimes.
• Always on, with custom domains, deployment slots, autoscale, and VNet integration.
• Predictable pricing per plan with no per-execution billing.

Choose Functions for event-driven glue and spiky traffic. Choose App Service for conventional web APIs, long-running requests, or when you need deployment slots.

Managed disks are block-level volumes for Azure VMs, managed by Azure. A storage account is a broader namespace that hosts blobs, files, queues, and tables, and previously also unmanaged disks.

• Managed disks are created and managed by Azure, replicated within a region, and support snapshots, encryption, and disk types such as Standard HDD, Standard SSD, Premium SSD, and Ultra Disk. You pick a size and performance tier.
• A storage account is a container for services such as Blob, Azure Files, Queue, and Table. It defines replication (LRS, ZRS, GRS), performance tier, and access tier.

VMs now use managed disks by default; unmanaged disks in storage accounts are legacy. Use a storage account for object and file data, and managed disks for VM OS and data volumes.

Blob Storage offers tiers that trade storage cost against access cost and latency.

• Hot: frequent access, highest storage cost, lowest access cost.
• Cool: infrequent access, minimum 30-day storage, lower storage cost, higher access cost.
• Cold: rarely accessed, minimum 90 days, lower still.
• Archive: offline, minimum 180 days, lowest storage cost, hours to rehydrate before reading.

Set a tier at upload or move blobs later with lifecycle management policies.

{
  "rules": [{
    "name": "archive-old",
    "type": "Lifecycle",
    "definition": {
      "filters": {"blobTypes": ["blockBlob"], "prefixMatch": ["logs/"]},
      "actions": {"baseBlob": {
        "tierToCool": {"daysAfterModificationGreaterThan": 30},
        "tierToArchive": {"daysAfterModificationGreaterThan": 180}
      }}
    }
  }]
}

Early deletion before the minimum age incurs charges, so model the access pattern before choosing a tier.