Microsoft AZ-104 - Microsoft Azure Administrator - Deploy and manage Azure Compute Resources - VMs & Containers AKS

brencronin

6 hours ago

46 min read

Deploy and Manage Azure Compute Resources — 20–25%

Create and configure virtual machines

Create a virtual machine
Configure Azure Disk Encryption
Move a virtual machine to another resource group, subscription, or region
Manage virtual machine sizes
Manage virtual machine disks
Deploy virtual machines to availability zones and availability sets
Deploy and configure an Azure Virtual Machine Scale Sets
Virtual machine cost controls
Azure VM reliability settings
Azure VM security settings

Provision and manage containers in the Azure portal

Azure 'Azure Kubernetes Service' (AKS) and Containers Overview
Container Networking
Create and manage an Azure Container Registry
Provision a container by using Azure Container Instances
Provision a container by using Azure Container Apps
Manage sizing and scaling for containers, including Container Instances and Container Apps
Manage sizing and scaling for containers, including Container Instances and Container Apps
AKS and Container security concepts
Azure Kubernetes special features

Create and configure virtual machines

Create a virtual machine
Configure Azure Disk Encryption
Move a virtual machine to another resource group, subscription, or region
Manage virtual machine sizes
Manage virtual machine disks
Deploy virtual machines to availability zones and availability sets
Deploy and configure an Azure Virtual Machine Scale Sets
Virtual machine cost controls
Azure VM reliability settings
Azure VM security settings

Create a virtual machine

An Azure virtual machine (VM) is an on-demand computer that runs an operating system and applications in Azure. Creating a VM also involves selecting the supporting storage, networking, security, and management settings it needs.

The first diagram shows those building blocks. The second shows how to select a VM for a workload and create repeatable deployments.

VM building blocks and creation

A VM deployment brings together several resources and settings:

Component	Purpose
Resource group	A logical container used to manage related Azure resources. Resources used by a VM can also be in different resource groups when supported.
VM size	Determines available compute resources and influences capabilities such as memory, networking, disk throughput, and the number of NICs and data disks.
OS image	Provides the starting operating system and, depending on the image, preinstalled software. Images can come from Azure Marketplace or Azure Compute Gallery.
OS disk	Contains the operating system. The usual choice is a managed disk; an ephemeral OS disk is available for supported VM sizes and scenarios.
Data disks	Optional disks used for application data, databases, and other workloads.
NIC, VNet, and subnet	Connect the VM to a virtual network. The NIC provides the VM’s network configuration and private IP address.
Public IP address	Optional. When used directly with a VM, it is associated with a NIC IP configuration.
Network security group (NSG)	Controls permitted inbound and outbound traffic at the subnet or NIC level.
Boot diagnostics	Helps troubleshoot startup problems using boot information such as a serial log and screenshot.
Managed identity	Gives the VM an identity in Microsoft Entra ID that can be granted access to supported services without storing credentials in application code.

Ephemeral OS disk: An ephemeral OS disk uses eligible local VM storage and can be useful for stateless workloads. Its contents do not have the same persistence characteristics as a managed OS disk, so applications must be designed to rebuild or recover the VM when needed.

Public access: A public IP is not required for every VM. For example, Azure Bastion can provide RDP or SSH access to a VM over its private IP address.

Typical Azure portal creation process

Basics: Select the subscription, resource group, VM name, region, availability option, image, size, and administrator credentials.
Disks: Choose the OS disk type and configure any data disks.
Networking: Select a VNet and subnet, decide whether a public IP is needed, and configure network security.
Management: Configure features such as boot diagnostics and managed identity when needed.
Review and create: Review the settings, deploy the VM, and validate connectivity and application operation.

The portal may also present Security, Monitoring, Advanced, and Tags settings. The available options depend on the selected VM configuration and current portal experience.

Choose and deploy Azure VM resources

Azure offers VM sizes designed for different workload needs. The examples below identify common families, not every available size.

Category	Design emphasis	Common workloads	Example families
General purpose	Balanced CPU and memory; some sizes support burstable workloads	Development, testing, web servers, and small-to-medium applications	B, D
Compute optimized	Higher CPU capacity relative to memory	Batch processing, application servers, and compute-intensive workloads	F
Memory optimized	More memory relative to CPU	Relational databases, large caches, and in-memory analytics	E, M
Storage optimized	High storage throughput and I/O capacity	Large databases, data processing, and storage-intensive workloads	L
GPU accelerated	Specialized GPUs for compute or graphics	AI and machine learning, rendering, visualization, and video workloads	NC, ND, NV
High-performance computing (HPC)	High-performance CPU resources; some sizes support specialized interconnects such as RDMA	Scientific modeling, simulations, engineering, and financial analysis	H families

The older size names in the supplied notes illustrate these categories, but availability and support change. Check the current VM-size documentation and the target region, availability zone, subscription quota, and required features before selecting a size. GPU VMs support more than graphics: many are designed for AI training, inference, and scientific computation.

Standardized images and deployments

Azure VM Image Builder automates creation of customized VM images. A typical workflow is:

Start with a supported base image.
Apply customization steps, such as installing software and configuring the OS.
Publish a versioned image to Azure Compute Gallery.
Deploy VMs from that image through the portal, Azure CLI, PowerShell, ARM templates, or Bicep.

A build pipeline can trigger this process when the organization updates its image definition or software. The gallery provides a place to manage and distribute image versions; the pipeline and its triggers must be configured.

Linked ARM templates and parameter files support repeatable infrastructure deployments. A primary template can reference smaller templates for shared components, while parameter files provide environment-specific values such as VM size, location, network names, and tags. Bicep provides a similar modular approach through modules.

VM extensions configure or manage a VM after deployment. For example, a Custom Script Extension can install software and apply a configuration script. Image Builder and extensions can be used together: place common, stable software in the image and use an extension for configuration needed by a particular deployment.

Exam tip: When asked to create a VM, consider the whole deployment: image + size + OS disk + NIC + VNet/subnet, followed by the access, security, availability, and management settings required by the scenario.

VM Disck Encryption, Movemenet, Size Management

Configure Azure VM disk encryption

Azure offers several ways to protect VM disk data. For AZ-104, distinguish managed disk encryption, encryption at host, and Azure Disk Encryption (ADE).

Method	What it protects	How it works
Managed disk server-side encryption	Managed OS and data disks stored in Azure	Enabled automatically for Azure managed disks. Platform-managed keys are the default; customer-managed keys are supported for eligible configurations.
Encryption at host	Temporary disks and disk caches on the VM host, as well as data flowing from the host to Azure Storage	Encryption begins on the host before data reaches Azure Storage. Enable it for a supported VM configuration.
Azure Disk Encryption (ADE)	Supported OS and data volumes inside the VM	Uses BitLocker on Windows or DM-Crypt on Linux, with Azure Key Vault managing encryption secrets and keys.

ADE retirement: Microsoft has scheduled Azure Disk Encryption for retirement on September 15, 2028. Microsoft recommends encryption at host for new VMs and migration of existing ADE-enabled workloads before retirement. Its documentation warns that ADE-encrypted disks will fail to unlock after a VM reboot following retirement. Follow Microsoft’s migration guidance, including the guidance for backups.

Customer-managed keys: When an organization needs to control the key used for managed disk encryption, Azure can use a disk encryption set associated with a key in Azure Key Vault, subject to the configuration’s requirements. This is distinct from enabling ADE inside the guest OS. Microsoft Learn

Exam tip: Managed disk server-side encryption is enabled automatically. Encryption at host extends protection to host-side caches and temporary disks. ADE is the guest-based BitLocker or DM-Crypt option.

Move a VM to another resource group, subscription, or region

The method depends on what is changing. A resource group or subscription move changes management ownership; a region move relocates the workload.

Destination	Typical method	Key consideration
Another resource group	Azure Resource Manager resource move	The VM remains in its existing Azure region.
Another subscription	Azure Resource Manager resource move	The subscriptions must be associated with the same Microsoft Entra tenant for this move method.
Another region	Azure Resource Mover	Prepare and replicate supported resources, validate the destination, and perform a planned cutover.

For a resource group or subscription move, review the VM’s dependencies, including disks, NICs, networking resources, public IPs, backup configuration, identities, and access assignments. Some resources must move together, while others have separate restrictions or require reconfiguration. Validate the move before committing it and update references that use resource IDs, because those IDs change with the resource group or subscription.

A move to a subscription in a different Microsoft Entra tenant is a separate migration scenario; the standard ARM move API does not support a cross-tenant VM resource move.

For a region move, check destination capacity, VM size and disk availability, quota, network configuration, and recovery requirements. Azure Resource Mover can coordinate a supported migration, but a successful move still requires testing and a planned cutover.

Exam tip: Moving a VM to another resource group does not move it to another region. A cross-region migration uses a different process.

Manage VM sizes

A VM size determines its compute capacity and affects supported features and limits, including:

Number of vCPUs and amount of memory.
Network and disk performance limits.
Number of supported NICs and data disks.
Support for capabilities such as Accelerated Networking, GPUs, and particular disk types.

o resize a VM in the Azure portal:

Open the VM and select Size.
Review available sizes and select an appropriate target.
Confirm that the size meets the workload, disk, network, and quota requirements.
Apply the resize and validate the VM and application after it restarts.

A resize generally causes a restart. Some changes require the VM to be stopped and deallocated, particularly when the target size is unavailable on the current hardware cluster. Deallocation can remove temporary disk data and may change a dynamically assigned public IP address. Availability-set VMs can have additional resizing constraints.

B-series burstable VMs

B-series VMs suit workloads that run below a baseline CPU level much of the time but occasionally need more processing power. Examples include development systems, small web applications, and lightly used servers.

Below baseline: The VM accumulates CPU credits, up to its credit limit.
Above baseline: The VM spends credits to burst above its baseline CPU performance.
Credits exhausted: CPU performance is limited to the baseline until credits accumulate again.

Monitor CPU Credits Remaining, CPU Credits Consumed, and CPU utilization to determine whether the VM can sustain its workload. If the application consistently needs CPU above the baseline, a non-burstable size may be a better fit.

Billing clarification: CPU credits control the VM’s ability to burst; they are not a separate billing currency. The VM is billed according to its applicable VM pricing and billing state, with related services such as disks billed separately. A low-usage period can build credits, but it does not by itself stop VM compute charges.

Manage Azure virtual machine disks

Azure managed disks are block storage volumes managed by Azure and used with virtual machines. Azure handles the underlying storage infrastructure, while you choose the disk type, capacity, performance, redundancy, encryption, and access controls.

The first diagram compares disk roles and types. The second covers protection, recovery, management, and private disk transfers.

VM disk roles

Disk role	Purpose	Persistence
OS disk	Contains the operating system and boot volume. A VM has one OS disk.	Usually a managed disk. Eligible VM configurations can use an ephemeral OS disk, which has different persistence and recovery characteristics.
Data disk	Stores application data, databases, files, and other information that must persist.	A managed disk remains a separate Azure resource. The VM size limits how many data disks can be attached and their achievable performance.
Temporary disk	Provides local scratch space for temporary files, page files, or swap.	Not a managed disk. Its contents can be lost during events such as deallocation, redeployment, or host maintenance. Not all VM sizes include one.

Temporary disk letters and device paths vary by image, operating system, VM generation, and disk controller. Check the VM’s actual configuration rather than assuming a fixed drive letter or Linux device name. Modern Azure VMs can use SCSI or NVMe controllers.

Exam tip: Store data you need to retain on an appropriate persistent disk, not solely on the temporary disk.

Managed disk types

Azure currently provides five managed disk types:

Disk type	Typical use	OS disk or data disk?
Ultra Disk	Data-intensive workloads requiring very high IOPS, throughput, and low latency, such as large databases. Performance can be adjusted within supported limits.	Data disk only
Premium SSD v2	Production data workloads requiring flexible capacity, IOPS, and throughput settings.	Data disk only
Premium SSD	Production applications requiring SSD performance and low latency.	OS or data disk
Standard SSD	Web servers, lightly used applications, development, and test workloads.	OS or data disk
Standard HDD	Low-cost, latency-insensitive workloads.	OS or data disk

The VM size, region, zone, disk type, and feature configuration determine what is available. Check both per-disk and per-VM IOPS and throughput limits: selecting a faster disk does not overcome a lower VM-level limit. Ultra Disk and Premium SSD v2 cannot be used as OS disks.

IOPS measures input/output operations per second. Throughput measures the amount of data transferred over time, commonly in MB/s. A workload can require high IOPS, high throughput, or both.

Common disk-management tasks

Create and attach: Create a managed data disk and attach it to the VM, subject to the VM’s disk limits.
Initialize and format: Inside Windows or Linux, identify the new disk, partition and format it as needed, and mount it or assign a drive letter.
Expand: Increase the disk size in Azure, then extend the partition or volume inside the guest OS. Some configurations require deallocation; others support online expansion.
Change disk type: Convert between supported types when requirements change. Some conversions have limitations or require migration through a snapshot.
Protect and recover: Configure backup or snapshots, monitor capacity and performance, and periodically test restoration. Microsoft Learn

Exam tip: Remember the distinction between a disk’s role, OS, data, or temporary, and its type, such as Premium SSD or Standard HDD. Also remember that Ultra Disk and Premium SSD v2 are data-disk-only options.

Building Azure VMs for HPC and machine learning

High-performance computing (HPC) and machine learning workloads can require substantial CPU or GPU capacity, high-speed communication between VMs, and storage capable of serving large datasets. The right configuration depends on how the application uses those resources.

Choose the compute resources

Workload	Typical Azure VM choice	Example
CPU-intensive HPC	Supported H-series sizes	Engineering simulations, scientific modeling, and financial analysis
GPU computing and ML	Supported N-series sizes, including NC and ND families	Model training, inference, and GPU-accelerated analytics
Distributed ML or HPC	Multiple compatible GPU or HPC VMs, with an appropriate interconnect	Training a model across multiple GPUs or running a parallel simulation

Some N-series sizes provide multiple GPUs and a high-throughput InfiniBand network with remote direct memory access (RDMA) for distributed workloads. Select a specific supported size: not every N-series VM has multiple GPUs or InfiniBand. The VM image, GPU drivers, communication libraries, and application framework must also support the chosen configuration.

Networking and storage options

Accelerated Networking: Uses SR-IOV on supported VMs to reduce networking overhead, latency, jitter, and CPU utilization for the VM’s Azure Ethernet network.
InfiniBand and RDMA: Provide a separate high-performance interconnect on supported HPC and GPU sizes. They are useful when distributed application nodes must exchange data frequently.
DPDK: A set of libraries for high-performance packet processing in user space. It can help supported Linux-based network functions, such as virtual network appliances, but requires compatible drivers and configuration. DPDK is distinct from RDMA and is not required for every HPC workload. Microsoft Learn
Ultra Disk: A high-performance managed data disk option with configurable performance. Verify support for the selected VM size, region, zone, and—if used—dedicated host.

Azure Batch

Azure Batch manages the scheduling and execution of large-scale jobs across a pool of compute nodes. A typical workflow is to submit a job, divide it into tasks, run those tasks on a GPU- or HPC-enabled pool, and collect the results.

You can configure pool autoscaling to adjust node counts with demand. Spot nodes may reduce costs for interruption-tolerant workloads, but Azure can reclaim that capacity. GPU drivers and the appropriate software environment must be available on the nodes.

Azure Dedicated Host

An Azure Dedicated Host reserves a physical server for one customer’s Azure VMs. It can help address physical isolation or licensing requirements, while allowing supported VMs to use Azure management features.

A demanding workload may combine a compatible dedicated host, Accelerated Networking, and Ultra Disk. Check the specific host SKU, VM size, region, zone, and configuration: not every combination is supported. A dedicated host is optional for HPC and does not, by itself, guarantee application performance. Host, storage, networking, and applicable software charges should be considered together.

Exam tip: Start with the workload requirement: GPU compute, CPU-intensive HPC, fast communication between nodes, high disk I/O, or physical host isolation. Then select a compatible VM size and supporting services, and benchmark the complete configuration.

Deploy VMs to availability zones and availability sets

Azure offers availability zones and availability sets to help keep applications available when infrastructure fails or maintenance occurs. Both approaches depend on deploying multiple application instances that can continue serving users when one instance is unavailable.

Availability zones

An availability zone is a physically separate location within a supported Azure region. Each zone has independent power, cooling, and networking infrastructure.

To make an application resilient to a zone outage, deploy its VM instances across at least two zones. For example:

VM1 runs in Zone 1.
VM2 runs in Zone 2.
An Azure Load Balancer sends requests to healthy instances.

If Zone 1 becomes unavailable, VM1 is affected, but VM2 in Zone 2 can continue serving traffic if the application, data, and load balancing are configured appropriately.

A single VM deployed to one zone remains dependent on that zone. It does not automatically move to another zone during an outage. Zone support and VM size availability vary by region.

Availability sets

An availability set is a logical group of VMs that Azure distributes across fault domains and update domains.

Fault domains represent groups of hardware that share infrastructure such as a power source and network switch. Spreading VMs across fault domains reduces the chance that one hardware failure affects all instances.
Update domains group VMs for planned platform maintenance. Azure sequences applicable maintenance across update domains to reduce simultaneous disruption.

For example, two application VMs in the same availability set can be placed in different fault and update domains. If a fault affects one domain, the other VM can continue operating, provided the application and traffic routing support it.

An availability set can have up to three fault domains and 20 update domains, depending on the configuration and region. The counts are selected when the set is created and cannot subsequently be changed. An availability set does not provide the same zone-level separation as a deployment across availability zones. Azure Virtual Machines

Comparison

Consideration	Availability zones	Availability sets
Scope	Physically separate zones within one supported region	Logical grouping across fault and update domains
Primary protection	Helps protect an application from a zone-level outage	Helps reduce the impact of hardware failures and planned maintenance
Application instances	Deploy at least two replicas across different zones	Deploy at least two replicas in the same availability set
Traffic distribution	Configure a load balancer or another routing solution	Configure a load balancer or another routing solution
Regional outage	Requires a separate cross-region recovery strategy	Requires a separate cross-region recovery strategy

Neither option automatically makes an application highly available. You must also consider load balancing, health probes, application state, data replication, backups, and testing. For a region-wide disaster, consider a separate disaster-recovery design, such as replication to another region.

Deploy in the Azure portal

When creating each VM, go to Basics → Availability options and choose the desired option:

For availability zones, select a supported region and zone. Deploy additional application VMs to other zones.
For an availability set, create or select an availability set and deploy the application VMs into it.
Configure networking and, where appropriate, place the VMs behind a load balancer with health probes.
Validate application access and test the loss of an instance or zone.

Existing VM placement changes can require a migration or redeployment; they are not always an in-place setting change. For example, Microsoft documents creating a new zonal VM as part of moving an existing regional VM into a zone. learn.microsoft.com

Exam tip: A question about physical separation across datacenters in one region points to availability zones. A question about fault domains and update domains points to an availability set.

Deploy and configure Azure Virtual Machine Scale Sets

An Azure Virtual Machine Scale Set (VMSS) manages a group of virtual machines that support an application. A scale set can change the number of VM instances as demand changes, distribute instances across availability zones when configured to do so, and integrate with load balancing and health monitoring.

The first diagram shows the architecture and orchestration modes. The second shows autoscaling, scale-in selection, health and repair, and updates.

1. Orchestration modes

Azure supports Uniform and Flexible orchestration. Both are supported modes, but they manage instances differently.

Feature	Uniform orchestration	Flexible orchestration
VM management	Instances are managed through scale-set VM APIs.	Instances are standard Azure VM resources managed with standard VM APIs.
Configuration	Uses a shared scale-set VM model and is suited to consistent instances.	Can manage supported combinations of VM configurations, including different VM types in supported scenarios.
Scaling profile	Required.	Optional. Without one, instances are managed individually.
Typical use	Large groups of similarly configured, often stateless application instances.	Workloads requiring more control over individual VMs or a mix of supported configurations.

The statement that all scale sets require identical VM types applies more closely to the Uniform model. Flexible orchestration provides more configuration flexibility. If automatic scale-out is required, check the supported scaling-profile and instance-mixing options for the intended configuration.

A scale set can support hundreds or, for supported configurations, up to 1,000 instances. Actual limits depend on orchestration mode, configuration, quota, region, and capacity.

2. Scale sets, availability zones, and load balancing

A scale set can be deployed across multiple availability zones in a supported region. Zone placement is determined by the scale-set configuration.

A load-balancing service can then direct incoming traffic to healthy instances:

Service	Layer	Typical use
Azure Load Balancer	Layer 4	TCP/UDP traffic distribution to VM instances
Azure Application Gateway	Layer 7	HTTP/HTTPS applications requiring features such as host- or path-based routing, TLS termination, or an optional WAF

The load balancer directs traffic; it does not determine where the scale-set instances are placed. Configure zone distribution in the scale set, then configure health probes and routing in the chosen load-balancing service.

3. Autoscaling

Autoscaling changes the number of VM instances based on configured metrics or a schedule:

Scale out: Add instances when more capacity is needed.
Scale in: Remove instances when demand falls.

For example, an autoscale configuration might use:

Setting	Example
Minimum capacity	2 VMs
Default capacity	3 VMs
Maximum capacity	6 VMs
Scale-out rule	If average CPU is above 70% for 10 minutes, add 1 VM
Scale-in rule	If average CPU is below 30% for 15 minutes, remove 1 VM
Cooldown	Wait after a scaling action before evaluating another action, as configured

These are example thresholds, not universal recommendations. Choose values based on application behavior and test them under load. Separate scale-out and scale-in thresholds, evaluation periods, and cooldowns help prevent repeated expansion and contraction.

Horizontal scaling changes the number of VMs. Changing an individual VM’s CPU or memory means choosing a different VM size; that is a separate resize operation and generally involves a restart.

Metrics and telemetry

Azure Monitor autoscale can use supported platform and custom metrics. Common VM-related examples include CPU utilization, network traffic, and disk operations. The exact metrics and aggregations available depend on the selected metric and resource.

For additional visibility:

Application Insights collects application telemetry, such as request rates, response times, failures, and custom application measurements when the application is instrumented.
VM Insights and Azure Monitor Agent, when configured, can collect guest-level performance data and support deeper monitoring.
Custom metrics can represent business or application signals where supported, for example, work-queue depth.

Application monitoring does not automatically create an autoscale rule. The metric must be available in a supported form and referenced by a configured rule.

4. Scale-in policy

An autoscale rule determines when and how much to scale in. A scale-in policy helps determine which instances are removed.

Policy	Selection behavior
Default	First balances across availability zones, then fault domains on a best-effort basis, and then removes the instance with the highest instance ID from the selected group.
NewestVM	Balances across zones when applicable, then selects the newest eligible VM.
OldestVM	Balances across zones when applicable, then selects the oldest eligible VM.

Instance protection, when configured and supported, can exclude an instance from scale-in. Zone or fault-domain balancing through scale-in is achieved by selecting instances for removal; it does not move a VM between zones.

5. Health monitoring and automatic repair

Health monitoring determines whether an instance can serve the application. Depending on the orchestration mode and configuration, scale sets can use:

Application Health Extension: Runs within the VM and reports application health using a configured TCP, HTTP, or HTTPS endpoint.
Supported Azure Load Balancer health probe: Checks an endpoint using TCP, HTTP, or HTTPS.

A UDP application can be load balanced by Azure Load Balancer, but its health probes use TCP, HTTP, or HTTPS, not UDP.

When automatic instance repairs are enabled and the required health monitoring is configured, the scale set can take a supported repair action on an unhealthy instance, such as restart, reimage, or replace. A configured grace period allows a new or recently repaired instance time to start before repair evaluation.

A load-balancer probe and automatic repair serve related but different purposes: the probe can stop traffic going to an unhealthy backend; automatic repair must be configured if the scale set should also attempt to recover that instance.

6. Upgrade and maintenance policies

Where supported, the scale-set upgrade policy determines how changes to the scale-set model reach existing instances.

Mode	Behavior
Manual	An operator controls when existing instances receive the model update. New instances use the current model.
Automatic	Azure applies the model update automatically, without a guaranteed instance-update order.
Rolling	Azure updates instances in batches, using health checks and configured rollout controls.

Automatic OS image upgrades are a separate feature for applying newer supported OS image versions; they should not be confused with the general model upgrade policy.

Flexible-mode documentation note: Microsoft’s current documentation is inconsistent: one orchestration-mode page lists some Flexible upgrade features as unsupported, while a dedicated upgrade-policy page describes Flexible rolling upgrades with the Application Health Extension. Verify the current support matrix, scaling profile, image, and region for the exact feature before relying on it in a deployment.

7. Basic deployment sequence

Create the scale set and select Uniform or Flexible orchestration.
Choose the VM image, size, region, network, and availability-zone configuration.
Configure a scaling profile if automatic scaling is required.
Associate Azure Load Balancer or Application Gateway if the application needs traffic distribution.
Configure instance health monitoring and automatic repairs if required.
Configure autoscale rules, capacity limits, and a scale-in policy.
Review upgrade and OS maintenance settings, then test scale-out, scale-in, health checks, and recovery.

Exam tip: A scale set changes instance count to handle demand. Autoscale rules decide when to change capacity; the scale-in policy helps select which VM is removed; and health and repair settings address unhealthy instances.

Azure virtual machine cost controls

Azure VM cost management combines usage monitoring, spending analysis, and optimization recommendations. The objective is to provide enough capacity for the workload while avoiding unnecessary compute, storage, and licensing costs.

Monitor usage and review recommendations

Azure Monitor provides metrics that help reveal how a VM is used over time. Depending on what is collected and configured, these can include CPU, network, disk, and guest operating-system memory measurements.

Microsoft Cost Management + Billing helps you analyze spending by subscription, resource group, resource, tags, and other dimensions. You can also configure budgets and alerts to notify stakeholders when spending reaches a threshold.

Azure Advisor analyzes supported utilization data and generates recommendations, including suggestions to resize or shut down underutilized VMs. Cost Management can display these Advisor recommendations alongside cost information. Recommendations are estimates that should be reviewed before changes are made.

Image-related clarification: The VM image and associated software licenses can affect cost, but VM right-sizing recommendations are based on utilization and other supported signals.

An image-analysis feature is not required for right-sizing.

Common cost controls

Control	How it helps	Consideration
Right-size VMs	Select a smaller or more appropriate VM size when observed usage leaves sufficient capacity.	Check peak CPU, memory, disk and network needs, compatibility, and application performance. A resize can restart the VM or require deallocation.
Stop and deallocate unused VMs	Releases the VM’s compute allocation and stops VM compute charges.	A VM that is merely Stopped can still incur compute charges. Managed disks and other associated resources can continue to incur charges after deallocation.
Use autoscaling	VM Scale Sets add or remove instances as demand changes.	Configure appropriate minimum and maximum counts, rules, and cooldowns.
Use budgets and alerts	Warns stakeholders when spending reaches configured thresholds.	A budget alert does not automatically cap spending or stop resources.
Evaluate reservations and savings plans	Can reduce compute costs for eligible, predictable usage under a commitment.	Review commitment terms, utilization, and whether resizing affects discount coverage.
Use Spot VMs	Offers access to unused Azure capacity at a lower cost.	Azure can interrupt or evict Spot VMs; use them for suitable fault-tolerant workloads.
Evaluate Azure Hybrid Benefit	Can reduce costs for eligible workloads using qualifying licenses.	Verify license eligibility and applicable terms.
Review associated resources	Identifies costs such as unused disks, snapshots, public IPs, and excess storage capacity.	Confirm a resource is no longer needed before deleting it.

A stopped VM and a stopped (deallocated) VM have different billing implications. Deallocation releases the underlying compute allocation, while persistent resources such as managed disks remain and can continue to be billed.

Practical right-sizing workflow

Review cost: Use Cost Management to identify expensive VMs and their related resources.
Review utilization: Examine representative usage over time, including peak periods and any available guest memory data.
Inspect Advisor recommendations: Review the proposed target size and estimated savings.
Validate: Check application requirements, VM-size capabilities, disk and network limits, availability, and existing reservation or savings-plan coverage.
Implement and monitor: Resize or deallocate as appropriate, then verify performance and compare actual costs.

Exam tip: For an underused VM, look for an Azure Advisor right-sizing recommendation. To stop VM compute charges while preserving the VM and its disks, select Stop (deallocate), and remember that disk charges can continue.

Spot VMs and interruption handling

Azure Spot VMs use available Azure capacity at a lower price, but Azure can evict them when capacity is needed or the configured conditions are met. They fit interruption-tolerant workloads such as batch processing, simulations, or restartable jobs.

For reliable use, design the workload to save progress to persistent storage, handle interruption, and restart or reschedule work. An eviction notice may be available, but the workload should tolerate interruption even if it cannot complete its checkpoint.

Azure VM reliability and redundancy

A reliable Azure VM solution combines several controls: availability to keep an application running during infrastructure failures, backup to recover data, disaster recovery to restore service in another location, and operational practices to keep the environment configured and patched.

The first diagram compares availability, disk redundancy, backup, and disaster recovery. The second shows configuration, patching, managed identity, and Spot VM considerations.

Availability and disk redundancy

For an application that must remain available during a zone outage, deploy multiple application instances across availability zones in a supported region. A load balancer with health probes can direct traffic to healthy instances.

This requires more than placing VMs in different zones. The application must also handle the loss of an instance, and its data and dependencies must remain available. A single VM in one zone is unavailable if that zone fails.

Managed disk redundancy protects disk data against certain infrastructure failures:

Disk redundancy	How it works	Main protection
Locally redundant storage (LRS)	Maintains three copies within one location in the region.	Helps protect against local hardware failures.
Zone-redundant storage (ZRS)	Synchronously replicates supported disks across three availability zones in a region.	Helps protect disk data against a zone-level failure.

ZRS availability depends on the disk type and region. A ZRS disk also does not automatically make a single VM or its application available during a zone outage: the compute and application recovery design still matters.

Redundancy is not backup. A deletion, corrupted file, or unwanted application change can affect replicated data. Use backups and test restores to recover an earlier state.

Azure Backup and Site Recovery

Capability	Azure Backup	Azure Site Recovery
Primary purpose	Recover data or a VM from a recovery point.	Recover workloads in another location after a disruption.
Typical use	Recover from deletion, corruption, ransomware, or an operational mistake.	Replicate and recover VMs during a regional or other supported disaster scenario.
Key configuration	Backup policy, schedule, retention, and vault.	Replication, target resources and networking, recovery points, and recovery plans.
Validation	Perform restore tests.	Perform test failovers and application validation.

Azure Backup

Azure VM Backup uses a Recovery Services vault and a backup policy to manage recovery points and retention. Depending on the supported configuration, you can restore a VM, disks, or individual files and folders.

Backup consistency varies by OS and configuration. For example, Windows VM backup can coordinate with Volume Shadow Copy Service (VSS) for application-consistent snapshots. Linux VM backups are generally file-system consistent by default; application-consistent protection may require pre- and post-scripts or a workload-specific backup method.

Azure Site Recovery

Azure Site Recovery (ASR) replicates supported VMs to a recovery location and helps orchestrate failover and failback. A recovery plan can group application components and sequence their recovery; scripts and automation can be added where needed.

A typical disaster-recovery process is:

Configure replication and target networking.
Monitor replication health and recovery points.
Run a test failover into an isolated network.
Validate the application, DNS, connectivity, permissions, and data.
Measure recovery time and document results.
During an actual event, initiate failover and follow the recovery and failback procedures.

ASR replication is generally asynchronous, so the most recent changes may not yet be present at the recovery site. It does not promise zero data loss. Failover is also not automatically initiated by default; organizations can build additional detection and automation where appropriate.

Two terms are useful for DR planning:

Recovery point objective (RPO): The maximum acceptable amount of data loss, measured in time.
Recovery time objective (RTO): The maximum acceptable time to restore the service.

ASR logs and Azure Monitor can help review replication health, test failover status, and recovery metrics. The organization still needs to define its tests, assess results, and maintain any compliance evidence required by its policies.

Multi-region application deployments

A multi-region application can use VMs in separate regions, application-level data replication, and a global routing service such as Azure Front Door or Traffic Manager. This can reduce user latency and improve resilience, but these capabilities must be designed and configured:

Deploy sufficient application capacity in each region.
Select and validate a data replication strategy.
Configure routing and health checks.
Test failover, failback, application dependencies, and data consistency.

Active-active application deployments and ASR-based disaster recovery are different patterns. Both can be part of a broader resilience strategy, but neither automatically guarantees zero data loss or uninterrupted service.

Configuration and maintenance

VM extensions and repeatable configuration

Azure VM extensions can automate tasks during or after VM deployment. For example, the Custom Script Extension can install software, apply settings, or run a configuration script. ARM templates or Bicep can deploy the VM and its extension together, supporting repeatable deployments.

PowerShell Desired State Configuration (DSC) has also been used for VM configuration. For new designs, check Microsoft’s current guidance: the Azure DSC extension is scheduled to retire on March 31, 2028, and Azure Automation State Configuration is scheduled to retire on September 30, 2027. Azure Machine Configuration is Microsoft’s recommended transition for the latter.

Azure Update Manager

Azure Update Manager can assess update status, schedule installation in maintenance windows, and report update compliance for supported Windows and Linux machines.

A practical approach is to:

Assess available updates.
Test updates on a pilot group.
Deploy to production in planned maintenance windows.
Validate application health and review results.
Use a separately designed recovery procedure if an update causes problems.

Update Manager supports scheduling and orchestration, but it does not provide a built-in OS patch rollback mechanism. Testing and rollback or restore procedures must be planned separately.

Azure VM Operational Reliability & Access Review

Azure VM security configurations and best practices

Securing an Azure VM involves several layers: protecting disks and recovery points, controlling administrator and application access, enforcing configuration standards, and collecting the information needed to detect problems.

1. Disk protection and recovery

Encryption options

Method	Purpose	Key point
Server-side encryption (SSE)	Encrypts managed disk data at rest in Azure Storage.	Enabled automatically. Azure uses platform-managed keys by default; supported configurations can use customer-managed keys.
Encryption at host	Extends encryption to supported host-side disk caches and temporary disks, and encrypts data before it reaches Azure Storage.	Enable it for a supported VM configuration.
Azure Disk Encryption (ADE)	Encrypts supported guest OS volumes using BitLocker on Windows or DM-Crypt on Linux.	ADE is scheduled to retire on September 15, 2028. Microsoft recommends encryption at host for new VMs and migration planning for existing ADE deployments.

For supported customer-managed key configurations, a disk encryption set connects managed disk encryption to a key managed in Azure Key Vault. Protect access to the key and plan for key lifecycle management: a disk may become unavailable if Azure cannot use the required key.

Disk permissions and private transfers

Two permission layers apply:

Azure RBAC controls management actions against the Azure disk resource, for example, creating, attaching, modifying, snapshotting, or deleting it.
Guest OS permissions control access to files and folders within the mounted disk.

Private Link for managed disks protects supported disk and snapshot import/export operations using a disk access resource and private endpoint. Normal VM I/O to an attached managed disk does not require that private endpoint.

Snapshots, images, and backup

A managed disk snapshot is a point-in-time copy of one disk. Full and incremental snapshots can be used to create a new managed disk. A snapshot taken while a disk is active can be crash-consistent; multi-disk applications need additional coordination to achieve the desired consistency.

Azure Backup provides policy-based recovery points and retention for supported VM and disk configurations. Select the backup scope and consistency level that match the application, and test restores.

A custom VM image is primarily used to deploy VMs from a prepared OS and configuration. It should not automatically be treated as an application-consistent backup of a multi-disk workload.

2. Identity and administrative access

Managed identity and Key Vault

A system-assigned managed identity gives a VM an identity in Microsoft Entra ID. An application on the VM can use that identity to request a token and access a supported Azure service without storing an application password or client secret.

For Key Vault:

Enable the VM’s system-assigned managed identity.
Grant the identity only the required Key Vault permissions through the vault’s configured authorization model.
Ensure the VM can reach the vault and resolve its name.
Configure the application to use the managed identity.

Enabling the identity does not grant Key Vault access by itself. The identity still needs authorization and network connectivity.

Bastion, Just-in-Time access, and identity controls

Control	Purpose
Azure Bastion	Provides a managed administrative path to a VM over its private IP address using RDP or SSH.
Just-in-Time (JIT) VM access	Temporarily permits approved management access for a defined source, port, and duration.
Azure RBAC	Controls who can manage Azure resources and request supported operations.
Microsoft Entra Conditional Access	Applies identity-based sign-in conditions where the relevant authentication flow supports it.
Privileged Identity Management (PIM)	Can provide time-limited activation of eligible privileged roles.

Defender for Servers Plan 2 provides JIT VM access. JIT uses supported network controls, including NSG rules, to limit management-port exposure. Bastion and JIT can be combined when configured, but JIT is not required for every Bastion deployment. Guest OS authentication is still required to sign in to the VM.

For auditability, use the Azure Activity Log for relevant management and JIT operations, Bastion diagnostics where configured, and guest OS security logs for sign-in and session activity. These sources do not automatically provide a complete record of every command executed inside the VM.

VM tagging and least privilege

To let a user manage tags without granting broad VM-management rights, assign Tag Contributor at the narrowest appropriate scope. The user may also need Reader or equivalent existing read permissions to find and view the VMs in the portal.

Azure Policy can enforce or audit tagging requirements, but Azure RBAC grants the user permission to perform the tagging action.

Dedicated Host

Azure Dedicated Host reserves a physical server for a single customer’s VMs and can support physical isolation or licensing requirements. The host remains in Azure datacenters and can share underlying networking and storage infrastructure with other Azure services.

Do not treat a dedicated host as a guarantee of network bandwidth, storage performance, or complete infrastructure isolation. Check supported host and VM combinations and benchmark the workload.

3. Governance, monitoring, and hardening

Azure Policy and Machine Configuration

Azure Policy evaluates resources against organizational standards. Depending on the assigned policy, it can audit configurations, deny noncompliant deployments, or deploy required configuration through supported effects and remediation.

Examples include policies to:

Restrict deployments to approved regions or VM configurations.
Require tags.
Assess whether security features are enabled.
Deploy supported monitoring or configuration components.

Azure Machine Configuration, formerly called guest configuration, extends assessment into supported Windows and Linux guest operating systems. Its behavior depends on the assigned configuration:

Mode	Behavior
Audit	Checks settings and reports compliance.
Apply and monitor	Applies the configuration and then monitors for drift.
Apply and auto-correct	Applies the configuration and corrects supported drift automatically.

Automatic remediation is not universal: it depends on the policy or package, assignment mode, permissions, extensions, and other prerequisites. Some Azure Policy remediation actions also require a configured remediation task.

VM monitoring

Azure Monitor provides several views of a VM:

Metrics: Platform measurements such as CPU, network, and disk activity.
Activity Log: Azure management operations against resources.
Insights: A consolidated monitoring experience for supported VM performance data.
Logs: Queries against collected data in a Log Analytics workspace.
Alerts and workbooks: Notifications and dashboards built from configured data and conditions.

For guest OS events and performance data, configure the Azure Monitor Agent (AMA) and an appropriate data collection rule (DCR). VM Insights can install AMA and create a default DCR for supported onboarding scenarios. Configure the required data sources and alert rules rather than assuming all guest security events are collected automatically.

Additional hardening practices

Trusted Launch: On supported Generation 2 VMs, use Secure Boot and a virtual TPM to strengthen the boot process. Boot-integrity monitoring requires the relevant attestation and Defender for Cloud configuration.
Microsoft Defender for Servers: Enable the appropriate plan for supported security recommendations and threat-detection capabilities.
Azure Update Manager: Assess and schedule OS updates. Test patches and maintain a separate recovery plan because built-in patch rollback is not provided.
Backup: Protect the VM and its data according to recovery requirements, and test restoration.
Network access: Limit management and application ports using NSGs and appropriate network paths.

AZ-104 exam tip: RBAC answers “Who can perform an action?” Azure Policy answers “Does the resource meet the required configuration?” Machine Configuration can assess—and, when configured, remediate—settings inside the guest OS.

Provision and manage containers in the Azure portal

Azure 'Azure Kubernetes Service' (AKS) and Containers Overview
Container Networking
Create and manage an Azure Container Registry
Provision a container by using Azure Container Instances
Provision a container by using Azure Container Apps
Manage sizing and scaling for containers, including Container Instances and Container Apps
AKS and Container security concepts
Azure Kubernetes special features

Azure 'Azure Kubernetes Service' (AKS) and containers overview

Azure Kubernetes Service (AKS) is Azure’s managed Kubernetes service. It helps you deploy and operate containerized applications when you need capabilities such as service discovery, scaling, health management, and coordinated updates.

The four diagrams below build from a container image to an AKS cluster, then show application traffic, scaling, and advanced workloads.

1. From a container image to a running application

A container image is a packaged template containing an application and its dependencies. A container is a running instance of that image. Images are typically stored in a registry, such as Azure Container Registry, until a node pulls them.

A pod is the smallest unit Kubernetes schedules. It contains one or more closely related containers that share networking and can share storage. Most application pods contain one primary container; a supporting sidecar container is added when needed.

A node is the machine that runs pods. In a typical AKS cluster, nodes are Azure VMs. Containers share the node’s operating-system kernel, while a VM has its own guest operating system.

Term	What to remember
Image	The packaged application template.
Registry	The place where container images are stored.
Container	A running instance of an image.
Pod	The unit Kubernetes schedules; contains one or more containers.
Node	The machine that runs pods.
Node pool	A group of nodes with a common configuration.

2. AKS cluster architecture

The control plane makes decisions about the cluster and maintains its desired state. Azure operates the control-plane components for AKS:

API server: The entry point for Kubernetes management requests. Tools such as kubectl communicate with it.
etcd: Stores cluster configuration and state.
Scheduler: Selects a suitable node for a pod that needs to run.
Controllers: Reconcile the actual state with the desired state, for example, helping maintain the requested number of pod replicas.

The worker nodes run the applications. Each node uses a kubelet to communicate with the control plane and ensure assigned pods run. The container runtime, commonly containerd, manages the containers. The runtime can use an OCI-compatible runtime such as runc to start them.

Kubernetes networking may use kube-proxy to implement Service traffic forwarding. Some AKS networking configurations use a replacement dataplane, so kube-proxy should not be assumed to be present in every cluster.

AKS requires a system node pool for critical system pods. A user node pool is commonly used to separate application workloads from system workloads; an application can also run in a system pool unless scheduling restrictions prevent it.

Who manages what?

Azure operates the AKS control plane. You remain responsible for your applications, identities, access policies, workload configuration, and operational choices. In AKS Standard, you configure and manage node pools and their upgrade policies. AKS Automatic preconfigures and automates more cluster and node-management settings.

AKS pricing: a correction to the older note

“AKS is free and you only pay for the nodes” applies only in a limited sense:

Cluster-management tier	Key point
Free	No cluster-management charge and no financially backed control-plane uptime SLA.
Standard	Paid cluster-management tier with an uptime SLA.
Premium	Paid tier that includes Standard capabilities and supports AKS long-term support for eligible Kubernetes versions.

In every tier, other Azure resources, such as worker VMs, disks, load balancers, and networking, can incur charges. AKS Automatic is configured with the Standard tier during cluster creation.

Exam tip: Azure manages the AKS control plane, but the customer still manages the applications and their security and operational configuration.

3. Application traffic and scaling

Getting traffic to pods

A Kubernetes Service provides a stable way to reach a group of matching pods, even when individual pods are replaced and their IP addresses change.

A Service configured with type: LoadBalancer can provision an Azure Load Balancer to expose the application. Depending on configuration, the frontend can be public or internal. The load balancer and Service route traffic to eligible application pods.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

In this example, the Service listens on port 80 and forwards to port 8080 on pods labeled app: web. The application deployment must create pods with that label and have the application listening on the target port.

Scaling: pods and nodes are different

Mechanism	What it scales	Example
Horizontal Pod Autoscaler (HPA)	Pod replicas	Increase web-app replicas when CPU utilization rises.
KEDA	Workload replicas based on events	Increase worker replicas as a queue grows; supported workloads can scale to zero.
Cluster Autoscaler	Nodes in an enabled node pool	Add a node when pending pods cannot fit on existing nodes.

These mechanisms can work together: increasing demand causes more pods to be requested; if the cluster lacks capacity, the Cluster Autoscaler can add nodes within the configured limits. Pod resource requests, node-pool limits, quotas, and available VM capacity all affect the result.

KEDA integrates with HPA for event-driven scaling. Avoid independently configuring both a KEDA ScaledObject and another HPA to control the same workload.

Exam tip: HPA and KEDA scale pods. Cluster Autoscaler scales nodes.

4. Advanced workloads: service mesh and GPUs

Istio service mesh

The optional Istio-based service mesh add-on helps manage communication between microservices. It can provide traffic management, telemetry, and mutual TLS (mTLS) between participating services when configured.

The mesh adds operational components and resource overhead. It does not automatically secure every connection or replace Kubernetes and Azure access controls; workloads must participate in the mesh and policies must be configured.

GPU-enabled node pools

AKS supports GPU-enabled node pools for workloads such as machine-learning training and inference. A workload requests GPU resources, and Kubernetes schedules it onto a node that has compatible capacity.

You must select a supported GPU VM size and account for regional availability, quota, drivers, device plugins, and cost. Autoscaling can help add GPU nodes when workloads need them, but it remains subject to configured limits and available capacity.

When to choose AKS

Azure option	Typical use
Azure Container Instances	Run a container or container group without managing Kubernetes nodes.
Azure Container Apps	Run containerized applications with managed application features and scaling, without directly managing a Kubernetes cluster.
Azure Kubernetes Service	Use Kubernetes APIs and orchestration for applications that need more control over deployment, networking, workloads, and cluster configuration.

AKS is useful when an application consists of multiple services that need coordinated deployments, service discovery, health monitoring, and scaling. It also introduces Kubernetes configuration and operational responsibilities, so the simpler services can be appropriate when full Kubernetes control is unnecessary.

Bridge to Kubernetes

Bridge to Kubernetes, is a developer extension historically used with Visual Studio or Visual Studio Code to run and debug a local microservice while connecting it to dependencies in a Kubernetes cluster. Treat it as a development aid, not an AKS cluster component. Verify current extension availability and support before choosing it for a new workflow.

AZ-104 review points

Control plane: API server, scheduler, controllers, and etcd; operated by Azure in AKS.
Node: A machine that runs pods; a node pool groups similarly configured nodes.
Pod: The smallest Kubernetes scheduling unit; contains one or more containers.
Service: Gives clients a stable way to reach matching pods; LoadBalancer can expose them through an Azure Load Balancer.
HPA/KEDA: Adjust workload replicas. Cluster Autoscaler: adjusts node capacity.
System pool versus user pool: System pools host critical cluster services; user pools commonly host application workloads.
Pricing: The Free tier has no cluster-management fee, but workload resources still cost money. Standard and Premium have paid management tiers.

Container Networking

The diagram compares where AKS pods receive their IP addresses and how their traffic reaches resources outside the cluster.

Networking mode	Pod IP allocation	Key distinction
Kubenet — legacy	Separate pod address range outside the node subnet.	Uses route tables for pod routing; outbound traffic to the VNet is translated to the node IP.
Azure CNI Node Subnet — legacy	Same VNet subnet as the nodes.	Pods consume subnet addresses, so plan enough IPs for nodes, pods, and growth.
Azure CNI Pod Subnet	A separate pod subnet in the VNet.	Separates node and pod addressing; dynamic allocation assigns pod IPs as needed.
Azure CNI Overlay	Separate pod CIDR outside the VNet address space.	Conserves VNet IPs and does not require pod-routing UDRs. Traffic leaving the pod network uses the node IP through SNAT.

Azure CNI Node Subnet and Pod Subnet use flat networking, where pods have VNet addresses. Overlay uses a separate pod address space; applications are typically exposed through Kubernetes Services or ingress rather than direct external access to pod IPs.

Clarification: “Overlay does not use route tables” means it does not require route tables for routing between pods. UDRs may still be used for other purposes, such as directing outbound traffic through Azure Firewall.

AZ-104 tip: Separate VNet pod subnet → Azure CNI Pod Subnet. Separate pod CIDR that conserves VNet addresses → Azure CNI Overlay. Kubenet retires on March 31, 2028; Microsoft recommends migration to Azure CNI Overlay.

Create and manage an Azure Container Registry

What is Azure Container Registry?

Azure Container Registry (ACR) is a managed, private registry for storing and distributing container images and other supported Open Container Initiative (OCI) artifacts. It integrates with container tools, development pipelines, and Azure services.

A typical workflow is:

A developer creates application code and a Dockerfile.
A build process combines the code, dependencies, and a base image into a container image.
The image is pushed to a repository in ACR.
A deployment target pulls the image from ACR.
A container runtime starts one or more containers from that image.

AKS, Azure Container Apps, Azure Container Instances, and other compatible container platforms can pull images from ACR when they have the required authentication and network access.

Registry, repository, image, and container

Concept	Description	Example
Registry	The service that stores and distributes images.	myregistry.azurecr.io
Repository	A collection of related images within a registry.	webapp
Tag	A readable label associated with an image.	v1 or v2
Digest	A content-based identifier for a specific image manifest.	A sha256 digest
Container	A running instance of an image.	A running web application

An image reference might look like:

myregistry.azurecr.io/webapp:v1

Here, myregistry.azurecr.io is the registry, webapp is the repository, and v1 is the tag. Tags can be reassigned; referencing an image by digest identifies the specific image content more reliably for repeatable deployments.

Exam tip: ACR stores and distributes the image. AKS, Container Apps, Container Instances, or another runtime runs the resulting container.

Provision containers with Azure Container Instances and Azure Container Apps

The diagram below compares two ways to run a container image in Azure without managing virtual machines. Azure Container Instances (ACI) is suited to running individual container groups and short-lived tasks. Azure Container Apps adds managed application features such as ingress, revisions, and automatic replica scaling.

Both services can pull images from Azure Container Registry (ACR) or another supported registry. Both can also use Azure Files for persistent data when configured.

Azure Container Instances

Azure Container Instances lets you run containers without deploying or managing servers or a Kubernetes cluster. You provide an image and configure settings such as CPU, memory, networking, and restart behavior.

ACI deploys containers in a container group. A group can contain an application container and, in supported Linux configurations, additional containers such as a logging sidecar. Containers in a group share their lifecycle and local network.

Common ACI use cases include:

A batch job or data-processing task that runs and exits.
A development or test container.
A simple containerized application that does not require a managed autoscaling platform.
A short-lived workload initiated by another application or automation process.

Provision an ACI container in the Azure portal

Search for Container instances and select Create.
Select a subscription, resource group, container name, and region.
Choose an image source, such as a public registry or Azure Container Registry, and enter the image reference.
Select the operating system and configure CPU and memory.
Configure networking, including the required ports and either public or private connectivity as appropriate.
Configure optional settings, such as environment variables, a restart policy, and storage.
Select Review + create, validate the configuration, and create the container group.
Review the container’s status and logs; test the application endpoint if networking was enabled.

For a private ACR image, the container group needs an appropriate authentication method and permission to pull the image. ACI supports managed identity for ACR authentication in supported configurations.

Restart policies

Policy	Behavior	Example
Always	Restarts the container after it stops.	A long-running application.
On failure	Restarts the container when it exits unsuccessfully.	A batch job that should retry after an error.
Never	Does not restart the container after it exits.	A task intended to run once.

ACI does not provide the same built-in application replica autoscaling experience as Container Apps. You can create additional container groups through external automation when needed.

Networking note: When an ACI container group is deployed into a virtual network and needs outbound connectivity, Microsoft documents a NAT gateway as the supported outbound configuration.

Azure Container Apps

Azure Container Apps is a managed platform for running containerized applications and microservices. Azure manages the underlying infrastructure while you configure the application, its image, resources, networking, and scaling rules.

A container app runs inside a Container Apps environment. An environment provides a shared boundary for one or more container apps and their supporting platform configuration.

Container Apps provides capabilities including:

Ingress: Makes an application reachable using supported HTTP or TCP configurations.
Replica scaling: Adds or removes application replicas based on configured demand.
Revisions: Maintains versions of an application configuration for deployment and traffic management.
Service discovery: Helps container apps communicate within an environment.
Persistent storage integration: Supports mounting Azure Files where an application requires persistent shared storage.

Provision a container app in the Azure portal

Search for Container Apps and select Create.
Choose the subscription, resource group, application name, and region.
Select an existing Container Apps environment or create one.
Choose an image from ACR or another supported registry, and configure authentication if it is private.
Configure container resources, environment variables, secrets, and any required storage.
Enable ingress if the app needs to receive traffic. Choose the appropriate external or internal access and specify the container’s target port.
Configure the minimum and maximum replicas and any scaling rules.
Select Review + create, then create the app.
Check the revision and replica status, inspect logs, and test the application URL if ingress is enabled.

Automatic scaling

Container Apps supports horizontal scaling: it adds or removes replicas of an application based on rules. Scaling can respond to HTTP requests, TCP connections, or supported event sources such as a message queue.

For example:

A web app receives more requests, so Container Apps starts additional replicas.
A queue accumulates messages, so Container Apps starts more worker replicas.
Demand falls, so the number of replicas decreases.

You can configure a minimum and maximum replica count. Some workloads can scale to zero when idle; set a minimum of one or more if an instance must remain running. When ingress is disabled, configure an appropriate scale rule or a nonzero minimum so the app has a way to start when needed.

Ingress and scaling have different jobs: ingress routes incoming traffic; scaling changes the number of replicas available to handle work.

Revisions

A revision is an immutable snapshot of a container app’s configuration. A revision-scope change, such as an updated image or scaling configuration, creates a new revision. In multiple-revision mode, you can configure traffic distribution between active revisions to support a controlled rollout.

Persistent storage

Container filesystem changes should not be treated as durable application storage. The optional Azure Files path in the diagram represents a mounted file share that can retain data independently of an individual container or replica.

The connection must be configured; persistence does not happen automatically. For ACI, Azure Files volume mounting is supported for Linux container groups, and the documented mount configuration requires storage account details and an access key.

Choosing between ACI, Container Apps, and AKS

Requirement	Usually a good starting point
Run a container or batch task without managing servers	Azure Container Instances
Run an application with managed ingress and automatic replica scaling	Azure Container Apps
Manage Kubernetes workloads using Kubernetes APIs and cluster configuration	Azure Kubernetes Service

AZ-104 exam tip: “Run a container quickly without managing infrastructure” points toward ACI. “Run microservices with automatic scaling and managed ingress” points toward Container Apps. “Full Kubernetes orchestration and cluster control” points toward AKS.

Manage container sizing and scaling

The diagram shows the main distinction: Azure Container Instances (ACI) lets you size a container group, while Azure Container Apps lets you size an application replica and configure rules that add or remove replicas.

Sizing determines how much CPU and memory a container receives. Scaling changes the amount of capacity available, for example, by running more copies of an application.

Azure Container Instances

ACI runs containers without requiring you to manage the underlying virtual machine. It is useful for isolated applications, build jobs, and tasks that run for a limited time.

Size a container group

A container group is the deployment unit in ACI. Its containers share a lifecycle, local network, and access to configured volumes. A group is conceptually similar to a Kubernetes pod, although it is not itself a Kubernetes pod.

You specify the CPU and memory requested by the containers. For a multi-container group, ACI calculates the group’s allocation by adding the requests of its containers.

Container	CPU request	Memory request
Application	1 vCPU	2 GiB
Logging sidecar	0.5 vCPU	1 GiB
Group total	1.5 vCPU	3 GiB

Supported resource amounts depend on the region, operating system, quotas, and deployment configuration. ACI supports Linux and Windows containers; multi-container groups are supported for Linux.

Scale ACI workloads

ACI does not provide Container Apps’ built-in rule-driven application replica autoscaling. To run more copies, you can deploy additional container groups using external automation and arrange traffic distribution if the workload requires it.

To give a group more CPU or memory, update or redeploy it as supported for the change. Plan for a restart and possible disruption. Some properties, including the restart policy, require the group to be deleted and recreated.

Restart policies

Policy	Behavior	Typical use
Always	Restarts containers whenever they stop. This is the default.	A long-running web service.
Never	Runs containers without restarting them after exit.	A one-time task.
OnFailure	Restarts containers that exit with an error.	A batch job that should retry after failure.

A restart policy applies to the container group and its containers.

Azure Container Apps

Container Apps runs containerized applications with managed ingress, revisions, and horizontal scaling. You configure the resources for a replica and the rules that determine how many replicas should run.

Size a replica

Choose the CPU and memory for the application’s containers within the selected workload profile. Supported CPU and memory combinations depend on that profile. When an app has multiple containers in a replica, account for the combined resource requirements of the containers.

Changing a container app’s CPU or memory configuration is a revision-scope change. Container Apps creates a new revision with the updated configuration.

Scale replicas

Container Apps can add or remove replicas according to configured rules and minimum and maximum replica counts.

Scaling signal	Example
HTTP requests	Add web-app replicas as concurrent requests increase.
TCP connections	Add replicas as connection demand increases.
Queue or event demand	Add worker replicas as messages accumulate.
CPU or memory	Add replicas when resource utilization reaches a configured threshold.

Scale out adds replicas; scale in removes them. Container Apps uses KEDA-based scaling capabilities to respond to supported triggers.

For example, you could configure a minimum of 1 replica and a maximum of 5. If request demand rises, Container Apps can add replicas up to that limit; as demand falls, it can reduce the count.

Some supported configurations can scale to zero when idle. CPU- or memory-based scaling rules alone cannot scale an app to zero. If ingress is disabled, configure an appropriate event-driven rule or a minimum of at least one replica so the workload can start when needed.

Exam tip: ACI generally sizes a container group. Container Apps sizes a replica and can automatically change the number of replicas.

Persistent and temporary storage

The container filesystem is generally ephemeral: data written only inside it should not be relied on after a container or replica is replaced. Both services can integrate with Azure Files for persistent data when configured.

Storage option	Purpose	Persistent application data?
Azure Files	External file share that can be mounted by a supported container configuration.	Yes, subject to the storage account’s configuration.
Empty directory	Temporary storage shared by containers within the relevant group or replica.	No; removed with its group or replica.
Secret volume	Makes configured secrets available to containers.	No; it is for secret delivery, not durable application data.
Git repository volume in ACI	Makes repository content available in supported configurations.	No; it is not a persistent application data store.

For ACI, Azure Files volume mounting is supported for Linux container groups. In Container Apps, multiple replicas can mount the same configured Azure file share; the application must handle concurrent access appropriately.

Monitoring and troubleshooting

Monitor CPU, memory, application logs, and replica behavior to determine whether a workload needs a larger allocation or additional replicas.

Useful ACI commands include:

# Show logs from a container
az container logs \
  --resource-group myResourceGroup \
  --name myContainerGroup

# Attach to a container group to observe startup output
az container attach \
  --resource-group myResourceGroup \
  --name myContainerGroup

# Run an interactive command in a container
az container exec \
  --resource-group myResourceGroup \
  --name myContainerGroup \
  --exec-command "/bin/sh"

For a group with more than one container, specify the container name where required. az monitor metrics list can query available Azure Monitor metrics when supplied with the resource ID and metric names.

For Container Apps, review Metrics, Logs, and Revisions and replicas in the portal. If an app is not scaling as expected, check the scale rule, replica limits, event-source connectivity, and application readiness.

Azure containers and AKS monitoring and reliability

The diagram brings together four related capabilities: monitoring an AKS workload, placing workloads on suitable nodes, protecting application data, and recovering across regions. It also shows a separate Azure Container Apps example that scales replicas in response to Service Bus messages.

Monitoring container and application health

Azure Monitor provides several complementary tools. They answer different questions about a containerized application.

Tool	Primary purpose	Example questions
Container Insights	Collect and analyze container logs and Kubernetes inventory and events.	Are pods restarting? What errors appear in container logs?
Azure Monitor managed service for Prometheus	Collect Kubernetes and application metrics for analysis and alerting.	Is CPU or memory consumption rising? How many requests are failing?
Application Insights	Monitor instrumented application behavior, including requests, dependencies, and distributed traces.	Which service or dependency is causing a slow transaction?
Grafana and Azure Monitor dashboards	Visualize metrics and trends.	How is application performance changing over time?

For example, Container Insights might show that a pod is healthy while Application Insights reveals that requests are slow because the application is waiting on a database dependency.

Application Insights requires application telemetry to be configured. Deploying Container Insights alone does not automatically produce complete distributed traces for every application. Applications can use supported instrumentation, including OpenTelemetry, to send traces and metrics.

Exam tip: Use Container Insights for container and cluster visibility. Use Application Insights for application performance and distributed tracing.

Multiple node pools and workload-aware scheduling

An AKS node pool is a group of nodes with a common configuration. Multiple pools let a cluster support workloads with different compute requirements.

Examples include:

A system node pool for critical Kubernetes system workloads.
A general-purpose user pool for web applications.
A memory-optimized pool for applications that need more memory.
A GPU-enabled pool for supported machine-learning workloads.

Kubernetes can use resource requests, node labels, node selectors, affinity, taints, and tolerations to influence placement. For example, an administrator can label and taint a GPU pool, then configure an ML workload to request GPU resources and tolerate that taint.

A toleration permits a pod to run on a tainted node; it does not, by itself, require the pod to use that node. A node selector or affinity rule can express the placement requirement.

The diagram shows ingress controllers and monitoring agents in the system pool as an example. Their actual placement depends on how they and the node pools are configured.

Multi-region AKS and disaster recovery

A multi-region design deploys separate AKS clusters in different Azure regions. A traffic-management service can direct users to a healthy application endpoint.

Two common patterns are:

Active-active: Both regions serve traffic during normal operation.
Active-passive: A primary region serves traffic, while a secondary region is prepared to take over.

For HTTP applications, Azure Front Door can provide global routing and health-based failover. Azure Traffic Manager uses DNS-based routing and can direct clients to a different endpoint when a configured endpoint becomes unhealthy. With DNS-based failover, cached DNS responses can affect how quickly individual clients switch regions.

A second cluster alone does not replicate application data or guarantee recovery. A complete design also needs:

Application deployment and configuration in both regions.
Suitable image availability, networking, DNS, identity, and secrets.
Data replication or a tested restore method for the application’s databases and persistent volumes.
Capacity in the recovery region.
Health probes, routing rules, and tested failover procedures.

Define a recovery point objective (RPO) for acceptable data loss and a recovery time objective (RTO) for acceptable downtime. Replication lag and failover behavior affect whether the design meets those objectives.

Kubernetes backup and application recovery

A Kubernetes backup strategy should address the components needed to rebuild and recover the workload:

Component	Recovery consideration
Kubernetes configuration	Protect or recreate selected resources, such as deployments and services.
Persistent application data	Back up supported persistent volumes or use the data service’s own backup capabilities.
Container images	Preserve images in a registry and ensure they are available to the recovery environment.
Secrets and external dependencies	Include them where appropriate, or recreate access to external secret stores and services.

Azure Backup for AKS can protect supported Kubernetes resources and persistent volumes using the AKS Backup extension. Supported storage types and restore capabilities depend on the backup configuration and current support matrix.

A volume snapshot may provide a useful recovery point, but it is not necessarily application-consistent, especially when an application writes across several volumes. Coordinate application-level backup where required and test the restore.

The container registry shown in the diagram is a separate image source. An AKS configuration and volume backup should not be assumed to contain the container images themselves.

AKS and Container security concepts

The diagram shows two complementary security layers: protecting container images before deployment and protecting communications between running services.

Service mesh: authenticate, encrypt, and authorize traffic

The Istio-based service mesh add-on for AKS can secure communication between participating microservices:

Mutual TLS (mTLS) authenticates both ends of a connection and encrypts traffic between mesh proxies.
Workload identities identify the services communicating.
Authorization policies determine which identities may access a service.

For example, a policy could allow the checkout service to call the payment service while denying calls from other workloads. Configure these controls explicitly; enabling a mesh alone does not establish every required access restriction.

Image scanning and signing serve different purposes

Control	Purpose	Important distinction
Vulnerability scanning	Finds known vulnerabilities in image components.	Findings require remediation; scanning does not automatically block deployment.
Image signing and verification	Checks image integrity and whether its signer is trusted.	A valid signature does not mean an image is vulnerability-free.
Deployment policy	Enforces configured requirements before admitting a workload.	Enforcement must be configured separately.
Registry access controls	Restrict who can push, pull, or manage images.	Use least-privilege identities and appropriate network access.

Microsoft Defender for Cloud can assess images stored in ACR. For signing, Microsoft provides Notary Project/Notation guidance; signatures can be verified before deployment, including through configured AKS admission controls.

Automated image maintenance

ACR Tasks can rebuild an application image when a tracked base image changes. A secure maintenance workflow is:

Update the base image or application dependencies.
Rebuild and test the application image.
Assess vulnerabilities and apply approval criteria.
Sign the approved image.
Deploy the new image and verify application health.

Rebuilding does not patch containers already running. They must be replaced or redeployed using the updated image. A rebuild also cannot fix a vulnerability unless the relevant dependency receives a suitable update.

Retention and image lifecycle

Use retention or scheduled cleanup to remove obsolete artifacts while preserving versions required for rollback and recovery. ACR’s native retention policy targets untagged manifests; broader cleanup can use scheduled ACR Tasks with acr purge. Review cleanup rules carefully when deployments reference image digests.

Current terminology: ACR’s older Docker Content Trust capability retires on March 31, 2028. For new designs, follow Microsoft’s Notary Project/Notation signing and verification guidance.

AZ-104 reminder: Scanning finds vulnerabilities; signing establishes integrity and signer trust; policy enforces deployment requirements; mTLS protects service communication.

Azure Kubernetes special features

The diagram summarizes seven AKS capabilities that support flexible workloads, cost control, and simpler operations.

Feature	Purpose and key consideration
Multiple node pools	Use different VM sizes or configurations for different workloads. Keep critical system components on a system pool and place applications on suitable user pools.
Stop/start a cluster	Pause supported clusters when workloads are not needed, such as development environments. Applications become unavailable while stopped; retained storage and other resources can still incur charges.
ACI bursting through virtual nodes	Schedule eligible pods onto Azure Container Instances through a virtual node backed by virtual kubelet, providing capacity without adding ordinary AKS VM nodes.
Spot user node pools	Reduce compute costs for interruption-tolerant workloads. Spot nodes can be evicted, so applications should support retries, checkpointing, or replacement.
Auto-healing	AKS can repair unhealthy nodes. Separately, Kubernetes restarts containers and controllers replace pods according to workload configuration and health checks.
Auto-upgrade	Configure Kubernetes and node OS upgrade channels, with planned maintenance schedules. Test application compatibility and design workloads to tolerate node replacement.
Managed identities	Let AKS components authenticate to Azure without stored application credentials. Grant only the required permissions. Pods can use Microsoft Entra Workload ID for application access to Azure services.

Virtual-node bursting has networking and workload restrictions; it is not a transparent destination for every pod. The documented classic integration supports eligible Linux workloads and requires Azure CNI networking.

Cluster stop/start also has configuration restriction, for example, clusters using node autoprovisioning cannot currently be stopped through this feature. Auto-repair and auto-upgrade help maintain infrastructure but do not replace application health checks, backups, or availability planning.

AZ-104 tip: Spot pools provide lower-cost interruptible VM capacity; virtual nodes provide ACI-backed burst capacity. They are different mechanisms.