Skip to content

Azure portal walkthrough

New to Azure or to the SRE Agent? This page is your complete, click-by-click reference for every action the challenges ask you to perform. Each challenge links back to the exact procedures below, so you never have to guess where a button is.

Portal UI may vary

Azure portal labels and blades occasionally move. When a screen differs from a step here, follow the matching step in the linked official doc. The flow is the same. Keep the Azure portal open in one tab and this page in another.

Everything in this hack uses the same defaults:

Setting Value
Resource group rg-aetherion-microhack-<suffix> (your unique name)
Region swedencentral
AKS cluster aetherion-aks (namespace aetherion)
SRE Agent aetherion-sre-agent

Your resource group name is unique

Provisioning always creates rg-aetherion-microhack-<suffix> (for example rg-aetherion-microhack-a7c3) and prints the exact name at the end. Wherever this guide says the resource group, use your suffixed name.

A · Sign in to the Azure portal

  1. Open https://portal.azure.com and sign in with the account that owns the subscription you provisioned.
  2. Confirm the correct directory/subscription: select your avatar (top-right) → Switch directory if you have more than one.
  3. In the top search bar, type your resource group name (rg-aetherion-microhack-<suffix>) and open it. Pin it (the star icon) so it's one click away all day.

B · Open the Operations Center

The Operations Center is the live health board you use to detect and verify every incident.

  1. The provisioning script opened it automatically. If you lost the tab, get the URL again by running in your terminal: 
    $st = Get-Content ./scripts/.env.aetherion.json | ConvertFrom-Json
if ($st.httpsUrl) { $st.httpsUrl } else { "http://$($st.gatewayIp)/" }
  2. Open that URL (HTTPS if configured). Let the page settle. The flight board, service tiles and operational-risk gauge should all render.
  3. Healthy reference: every service tile is green and the risk gauge is low. This is what you compare against when something breaks.

C · Open Grafana and sign in

  1. In the portal search bar, type Grafana and open Azure Managed Grafana → the aetherion workspace → Endpoint URL.
  2. Sign in with your Azure account (single sign-on). If prompted for access, you need at least Grafana Viewer on the workspace.
  3. Open the Aetherion dashboard. Confirm data is flowing in two panels: AKS (pods / CPU) and Application Insights (requests / latency).

D · Create the SRE Agent

Do this once, in Challenge 1. Creating the agent and setting it up are two separate steps. Create alone grants no access to your app.

  1. In the portal search bar, type Azure SRE Agent and select it.
  2. Select Create.
  3. On Basics, set:
    • Subscription: your subscription.
    • Resource group: your provisioned group (rg-aetherion-microhack-<suffix>).
    • Name: aetherion-sre-agent.
    • Region: the closest supported region (e.g. swedencentral).
    • Application Insights: choose Create new. The agent provisions its own App Insights + Log Analytics for its own telemetry. This is separate from the app's aetherion-law / aetherion-appi.
    • Model provider: Azure OpenAI is a good default (lower cost, stays in the EU data boundary).
  4. Leave the default managed identity option so the agent gets its own identity.
  5. Select Review + create → Create and wait for deployment to finish.
  6. Open the resource and confirm the chat/console loads.

Reference: Create and set up · Complete your setup

D2 · Set up your agent: connect context

In the agent, run Set up your agent (Full setup) and connect three sources:

  1. Code → GitHub → sign in → add your copy of aetherion-airops-platform (used for change correlation in Challenge 3).
  2. Logs → Log Analytics Workspace → pick the app's aetherion-law (not the agent's own auto-created workspace).
  3. Azure resources → set the scope to Resource group, select only your app resource group, and pick the Reader permission level.

Scope the agent to the app resource group only

Do not choose Subscription or Management group scope. Resource-group scope keeps the agent focused on just this application.

Knowledge is connected later, in Challenge 4, not here.

E · Give the agent read-only (Reader) access

The Set up your agent wizard (section D2) already grants this. Do it manually here only if you skipped the wizard's Azure resources step. Reader lets the agent see the resource group; in Review mode it still asks before any change.

  1. Open your resource group (rg-aetherion-microhack-<suffix>) → Access control (IAM).
  2. Select Add → Add role assignment.
  3. Role: search and pick Reader.
  4. Members: choose Managed identity → select the aetherion-sre-agent identity.
  5. Select Review + assign.
  6. Back in the agent, ask it to "list the resources in the resource group and summarise the application" to confirm scope.

Permissions vs. run mode

Creating and setting up the agent grants its identity Monitoring Contributor plus a reader bundle, so the identity is not strictly read-only. The guarantee that it won't change anything without you comes from the Review run mode (section F), not from the role.

Reference: Manage roles and permissions

F · Set the run mode (Review vs Autonomous)

  1. Open the aetherion-sre-agent resource → Settings (or the run-mode control in the agent console).
  2. Review (default): the agent proposes a plan and waits for your approval before any write. Use this for Acts I-III.
  3. Autonomous: the agent executes approved classes of action without pausing. Only switch a specific, validated fault to Autonomous (Challenge 6).
  4. Changing run mode is approved by the SRE Agent Administrator role.

G · Ask the agent / start a thread

  1. Open the agent resource → the chat/console.
  2. Type a specific question, for example "Give an operational baseline for the aetherion namespace: services, ready replicas, dependencies, and check-in latency."
  3. When the agent proposes a write in Review mode, it shows a plan with an Approve / Reject prompt. Read the plan, because that plan is your approval artifact, then decide.

H · Approve a write, or grant a narrow write role

When a fix needs a change, you have two governed paths.

  1. Ask the agent for a remediation plan, and read it.
  2. A plan on its own queues nothing. Tell the agent to apply it — the approval card appears when it attempts the write, not when it finishes thinking.
  3. Read the exact command on the card, then select Approve action.

The card states "Agent permissions will be used to complete this action." The write runs as the agent's own managed identity, so the change is attributed in the Activity Log to the agent rather than to you. Your approval is recorded in the thread, not on the resource.

Best when you want a human decision on each change.

  1. Decide the narrowest role that covers the action (e.g. a write role on the AKS cluster only, not the whole subscription).
  2. Open the target resource → Access control (IAM) → Add role assignment → pick the role → Managed identity → aetherion-sre-agent → Review + assign.
  3. Best when the agent needs to reach something it currently cannot, rather than when you want a decision point.

On-behalf-of (OBO)

The docs describe an OBO path where an action runs using your credentials. It is not available in this environment — attempts return "OBO flow is not supported with CliInAdc enabled". Everything the agent does here runs as its own identity, which is why scoping that identity matters.

Reference: Security overview

I · Load the knowledge base (ground the agent)

  1. In the agent, open Builder → Knowledge Sources.
  2. Upload the Markdown files from your lab clone's knowledge/ folder. The application repo does not contain them.
  3. Check every file reaches Indexed. Bulk upload can partially fail.
  4. Re-ask your remediation question. The advice should now cite Aetherion's own runbook guardrails instead of generic steps.

Reference: Team onboarding & memory

J · Create a specialist subagent

  1. In the agent, open Builder → Agent Canvas, then click + Create subagent.
  2. Custom agent name: aks-triage.
  3. Instructions: a narrow remit, "AKS reliability triage for the aetherion namespace: pod status, events, rollout history, dependency health." Say how it should behave and what it should do when the evidence points outside its scope, not just what it covers.
  4. Scope the Tools panel deliberately. Left alone the subagent inherits all 46 tools, which makes it a persona rather than a specialist. Selecting tools replaces the inherited set instead of adding to it, so your list has to be complete, not a highlight reel. Challenge 5 gives the exact eight tools and the reason for each. Instructions are advisory; the tool list is what is actually enforced.
  5. Leave Skills inherited while you build. Who owns which skill is a deliberate decision you make in Challenge 5, Task 3.
  6. Create, then use it by asking the main agent to delegate to it by name ("delegate this to your aks-triage subagent"). Asking the agent to "act as" a specialist does not invoke the subagent. It just adopts the persona.

The Form / YAML toggle edits the same definition and exposes handoff_description, agent_type and enable_skills.

Reference: Subagents & extensibility

K · Create a reusable skill

  1. Same place: Builder → Agent Canvas → + Create skill (or Builder → Skill Builder).
  2. Name it, then click Edit on Description and describe when the skill should be reached for. The description is what the agent matches the situation against, so a vague one means the skill is never considered. Do not assume a skill fires on its own. Name it when you want it used.
  3. In the pre-scaffolded SKILL.md, fill in the name / description frontmatter and encode a well-defined procedure (e.g. the crew query-path recovery) as steps, keeping the guardrails (confirm which layer is saturated, repair the query path, never delete the database).
  4. Create.

Reference: Skills

L · Review agent consumption (AAUs)

  1. In the agent, open Settings → Agent Consumption.
  2. Break usage down by thread type (Chats, Incidents, Scheduled tasks, Triggers) and by thread, to see where Azure Agent Units (AAUs) go.
  3. Use only real figures from your environment or the official pricing & billing doc. Never invent rates or savings.

M · Inspect AKS (pods, events, rollout)

You can let the agent do this, or check directly:

  • In the portal: resource group → aetherion-aks → Workloads → select a deployment (e.g. flight-ops) → Pods and Events.
  • In your terminal (read-only): 
    kubectl get pods -n aetherion
kubectl describe deploy flight-ops -n aetherion
kubectl rollout history deploy/flight-ops -n aetherion

N · Correlate a change with rollout history & the Activity Log

  1. For workload changes, start with the cluster's own change record: 
    kubectl rollout history deploy/<service> -n aetherion
    Each revision carries the change cause recorded with it.
  2. For Azure-resource changes (for example an API Management policy), open the resource or resource group → Activity log and filter by the time the tile went red.
  3. Note the gap: changes applied straight to the cluster never appear in the Activity Log, which is exactly why teams route changes through a pipeline. Proximity in time is your strongest lead for a change-induced outage.

O · Compare direct-vs-APIM (front-door problems)

When clients fail but the backend looks healthy, the problem is at the front door:

# Load env once
$st = Get-Content ./scripts/.env.aetherion.json | ConvertFrom-Json

# Through the API front door (APIM)
Invoke-WebRequest "$($st.apimGatewayUrl)/aetherion/api/status" `
  -Headers @{ 'Ocp-Apim-Subscription-Key' = $st.apimSubscriptionKey } -UseBasicParsing

# Direct to the service (bypasses APIM). If this is 200, the service is fine
Invoke-WebRequest "http://$($st.gatewayIp)/api/status" -UseBasicParsing

If direct returns 200 but APIM fails, the fault is an API Management policy, not the service.

Return to any challenge. Each one tells you exactly which of these procedures to run, in order.