Add Deploy-to-Azure Bicep template - #1477

…t kind

The AVM database-account module (br/public:avm/res/document-db/database-account:0.10.0)
derives the account's 'kind' property from whether mongodbDatabases is
non-empty, independent of capabilitiesToAdd. Passing an empty
mongodbDatabases array left the account at kind=GlobalDocumentDB (SQL
API) even with EnableMongo set, which then rejected the MongoDB-groupId
private endpoint with:

  BadRequest: Call to Microsoft.DocumentDB/databaseAccounts failed.
  Error message: GroupId MongoDB is not supported

Fixed by provisioning a default database (name configurable via the new
'databaseName' param, default 'scope') so the module correctly resolves
kind=MongoDB. The child mongodb-database module already skips setting
throughput when EnableServerless is present, so this has no cost impact
under the default serverless configuration.

Verified: deploy/azure/modules/cosmosdb.bicep and the full
deploy/azure/main.bicep both compile with zero errors/warnings via
'az bicep build'; confirmed the compiled azuredeploy.json's kind
expression now resolves to 'MongoDB' when mongodbDatabases is populated.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

…e connectivity

The private DNS zone for the Cosmos DB MongoDB API private endpoint was
named 'privatelink.mongo.cosmos.azure.net' - wrong TLD, likely a copy/paste
mix-up with the Key Vault zone (privatelink.vaultcore.azure.net). The
canonical zone name, per the public DNS CNAME chain
(*.mongo.cosmos.azure.com -> *.privatelink.mongo.cosmos.azure.com), is
'privatelink.mongo.cosmos.azure.com' (.com).

With the wrong zone name, pods resolved the Cosmos Mongo hostname to its
public IP (no matching records in the misnamed zone), and Cosmos's
firewall rejected the connection since publicNetworkAccess is Disabled -
MongoServerSelectionError connecting to the public IP on port 10255.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

…ad identity

The shared workload identity only had Key Vault Secrets User (read-only),
which is correct for the Helm chart's Secrets Store CSI mounts but blocks
the Token Manager service (apps/token-manager), which writes BYO
credentials (GitHub/Anthropic API keys, etc.) into the vault at runtime via
SecretClient.setSecret() using this same shared identity. Read-only access
403s that write path, leaving the portal's built-in credential
registration UI (POST/DELETE /api/v1/keys) non-functional out of the box
on a freshly provisioned environment.

Key Vault Secrets Officer is a superset of Secrets User (adds set/delete
alongside get/list on secrets, still scoped to secrets only - no key/cert
or permission-management access), so this replaces rather than stacks
alongside the previous role assignment.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

… Data Owner

Storage Blob Data Contributor's data actions do not include
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write,
so the app's practice of setting Blob Index Tags (requestId/runId/iteration)
via the x-ms-tags header on per-iteration workspace snapshot uploads
403s with AuthorizationPermissionMismatch under Contributor alone.
100% reproducible, confirmed via raw PUT with/without x-ms-tags using a
storage-scoped AAD token exchanged from the workload identity's federated
token.

Storage Blob Data Owner includes the tags/write data action alongside
everything Contributor already grants, so this keeps tagged snapshot
uploads working without the app needing to drop tags.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

…ed Redis

Classic Azure Cache for Redis (Microsoft.Cache/redis) is being retired for
new deployments, causing DeploymentFailed errors on the redis sub-deployment
("Azure Cache for Redis is retiring, create Azure Managed Redis instance
instead").

Rewrote redis.bicep to use the AVM module avm/res/cache/redis-enterprise:0.5.0
(Microsoft.Cache/redisEnterprise), targeting the "Balanced" Azure Managed
Redis SKU tier:

- Replaced the Basic/Standard/Premium skuName + C/P skuFamily + integer
  skuCapacity parameter trio with a single skuName enum of AMR SKU strings
  (Balanced_B0/B1/B3/B5/B10; capacity is now encoded in the SKU name itself).
  Default is Balanced_B1.
- Private endpoint service/groupId changed from redisCache to redisEnterprise;
  private DNS zone changed from privatelink.redis.cache.windows.net to
  privatelink.redisenterprise.cache.azure.net.
- Entra ID (Azure AD) data-plane auth is now granted via an access policy
  assignment on the database submodule (accessPolicyAssignments), replacing
  the classic module's redisConfiguration 'aad-enabled' flag. The shared
  workload identity's principal ID is threaded through from main.bicep (same
  pattern already used for storage.bicep).
- Access-key auth (accessKeysAuthentication: 'Enabled') is kept as a
  compatibility fallback; the primary access key is still surfaced as a
  @secure() output and written to the redis-primary-key Key Vault secret, now
  sourced directly from the AVM module's own output instead of a manual
  listKeys() call — the AMR database submodule's output is correctly ordered,
  so the existing-resource + explicit dependsOn workaround from the prior
  dependsOn fix is no longer needed.
- Updated main.bicep (params, redisName max length 63->60 per
  Microsoft.Cache/redisEnterprise naming rules, module wiring, outputs),
  main.parameters.json, createUiDefinition.json (single SKU dropdown, capacity
  slider removed), metadata.json, and README.md to match.

Verified with `az bicep build` on the module and full orchestrator (clean,
zero errors/warnings), `az bicep lint`, and a rebuild-and-diff drift check
against the committed azuredeploy.json (no drift).

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

Live deployment hit:

  Unable to process template language expressions for resource
  '.../redis-apa-0'... 'The language expression property name doesnt
  exist, available properties are userObjectId.' (Code: InvalidTemplate)

Root cause: the AVM redis-enterprise module's nested access-policy-assignment
deployment reads parameters('accessPolicyAssignments')[i].name directly
(not via tryGet), even though name is documented as optional/nullable on
accessPolicyAssignmentType. ARM strips omitted optional properties from the
JSON object entirely (there is no null placeholder), so direct property
access on a missing key throws InvalidTemplate. Our accessPolicyAssignments
array item only set userObjectId, omitting name as the (incorrect) docs
imply is fine.

Fix: explicitly set name: 'workload-identity-access' on the access policy
assignment entry in redis.bicep's database block, working around the
module's property-access bug.

Verified with az bicep build (module + full orchestrator, clean), az bicep
lint (clean), and a rebuild-and-diff drift check against the committed
azuredeploy.json (no drift) - confirmed the compiled ARM template now
includes the explicit name property on the access policy assignment.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

…t isolation

ACP worker pods execute benchmark-controlled/untrusted agent code in the same
container as the workload identity used for Azure resource access. The
previously single shared identity had Key Vault Secrets Officer (write access),
meaning a compromised worker process could read or tamper with Key Vault
secrets it has no legitimate need to touch.

Fix: split into two user-assigned managed identities, each with its own
federated credential and Kubernetes service account subject:

- Backend identity (scope-workload-identity, unchanged name/behavior): Key
  Vault Secrets Officer, Redis Entra ID access, Storage Blob/Queue data-plane
  access. Used by trusted components (api, Token Manager, scheduler, etc.).
- Worker identity (scope-worker-workload-identity, new): Storage Blob/Queue
  data-plane access ONLY - no Key Vault role, never wired into keyvault.bicep.

storage.bicep now accepts a second optional principal ID
(workerWorkloadIdentityPrincipalId) and grants the same Storage Blob Data
Owner + Storage Queue Data Contributor roles to both identities that are
non-empty.

New outputs: workerWorkloadIdentityClientId,
workerWorkloadIdentityServiceAccountNamespace,
workerWorkloadIdentityServiceAccountName - for the Helm chart to annotate the
worker pods Kubernetes service account.

New params (with defaults, exposed in createUiDefinition.json and
main.parameters.json): workerWorkloadIdentityServiceAccountNamespace,
workerWorkloadIdentityServiceAccountName.

Verified: az bicep build (clean), az bicep lint (clean), rebuild-and-diff
against committed azuredeploy.json (no drift).

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

…Key Vault isolation"

This reverts commit a28ed98.

Avoids naming collisions when multiple people deploy the template into
the same tenant/subscription concurrently, similar to how the Azure
portal suggests a randomized default resource group name. Uses
createUiDefinition's client-side guid()/substring() functions; actual
resource names still get their own uniqueString()-based suffix in
main.bicep regardless of what's typed here.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

The button link only included the template uri (azuredeploy.json),
so the portal's Custom Deployment screen used the raw ARM template
parameter form instead of the curated createUiDefinition.json UI —
explaining why the prepopulated Environment name field (and the
Basics/Advanced grouping) wasn't showing up when testing the link.

Adds the required /createUIDefinitionUri/<encoded-uri> segment
pointing at createUiDefinition.json alongside the existing
/uri/<encoded-uri> template segment, in both README.md and
deploy/azure/README.md.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

outputs was a top-level sibling of parameters instead of nested inside
it (parameters.outputs), which is invalid per the classic
CreateUiDefinition (Microsoft.Azure.CreateUIDef / 0.1.2-preview)
schema. The Azure portal's Custom deployment page failed to parse it
as the classic schema, silently fell back to trying the newer Form
view (uiFormDefinition) schema instead, and surfaced that fallback
parser's error: 'The provided uiFormDefinition does not have a
parameters property under $.view.outputs.'

No content changes — basics, steps, and all 19 output mappings are
unchanged, just correctly nested. Re-validated as valid JSON and
cross-checked output keys against main.bicep's parameter names.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

Restores README.md, deploy/azure/README.md, and
deploy/azure/createUiDefinition.json to their exact content as of
1cd20c1, undoing d6a9dc7 (env-name random suffix),
e8d216b (wiring createUIDefinitionUri into the button link),
fe87207 (outputs-nesting fix), and f846714 (partial manual revert).

The createUIDefinitionUri change kept surfacing portal errors
('uiFormDefinition does not have a parameters property under
$.view.outputs') that didn't clear even after the underlying
createUiDefinition.json structure was fixed, likely compounded by
raw.githubusercontent.com CDN caching. Reverting to the plain
Microsoft.Template/uri/<azuredeploy.json> button link (no custom UI)
restores the last confirmed-working deploy experience. The portal
falls back to its default ARM-parameter form, which is less polished
but functional; revisiting the custom createUiDefinition.json UI is
left for a future iteration.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

…lity

The AVM managed-cluster module defaults every agent pool's
availabilityZones to [1,2,3] when not explicitly set. Not all regions
support AKS availability zones (e.g. centralus), so deployments there
failed preflight validation with:

  AvailabilityZoneNotSupported: The zone(s) '1' for resource 'system'
  is not supported. The supported zones for location 'centralus' are ''.

Both the system and user node pools now explicitly request an empty
availabilityZones array, trading zone-redundant HA (already not
guaranteed with the 1-node-per-pool quota-friendly defaults) for
working deployments in any region. Set availabilityZones explicitly
per node pool for a production environment in a region that supports
them.

Verified: az bicep build clean, az bicep lint clean, rebuild-and-diff
shows no drift in azuredeploy.json, and confirmed both agent pool
profiles compile to "availabilityZones": [] in the ARM template.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

Standard_B2ms (classic B-series) is not an allowed VM size in every
subscription - a live deployment failed preflight validation with:

  The VM size of Standard_B2ms is not allowed in your subscription in
  location 'centralus'.

Standard_D2s_v5 (general-purpose, non-burstable) has the same 2 vCPU /
8 GiB memory profile as the previous default, is on this subscription's
allowed-SKU list, and is a far more broadly available family across
subscriptions/regions than burstable B-series sizes (some subscriptions
only allow the newer "_v2" B-series, not classic B2ms, so guessing
another B-series variant risks the same failure mode elsewhere).

Updated: aks.bicep/main.bicep param defaults + comments,
main.parameters.json, createUiDefinition.json tooltips/recommendedSizes,
and deploy/azure/README.md sizing guidance.

Verified: az bicep build + lint clean, zero drift in azuredeploy.json,
all JSON files parse, no remaining Standard_B2ms default references.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

Live-tested by the Helm-deploy session: with 1 System + 1 User node (both
Standard_D2s_v5, 2 vCPU), the core app alone (api/portal/judge/
token-manager/scheduler/report-generator) already consumes ~85% of the
User node's allocatable CPU. An optional Phase 3 ACP worker pod
(coder-acp-copilot: 500m main + 250m MCP-gateway sidecar = 750m) then
fails to schedule with 'Insufficient cpu' on both nodes.

Bumping aksUserNodeCount default to 2 (same Standard_D2s_v5 size, no
pool recreation needed) resolves it - confirmed live by scaling the
user pool to 2 nodes, after which the worker pod scheduled and came up
2/2 Running. Total default footprint is now 3 nodes / 6 vCPUs, still
comfortably inside the common 10-vCPU regional quota.

Users running only the core app (no ACP workers) can still set
aksUserNodeCount=1.

Updated: aks.bicep/main.bicep param defaults + comments,
main.parameters.json, createUiDefinition.json slider default/tooltip,
and deploy/azure/README.md sizing guidance.

Verified: az bicep build + lint clean, zero drift in azuredeploy.json
(only the intended defaultValue/description diffs + template hashes),
all JSON files parse.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72

A coworker's live deployment failed with:

  ServiceUnavailable: Sorry, we are currently experiencing high demand
  in Central US region for the zonal redundant (Availability Zones)
  accounts, and cannot fulfill your request at this time.

Root cause: cosmosdb.bicep didn't pass a 'locations' param to the AVM
document-db/database-account module, so its internal fallback
(defaultFailoverLocation) applied - which hardcodes isZoneRedundant:
true. This silently requested a zone-redundant Cosmos DB account,
which some regions (e.g. centralus) intermittently lack capacity for,
independent of subscription quota.

Fix: explicitly pass a single-region 'locations' entry with
isZoneRedundant: false, opting out of zone redundancy by default -
same rationale/pattern as the earlier AKS availabilityZones: [] fix.

Also documented in README.md that the companion Redis
'ComputeProvisioningFailed' error reported alongside this is an
unrelated, separate transient Azure capacity issue: confirmed via the
compiled AVM template that 'zones' only ever applies to
Enterprise/EnterpriseFlash Redis SKUs, not the Balanced/AMR tier this
template uses, so it is not caused by anything in this template.

Verified: az bicep build + lint clean, zero drift in azuredeploy.json
beyond the intended locations/isZoneRedundant diff and template
hashes, confirmed isZoneRedundant: false compiles into the output.

Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 2250d38f-729e-4dd7-b6e1-41b525e44a72