Virtual Machines

A Virtual Machine gives you a complete operating system running in Azure. Full control, full responsibility. Microsoft manages the physical hardware, the hypervisor, the power, the cooling. You manage everything from the operating system up: patches, security, runtime, middleware, application code, and data. The private house metaphor works well. VMs are your house. You own everything, the plumbing, the electrical, the roof. You fix it when it breaks. You control every detail. But you also maintain it. App Service is a serviced apartment. Functions are a hotel room by the hour. VM sizing: the series letter tells you the optimisation. D-series is general purpose, balanced CPU and memory, your default choice. E-series is memory optimised, for SAP HANA and in-memory databases. F-series is compute optimised, for batch processing. N-series has GPUs, for machine learning. B-series is burstable, earns CPU credits when idle and spends them during peaks, perfect for dev machines and CI/CD agents. Critical about the temporary disk: every Azure VM has a temp disk, typically the D drive on Windows. It is physically on the host server, not on a managed disk. Fast, great for temp files and the page file. But it is completely wiped when the VM is deallocated, resized, or moved to a different host. Never store application data, databases, or logs on the temp disk. This is the number one data loss scenario in. the exam and in real-world incidents. Managed disks are the right place for persistent data. They are separate Azure resources that survive VM operations. You can detach a data disk from one VM and attach it to another. The billing trap that catches everyone: stopping a VM through the operating system does NOT stop Azure billing. Azure still has the hardware reserved. To stop billing, you must Deallocate the VM through the Portal, CLI with az vm deallocate, or PowerShell. Deallocated means Azure releases the hardware and compute charges stop.. Remember: Temp disk is wiped on deallocate or resize, never store data there. Stop through OS does not stop billing. Deallocate does. D-series for general purpose. Right-size before deploying.

VM Size Families

Disk Types — Performance vs Cost

Availability — Sets vs Zones

Stop vs Deallocate — Critical Billing Difference

VM Scale Sets (VMSS)

App Service is Azure's Platform-as-a-Service web hosting. With a VM you manage the operating system, the web server, the runtime, the patches, the scaling, everything. With App Service you deploy your code and Microsoft handles everything else. The OS, IIS or Nginx, the runtime, patching, load balancing, scaling, certificate renewal, all of it. The serviced apartment metaphor: you bring your furniture, your code, and move in. Building management handles maintenance. You have constraints, you cannot knock down walls, but you also do not get called at 3am because the boiler broke. The App Service Plan is the infrastructure layer. You pay for the plan, not the apps. A single plan can host multiple apps. Plan tiers determine available features. Free and Shared are development only. Basic gives dedicated compute but no deployment slots. Standard is where production features start: autoscale up to 10 instances and up to 5 deployment slots. Premium gives 30 instances, 20 slots, and VNet Integration. Isolated runs in a dedicated App Service Environment for maximum security requirements. Deployment Slots are the most important and most tested App Service feature on AZ-104. A slot is a separate live version of your app with its own URL. Production slot is your live site. Create a staging slot at myapp-staging.azurewebsites.net. Deploy your new version to staging. Test it thoroughly. Then swap. The swap is nearly instantaneous, usually under 10 seconds. Azure redirects traffic from staging to production. Zero downtime. No users experience an outage. If you find a bug, swap back immediately. The old version is sitting in staging ready to return.. The exam gotcha about sticky settings: settings marked as deployment slot settings stay with their slot regardless of swaps. Always mark connection strings as slot-sticky. Production code should connect to the production database, staging code to the staging database. If settings are not sticky, your production code suddenly connects to the staging database after a swap. Catastrophic.. Remember: Standard tier minimum for deployment slots. Swap gives zero-downtime deployment. Mark connection strings as slot-sticky. VNet Integration requires Premium for private resource access.

App Service Plans — Tiers

Deployment Slots — Zero Downtime Deployment

App Service Networking

Azure Functions is serverless compute. Serverless does not mean no server. It means you do not manage any server. You write a function, a single piece of code that does one thing, and Azure runs it in response to an event. HTTP request, queue message, timer, file uploaded to blob. You pay per execution and per memory used. Nothing running means nothing billed. The hosting plan choice is the most important Functions decision. Consumption plan is pure serverless. You pay per million executions. Scale to zero when idle. Scales to hundreds of instances automatically under load. But it has cold starts. When your function has been idle and a new request arrives, Azure needs to provision an instance, load the runtime, and start your code. This can take one to ten seconds. For background processes that is fine. For user-facing APIs that is a terrible first response experience. The Consumption plan also cannot access VNet resources. If your function needs to call a Cosmos DB behind a private endpoint, or a storage account restricted to a VNet, the Consumption plan cannot do this. This is the most tested Function App scenario on AZ-104, and it is directly relevant to your Kube platform. The Premium plan adds a pre-warmed instance that is always ready, eliminating cold starts. It supports VNet Integration. It can run indefinitely. The trade-off is a minimum billing of one instance always running. The Dedicated plan runs functions on an App Service Plan you already have. Same VNet capabilities as Premium.. For Kube: your function apps processing IoT events and writing to Cosmos DB private endpoints must use Premium plan. VNet Integration is non-negotiable when Cosmos DB is behind a private endpoint. Durable Functions extend serverless to stateful long-running workflows. An orchestrator coordinates multiple activity functions, calls APIs, waits for results, handles human approval steps. All serverless, all automatically retried if steps fail.. Remember: Consumption has cold starts and no VNet Integration. Premium has pre-warmed instances and VNet Integration. Use Premium for private endpoint access. Durable Functions for stateful multi-step workflows.

Hosting Plans — Critical Differences

Durable Functions — Stateful Workflows

A Docker image is a blueprint. Read-only. It defines your application's code, runtime, dependencies, and configuration. A container is a running instance built from that image. You can run ten containers from the same image, ten identical copies of your application running in isolation. Same image runs identically on your laptop, test server, and in Azure. No more it works on my machine. Azure Container Registry, ACR, is your private image registry. Instead of pushing images to public Docker Hub, you push them to ACR, which is private, secured, and inside Azure. For authentication, use Managed Identity. Your compute resources authenticate to ACR using their identity. No credentials in code. Three Azure services for running containers. Azure Container Instances, ACI, is the simplest. Run a container in about 30 seconds. No cluster, no orchestration, just specify the image, CPU, memory, and port. ACI restart policy: Always means keep restarting if the container exits, for long-running services. Never means run once and stop, for batch jobs. OnFailure means restart only on errors. ACI is great for batch processing, CI/CD pipeline steps, and dev/test environments. Not designed for production web applications needing scaling. Container Apps is the middle ground, managed Kubernetes without you managing Kubernetes. Microsoft runs the cluster. Define your app and its scaling rules. Container Apps supports scale to zero, billing stops when nobody uses your app. Supports traffic splitting between revisions for canary deployments. Built-in KEDA support for event-driven scaling. For AZ-104, Container Apps is. the exam-tested production container service. AKS, Azure Kubernetes Service, is managed Kubernetes for when you need full capabilities. Microsoft manages the control plane for free. You manage and pay for the worker nodes. AKS is covered in depth in AZ-204 and AZ-305.. Remember: Image is blueprint, container is running instance. ACR is your private registry, use Managed Identity to authenticate. ACI for simple short-lived containers with restart policy Always, Never, or OnFailure. Container Apps for production microservices with auto-scaling.

ACI — Azure Container Instances

Container Apps vs AKS — The Key Difference

Infrastructure as Code means defining your Azure environment in files rather than clicking through the portal. Azure has two formats: ARM Templates and Bicep. ARM stands for Azure Resource Manager. Every operation you do in Azure, whether through the portal, CLI, PowerShell, or any SDK, ultimately becomes an ARM API call. ARM Templates are JSON files describing the desired state of your Azure resources. Submit the template and Azure creates exactly what you described. Bicep is a domain-specific language designed by Microsoft specifically for Azure. It compiles to ARM JSON. Azure never sees Bicep directly, it is a developer-friendly wrapper that converts to ARM before deployment. ARM JSON is legalese. Bicep is the same document written in plain English. Same legal effect, much easier for humans to write and read. A concrete comparison: creating a storage account in ARM JSON takes about 20 lines of deeply nested JSON with schema declarations and API version strings. The same storage account in Bicep is 7 clean readable lines. Bicep also automatically detects dependencies between resources. If resource B references resource A, Bicep knows to create A first. In ARM JSON you would have to explicitly declare that with a dependsOn array. Deployment modes are critical for. the exam. Incremental mode, the default, is additive. It creates or updates resources in your template and leaves everything else alone. If your resource group has a Cosmos DB not in the template, Incremental mode does not touch it. Safe for production. Complete mode is dangerous and powerful. It creates and updates everything in the template, and deletes everything in the resource group that is not in the template. If Cosmos DB is not in your template and you run Complete mode, it gets deleted. No warning. No confirmation. Gone. Always run what-if before any deployment. The command az deployment group what-if shows exactly what will be created, modified, and deleted without doing anything. In Complete mode, what-if is not optional, it is mandatory.. Remember: Bicep compiles to ARM, same capability, better developer experience. Incremental mode is safe and the default. Complete mode deletes resources not in the template. Always run what-if before deploying.

{
  "$schema": "https://schema.management.azure.com/...",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageName": {
      "type": "string"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-01-01",
      "name": "[parameters('storageName')]",
      "location": "[resourceGroup().location]",
      "sku": { "name": "Standard_LRS" },
      "kind": "StorageV2"
    }
  ]
}

// Much cleaner — same result
param storageName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageName
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

// Output the endpoint
output blobEndpoint string = storageAccount.properties.primaryEndpoints.blob

# Preview changes BEFORE deploying (always do this)
az deployment group what-if \
  --resource-group RG-Prod \
  --template-file main.bicep \
  --parameters storageName=kubestgprod

# Deploy Bicep (Incremental = default = SAFE)
az deployment group create \
  --resource-group RG-Prod \
  --template-file main.bicep \
  --parameters storageName=kubestgprod \
  --mode Incremental

# Share template with team (version it in Template Specs)
az ts create \
  --resource-group RG-Templates \
  --name kube-storage-template \
  --version "1.0" \
  --template-file main.bicep

# Deploy from Template Spec (team uses approved template)
az deployment group create \
  --resource-group RG-Prod \
  --template-spec /subscriptions/.../templateSpecs/kube-storage-template/versions/1.0