Conflict: Another update operation is in progress

[brooke-hamilton]

Problem

We have seen Bicep deployments that fail with a "conflict" error.

{
    "status": "Failed",
    "error": {
        "code": "Conflict",
        "message": "Another update operation is in progress"
    }
}

Or with

{
    "status": "Failed",
    "error": {
        "code": "DeploymentFailed",
        "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.",
        "details": [
            {
                "code": "Conflict",
                "message": "{\r\n  \"error\": {\r\n    \"code\": \"Conflict\",\r\n    \"message\": \"Another update operation is in progress\"\r\n  }\r\n}"
            },
            {
                "code": "Conflict",
                "message": "{\r\n  \"error\": {\r\n    \"code\": \"Conflict\",\r\n    \"message\": \"Another update operation is in progress\"\r\n  }\r\n}"
            }

// Truncated...this pattern repeats several times

        ]
    }
}

Cause

The cases we have seen have been difficult to reliably reproduce, but appear to happen when the MLZ deployment parameter deployASC=true is set (to deploy Azure Security Center/Defender) and the subscription already contains a configuration for Azure Security Center/Defender (including the related policy assignments). In other words, it appears to happen when we attempt to deploy ASC/Defender to a subscription that already has ASC/Defender set up.

Workaround

Until we have a more specific root cause and a fix, a reliable workaround has been to remove the ASC/Defender configuration and remove the related policy assignments before deploying MLZ. See the Bicep cleanup instructions for details on removing policy assignments and downgrading the ASC pricing tier.