FrontDoor Bicep Fails - How do I get the reason?

Question

I have a bicep that adds a front door endpoint and origin. It is failing with:

The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'.

That's the raw error I see in the Resource Group Deployment in the UI.

This bicep takes parameters and it works for another app service. These parameters are identical, except for the app service and end point name.

I am deploying the bicep with this command:

New-AzResourceGroupDeployment -ResourceGroupName $FrontDoorResourceGroupName -Mode Incremental -TemplateFile .\bicep\frontdoor.bicep -TemplateParameterObject $templateParameters -DeploymentDebugLogLevel All

I tried to validate the deployment with Test-AzDeployment, but it gives no meaningful information.

Here is the vague entry from the resources deployment, in the Azure UI.

How can I get more information about why it failed?

Answer 1

Front Door Bicep Fails - How do I get the reason?

After a workaround on your requirement, I found below ways to retrieve the error information more explicitly in bicep.

Approach-1:

The PowerShell command New-AzResourceGroupDeployment has an argument named

-DeploymentDebugLogLevel provides detailed error information including line and column numbers. DeploymentDebuglevel can be enabled as per your requirement. This option is incompatible with CLI deployment.

New-AzResourceGroupDeployment -ResourceGroupName "xxxx" -TemplateFile "/home/xx/new.bicep" -DeploymentDebugLogLevel All

Approach-2:

You can use the Bicep build command to acquire troubleshooting information. The output includes the line and column number of each error, as well as the error message.

Build the bicep file by passing an argument --Debug along with the az bicep build command. It will also retrieve the information with the line numbers and a clear error message.

Refer Github Doc for more related information.

Approach-3:

And also Test-AzDeployment helps you to validate the deployment and shows the error messages if any. This might not be an efficient way if you have multiple blockers.

Approach-4:

The last one would be checking portal deployment history. It might not be helpful in few scenarios. To check this, go to your deployment resource group and then choose deployments under settings. You will be able to view the below deployments history page as shown.

You can also refer Github MS Doc for more related information on your issue.