version: "1.0.0" name: deploying-demo description: Deploy the SRE Agent demo end-to-end. Use when asked to set up, deploy, or get this demo running.

Deploying the Demo

Prerequisites Check

Run these and install anything missing:

• az version — need 2.60+
• azd version — need 1.9+
• pwsh -v — need 7.4+
• Azure permission: Owner, User Access Administrator, or equivalent

Microsoft.Authorization/roleAssignments/write at subscription scope. The template grants the agent runtime identity subscription Reader for correlation context and removes it during azd down.

• The responsible owner and expiry date, using the tag keys required by the

target subscription. If deployment policy does not apply them, tag the resource group immediately after azd up.

Note: kubectl is not required on your local workstation. The cluster is private. Operator

scripts in this repo go through az aks command invoke (wrapped by scripts/_aks-helpers.ps1).

The SRE Agent uses its built-in RunKubectlReadCommand and RunKubectlWriteCommand tools instead.

Phase 1: Azure Deployment

1. Check if user has a subscription: az account show
2. Set azd environment: azd env set AZURE_SUBSCRIPTION_ID <sub-id> and azd env set AZURE_LOCATION swedencentral
3. Run azd up --no-prompt
4. Wait for completion (~25 min). Monitor progress. The post-provision hook

handles image build, k8s manifest apply (via command invoke), workload identity federation, and SRE Agent data-plane sync.

Phase 2: Verify Deployment

The AKS API server is private (enablePrivateCluster: true) — local kubectl will not work. Human operators use the Azure-proxied command-invoke path:

. .\scripts\_aks-helpers.ps1
$ctx = Resolve-AksContext
$r = Invoke-AksCommand -ResourceGroup $ctx.ResourceGroup -ClusterName $ctx.ClusterName `
    -Command "kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}'" -Quiet
$ip = ($r.logs -replace '[^\d\.]','').Trim()
"Storefront: http://$ip"

1. Open http://<ip>/ in a browser — verify products load, status shows healthy.
2. Hit the health endpoint from your local workstation: Invoke-RestMethod "http://<ip>/api/health"

(the storefront LoadBalancer IP is public; only the cluster API server is private).

1. If the LB IP is not reachable from your machine (corporate VPN, etc.), verify

from inside the cluster instead: ``powershell Invoke-AksCommand -ResourceGroup $ctx.ResourceGroup -ClusterName $ctx.ClusterName -Command "kubectl exec -n zava-demo deploy/zava-api -- wget -qO- http://localhost:3001/api/health" ```

For SRE Agent operations, use the built-in RunKubectlReadCommand and

RunKubectlWriteCommand tools. See docs/aks-access-and-auth.md for other

operator and automation access options.

Phase 3: Configure + verify SRE Agent

Bicep provisions the agent, identity, networking, autonomous mode, and Azure Monitor binding. The setup script waits for the authenticated configuration API, then applies the separate connector Bicep template. It applies custom skills and response plans from the repository, uploads knowledge files, syncs global instructions, enables the Microsoft Learn tools, and verifies the result.

azd up runs setup-sre-agent.ps1 through the post-provision hook. Run it manually only to retry or apply later configuration changes:

1. If azd outputs are complete, run .\scripts\setup-sre-agent.ps1.
2. For standalone recovery after partial provisioning, pass the values

explicitly: ``powershell .\scripts\setup-sre-agent.ps1 -ResourceGroup <resource-group> -AgentName <sre-agent-name> -PostgresHost <server>.postgres.database.azure.com -PostgresDatabase zava_store -SreAgentClientId <attached-umi-client-id> -SreAgentPrincipalName <attached-umi-resource-name> ` PostgresHost` must be the Flexible Server FQDN. The principal name must be the resource name of the same attached/action UMI selected by the client ID. Never substitute the SRE Agent resource name while using the UMI client ID.

1. For missing connectors, skills, or response plans, inspect the reported

failure and rerun setup-sre-agent.ps1. If core agent infrastructure is missing, rerun azd provision. Do not add sleeps to hide readiness failures: -ReadinessTimeoutSeconds and -ConnectorTimeoutSeconds bound the existing readiness/deployment gates. A timed-out connector deployment is canceled on a best-effort basis; inspect its status before retrying.

Post-provision waits for the operator's Kubernetes access before applying manifests and fails if ingress installation, application rollout, or endpoint lookup fails. After correcting a transient failure, retry .\scripts\post-provision.ps1 -SkipImageBuild only if both image builds already succeeded. Do not treat ARM provisioning success as proof that the app is ready.

Optional: confirm the agent is reachable

Sanity-check the agent's data-plane API before running break/fix scenarios:

.\scripts\watch-agent.ps1     # lists incident threads (empty on a fresh deploy is fine)

This is the same script the running-demo skill uses to tail the agent live during scenarios.

Teardown

azd down --force --purge

Run teardown from the same azd environment. Confirm that the resource group is absent and the runtime identity's subscription Reader assignment was removed. If the command fails, inspect the reported AMPLS link or role assignment before retrying. Use a new environment name for the next deployment.