Repository navigation
[EPIC] New feature: azd validate #6866
Description
Description
Introduce a validation that performs app-level checks against the user's Azure subscription, identity, and environment configuration before provisioning. The goal is to surface common blockers — like missing role assignments, expired credentials, or unregistered resource providers — upfront, before users invest time waiting on a provision that will fail.
Motivation
Today, many provisioning failures are caused by conditions that are detectable before azd provision runs — things like insufficient permissions on the target subscription, authentication issues, or missing environment configuration. Users currently discover these problems mid-provision through error messages that don't always make the fix obvious, leading to repeated attempts or abandonment.
By validating the user's environment ahead of time and providing clear, actionable guidance, we can help more users succeed on their first attempt.
Proposed behavior
azd validate checks the user's current environment against what the target template requires and reports any issues with suggested fixes. Initial focus areas:
- Role assignments — Does the signed-in identity have the roles required by the template's target resource types? (e.g., Contributor on the subscription, resource-specific roles for Key Vault, Cognitive Services, etc.)
- Authentication state — Is the current credential valid? Is the right tenant/subscription selected?
- Environment configuration — Are required environment variables set? Is the selected region supported for the required resource providers?
Iterative approach
We plan to build this incrementally. Each iteration will target the most common provisioning error patterns, validate whether the checks meaningfully improve outcomes, and expand from there. Community feedback on which provisioning errors are most painful will directly inform what checks get added next.
How you can help
If you've hit provisioning failures that felt like they could have been caught earlier, we'd love to hear about them. Specifically:
- What error did you see?
- What was the root cause?
- How did you figure out the fix?
This feedback will help us prioritize which validation checks to build first.
Related
- Provisioning error handling improvements
- First-run developer experience
Activity
spboyer commentedon Mar 5, 2026
azd doctorextension served as handling some of these things., I would propose pulling in the diff of that extension and implementing in the core under thevalidatecommand. Also isvalidatethe correct verb here? Should it becheckkristenwomack commentedon Mar 6, 2026
I'm open to another verb. I considered
check,validate, andverifyand here's how I was thinking about it:azd checkazd validateterraform validate,az deployment group validate; clear pre-deployment intentazd verifyRecommendation:
azd validateterraform validateandaz deployment group validatehave established this verb for pre-deployment checks. Our users may already have this muscle memory.azd validate→azd upreads as an intuitive two-step workflow.Shayne Boyer (@spboyer) - what do you think? Stick with
validateor usecheckor something else?Victor Vazquez (@vhvb1989) - are you already reusing functionality for the azd doctor extension in this feature?
vhvb1989 commentedon Mar 6, 2026
Im not using functionality from the doctor extension. But I am designing the feature in a way that any extension can attach function-validations. So I would expect to update the doctor extension once the feature is ready
feat: add local preflight engine and integrate with bicep deploy
[-]New feature: azd validate[/-][+][EPIC] New feature: azd validate[/+]1 remaining item