Run a mock round

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.

ARM templates are the native JSON declarative language for Azure Resource Manager. Bicep is a domain-specific language that transpiles to ARM JSON.

Advantages of Bicep:

• Concise, readable syntax with no mandatory boilerplate.
• First-class modules, loops, conditions, and type checking.
• Tooling: VS Code extension, IntelliSense, and the bicep CLI.
• Idempotent deployments and what-if analysis, same as ARM.

param location string = resourceGroup().location
resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stapp${uniqueString(resourceGroup().id)}'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

Both use the same deployment engine, so you can decompile ARM to Bicep with az bicep decompile. Prefer Bicep for new work, and use ARM when you must generate JSON programmatically or consume existing templates.

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.

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.

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.

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.

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.