Module path
avm/ptn/ai-ml/ai-foundry
Module version
0.6.0
Summary
Preview flows fail before a what-if result is produced when the AI Foundry pattern creates internal associated-resource RBAC assignments from principal IDs that are only materialized later in the same deployment.
In our repo this shows up through both:
azd provision --previewaz deployment sub what-if --validation-level Template
The raw preview path fails with:
InvalidTemplate: The provided value for the template parameter 'roleAssignments[0]' is not valid. A non-null value for the property 'principalId' must be provided, but the property was null or missing.
Repro shape
The repro uses the AI Foundry pattern with associated resources enabled, including AI Search and Storage, so the module synthesizes RBAC for those resources and for the created project.
Compiled template evidence
From the compiled ARM output generated from the module usage:
- the storage associated-resource deployment builds
roleAssignments by concatenating user-provided assignments with new entries whose principalId values come from reference('foundryAccount').outputs.systemAssignedMIPrincipalId.value and reference('aiSearch').outputs.systemAssignedMIPrincipalId.value
- the project-related RBAC deployments pass
reference('project', '2025-07-01-preview', 'full').identity.principalId into nested role-assignment deployments
Those same-deployment identity references are valid for real deployment ordering, but preview validation appears to evaluate them too early.
Why this seems module-related
We already moved some repo-local RBAC assignments outside the AI Foundry module to reduce preview failures, but the remaining failure still comes from the module's internal associated-resource/project RBAC generation.
Expected behavior
The module should remain previewable in ARM what-if / azd provision --preview, even if the actual role assignments are created later in the deployment.
Actual behavior
Preview fails during template validation and produces no usable diff unless the caller strips the preview-hostile RBAC sections from a temporary compiled template.
Suggested fix directions
- Avoid constructing preview-critical
roleAssignments arrays from same-deployment managed-identity outputs inside the main pattern path.
- Split those associated-resource RBAC deployments into a phase that can be disabled or deferred for preview-sensitive scenarios.
- Expose an option to skip/defer internal associated-resource RBAC and project-connection RBAC so callers can keep preview working without forking the module.
- Where possible, prefer existing-resource lookups for already-deployed resources instead of preview-time references to fresh outputs.
Environment
azd 1.23.15azure-cli 2.84.0- preview attempted at subscription scope
If helpful, I can provide a minimized repro that isolates just the AI Foundry pattern and the failing associated-resource RBAC path.
Module path
avm/ptn/ai-ml/ai-foundry
Module version
0.6.0Summary
Preview flows fail before a what-if result is produced when the AI Foundry pattern creates internal associated-resource RBAC assignments from principal IDs that are only materialized later in the same deployment.
In our repo this shows up through both:
azd provision --previewaz deployment sub what-if --validation-level TemplateThe raw preview path fails with:
Repro shape
The repro uses the AI Foundry pattern with associated resources enabled, including AI Search and Storage, so the module synthesizes RBAC for those resources and for the created project.
Compiled template evidence
From the compiled ARM output generated from the module usage:
roleAssignmentsby concatenating user-provided assignments with new entries whoseprincipalIdvalues come fromreference('foundryAccount').outputs.systemAssignedMIPrincipalId.valueandreference('aiSearch').outputs.systemAssignedMIPrincipalId.valuereference('project', '2025-07-01-preview', 'full').identity.principalIdinto nested role-assignment deploymentsThose same-deployment identity references are valid for real deployment ordering, but preview validation appears to evaluate them too early.
Why this seems module-related
We already moved some repo-local RBAC assignments outside the AI Foundry module to reduce preview failures, but the remaining failure still comes from the module's internal associated-resource/project RBAC generation.
Expected behavior
The module should remain previewable in ARM what-if /
azd provision --preview, even if the actual role assignments are created later in the deployment.Actual behavior
Preview fails during template validation and produces no usable diff unless the caller strips the preview-hostile RBAC sections from a temporary compiled template.
Suggested fix directions
roleAssignmentsarrays from same-deployment managed-identity outputs inside the main pattern path.Environment
azd 1.23.15azure-cli 2.84.0If helpful, I can provide a minimized repro that isolates just the AI Foundry pattern and the failing associated-resource RBAC path.