fix: validate Flex Consumption zone redundancy region support (#133) (#134)

* fix: validate Flex Consumption zone redundancy region support (#133)

FC1 (Flex Consumption) with zone_balancing_enabled = true is only
supported in Azure regions that advertise the FCZONEREDUNDANCY
capability. Previously the module forwarded the request unchanged and
Azure returned an opaque 400 in unsupported regions.

This adds a region-aware precondition: when FC1 is combined with zone
balancing, the module queries the Microsoft.Web geoRegions API for
regions advertising FCZONEREDUNDANCY and fails early with an actionable
message listing the supported regions. Deployments in supported regions
(e.g. East US 2) are unaffected, and the data source is not evaluated
for any other SKU or when zone balancing is disabled.

Closes #133

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* chore: pre-commit governance sync

Apply current AVM governance template updates (AGENTS.md spec index
section and avm-terraform-module-development skill content) generated by
./avm pre-commit, keeping the repo in sync with the governance baseline.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: ethanjenkins1

.agents/skills/avm-terraform-module-development/SKILL.md

@@ -0,0 +1,91 @@
+# AVM Standard Interfaces
+
+AVM defines a small, fixed set of **interfaces** that resource modules expose where the underlying Azure resource supports them. They standardise variable names, types, and behaviour across every module so consumers learn one shape and reuse it everywhere.
+
+All interfaces are implemented in the canonical utility module **`Azure/avm-utl-interfaces/azure`** (version `~> 0.6`). Resource modules should compose that utility module rather than redefining variable shapes by hand. For the authoritative interface text, fetch each interface page via `https://azure.github.io/Azure-Verified-Modules/llms.txt`.
+
+## Interfaces
+
+### Diagnostic settings
+
+Exposes `diagnostic_settings` (map of objects) so consumers can route resource logs and metrics to Log Analytics, Storage, Event Hub, or partner solutions. Apply on every resource that produces diagnostic logs or metrics.
+
+**Modules MUST use the v2 schema.** The v2 shape models `logs` and `metrics` as sets of objects with `category` / `category_group`, `enabled`, and optional `retention_policy`, instead of the legacy flat sets of category strings. Do not specify allowed values for category names — the module must stay evergreen as resource providers add new categories.
+
+Wire it through the utility module via its `diagnostic_settings_v2` input and consume the `diagnostic_settings_azapi_v2` output — the legacy `diagnostic_settings` input/output on the utility module is the old shape and **must not** be used in new code.
+
+### Role assignments
+
+Exposes `role_assignments` (map of objects) so consumers can attach Azure RBAC role assignments scoped to the resource. The key becomes a stable map key for plan-time stability; the object specifies `role_definition_id_or_name`, `principal_id`, `description`, etc.
+
+### Locks
+
+Exposes a `lock` (single object: `kind` = `None | CanNotDelete | ReadOnly`, `name` optional). Apply to top-level resources that support management locks.
+
+### Managed identities
+
+Exposes `managed_identities` (object with `system_assigned` bool and `user_assigned_resource_ids` set of strings). Apply on every resource that supports managed identity.
+
+### Private endpoints
+
+Exposes `private_endpoints` (map of objects) so consumers can deploy private endpoints into a target subnet, register them in private DNS zones, and configure custom IP addressing. Apply on every resource that supports Private Link.
+
+### Customer-managed keys
+
+Exposes `customer_managed_key` (single object: `key_vault_resource_id`, `key_name`, optional `key_version`, optional `user_assigned_identity` reference). Apply on every resource that supports CMK encryption.
+
+### Tags
+
+Exposes `tags` (map of strings). Required on every resource that supports tags. The pattern-module equivalent typically forwards a shared `tags` input to every composed module.
+
+### AzAPI resource types
+
+Exposes `resource_types` (object) so consumers can pin the API version used for each `azapi_resource` the module owns. The keys are **module-specific** — declare one `optional(string, "<api-version>")` field per `azapi_resource` (or equivalent) the module declares, defaulting each to the latest tested API version. Defaults **MUST** be a stable (non-preview) API version unless the resource only ships preview.
+
+Parent modules **MUST** cascade the relevant subset of `resource_types` to each submodule (see TFFR6 and TFRMNFR1). Submodules **MUST** declare their own `resource_types` variable using the same pattern.
+
+### AzAPI retry
+
+Exposes `retry` (single object: `error_message_regex`, `interval_seconds`, `max_interval_seconds`, all optional). MUST be applied to every `azapi_resource` (and equivalent AzAPI resources) declared by the module and cascaded unchanged into every submodule. `retry` is an attribute on `azapi_resource`, so it is assigned directly.
+
+### AzAPI timeouts
+
+Exposes `timeouts` (single object: `create`, `read`, `update`, `delete`, all optional Go duration strings). MUST be applied to every `azapi_resource` (and equivalent AzAPI resources) declared by the module and cascaded unchanged into every submodule. `timeouts` is a **block** on `azapi_resource` (not an attribute), so a `dynamic "timeouts"` block is required to honour the variable's `null` default.
+
+For the full `retry` and `timeouts` variable schemas, the resource-side wiring (including the `dynamic` block), module-level defaults guidance, and submodule cascade pattern, read [AzAPI.md](./AzAPI.md#retry-and-timeouts).
+
+## Implementation pattern
+
+1. Take a dependency on `Azure/avm-utl-interfaces/azure` in `terraform.tf`.
+2. Call the utility module in `main.tf` to translate the standard inputs into the AzAPI body shape. Note the diagnostic-settings input field is `diagnostic_settings_v2` (the legacy `diagnostic_settings` field on the utility module is the old shape):
+
+   ```hcl
+   module "avm_interfaces" {
+     source  = "Azure/avm-utl-interfaces/azure"
+     version = "~> 0.6"
+
+     diagnostic_settings_v2    = var.diagnostic_settings
+     diagnostic_settings_scope = azapi_resource.this.id
+     managed_identities        = var.managed_identities
+     # …
+   }
+   ```
+
+3. Reference the utility module's outputs in the relevant `azapi_resource` blocks. For diagnostic settings iterate `module.avm_interfaces.diagnostic_settings_azapi_v2`:
+
+   ```hcl
+   resource "azapi_resource" "diagnostic_settings" {
+     for_each = module.avm_interfaces.diagnostic_settings_azapi_v2
+
+     type      = each.value.type
+     name      = each.value.name
+     parent_id = each.value.parent_id
+     body      = each.value.body
+   }
+   ```
+
+4. Implement supporting child resources (private endpoints, diagnostic settings, role assignments, locks) as separate `azapi_resource` blocks driven by the same input maps — never collapse them into the parent `body` (TFRMNFR1).
+
+## When NOT to expose an interface
+
+If the underlying Azure resource does not support a capability (e.g. no private endpoints, no managed identity, no diagnostic settings), do **not** expose the corresponding variable. Adding a no-op variable creates a misleading contract.

.agents/skills/avm-terraform-module-development/references/AzAPI.md

@@ -0,0 +1,75 @@
+# AVM Terraform Module Composition
+
+Concise summary of how an AVM Terraform Resource or Pattern Module fits together. For the authoritative text, fetch the relevant spec via `https://azure.github.io/Azure-Verified-Modules/llms.txt`.
+
+## File layout
+
+The root of every AVM Terraform module looks like this (TFNFR39):
+
+```
+.
+├── _header.md            # Source of README intro; edit this, NOT README.md
+├── _footer.md            # Source of README footer
+├── README.md             # Auto-generated by terraform-docs; do not edit
+├── main.tf               # Primary resource(s)
+├── main.<feature>.tf     # Feature-grouped sub-files (optional)
+├── main.telemetry.tf     # modtm telemetry block (managed by mapotf)
+├── variables.tf          # All inputs
+├── outputs.tf            # All outputs
+├── locals.tf             # Local values (if used)
+├── terraform.tf          # required_version + required_providers
+├── examples/             # One folder per example, each runnable on its own
+│   └── <example_name>/
+│       ├── main.tf
+│       ├── variables.tf
+│       ├── outputs.tf
+│       └── README.md
+├── modules/              # Internal sub-modules called only by this module
+│   └── <sub_module>/
+└── tests/
+    ├── unit/             # mock_provider tests
+    └── integration/      # real-deploy tests
+```
+
+Rules of thumb:
+
+- One `azapi_resource` block per logical resource — never collapse parent + child into a single `body`.
+- Group related resources into `main.<feature>.tf` (e.g. `main.privateendpoint.tf`, `main.diagnostics.tf`) once `main.tf` exceeds ~200 lines.
+- Sub-modules in `modules/` are private to the module and must follow the same file layout in miniature.
+- Examples are independent root modules; each must `terraform init && terraform plan && terraform apply && terraform plan` cleanly (idempotency check).
+
+## Resource modules (`res`)
+
+A resource module deploys one **primary** Azure resource (RMFR1). Child resources that have no useful lifecycle outside the primary (e.g. blob services for a storage account, network security rules for an NSG) belong in the same module. Anything you would reasonably manage independently belongs in its own resource module and is consumed via `module "..."`.
+
+Key obligations:
+
+- Implement the resource with the AzAPI provider (TFFR3).
+- Expose standard interfaces where applicable (diagnostic settings, locks, role assignments, private endpoints, managed identities, customer-managed keys, tags) — see [interfaces.md](interfaces.md).
+- Outputs include the required AVM outputs (RMFR7). For Terraform-specific additional outputs, prefer discrete computed attributes over whole resource object outputs (TFFR2).
+- Provide at least a `default` example demonstrating the simplest valid usage.
+
+## Pattern modules (`ptn`)
+
+A pattern module composes multiple AVM resource modules (and optionally other pattern modules) into an opinionated workload — for example, "AKS production baseline" or "regulated landing zone hub". It generally does **not** declare `azapi_resource` blocks directly; it wires resource modules together.
+
+Key obligations:
+
+- Re-use existing AVM resource modules instead of re-implementing resources.
+- Expose only the inputs the workload needs; opinionated defaults are encouraged.
+- Telemetry, naming, and tagging interfaces still apply to the pattern module itself.
+- Examples demonstrate the workload end-to-end, not just the wiring.
+
+## Telemetry
+
+`main.telemetry.tf` declares a `modtm_telemetry` resource so AVM can measure module usage (SFR3 / SFR4). It is generated/maintained by the mapotf configuration in this governance repo — do not hand-edit it. The user can opt out with `enable_telemetry = false`.
+
+## Required providers & versions
+
+`terraform.tf` pins `required_version` and `required_providers` (TFNFR26 / TFNFR27 / TFNFR39). At minimum:
+
+- `azapi` within the TFFR3-permitted major range (`>= 2.0, < 3.0`)
+- `modtm` if telemetry is implemented
+- `random` when the module directly uses it
+
+Provider version bounds are enforced by the mapotf `required_provider_versions.mptf.hcl` config in this governance repo.

.agents/skills/avm-terraform-module-development/references/interfaces.md

@@ -34,7 +34,7 @@ Submodules under `./modules/` follow the same pattern — each can have its own
 
 ## Unit Test Template
 
-Every AVM module uses the AzAPI provider. Unit tests MUST mock **all** providers declared in `terraform.tf` `required_providers`. AVM modules always include `azapi`, `modtm`, and `random`.
+Unit tests MUST mock **all** providers declared in `terraform.tf` `required_providers` for the module under test.
 
 ```hcl
 # tests/unit/unit.tftest.hcl
@@ -387,10 +387,10 @@ For debugging, the `terraform test -no-cleanup` flag prevents automatic destruct
 
 ## Best Practices
 
-1. **Always mock all providers** in unit tests — check `terraform.tf` `required_providers` for the full list. AVM modules always have at least `azapi`, `modtm`, and `random`.
+1. **Always mock all providers** in unit tests — check `terraform.tf` `required_providers` for the full list for the module under test.
 2. **Use `command = apply`** for unit tests (not `plan`) — mocked providers make apply safe and allow testing resource creation.
 3. **Write clear error messages** — assertion messages should describe the expected behavior, not restate the condition.
-4. **Set `location`** in the `variables` block — it is a required variable in all AVM modules with no default.
+4. **Set all required inputs** in the `variables` block — use the module's `variables.tf` to determine which variables are required and have no default.
 5. **Test validation rules** — use `expect_failures` to verify that invalid inputs are rejected.
 6. **Test conditional logic** — verify that optional features create resources when enabled and skip them when disabled.
 7. **Keep tests focused** — each run block should test one scenario or behavior.