Azure News - 2026-05-11

Understanding deployment quota limitation (800) Error in Azure Deployments (Bicep/ARM)

Introduction

When working with Infrastructure as Code (IaC) using Azure Bicep or ARM templates, deployment failures are a common part of day-to-day operations—especially in large-scale enterprise environments.

One such frequently encountered but often misunderstood issue is the quota limitation (800) error, which typically occurs during repeated or automated deployments.

This blog explains:

• What this error means
• A practical Bicep deployment use case
• Root causes
• Resolution approaches
• Preventive best practices

What is the quota limitation (800) Error?

The quota limitation (800) reference is commonly associated with a deployment quota limitation in Azure Resource Manager (ARM).

In simple terms:
Azure limits the number of deployment records that can be stored per resource group.

Key detail:

• Maximum allowed deployment history entries per resource group: 800

Once this limit is exceeded:

• New deployments fail
• Error messages such as the following are observed:

“DeploymentQuotaExceeded”

The current deployment count is '800'. Please delete some deployments before creating a new one.

This happens because Azure maintains deployment history for auditing, tracking, and troubleshooting purposes. [aka.ms/800]

Use Case: Bicep Deployment Failure in CI/CD

Scenario

An organization is deploying infrastructure using a Bicep template through an automated pipeline.

Example command:

Environment Characteristics

• Continuous deployment using pipelines (Azure DevOps / GitHub Actions)
• Multiple deployments triggered daily
• Incremental deployment mode enabled
• A shared resource group used across multiple deployments

Issue Encountered

After repeated deployments over time, the following failure occurs:

Error: DeploymentQuotaExceeded

The current deployment count is '800'

See aka.ms/800 for more information

At this point, no further deployments succeed in that resource group.

Root Cause Analysis

1. Deployment History Limit

Azure stores every deployment execution as a record under:

Resource Group → Deployments

These records accumulate over time, and once the count reaches 800, new deployments are blocked.

Important clarification:

• This is not a resource limit (VMs, VNets, etc.)
• This is a metadata limit related to deployment history

1. High Frequency CI/CD Deployments

In enterprise environments, pipelines may run frequently due to:

• Minor configuration updates
• Validation runs
• Automated releases

Each run contributes to the deployment count.

1. Absence of Cleanup Mechanism

Although Azure manages some cleanup automatically, it is not always sufficient in high-frequency environments. Manual or automated cleanup is often required.

Resolution Approaches

Option 1: Manual Cleanup from Azure Portal

Navigate to:

• Azure Portal
• Resource Group
• Deployments

Delete older deployment entries manually to free up space.

Option 2: Cleanup Using Azure CLI

az deployment group list
--resource-group prod-rg
--query "[].name" -o tsv

#Delete a deployment:

az deployment group delete
--resource-group prod-rg
--name <deployment-name>

Option 3: Automated Cleanup (Recommended)

Example PowerShell approach:

if ($deployments.Count -gt 700) { $deployments | Sort-Object Timestamp | Select-Object -First 100 | ForEach-Object { Remove-AzResourceGroupDeployment -ResourceGroupName "prod-rg" -Name $_.DeploymentName } }

This approach ensures that older deployments are periodically removed, preventing quota exhaustion.

Option 4: Use Multiple Resource Groups

Instead of using a single resource group for all deployments:

• Separate environments (Dev, Test, Prod)
• Temporary or experimental deployments

This helps distribute deployment records across multiple scopes.

Best Practices

1. Implement Deployment Retention Policy

• Maintain only recent deployments (for example, last 100–200)
• Automate deletion of older entries

1. Control Deployment Frequency

• Avoid unnecessary pipeline triggers
• Batch multiple changes into a single deployment

1. Use Predictable Deployment Naming

Example:

This improves traceability and cleanup management.

1. Monitor Deployment Count

Example:

Set alerts or monitoring thresholds if required.

1. Understand Deployment Mode Behavior

Incremental deployments prevent unwanted deletions of resources but still increase the deployment history count.

Common Misconceptions

Related Deployment Errors

While troubleshooting deployments, other common errors may appear, such as:

• Authorization failures (insufficient permissions) [learn.microsoft.com]
• Invalid template errors (syntax or parameter mismatch)
• Concurrent deployment conflicts

It is important to analyze deployment logs to identify the exact failure reason.

Summary

Closing Thoughts

For teams operating at scale with Azure Bicep and automated pipelines, this issue is common but preventable.

The key takeaway is to treat deployment history as an actively managed component of your environment. Without proper governance, it can become a blocking factor for ongoing automation efforts.

Scaling GitHub Advanced Security in Azure DevOps with a single reusable YAML template

Managing security scanning across dozens of repositories can quickly become complex—especially when each repository uses different languages, frameworks, and infrastructure patterns.

In our environment, we needed a scalable way to apply GitHub Advanced Security (GHAS) consistently across:

• Application code (Python, C#, Java, JavaScript)
• Infrastructure as Code (Terraform, ARM, Bicep)
• Mixed (polyglot) repositories

Instead of maintaining multiple pipelines, we built a single reusable Azure DevOps YAML template that dynamically adapts to any repository.

The problem

Most teams struggle with:

• Multiple pipelines for different tech stacks
• Inconsistent security coverage
• Maintenance overhead across repositories
• Unnecessary scans increasing build time

We needed a solution that:

• Detects repository content automatically
• Runs only relevant scans
• Standardizes security across all repos
• Minimizes duplication

Solution overview

The solution is a single-stage pipeline template with three key jobs:

1. Detect repository content
2. Run CodeQL for application code
3. Run IaC security scanning

Scanning behavior is driven entirely by detection outputs.

Architecture

🟦 High-level flow

Key design patterns

1. Detection-driven execution

Instead of hardcoding logic, the pipeline first detects repository content.

✅ Runs only when code is present
✅ Avoids unnecessary execution

2. Single template for all repositories

A single YAML template works for:

• Backend services
• Frontend apps
• IaC repositories
• Mixed projects

No duplication. No branching logic across repos.

3. Dynamic CodeQL configuration

The pipeline generates a runtime CodeQL config file:

✅ Keeps configuration centralized
✅ Avoids scan failures due to irrelevant directories

4. Language-aware setup

The pipeline dynamically prepares environments:

✅ No need for separate pipelines
✅ Works across polyglot repos

5. Correct CodeQL build strategy

For compiled languages like C#, the pipeline performs build tracing:

✅ Ensures proper CodeQL extraction
✅ Avoids empty-database failures

6. Integrated IaC security scanning

Infrastructure scanning is handled in the same pipeline:

✅ Covers Terraform, ARM, Bicep
✅ Unified reporting across code and infrastructure

7. Centralized reporting

Artifacts are published for traceability:

• Code scanning results → CodeScanningReports
• IaC results → IaCSecurityReports

✅ Easy audit and troubleshooting
✅ Retains SARIF outputs

Benefits

This approach delivers:

✔ One pipeline for all repositories
✔ Reduced maintenance overhead
✔ Consistent security enforcement
✔ Faster pipeline execution
✔ Scalable DevSecOps model

Lessons learned

• Detection-first pipelines are critical for scale
• Config-driven CodeQL execution prevents failures
• Build tracing must be handled explicitly for compiled languages
• IaC scanning should not be a separate workflow

Conclusion

Scaling GitHub Advanced Security across Azure DevOps doesn’t require multiple pipelines—it requires the right architecture.

By combining:

• Detection-driven execution
• Dynamic configuration
• Conditional setup
• Unified scanning

You can operationalize security at scale with a single reusable YAML template.