This chapter covers Azure Compute Gallery (formerly Shared Image Gallery) and image versioning, a core topic in the Compute domain for AZ-104 exam. You'll learn how to create, manage, and replicate custom VM images at scale. Expect 5-10% of exam questions to touch on image management, including gallery creation, image definitions, versioning, replication, and sharing. Mastering this topic ensures you can efficiently deploy standardized VMs across regions while minimizing storage costs and deployment time.
Jump to a section
Think of Azure Compute Gallery as a centralized library for golden VM images, similar to how Git manages source code versions. Each image definition is like a repository branch — it defines a family of images (e.g., Windows Server 2022 Datacenter) with specific attributes (OS state, publisher, offer, SKU). Image versions are like tagged commits — immutable snapshots with a semantic version number (major.minor.patch). When you create a VM from a gallery image, it's like cloning a specific commit from a branch. The gallery itself is the remote repository (e.g., GitHub), while local replicas in regions are like local clones. Replication is akin to pushing tags to multiple remotes — each region gets its own copy of the image version. Shared Image Gallery (the old name) is like a public repository; Azure Compute Gallery (the new name) is like a private enterprise repository with RBAC. Just as you can have multiple branches from a single repo, you can have multiple image definitions (e.g., Windows Server 2022, Ubuntu 22.04) within one gallery. Versioning follows semver: 1.0.0, 1.1.0, etc. You can roll back to a previous version by specifying the version ID when creating a VM, similar to checkout of an older commit. Replication across regions ensures low-latency deployment, like having mirrors of a repository worldwide.
What is Azure Compute Gallery?
Azure Compute Gallery (formerly Shared Image Gallery) is a service for managing and sharing custom VM images at scale. It allows you to store multiple image definitions and versions in a hierarchical structure: Gallery → Image Definition → Image Version. The gallery is a top-level resource that acts as a logical container. Image definitions hold metadata about the image family (e.g., Windows Server 2022, Ubuntu 22.04) including OS type, publisher, offer, SKU, and whether the image is generalized or specialized. Image versions are the actual VHD snapshots, each with a version number (e.g., 1.0.0, 1.1.0) and stored as managed images in the gallery.
Why Use Azure Compute Gallery?
Without a gallery, you manage custom images as individual managed images in each region. This leads to duplication, manual tracking, and inconsistent versions across regions. The gallery solves this by providing a central repository with automatic replication across regions. Key benefits: versioning (semantic versioning), replication (low-latency deployment), sharing (RBAC across subscriptions/tenants), and cost savings (only pay for underlying snapshots, not for the gallery itself).
How It Works Internally
When you create an image version, Azure captures a snapshot of the source VM's OS disk (and optionally data disks). This snapshot is stored as a managed image in the gallery's region. If you enable replication, Azure copies the managed image to target regions asynchronously. The replication process uses Azure's backbone network and can take minutes to hours depending on size. Each replicated copy is a full independent managed image in that region. When you create a VM from a gallery image, Azure uses the local replica if available; otherwise, it copies from the source region (which incurs cross-region data transfer costs).
Key Components and Defaults
Gallery: Must be created with a unique name within a resource group. No default limits but best practice: one gallery per application family.
Image Definition: Defines OS type (Windows/Linux), state (generalized/specialized), publisher, offer, SKU. For Windows, you must specify if it's gen1 or gen2. For Linux, hyper-V generation. Default: gen1.
Image Version: Uses semantic versioning (major.minor.patch). You can specify end-of-life date (default: none). Replication count per region: 1 (default). You can replicate to up to 50 regions per version.
Replication: Default replication mode is 'Full' (copies entire image). 'Shallow' replication (copy on first use) is not supported for Compute Gallery. You can set zone redundancy (ZRS) per region.
Configuration Commands
Create a gallery:
az sig create --resource-group MyRG --gallery-name MyGallery --location eastusCreate an image definition:
az sig image-definition create --resource-group MyRG --gallery-name MyGallery --gallery-image-definition MyImageDef --publisher MyPublisher --offer MyOffer --sku 2022-datacenter --os-type Windows --os-state Generalized --hyper-v-generation V2Create an image version from a source VM (generalized):
az sig image-version create --resource-group MyRG --gallery-name MyGallery --gallery-image-definition MyImageDef --gallery-image-version 1.0.0 --target-regions eastus=1=standard_lrs westus=1=standard_lrs --managed-image /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.Compute/images/MyManagedImageList versions:
az sig image-version list --resource-group MyRG --gallery-name MyGallery --gallery-image-definition MyImageDef -o tableCreate VM from latest version:
az vm create --resource-group MyRG --name MyVM --image /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.Compute/galleries/MyGallery/images/MyImageDef/versions/latest --admin-username azureuser --generate-ssh-keysHow It Interacts with Related Technologies
Azure Policy: Can enforce use of gallery images via built-in policies (e.g., "Allowed images").
Azure Blueprints: Can include gallery image definitions as artifacts.
Azure DevOps: Can automate image creation and versioning using pipeline tasks.
VMSS: Supports using gallery images for consistent scale sets across regions.
Azure Backup: Image versions are snapshots; backup policies apply to source VMs, not gallery images.
Performance and Scale Considerations
Replication speed: Approximately 20-30 minutes per 100 GB across regions within same continent; cross-continent may take hours.
Storage costs: You pay for managed snapshots in each region. Use ZRS for high availability.
Quotas: Default 10 galleries per subscription, 100 image definitions per gallery, 1000 image versions per gallery (soft limits, can be increased via support ticket).
Specialized vs Generalized Images
Generalized: Created from a VM that has been sysprepped (Windows) or waagent -deprovision+user (Linux). Used for creating multiple VMs with unique SIDs/SSH keys.
Specialized: Created from a running VM without generalization. Used for migration or disaster recovery scenarios. You can create a VM from a specialized image but cannot scale out VMSS.
Exam Pitfalls
The exam often tests the difference between generalized and specialized images. Remember: specialized images cannot be used for VMSS scale-out; they are for single VM creation only.
Replication is asynchronous; you cannot force immediate replication. The exam may ask about replication status (use az sig image-version show).
Image definitions are immutable after creation except for end-of-life date and tags. You cannot change OS type or state.
The gallery resource itself is free; you pay only for the underlying managed disks/snapshots and data transfer during replication.
Cross-tenant sharing: Use Azure Lighthouse or RBAC. The exam may test that you need to grant read permissions on the gallery to users in other tenants.
Prepare source VM for image capture
First, ensure the source VM is properly prepared. For Windows, run sysprep with generalize option (sysprep /generalize /shutdown). For Linux, run waagent -deprovision+user. This removes machine-specific identifiers (SID, hostname, SSH host keys) so the image can be reused. After sysprep, the VM is stopped and deallocated. Do not restart the VM; capture the image from the stopped state. If you need to capture a specialized image, skip sysprep and ensure the VM is running (or stopped) — but the VM must be deallocated for managed image capture. Note: The VM's OS disk must be a managed disk; unmanaged disks are not supported for gallery images.
Create managed image from source VM
Use Azure CLI: `az image create --resource-group MyRG --name MyManagedImage --source MyVM`. This creates a managed image resource in the same region as the source VM. The managed image contains the OS disk snapshot and optionally data disks. You can also capture from an existing managed disk or snapshot. The managed image is a prerequisite for creating the first image version. You cannot directly use a running VM as source for gallery image version; you must first create a managed image (or snapshot). For Linux, ensure you have deprovisioned; otherwise, the image may contain stale SSH keys.
Create Azure Compute Gallery
Create a gallery resource using: `az sig create --resource-group MyRG --gallery-name MyGallery --location eastus`. The gallery name must be unique within your subscription (not globally). You can create multiple galleries per subscription. The gallery is a regional resource; its location determines where the gallery metadata is stored. However, image versions can be replicated to any region. Best practice: create the gallery in the region where you will primarily manage images. The gallery itself incurs no cost.
Define image definition inside gallery
Create an image definition: `az sig image-definition create --resource-group MyRG --gallery-name MyGallery --gallery-image-definition Win2022 --publisher MyCompany --offer WindowsServer --sku 2022-Datacenter --os-type Windows --os-state Generalized --hyper-v-generation V2`. The publisher, offer, and SKU are arbitrary but should follow a naming convention. The OS state must match the source image (generalized or specialized). Hyper-V generation must be V1 or V2; most modern images use V2. You cannot change these properties after creation. Each definition can have multiple versions.
Create image version from managed image
Use: `az sig image-version create --resource-group MyRG --gallery-name MyGallery --gallery-image-definition Win2022 --gallery-image-version 1.0.0 --target-regions eastus=1=standard_lrs westus=1=standard_lrs --managed-image /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.Compute/images/MyManagedImage`. The version number must follow major.minor.patch format. Target regions specify where to replicate; you can include up to 50 regions. The number after region (e.g., 1) is replica count per region (default 1). Storage type: standard_lrs, standard_zrs, premium_lrs. The replication process is asynchronous; use `az sig image-version show` to check provisioningState. Once all replicas are 'Succeeded', the version is ready.
Deploy VM from gallery image version
Create a VM using: `az vm create --resource-group MyRG --name MyVM --image /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.Compute/galleries/MyGallery/images/Win2022/versions/1.0.0 --admin-username azureuser --generate-ssh-keys`. You can also use `versions/latest` to always get the newest version. If the VM is deployed in a region where a replica exists, Azure uses the local copy; otherwise, it copies from the source region (incurring egress costs). For cross-region deployment, ensure you replicate to the target region first. Note: You cannot use a specialized image with VMSS — only single VMs.
Enterprise Scenario 1: Global Application Standardization
A multinational company deploys thousands of VMs across 10 regions for a line-of-business application. They need consistent OS configurations with pre-installed security agents and custom registry settings. Using Azure Compute Gallery, they create a single gallery with one image definition per OS version (e.g., Windows Server 2022 with App Stack). Each quarter, they update the image by patching the source VM, sysprepping, and creating a new version (e.g., 2024-Q1). Replication is configured to all 10 regions with 2 replicas per region for high availability. The DevOps team uses Azure DevOps pipelines to automate image creation and replication. Common pitfall: forgetting to update the latest version tag — use versions/latest in ARM templates to automatically pick the newest. Performance: replication of a 128 GB image to 10 regions takes about 2 hours; plan maintenance windows accordingly.
Enterprise Scenario 2: Disaster Recovery with Specialized Images
A financial institution needs to migrate on-premises VMs to Azure for disaster recovery. They capture specialized images of critical servers (without sysprep) to preserve identities and configurations. They create a gallery with image definitions for each server role. After replicating to the DR region, they can quickly spin up VMs from the specialized images during failover. Key consideration: specialized images cannot be used for scale sets; each VM must be created individually. Also, specialized images are larger (no sysprep compression), increasing replication time and cost. They use Azure Site Recovery for automated replication but rely on Compute Gallery for manual failover testing.
Enterprise Scenario 3: Multi-Tenant SaaS with Image Sharing
A SaaS provider offers a platform that runs on custom Linux images with pre-installed agents. They use Azure Compute Gallery to share images with customers' subscriptions via RBAC. They create a gallery in their own subscription, grant Reader permissions to customer subscriptions, and allow customers to deploy VMs from those images. Challenges: customers may accidentally delete the gallery or versions. Solution: use Azure Policy to prevent deletion of gallery resources. Also, cross-tenant sharing requires the gallery to be in the same Azure AD tenant; for different tenants, use Azure Lighthouse or export the image as a VHD. Common mistake: granting Contributor instead of Reader — Contributor allows customers to create new versions, which may lead to inconsistent images.
What AZ-104 Tests on Azure Compute Gallery
AZ-104 objective 3.1 (Create and configure virtual machines) includes managing images and image galleries. Specific exam points:
Differentiate between managed images and Azure Compute Gallery images.
Understand image definitions vs image versions.
Know the difference between generalized and specialized images.
Replication: number of target regions, replica counts, storage types (LRS, ZRS).
Sharing: RBAC roles (Reader, Contributor, Owner) and cross-tenant sharing limitations.
CLI/PowerShell commands for gallery operations.
Common Wrong Answers and Why
"You can change the OS state of an image definition after creation." Wrong: Image definition properties (OS type, state, hyper-v generation) are immutable. Candidates confuse definitions with versions.
"Specialized images can be used for VMSS." Wrong: VMSS requires generalized images because each VM needs unique SID/SSH keys. Specialized images are for single VM migration only.
"Replication is synchronous and immediate." Wrong: Replication is asynchronous; you must check provisioning state. The exam may present a scenario where a VM deployment fails because replication is incomplete.
"You can create an image version directly from a running VM." Wrong: You must first create a managed image (or snapshot) from the VM, then use that as source for the version. The VM must be deallocated.
Specific Numbers and Terms
Maximum target regions per version: 50.
Default replica count per region: 1.
Storage types: Standard_LRS, Standard_ZRS, Premium_LRS.
Version format: major.minor.patch (e.g., 1.0.0).
Gallery limit: 10 per subscription (soft).
Image definitions per gallery: 100 (soft).
Image versions per gallery: 1000 (soft).
Edge Cases and Exceptions
Cross-tenant sharing: You cannot directly share a gallery with another Azure AD tenant. Use Azure Lighthouse or export the image as a VHD and upload to the other tenant.
Image version deletion: Deleting a version does not affect VMs created from it; those VMs continue to run. However, you cannot create new VMs from a deleted version.
End-of-life date: You can set an end-of-life date on a version; after that, the version is deprecated but still usable (Azure does not auto-delete).
Replication to unavailable regions: If a target region is temporarily down, replication will retry; you can also cancel replication.
How to Eliminate Wrong Answers
If the question mentions "scale set" and "specialized", the answer is always wrong. Specialized cannot scale.
If the question says "modify image definition publisher", it's impossible — definitions are immutable.
If the question implies immediate availability after replication command, look for asynchronous wording.
Use process of elimination: Gallery images support versioning, managed images do not. If versioning is needed, choose gallery.
Azure Compute Gallery (formerly Shared Image Gallery) provides centralized image management with versioning and replication.
Image definitions are immutable after creation; you cannot change OS type, state, or hyper-v generation.
Image versions use semantic versioning (major.minor.patch) and can be replicated to up to 50 regions.
Generalized images are created from sysprepped VMs and are required for VMSS; specialized images are for single VM migration.
Replication is asynchronous; use CLI to check provisioning state before deployment.
Default replica count per region is 1; you can specify up to 10 per region (soft limit).
You must create a managed image from a deallocated VM before creating an image version.
Cross-tenant sharing requires Azure Lighthouse or VHD export; direct RBAC only works within same tenant.
Deleting an image version does not affect existing VMs but prevents new VM creation from that version.
The gallery resource itself is free; costs are incurred for managed snapshots and data transfer during replication.
These come up on the exam all the time. Here's how to tell them apart.
Azure Compute Gallery
Supports versioning with semantic version numbers.
Can replicate across multiple regions automatically.
Centralized management with RBAC sharing across subscriptions.
Supports both generalized and specialized images.
Free service; pay only for underlying snapshots and replication data transfer.
Managed Images
No versioning; single image resource.
Limited to a single region; manual copy to other regions.
Cannot share across subscriptions without manual export/import.
Supports both generalized and specialized images.
Pay for managed disk storage; no additional replication costs.
Mistake
Azure Compute Gallery is the same as the old Shared Image Gallery with no changes.
Correct
Azure Compute Gallery is the new name for Shared Image Gallery. The service is identical; only the name changed. The exam may use either term.
Mistake
You can create an image version directly from a running VM without capturing a managed image first.
Correct
You must first create a managed image (or snapshot) from the VM (which requires the VM to be deallocated). Then use that managed image as the source for the image version.
Mistake
Replication is synchronous; once the command returns, the image is available in all target regions.
Correct
Replication is asynchronous. The command returns immediately, but the image may take minutes to hours to replicate. Use `az sig image-version show` to check provisioningState.
Mistake
Specialized images can be used with Virtual Machine Scale Sets.
Correct
Specialized images cannot be used with VMSS because each VM instance needs unique identifiers. VMSS requires generalized images. Specialized images are only for single VM creation.
Mistake
You can change the OS type or state of an image definition after creation.
Correct
Image definition properties (osType, osState, hyperVGeneration) are immutable. You must delete and recreate the definition if you need different properties.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
There is no functional difference. Azure Compute Gallery is the new name for Shared Image Gallery. The service and APIs are identical. The exam may use either name, but expect 'Azure Compute Gallery' as the current official term.
No. You must first deallocate the VM and capture a managed image (or snapshot). For generalized images, you must also sysprep (Windows) or waagent -deprovision (Linux) before deallocation. The VM cannot be running during managed image capture.
Replication time depends on image size and distance between regions. Typically 20-30 minutes per 100 GB within a continent, and several hours across continents. Replication is asynchronous; you can check status with `az sig image-version show`.
No. VMSS requires generalized images because each VM instance must have unique SID/SSH keys. Specialized images are only for creating single VMs, typically for migration or disaster recovery scenarios.
Use RBAC: assign the Reader role to the user or service principal on the gallery resource. The user must be in the same Azure AD tenant. For cross-tenant sharing, use Azure Lighthouse or export the image as a VHD and upload to the other tenant.
Existing VMs created from that version continue to run unaffected. However, you cannot create new VMs from that version. You can still create VMs from other versions of the same image definition.
No. Target regions are specified at creation time and cannot be modified. To add a new region, you must create a new image version with the desired target regions. Alternatively, you can delete the version and recreate it.
You've just covered Azure Compute Gallery and Image Versioning — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?