Bicep Reviewer

Step 1: Bicep Compilation (Run First)

Run actual Bicep compilation before the checklist. Do not declare “pass” based on visual inspection alone.

Collect all WARNINGs and ERRORs from the compilation results. This is the foundational data for the review.

Step 2: Fix Compilation Errors/Warnings

Fix issues found in compilation results:

• ERROR → Must fix and recompile
• WARNING → Handle according to the criteria below

🚨 WARNING Handling Criteria — Do Not Force Unnecessary Fixes:

WARNINGs do not block deployment. Attempting to resolve warnings often introduces deployment errors, so use the following criteria:

Never do the following:

• Downgrade API versions to resolve WARNINGs (maintain latest stable)
• Add properties not confirmed in MS Docs to resolve WARNINGs
• Force fixes targeting “zero warnings”

Principle: Document WARNINGs in review results, but do not fix them if they don’t block deployment.

Common issues and responses:

• BCP081 (type not defined) → API version is likely incorrect. Fetch MS Docs and update to the actual latest stable version
• BCP036 (type mismatch) → Check property value casing and type, then fix
• BCP037 (property not allowed) → Check MS Docs to verify if the property is supported in that API version
• no-hardcoded-env-urls → Hardcoded URLs in DNS Zone names etc. are sometimes unavoidable in Bicep. Note in review results

Step 3: Checklist Review

Review the following items after compilation passes. See references/service-gotchas.md for full gotchas.

Critical (Must Fix)

• Not done: Microsoft Foundry customSubDomainName setting exists — Cannot be changed after creation; if missing, resource must be deleted and recreated
• Not done: When using Microsoft Foundry, Foundry Project (accounts/projects) must exist — Portal access unavailable without it
• Not done: Microsoft Foundry identity: { type: 'SystemAssigned' } — Project creation fails without it
• Not done: publicNetworkAccess: 'Disabled' — All services using PE
• Not done: ADLS Gen2 isHnsEnabled: true — Without it, becomes regular Blob Storage
• Not done: pe-subnet privateEndpointNetworkPolicies: 'Disabled' — PE creation fails without it
• Not done: Private DNS Zone Group — Must exist for every PE
• Not done: Key Vault enablePurgeProtection: true

High (Recommended Fix)

• Not done: Storage allowBlobPublicAccess: false, minimumTlsVersion: 'TLS1_2'
• Not done: Private DNS Zone VNet Link registrationEnabled: false
• Not done: Resource types and kind values per service match references/ai-data.md or MS Docs
• Not done: Model deployments: Order guaranteed (dependsOn)
• Not done: No sensitive values in parameter files — Remove immediately if found

Medium (Recommended)

• Not done: Resource name collision prevention using uniqueString()
• Not done: Leverage implicit dependencies through resource references

Step 4: Hardcoding Regression Check (Prevent Dynamic Information Leakage)

Verify the following items are not hardcoded as literal values in the Bicep code:

Must Be Parameterized (No Hardcoding)

• Not done: location — Literal region names ('eastus', 'koreacentral', etc.) are not used directly; passed via param location
• Not done: Model name/version — Not literals; use values confirmed in Phase 1 and validated for availability in Step 0
• Not done: SKU — Use values confirmed with the user

Verify Dynamic Values Have Not Regressed Into References

This is not directly within this review’s scope, but if specific API versions, SKU lists, or region lists are hardcoded in code comments or parameter descriptions, remove them and replace with “Check MS Docs” guidance.

Decision Rule Violation Check

• Not done: If kind: 'OpenAI' is used instead of Foundry → Change to kind: 'AIServices' unless the user explicitly requested it
• Not done: If Hub (MachineLearningServices) is used for general AI/RAG → Change to Foundry unless the user explicitly requested it
• Not done: If a standalone Azure OpenAI resource is used → Suggest reviewing Foundry usage unless the user explicitly requested it or Docs indicate it’s necessary

Step 5: Recompile After Fixes

If any changes were made in Steps 2–4, run az bicep build again to verify no new errors were introduced.

Limitations of az bicep build

Compilation only validates syntax and types. The following items cannot be caught by compilation and are finally verified in Phase 4’s az deployment group what-if:

• Retired/unavailable SKU
• Per-region service availability
• Model name validity
• Preview-only properties
• Service policy changes (quota, capacity, etc.)

State these limitations in the review results so the user understands the importance of the what-if step.

Step 6: Report Results

Step 7: Phase 4 Transition — Reassurance Message Required

When asking whether to proceed to Phase 4 after passing code review, always include a message to reassure the user. Users may feel uneasy about the word “deployment”, so clearly communicate that what-if is a safe validation step.

Key points:

• Always state “This does NOT deploy immediately”
• Explain the 3-step process: what-if → preview diagram → final confirmation
• Reassure with “Nothing will be deployed without your approval”