Iac Patching Bicep

1. Look for infra/ folder in the project root
2. Check for *.bicep files (especially main.bicep, main.parameters.json)
3. Confirm with user: “I found Bicep files in infra/. Want me to patch them for reliability?”

File Discovery

Search for resources to patch using these patterns:

The resource definitions may be in module files, not main.bicep. Search all .bicep files for the resource type.

⚠️ AVM Modules vs Raw Bicep — Parameter Naming Differs

If the project uses Azure Verified Modules (br/public:avm/res/...), the parameter names will not match the raw ARM property names shown in the patches below. Per-service AVM examples live in the per-service references. The most universally-applicable mapping is:

Before patching, always:

1. Detect AVM usage:

   powershellCopy

   Select-String -Path infra -Recurse -Pattern "br/public:avm/res/" -List

2. For each AVM module reference, open the module’s published README (the version is in the registry path, e.g. br/public:avm/res/storage/storage-account:0.x.y) or run:

   powershellCopy

   # Show the module call so you can see which params it currently passes
   Select-String -Path infra -Recurse -Pattern "avm/res/storage/storage-account" -Context 0,15

3. Map the reliability property to the module’s parameter name, not the ARM property name. When in doubt, search the actual module call for the property and patch what’s already in use.

Per-service Bicep patches

The patches for compute (zone redundancy on the App Service plan or Function App plan, health check path) live in the per-service references because the SKU rules and ARM types differ:

Azure Container Apps per-service Bicep patches are planned for a future version of this skill.

The one truly cross-service patch — storage — lives below.

Patch: Storage Account — LRS / GRS → ZRS / GZRS

Find: Microsoft.Storage/storageAccounts

Search pattern: resource .* 'Microsoft.Storage/storageAccounts@

💡 No sku block in the IaC? If the storage resource (or AVM module call) does not specify a SKU, Azure deploys it as Standard_GRS by default. The patch in that case is to add the sku block (raw Bicep) or add the skuName parameter (AVM), not find-and-replace an existing value. Always grep for the absence of sku / skuName before assuming there’s a value to swap.

Before:

After — change to ZRS:

Case: SKU not specified at all (defaulted to GRS)

Before (no sku block):

After — add an explicit sku:

AVM module equivalent:

Parameterized SKU (common pattern)

If the SKU is parameterized, update the default value:

Before:

After:

Also check main.parameters.json for overrides:

⚠️ Important: Existing Deployed Storage

Changing SKU in Bicep expresses the desired end state, but does NOT automatically migrate existing storage.

• New storage account → deploys as ZRS directly ✅
• Existing storage account → ARM may attempt an in-place SKU update, but LRS→ZRS is a storage redundancy conversion, not a simple property change. For supported StorageV2/GPv2 accounts in supported regions, Azure can perform live conversion, but this is not guaranteed and the deployment may fail for unsupported account kinds.

Always follow this order for existing storage:

1. Patch the Bicep to Standard_ZRS (desired end state)
2. Run az storage account migration start to initiate the live conversion
3. Wait for migration to complete (az storage account migration show)
4. Then run azd up / deploy — the Bicep now matches the actual state

⛔ Do NOT run azd up before the migration completes. The deployment may fail or conflict with the in-progress migration.

Deploy Plan (Skill executes this directly)

After patching, the skill executes the deploys itself — do not stop and tell the user to run commands. Confirm once with the user before each deploy, then run it.

Summarize the plan for the user: