This chapter covers Azure Dev Center and Dev Box, two services that enable developers to create on-demand, project-specific development workstations in the cloud. For the AZ-204 exam, this topic falls under Domain 1 (Compute) Objective 1.3, which focuses on 'Create and manage container images for solutions' — but Dev Box is a key part of the developer tooling ecosystem. Roughly 5-10% of exam questions may touch on Dev Center and Dev Box concepts, especially in scenarios involving developer productivity, environment consistency, and integration with Azure DevOps. You will learn the architecture, configuration steps, and best practices for deploying Dev Boxes at scale.
Jump to a section
Imagine a large company where every developer needs a custom-built workstation with specific tools, libraries, and configurations. Instead of each developer buying and maintaining their own physical machine, the company has a fleet of pre-configured, high-performance laptops in a secure cabinet. A developer requests a specific laptop configuration (e.g., 'Python 3.9 with Visual Studio and SQL Server'), and within minutes, a laptop with that exact setup is delivered to their desk. They work on it for a few weeks, then return it to the cabinet, where it's wiped and reset for the next developer. The company's IT team manages the master images, updates, and security patches centrally. This is exactly how Azure Dev Center and Dev Box work: Dev Center acts as the cabinet manager, defining projects and dev box definitions (the laptop configurations). Dev Box is the actual laptop delivered to the developer. The developer connects to their Dev Box via Remote Desktop, works on it, and when done, deletes it. The IT admin controls which images and sizes are available, sets network policies, and ensures compliance. The key benefit: no time wasted setting up local environments, and no risk of configuration drift across teams.
What is Azure Dev Center and Dev Box?
Azure Dev Center and Dev Box are part of Microsoft's developer productivity suite. Dev Center is a management service that provides a centralized way to create and manage projects, define dev box configurations (including images, compute sizes, and network settings), and enforce policies across an organization. Dev Box is the actual virtual machine (VM) that a developer uses as their workstation. Each Dev Box is a Windows-based VM (Windows 10/11 Enterprise) that can be pre-configured with development tools, SDKs, and project-specific software. Developers can request a Dev Box from a catalog of predefined configurations, and it is provisioned within minutes in the same Azure region as the developer.
How It Works Internally
Azure Dev Center leverages Azure Compute Gallery (formerly Shared Image Gallery) to store and version custom VM images. A Dev Box definition references an image from the gallery, along with a compute size (e.g., 8 vCPUs, 32 GB RAM) and optional storage configuration. When a developer requests a Dev Box, Azure Dev Center orchestrates the creation of a VM using the specified image and size, attaches a managed disk, and joins the VM to a virtual network (either the default Dev Center network or a custom one). The VM is then assigned to the developer via Azure Active Directory (now Microsoft Entra ID). The developer connects using Remote Desktop (RDP) or via the Azure portal. Dev Boxes can be ephemeral (automatically deleted after a set period) or persistent (kept until manually deleted).
Key Components and Defaults
Dev Center: The top-level resource that organizes projects and dev boxes. Billing is based on the underlying VM compute and storage.
Project: A logical grouping within a Dev Center. Each project can have its own set of dev box definitions, network settings, and access policies. For example, you might have a 'Frontend' project and a 'Backend' project.
Dev Box Definition: Specifies the image source (from Azure Compute Gallery or a built-in marketplace image), compute size (Standard_D8s_v3, etc.), and storage (default 256 GB SSD). Default sizes range from 2 vCPUs/8 GB RAM to 32 vCPUs/128 GB RAM.
Network Connection: Defines the virtual network and subnet where Dev Boxes are deployed. You can use an existing VNet or let Dev Center create one. By default, Dev Boxes get a private IP and can be accessed via RDP over the internet using a public IP (if not restricted).
Azure Compute Gallery: Stores custom images. Images are versioned and can be replicated across regions. Dev Center can use images from any gallery in the same subscription.
Dev Box Timeout: Configurable idle timeout (default 4 hours). If the developer disconnects and the session is idle for the timeout period, the Dev Box is automatically shut down to save costs. The VM is deallocated (not deleted), so data persists.
Storage: Each Dev Box uses a managed disk. The default OS disk size is 256 GB (Premium SSD). You can increase it up to 2 TB. Data disks are not supported by default.
Configuration and Verification Commands
To create a Dev Center, you can use Azure CLI:
az devcenter admin devcenter create --name "MyDevCenter" --resource-group "rg-devcenter" --location "eastus" --identity-type "SystemAssigned"To create a project:
az devcenter admin project create --name "FrontendProject" --resource-group "rg-devcenter" --dev-center-name "MyDevCenter" --location "eastus" --description "Frontend development project"To create a dev box definition (reference an image from a gallery):
az devcenter admin devbox-definition create --name "Win11-VS2022" --resource-group "rg-devcenter" --dev-center-name "MyDevCenter" --location "eastus" --image-reference id="/subscriptions/.../galleries/MyGallery/images/Win11-VS2022/versions/1.0.0" --sku name="general_a_8c32gb256ssd_v2" --os-storage-type "ssd_256gb"To list available dev boxes for a user:
az devcenter dev dev-box list --dev-center-name "MyDevCenter" --project-name "FrontendProject" --user-id "user@contoso.com"To start a dev box:
az devcenter dev dev-box start --name "MyDevBox" --dev-center-name "MyDevCenter" --project-name "FrontendProject" --user-id "user@contoso.com"Interaction with Related Technologies
Azure DevOps: Dev Boxes can be integrated with Azure DevOps pipelines. For example, a pipeline can automatically provision a Dev Box for a pull request reviewer, or a Dev Box can be pre-configured with the latest build artifacts.
Microsoft Dev Box vs. Azure Virtual Desktop (AVD): Dev Box is a more developer-focused service, while AVD is a full Windows desktop virtualization platform. Dev Box is optimized for individual developer workstations, with features like idle shutdown and automatic deletion. AVD is better for persistent multi-user scenarios.
Azure Compute Gallery: Essential for custom images. You can create an image from a reference VM that has all tools installed, then distribute it to multiple Dev Centers.
Microsoft Entra ID: Dev Boxes are joined to Entra ID (formerly Azure AD), enabling single sign-on and conditional access policies. Developers authenticate using their corporate credentials.
Azure Policy: You can enforce policies on Dev Centers, such as restricting allowed VM sizes or requiring specific network connections.
Performance and Scaling
Dev Boxes are backed by Azure VMs, so performance scales with the chosen SKU. For large teams, you can have hundreds of Dev Boxes in a single Dev Center. However, there are subscription-level VM quotas to consider. Dev Center itself is a regional service, so you should create Dev Centers in regions close to your developers to minimize latency. Custom images can be replicated across regions using Azure Compute Gallery to speed up provisioning.
Create a Dev Center
First, you must create a Dev Center resource in your Azure subscription. This is the management hub. Use the Azure portal, CLI, or ARM template. You must assign a system-assigned managed identity (or user-assigned) so that Dev Center can create VMs and access Azure Compute Gallery. This step is done once per organization or team. The Dev Center name must be globally unique within the Azure AD tenant.
Configure a Network Connection
Create a network connection that defines the VNet and subnet where Dev Boxes will be deployed. You can use an existing VNet or create a new one. The VNet must be in the same region as the Dev Center. The subnet must have enough IP addresses for the expected number of Dev Boxes. You can also configure a delegated subnet for Dev Center. The network connection is then associated with a project.
Create a Project
A project groups Dev Boxes for a specific team or purpose. For example, 'Frontend Team' project. You assign the network connection to the project. Each project can have its own dev box definitions and access permissions. Projects are under a Dev Center. You can have multiple projects per Dev Center. Developers are granted access to projects via RBAC roles like 'DevCenter Dev Box User'.
Define Dev Box Definitions
Create dev box definitions that specify the image, compute size, and storage. The image can come from Azure Compute Gallery (custom) or a built-in marketplace image (e.g., 'Visual Studio 2022 Latest'). The compute size is an Azure VM SKU (e.g., 'general_a_8c32gb256ssd_v2' which corresponds to 8 vCPUs, 32 GB RAM, 256 GB SSD). You can also specify a storage SKU (Premium SSD LRS by default). Multiple definitions can be created for different workloads.
Grant User Access and Create Dev Box
Assign the 'DevCenter Dev Box User' role to developers on the project scope (or Dev Center scope). Developers then use the Azure portal, CLI, or REST API to create a Dev Box. They select a project, a dev box definition, and optionally a name. The Dev Box is provisioned as a VM in the project's VNet. Provisioning typically takes 5-15 minutes. Once ready, the developer connects via RDP.
Manage and Delete Dev Box
Developers can start, stop, or delete their Dev Boxes from the portal. Admins can set auto-delete policies (e.g., delete after 30 days of inactivity). Dev Boxes can be stopped to save costs; the VM is deallocated but the disk persists. When a Dev Box is deleted, the VM and its managed disk are permanently removed. Developers can create a new Dev Box from the same definition later.
In a typical enterprise, a large software company with 500 developers working on multiple products can use Azure Dev Center to standardize development environments. For example, the 'Product A' team has a project with a dev box definition that includes Visual Studio 2022, .NET 6 SDK, SQL Server Developer Edition, and specific NuGet packages. The 'Product B' team uses a different definition with Node.js, Python, and Docker. Each team's Dev Boxes are deployed in their own VNet to isolate network traffic. The IT department manages a single Azure Compute Gallery with versioned images; when a new tool version is needed, they update the image and publish a new version. Developers can choose to recreate their Dev Box from the latest image. Cost management is achieved by setting idle timeouts (e.g., 2 hours) and auto-deleting Dev Boxes that are not used for 7 days. A common problem is when developers forget to stop their Dev Boxes, resulting in unnecessary costs. To mitigate this, admins enforce a policy that automatically stops Dev Boxes at 7 PM local time. Another issue is image bloat: if custom images are too large, provisioning times increase. Best practice is to keep images under 127 GB (OS disk size limit) and use Azure Compute Gallery replication for fast provisioning across regions. In a misconfigured scenario, if the network connection uses a VNet that overlaps with the developer's on-premises network, RDP connectivity may fail due to IP conflicts. To avoid this, use a dedicated VNet with a unique address space (e.g., 10.200.0.0/16).
On the AZ-204 exam, Objective 1.3 includes 'Create and manage container images for solutions' but Dev Center and Dev Box are part of the broader compute ecosystem. Questions typically test your understanding of the architecture and configuration steps. The most common wrong answers involve confusing Dev Box with Azure Virtual Desktop (AVD) or assuming Dev Box is a container service. Candidates often choose 'Azure Virtual Desktop' as the solution for developer workstations, but the correct answer is Dev Box because it is purpose-built for development. Another trap: questions about image management — candidates may think you use Azure Container Registry for Dev Box images, but you actually use Azure Compute Gallery. Also, the exam may ask about the default idle timeout (4 hours) or the default OS disk size (256 GB). Edge cases: if a developer needs a Dev Box with a data disk, the exam tests that Dev Box does not support attaching additional data disks by default. Another exception: Dev Boxes can only be Windows-based (Windows 10/11 Enterprise) — Linux is not supported. To eliminate wrong answers, remember that Dev Box is a managed service that abstracts VM creation; the underlying compute is a standard Azure VM. Look for keywords like 'developer workstation', 'on-demand', 'remote development', and 'team project' to identify Dev Box scenarios. Also, note that Dev Center is the management plane, not the VM itself.
Azure Dev Center is a management service that organizes projects and dev box definitions.
Dev Box is a Windows 10/11 Enterprise VM provisioned on-demand for developers.
Custom images must be stored in Azure Compute Gallery, not Azure Container Registry.
Default idle timeout is 4 hours; after that, the Dev Box is automatically shut down.
Default OS disk size is 256 GB (Premium SSD), up to 2 TB.
Dev Box does not support Linux or additional data disks.
Developers need the 'DevCenter Dev Box User' role to create and manage their Dev Boxes.
These come up on the exam all the time. Here's how to tell them apart.
Azure Dev Box
Designed for individual developer workstations.
Supports idle timeout and auto-delete policies.
Uses Azure Compute Gallery for custom images.
Integrated with Dev Center for project management.
Only Windows 10/11 Enterprise.
Azure Virtual Desktop (AVD)
Designed for multi-user desktop virtualization.
Persistent or pooled session hosts.
Uses custom images stored in a gallery or marketplace.
Managed via Azure Virtual Desktop workspace and host pools.
Supports Windows 10/11, Windows Server, and Windows 7 (extended).
Azure Dev Box
Managed service with built-in developer experience.
Automatic provisioning via Dev Center.
Pre-configured SDKs and tools.
Idle shutdown and auto-delete policies.
Integrated with Azure DevOps and Entra ID.
Azure VM (Manual)
Full control over VM configuration.
Manual creation and management.
No built-in developer tooling.
No automatic idle shutdown (unless scripted).
Requires manual integration with DevOps.
Mistake
Azure Dev Box is the same as Azure Virtual Desktop (AVD).
Correct
Dev Box is specifically for individual developer workstations, with features like idle shutdown and project-based management. AVD is a general-purpose desktop virtualization platform for multiple users.
Mistake
Dev Box images must be stored in Azure Container Registry.
Correct
Dev Box uses Azure Compute Gallery (Shared Image Gallery) for storing and versioning VM images, not ACR.
Mistake
Dev Box supports Linux-based developer workstations.
Correct
Dev Box only supports Windows 10/11 Enterprise. Linux is not available.
Mistake
You can attach multiple data disks to a Dev Box.
Correct
Dev Box does not support attaching additional data disks. Only the OS disk (default 256 GB, up to 2 TB) is used.
Mistake
Dev Boxes are always persistent and never automatically deleted.
Correct
Dev Boxes can be configured with auto-delete policies (e.g., after 30 days of inactivity) to manage costs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, create a reference VM in Azure with all the required development tools installed. Then, generalize the VM using Sysprep (for Windows) and capture it as an image in an Azure Compute Gallery. You can then create a new image version and replicate it to other regions. Finally, create a Dev Box Definition in Dev Center that references that image version.
No, Azure Dev Box currently only supports Windows 10/11 Enterprise. For Linux development workstations, you would need to use Azure Virtual Desktop or a direct Azure VM.
A Dev Box is a managed service that automates provisioning, image management, and lifecycle policies. A regular Azure VM gives you full control but requires manual setup and ongoing management. Dev Box also integrates with Dev Center for project-based access control and cost management.
You can set idle timeouts (default 4 hours) to automatically shut down Dev Boxes when not in use. You can also configure auto-delete policies to remove Dev Boxes after a period of inactivity. Additionally, choose appropriate VM sizes and use Azure Reservations for discounted rates.
The developer must be assigned the 'DevCenter Dev Box User' role at the project or Dev Center scope. This role allows them to create, start, stop, and delete their own Dev Boxes. They also need Reader access to the image gallery if using custom images.
Yes, you can use the Azure CLI or REST API to create Dev Boxes as part of a pipeline. For example, you can automatically provision a Dev Box for a pull request reviewer or pre-configure a Dev Box with the latest build artifacts.
When a Dev Box is deleted, the underlying VM and its managed disk are permanently removed. Any data on the Dev Box is lost unless it has been backed up or stored elsewhere. Developers can create a new Dev Box from the same definition later.
You've just covered Azure Dev Center and Dev Box — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?