![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(249.60000000000002, 35%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAH%3C/text%3E%3C/svg%3E)
Azure Automation
An Azure service that is used to automate, configure, and install updates across hybrid environments.
Hello Andrew Holland,
Greetings! Thanks for raising this question in the Q&A forum.
The root cause here is a known platform limitation rather than a misconfiguration on your side. Azure Automation Source Control integration was built around PowerShell 5.1 and Python 2.7/3.8, and it does not officially support PowerShell 7.2 runbooks. When source control creates a brand new runbook that doesn't exist yet, it silently creates it as a PowerShell 5.1 runbook, which is exactly why deleting a runbook lets the sync succeed without errors. But when a runbook with that same name already exists and is linked to the 7.2 runtime, the sync engine tries to push an updated draft that conflicts with the runbook's assigned runtime type, and the Automation API rejects it with Bad Request(400). This also explains why recreating the source control connection didn't help, since the connection itself isn't the problem.
Here is how to work around this.
Confirm the runtime mismatch. In the Azure portal, open your Automation account, go to Runbooks, and check the Runtime version column for Runbook1 through Runbook7. If they show 7.2 while the successfully synced runbooks show 5.1, that confirms this is the same limitation described in Microsoft's own troubleshooting docs.
Move these specific runbooks out of Source Control sync. Since Source Control only reliably manages PowerShell 5.1 content, the safest long-term fix is to stop relying on the built-in Git sync for any runbook that must run on 7.2, and instead deploy those through your own CI/CD pipeline that calls the Automation API directly and can target the 7.2 runtime explicitly.
Deploy the 7.2 runbooks via Az PowerShell in a pipeline instead. In an Azure DevOps pipeline or GitHub Actions workflow, use Import-AzAutomationRunbook with -Force so it updates existing runbooks instead of failing, and explicitly set the type to PowerShell7:
Import-AzAutomationRunbook `
-Path ".\Runbook1.ps1" `
-Name "Runbook1" `
-ResourceGroupName "ExampleResourceGroup" `
-AutomationAccountName "ExampleAutomationAccount" `
-Type PowerShell7 `
-Force
Publish-AzAutomationRunbook `
-Name "Runbook1" `
-ResourceGroupName "ExampleResourceGroup" `
-AutomationAccountName "ExampleAutomationAccount"
- If you're using the newer Runtime Environment experience instead of the legacy 7.2 type, link the runbook explicitly to the correct runtime environment via REST after import, since Source Control has no awareness of Runtime Environments at all:
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/ExampleResourceGroup/providers/Microsoft.Automation/automationAccounts/ExampleAutomationAccount/runbooks/Runbook1?api-version=2024-10-23
{
"properties": {
"runtimeEnvironment": "YourPowerShell72RuntimeEnvironmentName",
"runbookType": "PowerShell"
}
}
Keep Source Control scoped to only the runbooks that are actually 5.1 compatible. If some of these seven runbooks don't strictly need 7.2 features, moving them back to 5.1 will let Source Control manage them without any special casing, and you only need the pipeline-based workaround for the ones that truly require 7.2.
Split your repo folder structure if practical, so 5.1 runbooks stay in the folder path your existing Source Control connection watches, and 7.2 runbooks live in a separate folder that only your pipeline touches. This avoids any ambiguity about which mechanism owns which files.
This is a documented gap rather than something Azure Support can toggle on for your account, so unless Microsoft ships explicit 7.2 support for Source Control, the pipeline-based deployment above is the supported path forward for those seven runbooks.
If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,
Jerald Felix.