fix(operate): correct ACA operations content (fixes for #1637)

[Simon J (simonjj)]

Summary

Fixes technical errors in the ACA Operate reference files from #1637, validated against official Microsoft ACA documentation.

Changes

day2-operations.md:

• Replace non-existent \�z containerapp stop/start\ CLI commands with \�z containerapp update --min-replicas 0\
• Remove plaintext password placeholder, add secret exposure warning

networking.md:

• Subnet size: /27\ for workload profiles (default), /23\ for legacy consumption-only
• IP restrictions: remove invalid Allow+Deny mix (official docs: cannot combine rule types)
• Internal ingress: corrected visibility description

revisions.md:

• Bicep: use \latestRevision: true\ instead of non-existent revision names at deploy time
• Blue/green: query actual revision name from
  evision list\
• Rollback: use label-based routing or explicit revision name

Validation

• All fixes verified against official docs at \MicrosoftDocs/azure-docs/articles/container-apps/\
• \�zure-prepare\ tests: 46/46 passed
• Token budget: all files under 2000 limit

Builds on #1637.

[Simon J (simonjj)]

Closing — will push fixes directly to #1637's branch instead.

[Copilot]

Pull request overview

This PR updates the Azure Container Apps “Operate” reference documentation under plugin/skills/azure-prepare to correct operational, networking, and revision-management guidance (intended to address inaccuracies noted in #1637).

Changes:

• Add/update guidance for revision management (traffic splitting, blue/green, rollback) including Bicep + CLI examples.
• Add/update guidance for networking (ingress modes, VNet integration, subnet sizing, IP restrictions, custom domains).
• Add/update guidance for day-2 operations (restart/exec/logs, env var updates, secret management/rotation).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
plugin/skills/azure-prepare/references/services/container-apps/revisions.md	Revision mode + traffic management patterns (blue/green, canary, labels, rollback) with CLI/Bicep examples.
plugin/skills/azure-prepare/references/services/container-apps/networking.md	Ingress/VNet/custom domain/TLS/IP restriction guidance and example Bicep snippets.
plugin/skills/azure-prepare/references/services/container-apps/day2-operations.md	Operational runbook-style commands and cautions (including secret exposure warnings).

[Copilot]

The JMESPath query --query "[0].name" assumes the first item returned by az containerapp revision list is the newest revision, but the CLI output order isn’t guaranteed. This can cause blue/green to switch traffic to the wrong revision. Consider sorting by created time (or filtering by the revision you just created, e.g., via a known --revision-suffix) before selecting the revision name.

Suggested change

	# Get the new revision name
	NEW_REV=$(az containerapp revision list -n $APP -g $RG --query "[0].name" -o tsv)
	# Get the newest revision name
	NEW_REV=$(az containerapp revision list -n $APP -g $RG --query "sort_by(@, &properties.createdTime)[-1].name" -o tsv)

[Copilot]

The canary example uses revision names like $APP--stable/$APP--canary, but revision names are typically auto-generated unless a --revision-suffix was set when creating them. As written, these commands will often fail. Prefer showing canary traffic split using actual revision names retrieved from az containerapp revision list (or demonstrate creating revisions with explicit --revision-suffix values first).

[Copilot]

The label assignment examples reference revisions $APP--v1/$APP--v2, which also won’t exist unless the revisions were created with those suffixes. To make this runnable, either show how to set --revision-suffix v1/v2 when deploying the revisions, or demonstrate selecting revision names from az containerapp revision list before labeling.

Suggested change

	# Assign labels
	az containerapp revision label add -n $APP -g $RG \
	--label stable --revision "$APP--v1"
	az containerapp revision label add -n $APP -g $RG \
	--label canary --revision "$APP--v2"
	# Get the two most recent revision names
	STABLE_REV=$(az containerapp revision list -n $APP -g $RG --query "[0].name" -o tsv)
	CANARY_REV=$(az containerapp revision list -n $APP -g $RG --query "[1].name" -o tsv)
	# Assign labels
	az containerapp revision label add -n $APP -g $RG \
	--label stable --revision "$STABLE_REV"
	az containerapp revision label add -n $APP -g $RG \
	--label canary --revision "$CANARY_REV"

[Copilot]

The “Resume (restore scaling)” command hard-codes --min-replicas 1 --max-replicas 10, which likely won’t restore the app’s prior scaling configuration and could unintentionally under/over-provision. Consider using placeholders (e.g., $MIN_REPLICAS/$MAX_REPLICAS) and/or instructing readers to capture current values before scaling to zero and then restore those specific values.

Suggested change

	| Resume (restore scaling) | `az containerapp update -n $APP -g $RG --min-replicas 1 --max-replicas 10` |
	| List replicas | `az containerapp replica list -n $APP -g $RG --revision $REV` |
	| Resume (restore scaling) | `az containerapp update -n $APP -g $RG --min-replicas $MIN_REPLICAS --max-replicas $MAX_REPLICAS` |
	| List replicas | `az containerapp replica list -n $APP -g $RG --revision $REV` |
	> 💡 **Tip:** Before scaling to zero, record the app's current `minReplicas` and `maxReplicas` values and set `$MIN_REPLICAS` / `$MAX_REPLICAS` to those values when resuming.