Study guide
10.2 Binary, Web App, Function & Scripted Deployments
Microsoft Certified: Azure DevOps Engineer Expert AZ-400
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Flow of Work, Traceability & Work Tracking
1.1 Flow of Work, GitHub Flow & Feedback Cycles 1.2 Work Tracking with Azure Boards & GitHub Projects 1.3 End-to-End DevOps Traceability & Quality Tracking
2 Chapter 2: DevOps Metrics, Dashboards & Team Collaboration
2.1 DORA Metrics, Flow Metrics & Dashboard Design 2.2 Lifecycle Metrics Across the Six DevOps Phases 2.3 Work Item Queries, WIQL Charts & Analytics 2.4 Project Documentation: Wikis, Mermaid Diagrams & Release Notes 2.5 Webhooks, Service Hooks & Microsoft Teams ChatOps
3 Chapter 3: Git Branching Strategies & Pull Request Workflows
3.1 Git Branching Models & Strategy Design 3.2 Pull Request Workflows & Merge Strategies 3.3 Branch Policies, Quality Gates & Compliance Restrictions
4 Chapter 4: Repository Management, Optimization & Git Data Operations
4.1 Git LFS Architecture & .gitattributes Tracking 4.2 LFS History Migration, git-fat & File Locking 4.3 Git Repository Scaling, Scalar & Monorepo Governance 4.4 Repository Permissions & Git Tag Governance 4.5 Git Data Recovery & Sensitive-Data Scrubbing
5 Chapter 5: Package Management & Dependency Versioning
5.1 Selecting Package Tools: Azure Artifacts vs. GitHub Packages 5.2 Feed Scoping, Upstream Sources & Pipeline Authentication 5.3 Package Views, Immutability & Quality Promotion 5.4 Dependency Versioning: SemVer, CalVer & Automated Versioning 5.5 Pipeline Artifact Versioning & Artifact Storage Strategy
6 Chapter 6: Pipeline Infrastructure, Agents & Integration
6.1 Selecting a CI/CD Solution: Azure Pipelines vs. GitHub Actions 6.2 GitHub-Azure Pipelines Integration & Hybrid Migration 6.3 Hosted vs. Self-Hosted Agents & Runners 6.4 VMSS Elastic Pools, Container Jobs & Agent Governance 6.5 Pipeline Triggers, Filters & Concurrency Management
7 Chapter 7: YAML Pipeline Architecture & Reusable Elements
7.1 YAML Pipeline Anatomy: Stages, Jobs, Steps & Workspaces 7.2 Job Execution Order: DAG Dependencies, Parallelism & Conditions 7.3 Reusable Elements: Templates, Parameters & Variables 7.4 Variable Groups, Secret Variables & Key Vault Linking 7.5 YAML Environments, Checks & Deployment Approvals
8 Chapter 8: Testing Strategy, Quality Gates & Code Coverage
8.1 Test Strategy Design: Local, Unit & Integration Testing 8.2 Load, Stress & Performance Testing in Pipelines 8.3 Test Execution Tasks, Agents & Results Integration 8.4 Code Coverage Analysis & SonarQube Integration 8.5 Quality Gates, Release Gates & Governance Checks
9 Chapter 9: Modern Deployment Strategies & Zero-Downtime Delivery
9.1 Progressive Delivery: Blue-Green, Canary & Ring Deployments 9.2 Minimizing Downtime: Deployment Slots & Rolling Updates 9.3 Feature Flags with Azure App Configuration & Feature Manager 9.4 Designing the High-Priority Hotfix Path 9.5 Ordered Dependency Deployments, Resiliency & Rollback
10 Chapter 10: Artifact Deployment & Database DevOps
10.1 Containerized Application Delivery: ACR, AKS & Container Apps 10.2 Binary, Web App, Function & Scripted Deployments 10.3 Database DevOps: State-Based & Migration-Based Strategies
11 Chapter 11: Infrastructure as Code (IaC) & Azure Deployment Environments
11.1 Infrastructure as Code Strategy: Bicep, ARM & Terraform 11.2 Desired State Configuration & Azure Machine Configuration 11.3 Azure Deployment Environments (ADE) & Developer Self-Service
12 Chapter 12: Pipeline Maintenance, Health & Modernization
12.1 Pipeline Health, Flaky Tests & Reliability Engineering 12.2 Pipeline Optimization: Caching, Slicing & Concurrency 12.3 Artifact & Build Retention Governance 12.4 Modernizing CI/CD: Classic to YAML Migration
13 Chapter 13: Authentication, Authorization & Identity Governance
13.1 Microsoft Entra Service Principals & Managed Identities 13.2 Service Connections, Workload Identity & Personal Access Tokens 13.3 Azure DevOps Projects, Teams & Permission Evaluation 13.4 Access Levels, GitHub Roles & Outside Collaborators
14 Chapter 14: Secrets Management, Sensitive Data & DevSecOps Scanning
14.1 Azure Key Vault, Secret Variables & Secretless CI/CD 14.2 Security Scanning Strategy, GHAS & Secret Scanning 14.3 CodeQL SAST in Pipelines and Containers 14.4 Software Supply Chain, Container Scanning & Cloud Defender
15 Chapter 15: Telemetry Collection, Azure Monitor & Alerting
15.1 Azure Monitor Architecture, AMA & Data Collection Rules 15.2 Application Insights & Specialized Azure Monitor Insights 15.3 Alerting Rules, Action Groups & GitHub Repository Insights
16 Chapter 16: Telemetry Analysis, Distributed Tracing & SRE Practices
16.1 Distributed Tracing, Application Map & Exception Triage 16.2 KQL Log Analytics, SRE Observability & Error Budgets
10.2 Binary, Web App, Function & Scripted Deployments
Key Takeaways Explain This Topic AI
Deploying web applications and Azure Functions using 'WEBSITE_RUN_FROM_PACKAGE=1' mounts an immutable zip archive directly as the read-only wwwroot directory, completely eliminating file locks and speeding up cold starts.
YAML pipelines manage IaaS virtual machine deployments using Environment VM resources and rolling batch strategies, superseding legacy Classic Release Pipeline Deployment Groups.
The Azure Pipelines agent installed on target VMs registers to Environment pools, leveraging custom tags (e.g., 'role: web') to direct rolling script execution across defined server batches.
Scripted post-deployment automation using AzureCLI@2 and AzurePowerShell@5 must enforce cross-platform runtime execution ('pwsh: true') and strict failure trapping ('failOnStandardError: true').
Deployment scripts must be strictly designed for idempotency, ensuring repeated pipeline runs achieve the identical desired end state without creating duplicate resources or corrupting configurations.
Last updated: September 2026
10.2 Binary, Web App, Function & Scripted Deployments
While containerization dominates cloud-native architectures, enterprise delivery pipelines frequently manage compiled binary artifacts, Platform-as-a-Service (PaaS) web workloads, serverless functions, and traditional Infrastructure-as-a-Service (IaaS) virtual machines. Achieving zero downtime across these diverse hosting models requires specialized deployment mechanics: eliminating runtime file locks on compiled assemblies, coordinating rolling script updates across virtual machine fleets, and constructing idempotent automation scripts.
For the AZ-400 exam, candidates must master the internal mechanics of Zip Deploy and Run From Package , transition legacy Deployment Groups into modern YAML Environment VM resources , and author resilient, cross-platform deployment automation scripts using Azure CLI and PowerShell Core .
1. Deploying Web Apps & Azure Functions: Zip Deploy vs. Run From Package
Deploying application code to Azure App Service and Azure Functions has evolved through several technical paradigms. Early methods—such as FTP, WebDeploy (MSDeploy), and continuous Kudu git pushes—relied on copying individual files into the web root directory ( /home/site/wwwroot on Linux or D:\home\site\wwwroot on Windows). In enterprise production environments, this file-by-file copy introduces severe failure vectors:
File Locking ( DLL in use ) : If an active worker process has compiled binaries or native assemblies open in memory, overwriting them during deployment generates an ERROR_FILE_IN_USE or ERROR_ACCESS_DENIED exception, causing corrupted deployments.
Inconsistent Intermediate State : During a prolonged file copy, client requests hitting the server execute a hybrid mix of old and new assemblies, resulting in runtime crashes.
Deployment Leftovers : Deleting obsolete files requires manual synchronization. Obsolete assemblies left behind can introduce security vulnerabilities or unintended dependency resolution.
The Solution: Run From Package ( WEBSITE_RUN_FROM_PACKAGE=1 )
To resolve these challenges, Microsoft introduced Run From Package , enabled by setting the application setting WEBSITE_RUN_FROM_PACKAGE = 1 (or setting it to a secure Azure Blob Storage shared access signature URL). ┌────────────────────────────────────────────────────────────────────────┐
- │ Azure App Service / Function App │
- │ │
- │ [Application Setting: WEBSITE_RUN_FROM_PACKAGE = 1] │
- │ │
- │ ┌──────────────────────────────────────────────────────────────────┐ │
- │ │ Storage / SitePackages: │ │
- │ │ 20260905-142010.zip (Immutable Package Archive) │ │
- │ └─────────────────────────────────┬────────────────────────────────┘ │
- │ │ │
- │ (Mounted as Virtual Read-Only FS) │
- │ ▼ │
- │ ┌──────────────────────────────────────────────────────────────────┐ │
- │ │ /home/site/wwwroot (or D:\home\site\wwwroot) │ │
- │ │ • Read-Only File System │ │
- │ │ • Zero File Locks / Atomic Pointer Swap │ │
- │ │ • Pre-Indexed for Ultra-Fast JIT Assembly Loading │ │
- │ └──────────────────────────────────────────────────────────────────┘ │
- └────────────────────────────────────────────────────────────────────────┘
- Architectural Mechanics & Benefits
Atomic Mount Operation : Instead of extracting thousands of individual files onto the local disk, Azure mounts the zip file directly as the virtual wwwroot directory. The deployment completes as an atomic pointer swap.
Elimination of File Locks : Because the mounted filesystem is strictly read-only , worker processes cannot lock files in a way that blocks subsequent deployments. A new zip file is uploaded alongside the old one, and Azure updates the mount point seamlessly.
Drastic Cold Start Reduction : In serverless Azure Functions and auto-scaled App Services, loading hundreds of loose files across remote storage shares causes substantial disk I/O latency. Reading from an indexed, immutable package eliminates file traversal latency, accelerating cold start initialization by up to 50%.
Complete Artifact Integrity : The application running in production is guaranteed to match the exact byte-for-byte binary package generated by the CI build pipeline, preventing configuration drift.
Caution
Because wwwroot becomes strictly read-only under WEBSITE_RUN_FROM_PACKAGE=1 , any legacy code that attempts to write log files, cache data, or upload temp files directly into wwwroot will throw runtime UnauthorizedAccessException or IOException errors. All dynamic runtime writes must be directed to %TEMP% or /tmp .
Pipeline Implementation: AzureWebApp@1 and AzureFunctionApp@1 # Deploying an ASP.NET Core Web App using Run-From-Package
- task: AzureWebApp@1
- displayName: 'Deploy Web App to Production'
inputs:
- azureSubscription: 'ContosoARMConnection'
- appType: 'webApp'
- appName: 'app-contoso-core'
- package: '$(Pipeline.Workspace)/drop/**/*.zip'
- deploymentMethod: 'runFromPackage'
- # Deploying an Azure Function App
- task: AzureFunctionApp@1
- displayName: 'Deploy Order Processing Function'
inputs:
- azureSubscription: 'ContosoARMConnection'
- appType: 'functionApp'
- appName: 'func-order-processor'
- package: '$(Pipeline.Workspace)/drop/func-order.zip'
- deploymentMethod: 'runFromPackage'
- 2. Virtual Machine Deployments: Deployment Groups vs. Environment VM Resources
Enterprise architectures frequently maintain persistent Infrastructure-as-a-Service (IaaS) virtual machines running Linux (RHEL, Ubuntu) or Windows Server for legacy frameworks, specialized third-party software, or high-compliance workloads.
Evolution from Classic Deployment Groups to YAML Environments
Classic Release Pipelines (Deployment Groups) : In the legacy Classic UI, administrators provisioned a Deployment Group within the Azure DevOps project. Running a registration script on each VM installed the Azure Pipelines agent and registered the machine into the group with metadata tags (e.g., web , db , eastus ). While functional, Classic Deployment Groups lack Git versioning, pull request validation, and branch isolation.
Modern YAML Pipelines (Environments & VM Resources) : In YAML pipelines, deployment targets are represented as Environments . An Environment can contain Kubernetes clusters or Virtual Machine resources . The Azure Pipelines agent installed on the VM registers directly to the environment, enabling true Configuration-as-Code delivery. ┌───────────────────────────────────────────────────────────────────────┐
- │ Azure DevOps YAML Pipeline │
- │ Environment: 'production-vms' │
- └───────────────────────────────────┬───────────────────────────────────┘
- │ (Rolling Strategy: maxParallel: 2)
- ┌─────────────────────────────┴─────────────────────────────┐
- ▼ ▼
- ┌───────────────────────────────┐ ┌───────────────────────────────┐
- │ VM Resource: 'vm-web-01' │ │ VM Resource: 'vm-web-02' │
- │ • Agent Pool: production-vms │ │ • Agent Pool: production-vms │
- │ • Tags: [role: web, zone: A] │ │ • Tags: [role: web, zone: B] │
- │ • Status: Updating Batch 1 │ │ • Status: Updating Batch 1 │
- └───────────────────────────────┘ └───────────────────────────────┘
- │ │
- ▼ ▼
- ┌───────────────────────────────┐ ┌───────────────────────────────┐
- │ VM Resource: 'vm-web-03' │ │ VM Resource: 'vm-web-04' │
- │ • Agent Pool: production-vms │ │ • Agent Pool: production-vms │
- │ • Tags: [role: web, zone: A] │ │ • Tags: [role: web, zone: B] │
- │ • Status: Queued for Batch 2 │ │ • Status: Queued for Batch 2 │
- └───────────────────────────────┘ └───────────────────────────────┘
- Registering VM Resources into an Environment
To onboard a target VM into an Environment:
In Azure DevOps, navigate to Pipelines > Environments and create an environment (e.g., production-vms ).
Select Add resource > Virtual machines , selecting the target operating system (Linux or Windows).
Azure DevOps generates a registration script containing a personal access token (PAT) and organization URL.
Execute the script on the target virtual machine with elevated privileges ( sudo or Administrator PowerShell). The script downloads and configures the vsts-agent as a local system service.
Assign metadata tags (e.g., role: web , tier: frontend , datacenter: eastus ) directly via the Azure DevOps portal or the registration script.
The Rolling Deployment Strategy in YAML
The YAML strategy: rolling block controls progressive deployment execution across the registered VM fleet. Key parameters and lifecycle hooks include:
maxParallel : The number or percentage of virtual machines that can be updated simultaneously (e.g., maxParallel: 2 or maxParallel: 25% ).
Lifecycle Hooks :
preDeploy : Executes before the update starts (e.g., taking the VM out of the Azure Load Balancer backend pool).
deploy : Steps that download artifacts, stop services, copy binaries, and start new application services.
routeTraffic : Steps to re-attach the VM to the load balancer pool.
postRouteTraffic : Executes automated health probes to verify application responsiveness under live traffic.
on: failure : Executes remediation or alerts if any step in the lifecycle fails. jobs:
- deployment: DeployWebFleet
- displayName: 'Rolling Deployment to Web VM Fleet'
pool:
vmImage: 'ubuntu-latest'
environment:
- name: 'production-vms'
- resourceType: VirtualMachine
- tags: 'role: web'
strategy:
rolling:
maxParallel: 2
preDeploy:
steps:
- script: echo 'Draining connections from load balancer...'
- displayName: 'Drain Traffic'
deploy:
steps:
- download: current
- artifact: drop
- script: |
- sudo systemctl stop contoso-service
- sudo cp -r $(Pipeline.Workspace)/drop/* /var/www/html/
- sudo systemctl start contoso-service
- displayName: 'Update Binaries and Restart Service'
postRouteTraffic:
steps:
- script: |
- curl --fail http://localhost:80/health || exit 1
- displayName: 'Local Smoke Test Health Probe'
- 3. Scripted Post-Deployment Operations & Automation Tasks
Automated pipelines require post-deployment scripting to execute database seed routines, purge Content Delivery Network (CDN) caches, update routing rules, and register API endpoints. Azure Pipelines provides two primary tasks for executing cloud-management scripts:
AzureCLI@2 vs. AzurePowerShell@5
- Attribute AzureCLI@2 AzurePowerShell@5
- Underlying Engine Azure Command-Line Interface ( az ) Azure PowerShell Az Modules ( Get-AzResource )
- Script Types bash , pscore , batch , ps pscore (PowerShell Core), ps (Desktop PS)
- Cross-Platform Native across Linux, macOS, and Windows Native when configured with pwsh: true
- Authentication Automatic via ARM Service Connection Automatic via ARM Service Connection
- Best Fit Cloud-native CLI automation, bash scripts Deep .NET scripting, complex object pipelines
- Mission-Critical Pipeline Properties: pwsh: true and failOnStandardError: true
Two configuration settings are frequently tested on the AZ-400 exam because their omission leads to silent pipeline failures:
pwsh: true : Specifies that the script must run using PowerShell Core ( pwsh ) rather than Windows PowerShell ( powershell.exe ). This is mandatory when pipelines run on Microsoft-hosted Linux agents ( ubuntu-latest ) or self-hosted Linux containers. If pwsh: true is omitted on a Linux agent, the pipeline attempts to invoke powershell.exe and fails immediately.
failOnStandardError: true : By default, Azure Pipelines determines step success based on the process exit code ( exit 0 ). However, many command-line utilities and legacy tools write fatal error descriptions to stderr while exiting with code 0. Enabling failOnStandardError: true instructs the task runner to treat any data emitted to the standard error stream as an immediate task failure. - task: AzureCLI@2
displayName: 'Purge Front Door Cache Post-Deploy'
inputs:
- azureSubscription: 'ContosoServiceConnection'
- scriptType: 'pscore'
- scriptLocation: 'inlineScript'
- failOnStandardError: true
- inlineScript: |
- $ErrorActionPreference = 'Stop'
- Write-Host 'Purging Azure Front Door edge caches...'
- az afd endpoint purge \
- -resource-group rg-contoso-network \
- -profile-name afd-contoso-global \
- -endpoint-name ep-contoso-prod \
- -content-paths '/*'
- Engineering for Idempotency in Deployment Scripts
An automated deployment script is idempotent if running it multiple times produces the exact same end state without error, unintended side effects, or duplicate resource generation. Because CI/CD pipelines can be retried following transient network drops or agent timeouts, non-idempotent scripts cause catastrophic environment corruption.
- Anti-Pattern (Non-Idempotent) : # FAILS on rerun: Throws ResourceExists error
- az storage container create --name static-assets --account-name contosostorage
- # FAILS on rerun: Appends duplicate configuration lines every run
- echo 'export FEATURE_FLAG=true' >> /etc/environment
- Idempotent Best Practice : # Safe on rerun: Checks existence or uses declarative flags
- if ! az storage container show --name static-assets --account-name contosostorage > /dev/null 2>&1; then
- az storage container create --name static-assets --account-name contosostorage
- fi
- # Safe on rerun: Uses sed or grep to replace or insert once
- grep -qxF 'export FEATURE_FLAG=true' /etc/environment || echo 'export FEATURE_FLAG=true' >> /etc/environment
- 4. Comparison Table: Deployment Methodologies
Deployment Mechanism Target Platform File Lock Safety Cold Start Impact Rollback Capability Best Fit Workloads
Run From Package App Service / Functions 100% Safe (Read-only mount) Fastest (Pre-indexed) Instant (Swap package pointer) C#, Java, Node.js web APIs & Functions
Zip Deploy App Service / Functions Vulnerable if app active Moderate (Disk extraction) Requires re-uploading zip Small scripts, PHP, Python apps
Environment VM (Rolling) IaaS Virtual Machines Managed via service stop Dependent on OS service Phased re-deployment Legacy Windows/Linux system services
Containerized Deploy AKS / ACA / Web App 100% Safe (Container layer) Fast (Cached image layers) Instant (Revision/pod switch) Microservices, Dockerized architectures
- 5. Realistic Exam Scenario & Common Traps
- Scenario: Global Retail Web App Locked DLL Outages
Organization : Tailspin Toys hosts their primary e-commerce web platform on an Azure App Service Premium v3 plan running on Windows. Deployments run via an Azure Pipelines YAML pipeline utilizing the AzureWebApp@1 task.
Problem : During high-volume holiday sales periods, CI/CD deployments intermittently fail with ERROR_FILE_IN_USE: The process cannot access the file 'Tailspin.Commerce.dll' because it is being used by another process . When this happens, customer checkouts stall for 5–10 minutes while engineers manually restart the App Service.
Requirement : Modernize the deployment pipeline to ensure zero file locks during deployment, reduce application cold-start initialization latency, and ensure that post-deployment cache invalidation scripts written in PowerShell Core execute reliably on both Windows and Linux pipeline build agents.
DevOps Solution :
Update the App Service configuration to set WEBSITE_RUN_FROM_PACKAGE = 1 .
Configure the AzureWebApp@1 task with deploymentMethod: 'runFromPackage' .
Verify the application writes temporary session cache files to %TEMP% rather than wwwroot .
Update post-deployment cache purge tasks to use AzurePowerShell@5 with pwsh: true and failOnStandardError: true .
Common Exam Traps to Avoid
Trap: Confusing Classic Deployment Groups with YAML Environments. Deployment Groups belong strictly to the Classic UI Release Pipelines. When designing modern YAML multi-stage pipelines, the correct resource is an Environment containing Virtual Machine resources .
Trap: Forgetting that Run-From-Package renders wwwroot read-only. If an exam scenario states that an application needs to generate log files or write dynamic image uploads into wwwroot , WEBSITE_RUN_FROM_PACKAGE=1 will fail unless the code is modified to store uploads in Azure Blob Storage or write temp data to %TEMP% .
Trap: Omitting pwsh: true when running PowerShell tasks on Linux agents. Windows PowerShell ( powershell.exe ) does not exist on Linux. Always configure pwsh: true (PowerShell Core) for cross-platform agent compatibility.