In Part 3, we gave GitHub Copilot a project identity. Custom instructions told it about our Zero Trust rules. Path-specific instructions scoped guidance to the right files. Prompt files turned repetitive tasks into one-click workflows. Custom agents gave it specialized personas with scoped tools.

But all of that is always on. Every Copilot conversation loads the custom instructions, whether you’re asking about networking or asking it to write a commit message. That’s fine when the instructions are small. It becomes a problem when your project grows when you accumulate rules for security reviews, cost analysis, state management, scaling, and image lifecycle. You can’t fit everything into `copilot-instructions.md` without turning it into a sprawling document that confuses the model as much as it helps it.

Skills solve this. They’re the on-demand counterpart to always-on instructions. A skill is a folder with a `SKILL.md` file that Copilot loads *only when your prompt is relevant to it. Ask about drift? The drift detector skill loads. Ask about costs? The cost estimator loads. Ask about a new Container App resource? Copilot uses the base instructions and leaves the cost estimator alone.

This is Part 4, and it’s entirely about skills.

What skills actually are

The mental model is straightforward. Custom instructions are rules you want Copilot to follow always your naming conventions, your provider version, your security posture. Skills are specialized knowledge packages you want available on demand the deep expertise for a specific task that would clutter the always-on context if it were always loaded.

Mechanically, a skill is a directory under `.github/skills/` with a single required file: `SKILL.md`. That file has two parts: a YAML frontmatter block and a Markdown body.

```
.github/
└── skills/
    └── my-skill-name/
        └── SKILL.md
```

The frontmatter defines the skill's identity:

```yaml
---
name: my-skill-name
description: >
  One sentence summary.

  When to use this skill:
  - "trigger phrase 1"
  - "trigger phrase 2"
---
```

The description field is doing a lot of work here. Copilot reads it to decide whether this skill is relevant to your current prompt. The “when to use” section isn’t documentation for humans it’s signal for the model. Write it as a list of phrases someone would actually type when they need this skill. The more specific and realistic, the better the match.

The Markdown body is the skill’s actual content: instructions, workflows, code examples, lookup tables, templates. Whatever Copilot needs to execute the task well.

Skills vs. the other tools in the toolbox

After three parts covering custom instructions, path-specific instructions, prompt files, and agents, it’s worth being precise about where skills fit.

The key distinction from agents: agents are personas you *select*. Skills are knowledge packages that Copilot *discovers*. When you assign an issue to the coding agent with the implementation agent selected, that’s an explicit choice. When you ask “how much does this architecture cost?” and the cost estimator skill loads, that’s automatic.

Building five skills for this project

Let’s build a complete skill library for the Azure Container Apps infrastructure we’ve been assembling across Parts 1, 2, and 3. Each skill addresses a real operational need.

Skill 1 Terraform Drift Detector :

Create `.github/skills/terraform-drift-detector/SKILL.md`:

---
name: terraform-drift-detector
description: >
  Detect, explain, and resolve Terraform state drift in this Azure Container Apps project.

  When to use this skill:
  - "Why does my terraform plan show unexpected changes?"
  - "Something changed in Azure but I didn't touch the Terraform"
  - "Detect drift", "check for drift", "why is plan not clean?"
  - "Azure Portal changes not reflected in state"
  - After manual changes via Azure CLI or Portal that weren't tracked in state
---

# Terraform Drift Detector

You are an expert in Terraform state management for Azure Container Apps infrastructure.
Your job is to detect, explain, and resolve drift between the Terraform state and actual Azure resources.

## What Is Drift

Drift happens when real Azure resources no longer match what Terraform's state file says they should be.
Common causes in this project:
- Manual changes via Azure Portal or CLI (e.g., scaling a Container App by hand)
- Azure auto-healing or auto-upgrading resources (e.g., Container App revision updates)
- Expiry or auto-rotation of identities
- Out-of-band certificate renewals on Application Gateway

## Detection Workflow

1. Read the current state using `#readFile` on `terraform.tfstate`
2. Run `terraform plan -detailed-exitcode`
   - Exit code 0 = no drift
   - Exit code 2 = drift found
3. Categorize each change by severity:
   - `external_enabled` flip on any Container App → 🔴 CRITICAL
   - `admin_enabled` change on ACR → 🔴 CRITICAL
   - Scaling values (min/max replicas) → 🟡 MEDIUM
   - Tag or label drifts → 🟢 LOW

## Reconciliation Rules

- NEVER auto-run `terraform apply` — show the plan first, ask for confirmation
- For CRITICAL: surface clearly, explain what probably happened, recommend remediation steps
- For LOW/MEDIUM: propose `terraform apply -target=<resource>` with the specific address

## Output Format

Present findings as a Drift Report with Critical Changes and Safe-to-Reconcile sections.

Why this skill matters. In a real team, someone will make a manual change in the Azure Portal usually in an incident, under pressure. Terraform will then want to revert it. The worst case is a terraform apply that flips external_enabled from true to false on the frontend, taking it offline. The drift detector loads the right context to catch that before it happens.

Skill 2 ACA Scaling Advisor

Create `.github/skills/aca-scaling-advisor/SKILL.md`:

---
name: aca-scaling-advisor
description: >
  Design, review, and optimize scaling rules for Azure Container Apps in this project.

  When to use this skill:
  - "Add scaling rules to my Container App"
  - "How should I scale the backend API?"
  - "My app is slow under load", "optimize scaling", "autoscale"
  - "Add KEDA scaler", "HTTP scaling", "queue-based scaling"
  - "min_replicas is too high", "I'm paying too much for idle containers"
---

# ACA Scaling Advisor

You are an expert in Azure Container Apps autoscaling using KEDA.
Architecture context: frontend is external-facing via Application Gateway,
backend is internal-only. Both run on Consumption workload profile.

## Key Rules

**Frontend** — safe for `min_replicas = 0`. Application Gateway handles the queue.
Use HTTP scaler with `concurrentRequests = 100`.

**Backend** — keep `min_replicas = 1` unless the frontend uses async calls.
Scale-to-zero on a synchronously-called backend means the frontend sees cold start latency.
Use CPU scaler at 70% utilization.

## HTTP Scaling (Frontend)

\`\`\`hcl
template {
  min_replicas = 0
  max_replicas = 10

  custom_scale_rule {
    name             = "http-scaler"
    custom_rule_type = "http"
    metadata = {
      concurrentRequests = "100"
    }
  }
}
\`\`\`

## CPU Scaling (Backend)

\`\`\`hcl
template {
  min_replicas = 1
  max_replicas = 5

  custom_scale_rule {
    name             = "cpu-scaler"
    custom_rule_type = "cpu"
    metadata = {
      type  = "Utilization"
      value = "70"
    }
  }
}
\`\`\`

Always validate: no conflicting scale rules, `max_replicas` fits your cost ceiling,
and `min_replicas ≥ 1` on synchronously-called services.

The scaling advisor encodes the architectural constraints of this specific project. A generic Copilot response might suggest min_replicas = 0 on the backend because it reduces costs. That’s correct in isolation. It’s wrong here because the frontend calls the backend synchronously a cold start becomes frontend latency. The skill carries that context.

Skill 3 Azure Cost Estimator

Create .github/skills/azure-cost-estimator/SKILL.md:

---
name: azure-cost-estimator
description: >
  Estimate and break down monthly Azure costs for this Container Apps infrastructure.

  When to use this skill:
  - "How much does this architecture cost?"
  - "Estimate my Azure bill", "cost breakdown", "cost estimate"
  - "Is the Application Gateway expensive?"
  - "I want to reduce costs", "cheapest way to run this"
  - "What's the difference in cost between Consumption and Dedicated?"
  - Before adding new resources — estimate the cost impact first
---

# Azure Cost Estimator

Pricing reference for West Europe (adjust by ~10-20% for other regions):

| Resource | Config | Est. Monthly Cost |
|---|---|---|
| Application Gateway | Standard_v2 | ~$185 |
| Container Registry | Standard SKU | ~$20 |
| Container Apps (per app) | 0.25 vCPU, 0.5GiB, 8h/day | ~$15 |
| Public IP | Standard | ~$4 |
| Private DNS Zone | 1 zone | ~$1 |
| Log Analytics | <5GB/day ingestion | ~$0 |

**Important:** Application Gateway accounts for ~75% of the bill at this scale.
It costs ~$185/month regardless of traffic volume.

When asked for an estimate:
1. Read `.tf` files to identify all provisioned resources
2. Ask for region if not West Europe
3. Present the cost table with actual resource configs from Terraform
4. Highlight the biggest cost driver
5. Suggest one or two project-specific optimizations
6. Always point to the Azure Pricing Calculator for accurate quotes

Every project eventually hits the “what’s this costing us?” question. Without the skill, Copilot would give a generic answer that doesn’t account for the Application Gateway’s flat cost, the specific SKUs we chose, or the Consumption billing model. The skill bakes those numbers in.

Skill 4 Security Posture Reviewer

Create .github/skills/security-posture-reviewer/SKILL.md:

---
name: security-posture-reviewer
description: >
  Review the Zero Trust security posture of this Azure Container Apps Terraform project.

  When to use this skill:
  - "Review my security", "security audit", "security check"
  - "Is this Zero Trust?", "what are my security gaps?"
  - "Check my NSG rules", "are my secrets safe?"
  - Before a production deployment or architecture review
  - After adding new resources — verify they follow the project's security rules
---

# Security Posture Reviewer

Review the project's Zero Trust compliance against this checklist.
Output ✅ or ❌ for each item after reading the Terraform files.

### Networking
- [ ] `internal_load_balancer_enabled = true` on Container App Environment
- [ ] ACA subnet CIDR is minimum `/23`
- [ ] NSG includes `GatewayManager` and `AzureLoadBalancer` inbound rules on AppGW subnet
- [ ] No `0.0.0.0/0` allow-all inbound rules (except those required by Azure platform)
- [ ] Private DNS zone linked to VNet with `registration_enabled = false`

### Container Apps
- [ ] Backend uses `external_enabled = false` (not just an NSG rule)
- [ ] No plaintext secrets in environment variables

### Container Registry
- [ ] `admin_enabled = false`
- [ ] SKU is Standard or Premium

### Identity and Credentials
- [ ] System-assigned Managed Identity enabled on both Container Apps
- [ ] `AcrPull` role assigned for each Container App's principal_id
- [ ] GitHub Actions uses workload identity federation (not service principal secrets)
- [ ] `terraform.tfstate` is NOT committed to the repository

## Common Gaps to Flag

**State file in repo**  contains resource IDs and output values. Add to `.gitignore` and use Azure Storage backend.

**Missing WAF policy**  Standard_v2 supports WAF but it's not enabled by default. Without it, no OWASP rule set protects the frontend from injection attacks.

**Log Analytics retention at default 30 days**  insufficient for incident response. Set `retention_in_days = 90`.

This skill is the automated version of the senior engineer’s pre-deployment checklist. It doesn’t just know generic security best practices it knows this project’s security model and can check it against the actual Terraform files.

Skill 5 ACR Image Manager

Create .github/skills/acr-image-manager/SKILL.md:

---
name: acr-image-manager
description: >
  Manage container images in Azure Container Registry — tagging strategy, image promotion,
  cleanup, and updating Container App image references in Terraform.

  When to use this skill:
  - "Tag my image for production", "promote image from staging to prod"
  - "Clean up old images in ACR", "delete untagged manifests"
  - "Update the Container App to use image version X"
  - "How should I tag my Docker images?", "image versioning strategy"
  - "Purge images older than 30 days", "reduce ACR storage costs"
---

# ACR Image Manager

ACR was created with `admin_enabled = false`. All operations use RBAC, not admin credentials.
Always authenticate with `az acr login --name <acr_name>` using the user's Azure CLI identity.

## Tagging Strategy

Use semantic versioning with a build reference. Never rely on `latest` alone for production.

\`\`\`
<acr_login_server>/<service>:<semver>-<short_sha>
\`\`\`

Examples:
- `acrab3k2m.azurecr.io/frontend:1.2.0-a3f9c1e`  ← immutable, for rollback
- `acrab3k2m.azurecr.io/frontend:latest`           ← mutable, for convenience

## Image Promotion (Staging → Production)

Use `az acr import` to copy between registries without pulling locally:

\`\`\`bash
az acr import \
  --name <prod_acr_name> \
  --source <staging_acr_login_server>/backend:1.2.0-a3f9c1e \
  --image backend:prod-1.2.0 \
  --registry <staging_acr_resource_id>
\`\`\`

## Updating Container App Image in Terraform

After promoting, update the `image` field in `aca.tf`:

\`\`\`hcl
image = "${azurerm_container_registry.acr.login_server}/backend:1.2.0-a3f9c1e"
\`\`\`

Then run `terraform plan` — only the image tag should change. Azure Container Apps creates a new revision automatically.

## Cleanup

Always dry-run before executing:

\`\`\`bash
az acr run \
  --registry <acr_name> \
  --cmd "acr purge --filter 'backend:.*' --untagged --ago 30d --dry-run" \
  /dev/null
\`\`\`

Remove `--dry-run` once the output looks right.

The image management skill is particularly useful after the GitHub Actions CI/CD pipeline from Part 3 starts pushing images. Without it, Copilot doesn’t know whether to suggest az acr commands, direct Docker commands, or Terraform changes. The skill normalizes that: use RBAC auth, use the ACR import command for promotion, update the specific image field in aca.tf.

How Copilot discovers and loads skills

You don’t invoke skills manually. When you type a prompt in Copilot Chat (or an issue body that gets routed to the coding agent), Copilot reads the description field of every skill in .github/skills/ and decides which ones are relevant. If the match is strong, the SKILL.md content is injected into the context for that conversation.

This means the description field is actually the most important part of the file. Write it as if you’re writing the queries that should trigger it. The more concrete and realistic, the better.

A few things that improve match quality:

Be specific about trigger phrases. “Detect drift”, “check for drift”, and “why is plan not clean?” are all things a real engineer would type. Generic phrases like “help with infrastructure” are too broad — they’d match every skill and load them all.

Include anti-examples if needed. If two skills might get confused (say, cost estimator and scaling advisor both relate to “spending less money”), mention what each one doesn’t cover in the description.

Keep the body focused. A skill loaded into context costs tokens. If the body is bloated with tangential information, the model’s attention dilutes. Each skill should do one thing well.

Your repo structure after Part 4

.github/
├── copilot-instructions.md            # Always-on: naming, provider, Zero Trust rules
├── agents/
│   ├── terraform-aca-implement.agent.md  # Specialist: writes and validates Terraform
│   └── terraform-aca-planning.agent.md   # Specialist: designs changes, creates plans
├── instructions/
│   ├── networking.instructions.md     # File-scoped: vnet.tf, nsg.tf, dns.tf
│   └── containers.instructions.md    # File-scoped: aca.tf, acr.tf
├── prompts/
│   ├── new-container-app.prompt.md   # One-click: scaffold a new Container App
│   └── terraform-review.prompt.md   # One-click: security review checklist
├── skills/
│   ├── terraform-drift-detector/
│   │   └── SKILL.md                 # On-demand: detect and resolve state drift
│   ├── aca-scaling-advisor/
│   │   └── SKILL.md                 # On-demand: design KEDA scaling rules
│   ├── azure-cost-estimator/
│   │   └── SKILL.md                 # On-demand: monthly cost breakdown
│   ├── security-posture-reviewer/
│   │   └── SKILL.md                 # On-demand: Zero Trust compliance check
│   └── acr-image-manager/
│       └── SKILL.md                 # On-demand: image tagging, promotion, cleanup
└── workflows/
    └── terraform.yml                # CI/CD: plan on PR, apply on merge

Each layer serves a different purpose. Always-on instructions keep every AI interaction aligned with your project’s conventions. Path-specific instructions add depth when editing specific file types. Prompt files make repetitive tasks one-click. Agents give you specialized personas. Skills provide deep expertise exactly when and only when you need it.

Where to find more skills

GitHub maintains the github/awesome-copilot repository with 247+ community-contributed skills. For Azure infrastructure work specifically, look at azure-architecture-autopilot (design and deploy Azure resources from natural language) and create-specification (generate structured spec files optimized for AI consumption). These are production-grade starting points — fork them, trim what you don’t need, add your project’s specific context.

One thing worth knowing: skills in awesome-copilot are organized by domain rather than by project. They’re designed to be generally useful, not specifically aware of your infrastructure. The value you get from writing your own is exactly that specificity — the drift detector that knows the difference between a MEDIUM and CRITICAL change for this architecture, the scaling advisor that knows this backend is called synchronously, the cost estimator that already has these SKUs and region prices loaded.

The full picture

Three parts built an infrastructure platform. Part 4 built the AI layer on top of it.

Start with what’s always relevant: custom instructions for project-wide rules that apply to every conversation. Add path-specific instructions for file types that have specialized concerns. Create prompt files for the tasks your team runs repeatedly. Build agents for the workflows that need specialized personas and specific tool access. Then write skills for the deep expertise that’s only needed sometimes state drift, scaling design, cost analysis, security review, image lifecycle.

None of these are about making Copilot smarter in the abstract. They’re about making it useful for your specific project, in the way that a colleague who’s worked on the codebase for six months is useful not because they know more general programming knowledge than a new hire, but because they know what matters here.

This is Part 4 of a series on building production-ready microservices on Azure Container Apps with Terraform and GitHub Copilot. Part1 covers the secure networking baseline. Part 2 covers ACR, internal backend, and frontend-backend wiring. Part 3 covers AI-assisted automation, Managed Identities, and CI/CD.

Most infrastructure tutorials end where Part 2 left off  you have working Terraform, a microservices architecture, and a mental model of how the pieces fit together. Then reality hits. Someone on the team pushes a Terraform change without running `terraform validate`. A new engineer copies an old module and hardcodes a subnet CIDR. The backend Container App gets deployed with `external_enabled = true` because someone missed it in review.

Part 3 is about preventing those mistakes before they happen, and automating everything else so you don’t have to think about it.

We’re going to wire up three things that don’t usually appear in the same blog post: GitHub Copilot custom instructions (so AI understands your infrastructure conventions), GitHub Actions pipelines (so deployments are repeatable), and Managed Identities (so there are zero credentials in your codebase). By the end, your repo will be a self-documenting, self-deploying, self-securing system.

Where we left off

Quick recap. In Part 1, we built the networking foundation: a VNet, NSGs, an Application Gateway, and a single frontend Container App behind an internal load balancer. In Part 2, we expanded to microservices: an Azure Container Registry with admin access disabled, an internal-only backend Container App (`external_enabled = false`), and frontend-to-backend wiring through an environment variable.

The architecture works. But it has three gaps that would make any senior engineer uncomfortable in production.

First, the Container Apps are still pulling from Microsoft’s public registry (`mcr.microsoft.com`). Our ACR exists but nothing pushes to it and nothing pulls from it. Second, there are no credentials connecting ACR to the Container Apps  because we disabled admin access (correctly), but haven’t set up the alternative yet. Third, deployments are manual. Every change requires someone to run `terraform plan` and `terraform apply` from their laptop.

Part 3 closes all three gaps.

Teaching your AI pair-programmer to think in Terraform

Before writing a single line of automation code, we’re going to do something that pays compounding dividends: teach GitHub Copilot how your project works.

If you’ve used Copilot in a Terraform project, you’ve probably noticed it generates syntactically correct HCL that’s architecturally wrong. It’ll suggest `admin_enabled = true` on a container registry because that’s what most tutorials do. It’ll hardcode resource group names instead of using references. It’ll create subnets without delegations because it doesn’t know you’re deploying Container Apps.

Custom instructions fix this by giving Copilot persistent context about your project’s rules and conventions.

The main instructions file

Create `.github/copilot-instructions.md` in your repo root. This file is automatically loaded by Copilot Chat in VS Code, Visual Studio, and JetBrains  every time, for every conversation. No slash commands, no manual attachment.

Here’s what ours looks like for this project:

“`markdown

Project Context

This is a 3-part Azure Container Apps infrastructure project using Terraform.

The architecture follows Zero Trust principles with internal-only networking.

Architecture Rules (ALWAYS follow these)

– Container App Environment uses internal load balancer (`internal_load_balancer_enabled = true`)

– Backend Container Apps MUST use `external_enabled = false` in their ingress block

– Only the frontend Container App may use `external_enabled = true`

– All traffic from the internet enters through the Application Gateway  never directly to a Container App

– Azure Container Registry MUST have `admin_enabled = false`  use Managed Identity with AcrPull role instead

– Container images are referenced via `azurerm_container_registry.acr.login_server`  never hardcode registry URLs

Terraform Code Style

– Provider: `azurerm ~> 4.33.0` (do NOT suggest older versions)

– Use resource references (e.g., `azurerm_resource_group.rg.name`)  never hardcode names

– Use `random_string.suffix.result` for globally unique resource names

– Every resource must include `resource_group_name` and `location` from `azurerm_resource_group.rg`

– Avoid deprecated arguments  check the latest azurerm provider docs

– Use `depends_on` only when Terraform cannot infer the dependency graph automatically

Naming Conventions

– Resource groups: `rg-<purpose>`

– VNets: `vnet-<purpose>`

– Subnets: `snet-<purpose>`

– NSGs: `nsg-<purpose>`

– Container Apps: `ca-<service-name>`

– Container App Environment: `cae-<purpose>`

Security Requirements

– No static credentials anywhere in the codebase

– ACR access via Managed Identity only (AcrPull role)

– Secrets go in Azure Key Vault  never in Terraform variables or environment variables

– NSG rules follow least-privilege: allow only the specific ports and CIDRs needed

“`

This file is roughly 40 lines of Markdown. It takes five minutes to write. But now, every time someone on your team asks Copilot to “add a new Container App for the payment service,” the generated code will use internal ingress, reference the existing Container App Environment, follow your naming conventions, and avoid admin credentials.

The key insight here is that custom instructions aren’t about making Copilot smarter  they’re about making it *contextual*. Copilot already knows Terraform syntax. It doesn’t know your project’s rules.

Path-specific instructions for different concerns

The main instructions file covers project-wide rules. But Terraform projects have different zones of concern  networking files need different guidance than application files.

Create `.github/instructions/` and add focused instruction files:

`.github/instructions/networking.instructions.md`:

“`markdown

—

applyTo: “**/vnet.tf,**/nsg.tf,**/dns.tf”

—

When working on networking files:

– Subnets for Container Apps MUST include a delegation block for `Microsoft.App/environments`

– The ACA subnet requires a minimum /23 CIDR range

– NSG rules: always include GatewayManager and AzureLoadBalancer inbound rules on the AppGW subnet

– Private DNS zones must be linked to the VNet with `registration_enabled = false`

“`

`.github/instructions/containers.instructions.md`:

“`markdown

—

applyTo: “**/aca.tf,**/acr.tf”

—

When working on container resources:

– Container Apps use `workload_profile_name = “Consumption”` unless dedicated compute is needed

– Backend services: `external_enabled = false`, `target_port = 80`, `transport = “auto”`

– Frontend services: inject backend URLs via `env` blocks, using the pattern `http://<backend>.ingress[0].fqdn`

– ACR: Standard SKU minimum. Never enable admin access. Future: connect via `registry` block with `identity = “System”`

– Use `min_replicas = 1` for always-on services, `min_replicas = 0` for event-driven scale-to-zero

“`

The `applyTo` glob pattern is the magic  Copilot only loads these instructions when you’re editing files that match. So when you’re in `nsg.tf`, you get networking-specific guidance. When you’re in `aca.tf`, you get container-specific guidance. No noise, no irrelevant suggestions.

Reusable prompt files for common tasks

Your team probably does the same Terraform tasks repeatedly: adding a new Container App, creating a new subnet, writing an output block. Prompt files turn these into one-click workflows.

Create `.github/prompts/` and add prompt files for your most common operations.

`.github/prompts/new-container-app.prompt.md`:

“`markdown

—

description: ‘Scaffold a new Azure Container App following project conventions’

—

Create a new `azurerm_container_app` resource with these requirements:

1. Use the existing Container App Environment: `azurerm_container_app_environment.env`

2. Resource group and location from `azurerm_resource_group.rg`

3. Naming: `ca-<service-name>` (ask me for the service name)

4. Workload profile: Consumption

5. Ingress: ask whether this is a backend (internal) or frontend (external) service

6. If backend: `external_enabled = false`, explain that this is only reachable within the CAE

7. If frontend: add `env` block for BACKEND_API_URL pointing to the backend’s internal FQDN

8. Template: placeholder image from MCR, cpu 0.25, memory 0.5Gi

9. Add a corresponding output for the app’s FQDN in main.tf

Follow the naming conventions and security rules in copilot-instructions.md.

“`

`.github/prompts/terraform-review.prompt.md`:

“`markdown

—

description: ‘Review Terraform code for security and best practice violations’

—

Review the selected Terraform code and check for:

1. Security: Any `admin_enabled = true` on registries? Any `external_enabled = true` on backend services? Any hardcoded credentials or secrets?

2. References: Are all resource names, locations, and resource groups using Terraform references (not hardcoded strings)?

3. Deprecated arguments: Flag any arguments deprecated in azurerm ~> 4.33.0

4.Naming conventions: Do resource names follow the `ca-`, `snet-`, `nsg-`, `rg-` patterns?

5. Dependencies: Are `depends_on` blocks only used where Terraform can’t infer the dependency?

6. Ingress rules: Is every backend Container App using `external_enabled = false`?

Output findings as a checklist with or for each item.

“`

In VS Code, you invoke these by typing `/` in Copilot Chat and selecting the prompt name. The prompt file becomes the instruction, and Copilot executes it in the context of your current workspace. It’s like having a senior engineer’s code review checklist that actually runs itself.

Custom agents: giving Copilot a Terraform specialty

Custom instructions and prompt files make Copilot *aware* of your project. Custom agents take this further  they create specialized personas with specific tools, focused expertise, and scoped permissions. Instead of one generalist Copilot, you can have a Terraform implementation agent, a planning agent, and a security review agent, each with its own toolset and behavioral rules.

What custom agents are

A custom agent is a Markdown file with YAML frontmatter, stored in `.github/agents/`. The frontmatter defines the agent’s name, description, and which tools it can access. The Markdown body contains the agent’s system instructions  its expertise, rules, and workflow. When you select a custom agent in Copilot Chat or assign it to an issue, the coding agent loads these instructions and operates as that specialized persona.

The file format is simple:

“`markdown

—

name: “Agent Name”

description: “What this agent does”

tools: [list, of, tools]

—

Agent Instructions

Your behavioral rules, expertise, and workflow go here.

“`

The `tools` property is the interesting part. You can restrict an agent to read-only tools (for planning and review agents that shouldn’t modify code), or give it full access to edit files, run terminal commands, and fetch documentation. If you omit `tools` entirely, the agent gets access to everything.

Building a Terraform implementation agent for this project

Let’s build a custom agent tailored to our Azure Container Apps infrastructure. Create `.github/agents/terraform-aca-implement.agent.md`:

“`markdown

—

name: “ACA Terraform Implementation”

description: “Creates and reviews Terraform for Azure Container Apps following project conventions, Zero Trust networking, and Managed Identity patterns.”

tools: [execute/getTerminalOutput, execute/runInTerminal, read/readFile, read/terminalLastCommand, edit/createFile, edit/editFiles, search, web/fetch, todo]

—

Azure Container Apps Terraform Implementation Specialist

You are an expert in Azure Container Apps infrastructure using Terraform.

This project follows Zero Trust principles with internal-only networking.

Architecture rules (ALWAYS follow these)

– Container App Environment uses internal load balancer (`internal_load_balancer_enabled = true`)

– Backend Container Apps MUST use `external_enabled = false` in their ingress block

– Only the frontend Container App may use `external_enabled = true`

– All internet traffic enters through the Application Gateway  never directly to a Container App

– Azure Container Registry MUST have `admin_enabled = false`  use Managed Identity with AcrPull role

– Container images are referenced via `azurerm_container_registry.acr.login_server`  never hardcode registry URLs

– No static credentials anywhere  ACR access via system-assigned Managed Identity only

Workflow

1. Review existing `.tf` files using `#search` before making changes

2. Write Terraform configurations using `#editFiles`

3. Break the user’s request into actionable items using `#todos`

4. After creating or editing files, run: `terraform fmt`, `terraform validate`

5. Offer to run `terraform plan`  but NEVER run it without explicit user confirmation

6. Prefer implicit dependencies over explicit `depends_on`

7. Remove dead code: unused variables, locals, and outputs

Naming conventions

– Resource groups: `rg-<purpose>`

– VNets: `vnet-<purpose>`, Subnets: `snet-<purpose>`

– NSGs: `nsg-<purpose>`

– Container Apps: `ca-<service-name>`

– Container App Environment: `cae-<purpose>`

Final checklist

– All resource names follow naming conventions and include appropriate tags

– No secrets or environment-specific values hardcoded

– AcrPull role assignments exist for every Container App with a system-assigned identity

– Backend services use `external_enabled = false`

– Provider version: `azurerm ~> 4.33.0`

– Generated Terraform validates cleanly and passes format checks

“`

This agent encodes everything from our `copilot-instructions.md` plus implementation-specific behavior: it runs `terraform fmt` and `validate` after every edit, it tracks work with todos, it refuses to run `terraform plan` without asking first, and it checks for dead code. The `tools` list gives it file editing, terminal execution, and search  but not destructive operations.

• Pairing it with a planning agent

For larger changes  adding a new microservice, refactoring the networking layer  you want a separate agent that plans *before* anyone writes code. Create `.github/agents/terraform-aca-planning.agent.md`:

“`markdown

—

name: “ACA Terraform Planning”

description: “Creates implementation plans for Azure Container Apps infrastructure changes. Read-only  does not modify Terraform files.”

tools: [read/readFile, search, web/fetch, edit/createFile, edit/editFiles, todo]

—

Azure Container Apps Infrastructure Planner

You create implementation plans for Terraform changes. You do NOT write Terraform code.

Workflow

1. Review existing `.tf` files and understand the current architecture

2. Research Azure resource requirements using `#fetch` against Microsoft docs

3. Write a structured plan to `.terraform-planning-files/INFRA.{goal}.md`

4. The plan must list every resource, its dependencies, required variables, and outputs

5. Break implementation into phased tasks with clear acceptance criteria

Plan structure

Each plan includes: an introduction summarizing the change, a resources section with YAML blocks defining each Azure resource (kind, module/provider, variables, outputs, dependencies), and phased implementation tasks with specific file-level actions.

Constraints

– Only create or modify files under `.terraform-planning-files/`

– Do NOT modify `.tf` files  that’s the implementation agent’s job

– Always consult Microsoft docs for resource configurations

– Flag any changes that would affect networking (CIDR ranges, NSG rules) as requiring human review

“`

The workflow becomes: assign a planning issue to the planning agent, review the generated plan, then assign the implementation issue to the implementation agent with a reference to the plan. The implementation agent reads the plan from `.terraform-planning-files/` and executes it.

Using agents with the coding agent

When you assign a GitHub issue to Copilot, you can select which custom agent handles it from a dropdown. The coding agent spins up an ephemeral GitHub Actions environment, loads the selected agent’s instructions and tools, reads your custom instructions and prompt files, makes changes, and opens a pull request.

For example, say your team needs a new internal microservice for notifications. You create an issue:

Issue title: Add internal Container App for notification service

Issue body:

“`

Create a new Container App `ca-notification` in the existing Container App Environment.

This is a backend service  it should only be reachable internally.

Use the placeholder nginx image from MCR for now.

CPU: 0.25, Memory: 0.5Gi, min replicas: 1.

Add an output for the notification service FQDN.

“`

You assign the issue to Copilot and select the ACA Terraform Implementation agent. The agent creates a `copilot/issue-42` branch, writes the resource in `aca.tf` with internal ingress, adds the identity block and `AcrPull` role assignment, runs `terraform fmt` and `terraform validate`, self-reviews its changes using Copilot code review, and opens a pull request. If you leave a comment like “@copilot also add an env block so the frontend can reach this service,” it picks up the feedback, pushes a new commit, and re-requests review.

Your CI pipeline runs `terraform plan` on the PR, so you can see exactly what the agent’s code would do to your infrastructure before approving.

Where to find more agents

GitHub maintains a curated collection of community agents at [github/awesome-copilot](https://github.com/github/awesome-copilot/tree/main/agents)  over 170 agent profiles covering everything from Azure infrastructure to security scanning, database administration, and code review. For Terraform specifically, look at `terraform.agent.md`, `terraform-azure-implement.agent.md`, `terraform-azure-planning.agent.md`, and `terraform-iac-reviewer.agent.md`. These are production-grade starting points that you can fork and customize for your project’s conventions.

The tasks where you still want a human: anything involving networking changes (CIDR ranges, NSG rules), provider version upgrades, or state-sensitive operations like resource renames. The agent doesn’t have access to your Terraform state, so it can’t predict plan output.

Managed Identities: killing the last static credential

In Part 2, we created an ACR with `admin_enabled = false` and left a comment saying “connect via Managed Identity in Part 3.” Here’s that connection.

The idea is simple: instead of giving Container Apps a username and password to pull images from ACR, we give them a Microsoft Entra ID identity and assign it the `AcrPull` role. The identity is managed by Azure  it’s created, rotated, and destroyed automatically. There’s nothing to store, nothing to leak.

Here’s the Terraform to add. First, enable system-assigned managed identity on both Container Apps by adding an `identity` block:

“`hcl

identity {

  type = “SystemAssigned”

}

“`

Then create role assignments that grant each Container App’s identity the `AcrPull` permission on the ACR:

“`hcl

resource “azurerm_role_assignment” “frontend_acr_pull” {

  scope                = azurerm_container_registry.acr.id

  role_definition_name = “AcrPull”

  principal_id         = azurerm_container_app.app.identity[0].principal_id

}

resource “azurerm_role_assignment” “backend_acr_pull” {

  scope                = azurerm_container_registry.acr.id

  role_definition_name = “AcrPull”

  principal_id         = azurerm_container_app.backend.identity[0].principal_id

}

“`

Finally, update the Container App definitions to use the `registry` block instead of pulling from a public registry:

“`hcl

registry {

  server   = azurerm_container_registry.acr.login_server

  identity = “System”

}

“`

The `identity = “System”` parameter tells Azure Container Apps to authenticate to the ACR using its own system-assigned identity. No passwords, no tokens, no environment variables. The authentication is handled entirely within the Azure control plane.

This also means your Container Apps will fail to start if the role assignment is missing or wrong  which is exactly the behavior you want. Fail closed, not open. If someone accidentally removes the `AcrPull` assignment, the app doesn’t silently fall back to anonymous access  it refuses to pull the image.

GitHub Actions: from `git push` to production

The final piece is a CI/CD pipeline that runs `terraform plan` on pull requests and `terraform apply` on merge to main. We’re using OIDC (OpenID Connect) to authenticate GitHub Actions to Azure  no service principal secrets stored in GitHub.

Setting up workload identity federation

This is Microsoft’s recommended approach for authenticating external workloads  like a GitHub Actions runner  to Azure without storing any secrets. Microsoft calls it workload identity federation, and it’s built on top of OpenID Connect (OIDC).

Here’s what’s happening under the hood. GitHub Actions has a built-in OIDC provider at `https://token.actions.githubusercontent.com`. Every time a workflow run needs to authenticate, GitHub issues a short-lived JSON Web Token (JWT) that contains claims about the workflow  which repository triggered it, which branch, which environment. That token is valid for minutes, not months.

On the Azure side, you create an app registration(or a user-assigned managed identity) in Microsoft Entra ID (formerly Azure AD) and add a federated identity credential to it. This credential tells Entra ID: “trust tokens from GitHub’s OIDC provider, but only when the subject claim matches this specific repository and branch.” The audience is set to `api://AzureADTokenExchange`.

At runtime, the `azure/login` action in your workflow exchanges the GitHub-issued JWT for a short-lived Azure access token via the Microsoft identity platform. The access token is scoped to your subscription and expires quickly. There’s no service principal secret, no client certificate, nothing to rotate or leak.

You’ll need to set up three things:

1. App registration in Entra ID  go to the Microsoft Entra admin center → App registrations → New registration. This creates the identity your GitHub workflow will authenticate as. Assign it a role (like `Contributor`) on your subscription or resource group.

2. Federated identity credential  on the app registration, go to Certificates & secrets → Federated credentials → Add credential. Select “GitHub Actions” as the scenario. Set the organization, repository, and entity type (branch, environment, or tag). For production deployments, use the `environment` entity type pointed at a GitHub Environment with required reviewers  this is more secure than branch-based subjects because it ensures a human approved the deployment.

3. GitHub repository secrets  store three values: `AZURE_CLIENT_ID` (the app registration’s Application ID), `AZURE_TENANT_ID` (your Entra ID tenant), and `AZURE_SUBSCRIPTION_ID`. These are identifiers, not credentials. If someone exfiltrates them, they get three GUIDs that are useless without a valid OIDC token from your specific GitHub repository, branch, and environment.

The pipeline

Here’s the structure of the workflow file (`.github/workflows/terraform.yml`):

“`yaml

name: ‘Terraform Plan & Apply’

on:

  pull_request:

    branches: [main]

    paths: [‘**.tf’]

  push:

    branches: [main]

    paths: [‘**.tf’]

permissions:

  id-token: write    # Required for OIDC

  contents: read

  pull-requests: write  # Post plan output to PR

concurrency:

  group: terraform-${{ github.ref }}

  cancel-in-progress: false

jobs:

  plan:

    runs-on: ubuntu-latest

    steps:

      – uses: actions/checkout@v4

      – uses: hashicorp/setup-terraform@v3

        with:

          terraform_version: ‘1.8.0’

      – uses: azure/login@v2

        with:

          client-id: ${{ secrets.AZURE_CLIENT_ID }}

          tenant-id: ${{ secrets.AZURE_TENANT_ID }}

          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      – name: Terraform Init

        run: terraform init

      – name: Terraform Format Check

        run: terraform fmt -check -recursive

      – name: Terraform Validate

        run: terraform validate

      – name: Terraform Plan

        run: terraform plan -out=tfplan -no-color

      # Post plan summary to PR as a comment

      – name: Comment Plan on PR

        if: github.event_name == ‘pull_request’

        uses: actions/github-script@v7

        with:

          script: |

            // Post truncated plan output to PR comment

  apply:

    needs: plan

    if: github.ref == ‘refs/heads/main’ && github.event_name == ‘push’

    runs-on: ubuntu-latest

    environment: production  # Requires approval

    steps:

      – uses: actions/checkout@v4

      – uses: hashicorp/setup-terraform@v3

      – uses: azure/login@v2

        with:

          client-id: ${{ secrets.AZURE_CLIENT_ID }}

          tenant-id: ${{ secrets.AZURE_TENANT_ID }}

          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      – run: terraform init

      – run: terraform apply -auto-approve

“`

A few design decisions worth calling out.

The `concurrency` block prevents two Terraform runs from executing simultaneously on the same branch. Terraform state is not designed for concurrent writes  parallel runs will corrupt it. The `cancel-in-progress: false` setting means new runs queue instead of canceling in-flight ones, because you never want to interrupt a `terraform apply` mid-execution.

The `paths` filter ensures the pipeline only triggers when `.tf` files change. A README update shouldn’t trigger an infrastructure deployment.

The `environment: production` on the apply job means someone has to click “Approve” in the GitHub UI before `terraform apply` runs. This is your human gate  the pipeline does the mechanical work (format, validate, plan), and a human makes the final call on whether the plan looks right.

This is the workload identity federation model in action  the only values in your GitHub secrets are non-sensitive identifiers. The actual authentication happens at runtime through the OIDC token exchange described above, and every token is short-lived and scoped.

What your repo looks like after Part 3

“`

.

├── .github/

│   ├── copilot-instructions.md          # Project-wide AI context

│   ├── agents/

│   │   ├── terraform-aca-implement.agent.md  # Implementation specialist

│   │   └── terraform-aca-planning.agent.md   # Planning specialist

│   ├── instructions/

│   │   ├── networking.instructions.md   # Path-specific: vnet, nsg, dns

│   │   └── containers.instructions.md   # Path-specific: aca, acr

│   ├── prompts/

│   │   ├── readme.prompt.md             # Generate README (from Part 1)

│   │   ├── new-container-app.prompt.md  # Scaffold new Container App

│   │   └── terraform-review.prompt.md   # Security review checklist

│   └── workflows/

│       └── terraform.yml                # CI/CD pipeline

├── aca.tf          # Frontend + Backend Container Apps (with identity blocks)

├── acr.tf          # Container Registry

├── appg.tf         # Application Gateway

├── dns.tf          # Private DNS

├── main.tf         # Outputs, Log Analytics, role assignments

├── nsg.tf          # Network Security Groups

├── provider.tf     # Provider config

├── rg.tf           # Resource Group

└── vnet.tf         # Virtual Network

“`

The security posture, end to end

Let’s step back and look at what three parts of Terraform and a few config files got us.

The networking layer is locked down. Container Apps sit behind an internal load balancer in a delegated subnet. The only public entry is through the Application Gateway, which terminates HTTP and forwards to the frontend’s internal FQDN via private DNS.

The application layer follows Zero Trust. The backend is platform-isolated  `external_enabled = false` means no load balancer rule exists, so there’s no path to misconfigure. The frontend reaches the backend via its internal FQDN, which resolves only within the Container App Environment.

The identity layer has zero static credentials. ACR admin is disabled. Container Apps authenticate to ACR using system-assigned Managed Identities with the `AcrPull` role. GitHub Actions authenticates to Azure using workload identity federation via OIDC  no service principal secrets, just short-lived tokens exchanged at runtime through Microsoft Entra ID.

The human layer is AI-augmented. Copilot custom instructions encode your project’s security rules, so AI-generated code follows them by default. Custom agents specialize Copilot into focused personas  a planning agent that researches and designs, an implementation agent that writes and validates code, each with scoped tools and guardrails. Prompt files automate code reviews that catch violations before they reach a PR. The CI/CD pipeline runs format, validate, and plan on every pull request, with mandatory approval before apply.

No admin passwords. No static credentials. No manual deployments. No AI-generated code that doesn’t understand your architecture.

That’s the end state of Part 3, and the end of this series.

What to explore next

This project is a solid foundation, but production environments always have more knobs to turn. A few ideas worth exploring: remote state with Azure Storage and state locking, Azure Key Vault integration for application secrets (database connection strings, API keys), custom domains with managed TLS certificates on the frontend, Dapr integration for service-to-service communication (sidecars, pub/sub, state management), and monitoring with Azure Application Insights wired through the existing Log Analytics workspace.

If you’ve followed along through all three parts, you have a microservices platform that’s network-isolated, identity-secured, AI-assisted, and pipeline-deployed. That’s not a tutorial  that’s a production foundation.

—

*This is Part 3 of a 3-part series (a few more series may be added on the future) on building production-ready microservices on Azure Container Apps with Terraform. [Part 1](./README.md) covers the secure networking baseline. [Part 2](./blog-part-2-microservices.md) covers ACR, internal backend, and frontend-backend wiring.*

In Part 1, we established a secure baseline: a VNet with NSGs, centralized logging, an Application Gateway as our public entry point, and a single frontend Container App behind an internal load balancer. Everything was locked down no direct internet access to the Container App, all traffic flowing through the Application Gateway.

Part 2 evolves that single-app deployment into a proper microservices architecture. We’re adding three things: a container registry to store our images, a backend API that only the frontend can reach, and the wiring between them.

By the end of this tutorial, the architecture looks like this:

Internet → App Gateway → Frontend ACA → (internal FQDN) → Backend ACA

                                                              ↑

                                               Only reachable inside the

                                               Container App Environment

Prerequisites

You need Part 1 deployed and running. Specifically, your Terraform state should contain these resources: `azurerm_container_app_environment.env`, `azurerm_container_app.app`, and `random_string.suffix`. If you’re starting fresh, deploy Part 1 first.

Tools required: Terraform >= 1.8.0, Azure CLI, and an Azure subscription with permissions to create container registries and container apps.

What we’re building

Three resources, each with a specific role in the Zero Trust model:

Azure Container Registry (ACR) a private registry to store container images. We’re using Standard SKU with admin access disabled. No static credentials, no shared passwords. In Part 3, we’ll wire this up with Managed Identities so our Container Apps can pull images using RBAC instead of admin keys.

Backend Container App an internal-only API service. The critical setting here is `external_enabled = false` on the ingress block. This isn’t just “not public” it means the backend has no ingress from outside the Container App Environment. Not from the VNet, not from the Application Gateway, not from the internet. Only sibling apps running in the same environment can resolve its internal FQDN.

Frontend Container App (updated) the existing frontend gets a new environment variable (`BACKEND_API_URL`) pointing to the backend’s internal FQDN. This is how the frontend discovers the backend at runtime, without hardcoding addresses.

Step 1 Create the Azure Container Registry

Create a new file called `acr.tf` in your project root:

resource "azurerm_container_registry" "acr" {

  name                = "acr${random_string.suffix.result}"

  resource_group_name = azurerm_resource_group.rg.name

  location            = azurerm_resource_group.rg.location

  sku                 = "Standard"

  admin_enabled       = false

}

A few things to note about this block.

The name uses the same `random_string.suffix` from Part 1, which gives us a globally unique name like `acrab3k2m`. ACR names must be 5–50 characters, alphanumeric only our 9-character name fits comfortably.

We chose Standard SKU deliberately. Basic lacks support for Private Endpoints (which we’ll need in Part 3 to lock down the registry to VNet traffic only) and has limited throughput. Premium adds geo-replication and content trust, but that’s overkill for this stage.

Setting `admin_enabled = false` is the Zero Trust play. The admin account is a single shared username/password that never rotates and can’t be scoped. By disabling it, we force all image pulls to go through Azure RBAC. In Part 3, we’ll create a Managed Identity for each Container App and assign the `AcrPull` role no credentials to store, rotate, or leak.

Step 2 Add the internal backend Container App

In your existing `aca.tf`, add the backend resource *before* the frontend (since the frontend will reference it):

resource "azurerm_container_app" "backend" {

  name                         = "ca-backend-api"

  container_app_environment_id = azurerm_container_app_environment.env.id

  resource_group_name          = azurerm_resource_group.rg.name

  revision_mode                = "Single"

  workload_profile_name        = "Consumption"

  template {

    container {

      name   = "backend-api"

      image  = "mcr.microsoft.com/azuredocs/containerapps-helloworld:latest"

      cpu    = 0.25

      memory = "0.5Gi"

    }

    min_replicas = 1

    max_replicas = 3

  }

  ingress {

    external_enabled = false

    target_port      = 80

    transport        = "auto"

    traffic_weight {

      latest_revision = true

      percentage      = 100

    }

  }

}

The image is a placeholder we’re using Microsoft’s hello-world image until Part 3, when we’ll push our own images to ACR and reference them via `${azurerm_container_registry.acr.login_server}/backend:latest`.

The `external_enabled = false` line is the most important setting in this entire tutorial. When set to `false`, Azure’s control plane never provisions a public-facing load balancer rule for this app. The backend gets an internal FQDN that follows this pattern:

“`

ca-backend-api.internal.<container-app-environment-default-domain>

“`

That FQDN resolves only within the Container App Environment’s internal DNS. If you try to `curl` it from your local machine, from a VM in the same VNet, or even from the Application Gateway it won’t resolve. Only apps running inside the same Container App Environment can reach it. This is platform-level isolation, not just network-level.

Step 3 Wire the frontend to the backend

Update the existing `azurerm_container_app.app` resource in `aca.tf`. The only change is adding an `env` block inside the `container` block:

resource "azurerm_container_app" "app" {

  name                         = "ca-hello-world"

  container_app_environment_id = azurerm_container_app_environment.env.id

  resource_group_name          = azurerm_resource_group.rg.name

  revision_mode                = "Single"

  workload_profile_name        = "Consumption"

  template {

    container {

      name   = "hello-world"

      image  = "mcr.microsoft.com/azuredocs/containerapps-helloworld:latest"

      cpu    = 0.25

      memory = "0.5Gi"

      env {

        name  = "BACKEND_API_URL"

        value = "http://${azurerm_container_app.backend.ingress[0].fqdn}"

      }

    }

    min_replicas = 1

    max_replicas = 3

  }

  ingress {

    external_enabled = true

    target_port      = 80

    transport        = "auto"

    traffic_weight {

      latest_revision = true

      percentage      = 100

    }

  }

}

We’re using `http://` (not `https://`) for the `BACKEND_API_URL`. This is intentional. Internal ACA-to-ACA traffic within the same environment doesn’t terminate TLS at the Envoy sidecar by default. If you sent `https://`, the request would fail certificate validation because there’s no managed certificate on the internal FQDN. Use `https://` only if you’ve configured a custom domain with a managed cert on the backend.

Terraform creates an implicit dependency here: the frontend resource depends on the backend resource (because it references `azurerm_container_app.backend.ingress[0].fqdn`). This means Terraform will always create the backend first, which is exactly the ordering we want.

Step 4 Add outputs

In `main.tf`, add these two outputs after the existing ones:

output "acr_login_server" {

  value       = azurerm_container_registry.acr.login_server

  description = "ACR login server used as image prefix in container definitions"

}

output "backend_app_fqdn" {

  value       = azurerm_container_app.backend.ingress[0].fqdn

  description = "Internal FQDN of the Backend Container App (resolvable only within the CAE)"

}

The `acr_login_server` output gives you the hostname (e.g., `acrab3k2m.azurecr.io`) that you’ll use in Part 3 to tag and push images. The `backend_app_fqdn` output is useful for debugging you can verify the internal FQDN pattern and confirm it matches what the frontend receives in its environment variable.

Step 5 Plan and apply

terraform plan -out=tfplan

terraform apply tfplan

Expected changes: 2 new resources (ACR + backend ACA), 1 modified resource (frontend ACA with new env var). The Container App Environment, Application Gateway, and all networking resources remain unchanged.

After apply, verify the outputs:

terraform output acr_login_server

terraform output backend_app_fqdn

The `backend_app_fqdn` should look something like `ca-backend-api.internal.cae-internal-demo.westeurope.azurecontainerapps.io`.

## Updated architecture

Here’s how the architecture looks after Part 2:

What changed from Part 1

Component	Part 1	Part 2
Container Apps	1 (frontend only)	2 (frontend + internal backend)
Container Registry	None	Standard SKU, admin disabled
Frontend Config	Static image, no env vars	BACKEND_API_URL injected
Backend Ingress	N/A	external_enabled = false (internal only)
Outputs	5 (gateway IP, frontend FQDN, URL, static IP, DNS zone)	7 (+ ACR login server, backend FQDN)
New Files	—	acr.tf

Security posture

Part 2 adds two important Zero Trust controls.

First, the backend is platform-isolated. Setting `external_enabled = false` isn’t the same as putting a deny rule in an NSG. NSG rules operate at the network layer and can be misconfigured, have priority conflicts, or get accidentally modified. The `external_enabled = false` setting is enforced by the Azure Container Apps control plane it never provisions the external load balancer rule. There’s no network path to misconfigure.

Second, the ACR has no admin credentials. There’s no username/password to steal, share, or accidentally commit to a repo. When we connect ACR to the Container Apps in Part 3, it will be through Azure RBAC and Managed Identities ephemeral, automatically rotated, least-privilege tokens.

What’s next in Part 3

Part 3 will close the loop with CI/CD and identity:

– Managed Identities : System-assigned identities on each Container App, with `AcrPull` role assignments to pull images from ACR without any credentials.

– GitHub Actions : CI/CD pipelines that build, push to ACR, and update Container App revisions.

– Full automation : From `git push` to production deployment with no manual steps.

The foundation we’ve built in Parts 1 and 2 internal networking, platform-level isolation, RBAC-ready registry makes Part 3 a matter of wiring, not rearchitecting.

This is Part 2 of a full series on building production-ready microservices on Azure Container Apps with Terraform. Part 1 covers the secure networking baseline.

Repo : achrafbenalaya/azure-workshop-aca

50K views: the blog is growing up

This year, my blog crossed the milestone of 50,000 all‑time views. Seeing that number on the analytics dashboard was a strong reminder that consistent sharing, even in small pieces, compounds over time. It is still a personal blog, but it is slowly becoming a useful resource for people starting or growing in cloud and AI.

Certifications: keeping skills sharp

On the learning side, I obtained two new certifications: one from Google Cloud and one from Microsoft Azure. I also renewed all my existing Azure certifications to stay aligned with the latest changes in the platform. Investing time in certification tracks is never just about the badge; it forces me to structure my knowledge, fill gaps, and bring fresher content back to my sessions, posts, and workshops.

Speaking and community events

Community has been at the center of this year. I had the chance to participate in several events and share my experience: Festive Tech Calendar, Azure User Group Sweden, WeDoAI 2025, and Global Azure 2025, among others. Each event was an opportunity to meet passionate people, exchange ideas, and hopefully make cloud and AI topics a little more accessible for attendees.

MVP & MCT renewals

Another highlight was renewing both my Microsoft MVP and Microsoft Certified Trainer status for one more year. Both recognitions are special to me because they are directly connected to sharing knowledge and helping the community grow. They also come with a responsibility: to keep learning, keep contributing, and keep showing up.

A new AI & GitHub Copilot corner

This year, I also introduced a new AI‑focused section on the blog, with a special emphasis on GitHub Copilot. The goal is to document how AI can practically support developers in their day‑to‑day work—from prototyping and refactoring to documentation and testing. Expect more deep dives, “how I actually use it” posts, and realistic scenarios rather than just high‑level theory.

YouTube: not at 1K yet, and that’s OK

On YouTube, I did not reach the symbolic 1,000‑subscriber mark yet; I am currently at 811. That said, the channel has a clear direction now: more focused series, shorter and actionable videos, and better alignment with what you read on the blog. The plan for next year is to bring more consistent content, experiment with playlists around certifications, best practices, architecture, and cost optimization, and hopefully cross that 1K line with a stronger community behind it.

A year full of change

Professionally and personally, 2025 brought a lot of changes. Some were planned, others completely unexpected, but each one came with lessons and new connections. I am grateful for everyone I met this year online or in person who shared questions, feedback, opportunities, or just a friendly message. These interactions are a big part of why I keep creating content.

Looking ahead to 2026

For the next year, the focus is on smaller, high‑value content series both on the blog and on YouTube. Think short, themed mini‑series about cloud architecture, security fundamentals, real‑world best practices, optimization and cost savings, and of course AI. I also want to do more collaborations, and I already have a long list of people in mind from the community that I’d love to co‑create with.

On a more personal note, one of my goals is finally building my first custom PC. With RAM prices going up, the timing is not perfect, but the plan is to target a build in the 1–2K range and see what kind of balanced workstation we can put together for content creation, labs, and maybe some light gaming.

To everyone who read the blog, attended a session, watched a video, or simply reached out this year: thank you. I wish you a happy new year and all the best for the next one. More content, more learning, and more collaboration are on the way see you in 2026.

Infrastructure as Code (IaC) has become the backbone of modern cloud architectures. Terraform, combined with Azure services, enables us to build scalable, secure, and reproducible platforms.

In this blog series, I’m starting from a real Terraform project that I initially built by hand, without AI assistance. This first part focuses on laying a solid foundation: a production-oriented Azure container infrastructure.

In the next parts, things get more interesting
We’ll enhance this infrastructure using GitHub Copilot, exploring:

• Chat mode
• Custom instructions
• Prompt-driven infrastructure evolution

This repository will be open-source, and anyone is welcome to contribute, learn, or suggest improvements.

Goal of This Series

This series has three main objectives:

1. Build a real-world Azure container architecture
2. Demonstrate Terraform best practices incrementally
3. Show how GitHub Copilot can assist cloud engineers in evolving infrastructure

Each article will introduce one logical improvement, keeping things practical and easy to follow.

Architecture – What We’re Building (Part 1)

In this first iteration, we deploy a public-facing containerized application with secure networking and observability.

Core Components

The current Terraform setup includes:

• Azure Application Gateway (Public)
  • Acts as the entry point
  • Handles HTTP/HTTPS traffic
• Azure Container Apps Environment
• Azure Container App
  • Hosts the main application
• Azure Log Analytics Workspace
  • Centralized logs and diagnostics
• Virtual Network (VNet)
• Network Security Groups (NSGs)
  • Network-level security controls
• Private DNS Zone
  • Internal name resolution between services

This design already follows production-grade principles:

• Network isolation
• Centralized logging
• Clear separation of responsibilities

Why Start Without Copilot?

For this first blog post, everything was written manually.

Why?

Because before using AI effectively, it’s important to:

• Understand the architecture
• Control the Terraform structure
• Define clear boundaries and responsibilities

This baseline will allow us to objectively measure Copilot’s value in the next parts:

• Does it accelerate development?
• Does it suggest better patterns?
• Does it catch errors or improve readability?

What’s Coming Next

In Part 2, we’ll enhance this platform by:

• Adding Azure Container Registry (ACR)
• Introducing a second Container App acting as a backend API
• Connecting frontend backend securely
• Using GitHub Copilot Chat to guide Terraform changes

Later parts will include:

• Copilot custom instructions
• Prompt files
• Security improvements
• CI/CD with GitHub Actions
• Community-driven enhancements

Open Source & Contributions

This project is 100% open-source.

If you want to:

• Learn Terraform on Azure
• Experiment with GitHub Copilot
• Contribute improvements or ideas
  
  Url : achrafbenalaya/azure-workshop-aca

You’re more than welcome to join.

Conclusion

This first part sets the foundation: a clean, functional Azure container platform built with Terraform.

From here on, we’ll iterate, enhance, and challenge our own work, with GitHub Copilot as a real teammate not a magic button.

Stay tuned for Part 2, where AI enters the game

Up until now, I’ve mainly been using existing MCP servers. But at some point the real question arrives:
How do you build your own MCP server? Where do you host it? And how do you actually use it in real projects?

That’s exactly what led me here. I wanted to create my first MCP server from scratch. While exploring different approaches, I came across several sample repositories in Azure-samples. Since I’m a long-time C# developer, my first instinct was to build a server using Azure Functions + C# totally in my comfort zone.

But this time, I made a promise to myself: step outside the comfort zone.
And after watching many presentations by the amazing Pamela Fox, I said why not Python for this first example?

So in this blog post, we’re going to build a simple expense-tracker MCP server using Python, deploy it as an Azure Function, and test it using MCP Inspector and VS Code’s MCP extension.

You’ll find a clear, step-by-step guide including:

Cloning the repo : https://github.com/achrafbenalaya/expensetrackermcpserver
Writing the server logic
Creating & deploying the Azure Function
Testing it locally and in VS Code with MCP Inspector

If you enjoy this walkthrough, feel free to share it and if you’d like to support my content, you can buy me a coffee here: buymeacoffee.com/ben2code

Prerequisites to follow along

To build and test this project, make sure you have:

• VS Code
• MCP Inspector
• Python
• Browser
• Docker (optional I’ll show how to run without it)
• Azure account with permissions to create Azure Functions
• And of course… an internet connection

Alright let’s jump right in.

When you walk into a car showroom, you don’t start by asking about the engine specs, compression ratio, or fuel injection system. First, you want to see the car. You look at the design, step inside, feel the seats, maybe even take it for a quick test drive. Only after that do you start digging into the technical details.

We’re going to take the exact same approach here.

Before diving into code, architecture, Azure Functions, or deployment pipelines, let me show you the final result what the MCP server can actually do once it’s up and running.

Tool #1: get_expenses

This first tool simply retrieves your saved expenses a clean, structured way to read your stored data through MCP. Think of it like opening your car’s dashboard to see your mileage and trip history before we start checking the engine.

Let’s take a look at how it works in action

Simply here i was asking for my expenses for the month of October for the year 2025

Tool #2: get_budget

The second tool gives us visibility into our monthly budget.

For the demo, I’ve set the default budget to $1000 per month. Later, we’ll make this more flexible by storing the budget in an environment variable which means you’ll be able to adjust it per month, per environment, or even per user without touching the code.Think of this tool like checking the car’s fuel range before a road trip you need to know how far you can go before running out

This command simply returns your current budget value, so you always have a clear reference point before adding or reviewing expenses.

Tool #3: get_spending_summary

This tool gives you a summary of your spending over a specific time range.

Tool #4: add_expense

Now that we can read our budget and existing data, it’s time for the fun part adding new expenses.

This tool allows you to record a new expense with all the important details: category, amount, description, and date.

Let’s check if the record is added :

But wait where is all this data actually stored?
Behind the scenes, everything is saved in an Azure Storage account, inside a Blob as a CSV file. Simple, lightweight, and easy to query.

Project Overview How We Built This MCP Server

Now that you’ve seen the final result, let’s open the hood and see how everything works under the engine. In this section, we’ll walk through:

• Where the project skeleton came from
• What was modified and why
• How the MCP server was implemented in Python
• How we deployed it to Azure Functions
• The configuration (environment variables, Storage, Blob, etc.)
• How we tested locally and in the cloud
• Tools used along the way (MCP Inspector, VS Code, Claude Desktop, etc.)

Let’s break it down step-by-step

1⃣ Pulling the Base Template (Source Repo)

I started by cloning the official Model Context Protocol example repository from Azure-Samples, which provides a clean starting point for building MCP servers.

It gave me a Python-based skeleton so I could focus on extending the logic instead of building everything from scratch.

repo url =====> Azure-Samples/remote-mcp-functions-python

Full functionel repo ===> https://github.com/achrafbenalaya/expensetrackermcpserver

git clone https://github.com/Azure-Samples/remote-mcp-functions-python.git

2⃣ Understanding the Starter Code & Modifying It

From the base template, I:

• Reviewed the MCP handler logic
• Created new MCP tools (get_budget, get_expenses, add_expense, get_spending_summary)
• Integrated Azure Blob Storage as the backend
• Added CSV read/write operations
• Structured responses to match MCP protocol expectations
  
  

Basically , I built a lightweight expense-tracking service in Python backed by Azure Blob Storage no pandas required. It handles both CSV and XLSX formats, includes reliable date and amount parsing, supports dynamic monthly budgets via environment variables, and provides simple rule-based expense categorization. Each capability is implemented as small, testable functions and exposed as MCP tools (get_expenses, add_expense, get_budget_status, get_spending_summary, categorize_expense).

I’ll first explain, in plain steps, how the existing “get all expenses” tool was added (what the method does and why). Then I’ll show a minimal example of adding a new simple “hello world” tool — both the class method and a small HTTP wrapper you can drop into an Azure Functions HTTP trigger or run locally.

How the “get all expenses” tool was added short, concrete steps

What we added: a public method get_expenses(month: str, category: Optional[str] = None) -> List[Dict] on ExpenseTracker.

Why: expose a small, testable API that lists expenses for a given month (and optional category) in a JSON-serializable format so it can be used by MCP tools, HTTP endpoints, or scripts.

Implementation summary :

• Input normalization:
  • _parse_yyyymm(month) accepts “YYYY-MM” or “YYYYMM” and normalizes to “YYYY-MM”. This makes the interface robust to common formats.
• Read source of truth:
  • Calls self._download_rows() which fetches the blob (XLSX or CSV) from the configured container and returns rows as dicts. If the blob is missing, _download_rows() returns an empty list.
• Iterate and filter:
  • For each row, read the Date field. The code accepts:
    • Excel date objects (openpyxl returns datetime/date),
    • datetime objects,
    • or ISO date strings “YYYY-MM-DD”.
  • Convert/normalize to a date, build row_month = "YYYY-MM" and compare with the requested month.
  • If category is supplied, compare case-insensitively and skip non-matching rows.
• Normalize fields:
  • Ensure Amount is cast to float() (on failure fallback to 0.0).
  • Ensure Category and Description are strings.
• Return shape:
  • A list of dicts like:
    • { “Date”: “YYYY-MM-DD”, “Amount”: float, “Category”: str, “Description”: str }
  • This JSON-friendly shape is easy to serialize as an HTTP response or an MCP tool return.

Error/edge behavior:

• If month format invalid → _parse_yyyymm raises ValueError.
• If no blob exists → returns [] (safe).
• Bad amount strings → amount becomes 0.0 for listing (but add_expense raises ValueError for invalid amounts).

How it becomes a “tool” (exposure options)

• Direct use in scripts: instantiate ExpenseTracker() and call get_expenses("2025-12").
• Wrap as HTTP endpoints (Azure Functions) where the function handler instantiates ExpenseTracker() and returns the list as JSON.
• Register it as an MCP tool wrapper (the repository already contains tooling that triggers these methods) the method contract is intentionally simple (primitive types + JSON-serializable results).
  
  example below the get_expenses function

def get_expenses(self, month: str, category: Optional[str] = None) -> List[Dict[str, Any]]:
    month = _parse_yyyymm(month)
    rows = self._download_rows()
    result = []
    for r in rows:
        d = r.get("Date")
        if not d:
            continue
        if isinstance(d, datetime):
            ddate = d.date()
        elif isinstance(d, date):
            ddate = d
        else:
            try:
                ddate = datetime.strptime(str(d), "%Y-%m-%d").date()
            except Exception:
                continue
        row_month = f"{ddate.year:04d}-{ddate.month:02d}"
        if row_month != month:
            continue
        cat = r.get("Category") or ""
        if category and str(cat).strip().lower() != category.strip().lower():
            continue
        amount = r.get("Amount", 0.0)
        try:
            amount = float(amount)
        except Exception:
            amount = 0.0
        result.append({
            "Date": ddate.isoformat(),
            "Amount": amount,
            "Category": str(cat),
            "Description": str(r.get("Description", "")),
        })
    return result

Where the tool is declared ?

in this part we define the new tool and we call the function

@app.generic_trigger(
    arg_name="context",
    type="mcpToolTrigger",
    toolName="get_expenses",
    description="Retrieve expenses filtered by month and optional category.",
    toolProperties=tool_properties_get_expenses_json,
)
def get_expenses(context) -> str:
    ...

Input the tool expects

The function receives a single context parameter which is a JSON string (the trigger payload). The function parses it like this:

content = json.loads(context)
month = content.get(“arguments”, {}).get(“month”)
category = content.get(“arguments”, {}).get(“category”)

So the caller should send a JSON payload shaped like:

{
  "arguments": {
    "month": "2025-12",
    "category": "IT"            // optional
  }
}

wrapper function :

1. Parse context JSON and extract month and optional category.
2. Validate required month argument. If missing, return a JSON error object.
3. Call the underlying tool method:
   • Uses _get_tracker() to get a singleton ExpenseTracker instance.
   • Calls _get_tracker().get_expenses(month=month, category=category).
4. Wrap the result in a uniform response object and return it as JSON string:

return json.dumps({
    "ok": True,
    "month": month,
    "category": category or "all",
    "count": len(result) if isinstance(result, list) else 0,
    "result": result
})

Sequence :

Client (MCP caller / script)
-> sends JSON context to MCP trigger
-> function_app.get_expenses(context) wrapper
-> parses JSON, validates month
-> calls _get_tracker().get_expenses(month, category)
-> ExpenseTracker.get_expenses(...)
-> _download_rows() reads blob (XLSX/CSV) <– Azure Blob Storage
<- rows
<- filtered/normalized result
<- wrapper returns JSON string { ok, month, count, result }

In the repo you will find readme file that will explain full code , so no worries.

3⃣ Adding Environment Variables

To keep settings flexible and secure, I added environment variables for:

4⃣ Local Development & Testing

To test everything locally, I used:

VS Code : to code and run the azure function => Download here
Python : because we are using python for this demo
Azure Functions Core Tools : Azure Functions Core Tools lets you develop and test your functions on your local computer
MCP Inspector (to simulate LLM connection) : MCP Inspector will be used later for testing .
it can be launched via the cmd : npx @modelcontextprotocol/inspector

Once you run it you can browse : http://127.0.0.1:6274/#resources to see the mcp inspector home page and you can connect to your function app by inserting this link to
http://localhost:7071/runtime/webhooks/mcp/sse to the URL and set

You can choose any tool and test it from the List Tools :

An storage emulator : An storage emulator is needed when developing azure function app in VScode : Azurite emulator for local Azure Storage development
You can run the Azurite in VS Code  : C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\Extensions\Microsoft\Azure Storage Emulator> .\azurite.exe
or Using Docker : docker run -p 10000:10000 -p 10001:10001 -p 10002:10002 mcr.microsoft.com/azure-storage/azurite

5⃣ Deploying to Azure Functions

Once everything worked locally:

• Created an Azure Function App
• Pushed the code via VS Code deployment
• Added same environment variables in Azure portal
• Uploaded/created the blob file for storage

The simplest way to deploy an azure function via vs code is to click on it and select : Deploy to function app (As I’m writing this article, I’m also planning to prepare a Terraform version of this Azure Function to streamline and automate the deployment process.)

Once the app is deployed , you can see the tools by clicking on functions from the portal :

Now before we go and test on MCP inspector or vs code we need to copy the system keys to use (not the best practice for now ,but its for the demo) .
where to find it ? simply go to App Keys and copy the mcp_extension key and save it .

If you’re familiar with the Model Context Protocol and how servers work with it, you know that we need an mcp.json file to define the MCP servers we plan to use.

{
    "inputs": [
        {
            "type": "promptString",
            "id": "functions-mcp-extension-system-key",
            "description": "Azure Functions MCP Extension System Key",
            "password": true
        },
        {
            "type": "promptString",
            "id": "functionapp-name",
            "description": "Azure Functions App Name"
        }
    ],
    "servers": {
        "remote-mcp-function": {
            "type": "sse",
            "url": "https://${input:functionapp-name}.azurewebsites.net/runtime/webhooks/mcp/sse",
            "headers": {
                "x-functions-key": "${input:functions-mcp-extension-system-key}"
            }
        },
        "local-mcp-function": {
            "type": "sse",
            "url": "http://0.0.0.0:7071/runtime/webhooks/mcp/sse"
        }
    }
}

You can add a new server always by using the CTRL+shift +P

Storage account :

I have uploaded a simple csvp file to a storage account on azure and i genrated SAS token for the blob and for the container of the blob

Generate two sas and save them because we will use them later

6⃣ Testing our MCP server

First lets run the MCP server in VS Code :

cd src
pip install -r requirements.txt
func start

you make sure you already have the mcp inspector runing and also the Azurite emulator for local Azure Storage development and now open the mcp inspector page and paste that url on the url tab :

Testing the online server :

Now that we’ve tested the local server and added our MCP server to the mcp.json file, there’s one final step before we test it. We need to add the environment variables — using the values we copied earlier — to the local.settings.json file

{
    "IsEncrypted": false,
    "Values": {
      "FUNCTIONS_WORKER_RUNTIME": "python",
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "EXPENSES_CONTAINER_SAS_URL": "EXPENSES_CONTAINER_SAS_URL",
      "EXPENSES_BLOB_NAME": "expenses.sample.csv",
      "EXPENSES_BLOB_SAS_URL": "EXPENSES_BLOB_SAS_URL"
    }
  }

To test the setup, copy the Azure Function URL and append /runtime/webhooks/mcp/sse to it.
Then, go to Authentication, select the app key, and use it to authenticate the request.
Make sure to set the header name to x-functions-key.

Testing our MCP server with GitHub Copilot

Testing an MCP server with GitHub Copilot means configuring the server in your development environment so Copilot Chat can leverage it for richer context and enhanced capabilities.
we have already added the configuration in the mcp.json we should see the server running by now and we have Agent mode selected .

Lets try another tool , lets add some expenses :

Testing our MCP server with Claude Desktop :

first we need to edit the claude_desktop_config.json under the  C:\Users\<username>\AppData\Roaming\Claude

We need to add to the file the config below

{
  "mcpServers": {
    "my‑mcp": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://localhost:7071/runtime/webhooks/mcp/sse"
      ]
    }
  }
}

we can see our local server up and running ,its time to test

Conclusion

In this guide, we walked through how to create an MCP server using Azure Functions and Python, and tested it with tools like MCP Inspector, VS Code, and Claude Desktop. By following these steps, you now have a fully functional server environment ready for further experimentation and development.

In our next blog post, we’ll explore how to achieve the same setup using C#, giving you an alternative approach and expanding your toolkit for building MCP servers in Azure. Stay tuned!

The Problem That Kept Me Up at Night

Let me paint you a picture. You’re managing an Azure environment, and over the years, different teams have spun up Log Analytics workspaces like they’re going out of style. Development team needs one? Boom, new workspace. QA wants their own? Sure, why not. That POC project from 2022? Yeah, it probably has three workspaces nobody remembers.

Fast forward to today, and you’re staring at over 100 Log Analytics workspaces across multiple subscriptions. Some are actively used, some are ghost towns, and honestly? You have no idea which is which. The monthly Azure bill keeps climbing, and management is asking questions you can’t answer:

• “Can we delete this workspace?”
• “What’s actually using it?”
• “How much is this costing us?”
• “Will anything break if we remove it?”

Sound familiar? This was my reality six months ago.

The “Just Delete It” Disaster

Here’s what happened when we tried the cowboy approach. A colleague decided to clean up what looked like an unused workspace. No data in the portal, no obvious activity, seemed safe enough.

Three hours later, we had:

• Two production alerts that stopped firing (hello, missed incidents!)
• An Application Insights of a web app resource that couldn’t send telemetry
• Three App Services with broken diagnostic settings
• One very angry DevOps Engineer

Turns out, the workspace wasn’t empty it just looked empty from a casual glance. The data was there, the dependencies were real, and we learned a very expensive lesson: you can’t audit Log Analytics workspaces with your eyeballs.

Enter the Bulk Audit Tool

After that incident, I spent a weekend building something (with the help of Ai) we desperately needed: an automated auditing tool that could answer all those questions before we touched anything. Not just for one workspace, but for all of them.

This PowerShell script became our safety net. It does what should be obvious but somehow isn’t it actually looks at what’s in each workspace, what’s connected to it, and what would break if you deleted it.

What This Tool Actually Does

Think of it as a full health check and dependency scanner rolled into one. For each workspace, it:

1. Discovers All Your Workspaces

Scans across all your subscriptions (or specific ones you target) and finds every Log Analytics workspace. No more “I didn’t know that existed” surprises.

.\BulkLAWorkspaceAudit.ps1 -AllWorkspaces -GenerateSummaryReport

2. Analyzes Active Data Tables

It doesn’t just count tables it checks which ones are actually receiving data. That 90-day-old SecurityEvent table with zero records? The script knows it’s dead weight.

3. Identifies Application Insights Data

Automatically detects if you’re dealing with a workspace-based Application Insights resource. These need special handling, and the script flags them clearly.

4. Maps Diagnostic Settings

This is the big one. It scans your Azure resources (App Services, Logic Apps, Functions, VMs, SQL Servers) and tells you which ones are sending diagnostics to each workspace. This is your “oh crap, this IS being used” detector.

5. Finds Dependent Alerts

Checks for scheduled query alerts that rely on the workspace. Delete the workspace, and these alerts go silent. Not ideal for production monitoring.

6. Calculates Actual Costs

Pulls Cost Management data to show you what each workspace has cost over the last 30 days. Real euros, real budget impact. (not working for now , working on a fix)

7. Assigns Risk Levels

Based on everything it finds, it gives you a simple risk rating:

• LOW: Empty or minimal usage, safe to delete
• MEDIUM: Has some data but no critical dependencies
• HIGH: Active diagnostic settings connected
• CRITICAL: Alerts would break, proceed with extreme caution
  

8. Generates Beautiful HTML Reports

Creates individual reports for each workspace AND a summary report showing your entire estate at a glance. No more spreadsheets, no more guesswork.

How to Use It

Quick Start – Audit Everything

The simplest approach audit all workspaces across all your subscriptions:

# Login first
Connect-AzAccount

# Audit all workspaces and generate a summary
.\BulkLAWorkspaceAudit.ps1 -AllWorkspaces -GenerateSummaryReport

This creates an output folder with individual reports for each workspace plus a master summary. Open the summary HTML in your browser, and you’ll immediately see which workspaces are high-risk vs. safe to delete.

Target Specific Subscriptions

If you only want to audit certain subscriptions (smart move for large enterprises):

.\BulkLAWorkspaceAudit.ps1 `
    -AllWorkspaces `
    -SubscriptionIds @("sub-id-1", "sub-id-2", "sub-id-3") `
    -GenerateSummaryReport

Single Workspace Deep Dive

Need to investigate one specific workspace before making a decision?

.\BulkLAWorkspaceAudit.ps1 `
    -WorkspaceName "production-logs" `
    -ResourceGroupName "prod-monitoring-rg"

Adjust the Analysis Window

By default, it looks at the last 30 days. But maybe you want to be more aggressive:

# Only check last 7 days (more aggressive cleanup)
.\BulkLAWorkspaceAudit.ps1 -AllWorkspaces -DaysBack 7

# Or more conservative - check last 90 days
.\BulkLAWorkspaceAudit.ps1 -AllWorkspaces -DaysBack 90

Real-World Use Cases

Use Case 1: The Big Spring Cleaning

Scenario: Your CFO wants to cut cloud costs by 15%. You need to identify optimization opportunities fast.

Solution: Run the bulk audit with -AllWorkspaces. Sort the summary report by cost. You’ll immediately see:

• Expensive workspaces with LOW risk (easy wins!)
• Workspaces collecting data nobody looks at
• Duplicate workspaces serving the same purpose

In our case, we found 23 workspaces marked LOW or MEDIUM risk that were costing us €8,000/month. Easy decisions.

Use Case 2: Pre-Migration Assessment

Scenario: You’re consolidating multiple workspaces into a centralized logging strategy.

Solution: Audit all current workspaces to understand:

• Which ones have active Application Insights data (need special handling)
• What diagnostic settings will need to be reconfigured
• Which alerts need to be migrated to the new workspace

The script’s diagnostic settings mapping becomes your migration checklist.

Use Case 3: Compliance Audit

Scenario: Security team needs to know which workspaces contain what type of data and who’s using them.

Solution: Run the audit and export the data. The reports show:

• Table names (SecurityEvent, Syslog, etc. = security-relevant)
• Resource types sending data (helps identify data owners)
• Active vs. inactive workspaces (data retention compliance)

Use Case 4: Inheriting an Unknown Azure Environment

Scenario: You’re acquiring another company’s Azure environment. You need to understand their Log Analytics setup.

Solution: Get contributor access to their subscriptions, run the audit. Within hours, you know:

• Total workspace footprint
• Critical dependencies
• Cost implications
• Technical debt (orphaned workspaces)

The Results: Our Success Story

After implementing this tool, here’s what changed for us:

Before the audit:

• 127 Log Analytics workspaces
• ~€15,000/month in Log Analytics costs
• Zero visibility into usage
• Afraid to delete anything

After the audit + cleanup:

• 34 workspaces (73% reduction!)
• ~€4,200/month in costs (72% savings!)
• Complete documentation of what each workspace does
• Confident decision-making process

But the real win? No production incidents during cleanup. Every workspace we deleted was marked LOW risk, and we had the data to back up our decisions.

Pro Tips from the Trenches

1. Start with a Read-Only Run Your first audit is pure reconnaissance. Don’t delete anything yet. Just generate the reports and share them with the relevant teams. You’ll learn things about your environment you didn’t know.

2. Use the Risk Levels as Guidelines, Not Gospel A HIGH risk workspace isn’t necessarily “don’t touch it ever.” It means “talk to the teams first.” We’ve deleted HIGH risk workspaces after confirming with owners that the diagnostic settings were legacy cruft.

3. Schedule Regular Audits We run this quarterly now. New workspaces appear, old ones become obsolete. Make it part of your regular housekeeping.

4. Export the Data The HTML reports are great for humans, but keep the raw data. We pipe the results into our CMDB to track workspace lifecycle.

5. Cost Threshold Alerts We added a second pass: any workspace costing more than €200/month gets flagged for review, regardless of risk level. Sometimes expensive LOW-risk workspaces are still worth investigating.

What’s Next?

We’re continuously improving this tool. Current wishlist includes:

• Workspace-to-workspace data flow mapping
• Retention policy analysis and recommendations
• Automated deletion with approval workflows
• Integration with Azure DevOps for change tracking

But honestly? Even in its current form, this tool has paid for itself a hundred times over.

The Bottom Line

If you’re managing more than a handful of Log Analytics workspaces, you need systematic auditing. Manual reviews don’t scale, and “it looks unused” isn’t a strategy.

This tool isn’t fancy. It’s not AI-powered or blockchain-enabled (thank god). It’s just a well-crafted PowerShell script that does the boring, important work of actually checking what’s in your environment.

And sometimes, that’s exactly what you need.

LInk : achrafbenalaya.com/Log_Analytics_Workspace_report/BulkLAWorkspaceAudit.ps1 at main · achrafbenalaya/achrafbenalaya.com

the link for the script : Tap_Link_here

Got questions? Found this useful? I’d love to hear about your Log Analytics cleanup adventures. What worked? What disasters did you narrowly avoid? Drop a comment or reach out.

Want to contribute? The script is designed to be extended. If you add cool features (better cost analysis, workspace recommendations, etc.), share them back with the community.

Remember: In cloud cost management, knowledge is literally money. Every workspace you can confidently delete is savings you can track. And every CRITICAL workspace you DON’T delete accidentally is a disaster you avoided.

Happy auditing!

Even more special, I’ve been recognized in two areas that are deeply connected to both my passion and the work I do every day:

• Azure Compute Infrastructure
• Azure Infrastructure as Code

It’s an honor to be part of this amazing community again. I’m incredibly grateful for the recognition and even more motivated to keep learning, sharing, and giving back to the tech community that’s been such a big part of my journey.

Receiving the Microsoft MVP award again is incredibly meaningful to me not just as a recognition, but as a reflection of the journey so far.

Over the past year, I’ve had the chance to share knowledge through community talks, open-source contributions, technical writing, and one-on-one support whether it’s helping someone troubleshoot an issue or guiding teams through complex cloud architectures. I’ve worked with a wide range of people from students and early-career devs to experienced architects all united by a shared passion for learning and building.

The Azure ecosystem continues to grow and shift rapidly, and I’ve been fortunate to be hands-on with real-world solutions designing and delivering infrastructure using IaaS, PaaS, and Infrastructure as Code, while helping organizations automate and scale more effectively.

Being part of the MVP community is something I value deeply. It’s full of incredibly talented individuals who are generous with their time, knowledge, and experience. This program has opened doors to collaborate globally, speak at inspiring events, and continue growing both personally and professionally.

I’m excited for what’s ahead and grateful to continue being part of this journey.

community

A heartfelt thank you to the incredible global tech community and to Microsoft for this continued recognition and support.
I’m constantly inspired by the passion, generosity, and collaboration I see every day whether it’s at events, in open-source projects, or in online conversations.
Being part of this journey with such talented and driven individuals is truly an honor.
I’m grateful for the opportunities, the learning, and most of all the people.
Here’s to another amazing year of sharing, growing, and building together!

Next Steps for me

Azure keeps evolving and so will my contributions to the community. In the coming year, I’m excited to dive even deeper and share more through:

• Hands-on content around PaaS services,IAC and Azure AI Foundry
• New talks and workshops at both local and international events
• Ongoing open-source contributions and technical blog posts
• Real-world client projects focused on scalable, secure Azure solutions

I’m always open to new ideas, questions, or collaborations feel free to reach out via LinkedIn : (1) Achraf Ben Alaya | LinkedIn or drop me a message anytime.

Thanks for reading and supporting! If you’ve enjoyed the content and want to help fuel more of it !

What is MCP (Model Context Protocol)?

The Model Context Protocol (MCP) is an open protocol developed by Anthropic that enables large language models (LLMs) to integrate with external data sources and tools in a standardized way. It creates a framework that allows AI tools to communicate with each other seamlessly.

In simpler terms, instead of building custom adapters every time we want an AI tool to perform a specific function—like reading a Figma design or managing a database—MCP lets us plug that tool in directly, provided our main AI interface understands the protocol.

MCP defines how AI models can:

• Call external tools
• Fetch data
• Interact with various services
• Access context in a manner that’s generalizable across different integrations
  
  

Why Use MCP?

Consider the traditional approach when you want your AI model to connect to your resources. You would need to:

1. Ask your developers to create custom connectors or extensions
2. Create web APIs
3. Handle authentication
4. Develop additional functionality as needs arise

MCP eliminates this complexity by providing a standardized way for AI models to interact with external tools and data sources.

Real-World Example: Updating My Microsoft Acronyms Project

To demonstrate MCP’s capabilities, I tested it on a small project I created two years ago: Microsoft Acronyms. Since I’ve been busy with work, family, and other projects, I hadn’t updated it with the latest acronyms.

Traditional Process (Without MCP)

Without MCP, updating the site would require me to:

1. Go to GitHub and examine the project structure
2. Search the internet for new Microsoft acronyms
3. Compare them against what’s already on my website
4. Consult an AI model like GPT about the newest acronyms
5. Pull the project
6. Create a branch
7. Update the file
8. Push changes
9. Create a pull request

With MCP

Using MCP and a GitHub MCP server, I simply asked in one prompt: “Can you create a new pull request on my repo: MicrosoftAcronyms001 and also update the data.tsx file with more and newer Microsoft Acronyms?”

That’s it! A new PR was created with updated content, no manual intervention required.

Setting Up the GitHub MCP Server

If you want to try this yourself, here’s how to set up the GitHub MCP server:

1. First, download the GitHub MCP Server from: https://github.com/github/github-mcp-server
2. In Visual Studio Code, go to Settings and activate the MCP server option.
3. Edit the settings.json file to add your server(s). You’ll need to replace ${input:github_token} with a Personal Access Token (PAT) generated from your GitHub account:

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "github_token",
        "description": "GitHub Personal Access Token",
        "password": true
      }
    ],
    "servers": {
      "github": {
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-e",
          "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
        }
      }
    }
  }
}

1. Click “Run” and Docker will launch the server locally. (If you prefer not to use Docker, check the official repository for alternative configuration options.)
2. Once the server is running, go to Agent mode in Visual Studio Code and check the tool buttons for available servers – you should see your MCP server listed.
3. Now you can ask Copilot (with Agent mode and the MCP server for GitHub) to perform tasks like creating pull requests or updating files.

Important Note: Make sure your PAT has the correct permissions. When I first tried this, I had only given read permissions, which prevented the MCP from creating the pull request.

MCP SERVER running

Now since the server is running , we click on the button select tools , and we scroll down we can see any MCP server that we have added .

now after I asked the Model that i have used here : Claude 3.7 , as you can see it”s asked me to use the mcp server I provided , and started to use it’s sub models to aces my repo , get the file content that i need it to be updated it and create new branch.

Results : As you can see , I have a PR created and that have updated the file with some Acronyms , the pipeline worked fine and the file contain new content

And now I asked to merge the Pull request too :

After the merge , i went to my website to test the new acronyms if its exist and the result as you can see , it works .

Conclusion

MCP represents a significant advancement in how we integrate AI models with external tools and data. By providing a standardized protocol for these interactions, it eliminates the need for custom development work and makes AI integration much more accessible.

Isn’t it amazing that all of this can be accomplished without developing any connectors or manual intervention? I believe MCP is just the beginning of a new era in AI integration, and I look forward to exploring its capabilities further in future posts.

List of available Servers & Clients : https://github.com/modelcontextprotocol/servers?tab=readme-ov-file

In this post, we will use Terraform to deploy a static website on Azure, leveraging Azure Storage and Azure Front Door. To keep things simple, I will be deploying everything from my local machine. However, in a real-world scenario, I would store the Terraform state in an Azure Storage Account, create a service principal (SPN), and set up federation with my GitHub repository where my code is hosted. But for now, the goal is to demonstrate how to set up Azure Front Door with an Azure Storage Account that has static website hosting enabled.

Step 1: Create the Storage Account with Terraform

The first step is to create a resource group and an Azure Storage Account. For redundancy and performance, I will use Read-Access Geo-Redundant Storage (RAGRS). This setup ensures that if the primary region becomes unavailable, the data can still be accessed from the secondary region, improving availability.

To learn more about RAGRS, check out Microsoft’s documentation.

Building the First Part of the Infrastructure

resource "azurerm_resource_group" "rg_demo_static_website" {
  name     = "rg-demo-static-website-002"
  location = "francecentral" # Update with the actual location of your resource group
  tags = {
    environment = "Dev"
  }
}


# This resource creates an Azure Storage Account with the specified configurations.
# - `name`: The name of the storage account.
# - `resource_group_name`: The name of the resource group where the storage account will be created.
# - `location`: The location/region where the storage account will be created.
# - `account_tier`: The performance tier of the storage account (Standard or Premium).
# - `account_replication_type`: The replication strategy for the storage account (e.g., LRS, GRS, RAGRS, ZRS).
# - `account_kind`: The kind of storage account (e.g., Storage, StorageV2, BlobStorage).
# - `infrastructure_encryption_enabled`: Whether infrastructure encryption is enabled for the storage account.
# - `tags`: A map of tags to assign to the storage account.

# This resource configures a static website for the specified Azure Storage Account.
# - `storage_account_id`: The ID of the storage account to enable the static website on.
# - `index_document`: The name of the index document for the static website.
# - `error_404_document`: (Optional) The name of the custom 404 error document for the static website.

resource "azurerm_storage_account" "storage_staticwebtorageachraf002" {
  name                              = "staticwebtorageachraf002"
  resource_group_name               = azurerm_resource_group.rg_demo_static_website.name
  location                          = azurerm_resource_group.rg_demo_static_website.location
  account_tier                      = "Standard"
  account_replication_type          = "RAGRS"
  account_kind                      = "StorageV2"
  infrastructure_encryption_enabled = true
  tags = {
    environment = "Dev"
  }
}

resource "azurerm_storage_account_static_website" "static_website02" {
  storage_account_id = azurerm_storage_account.storage_staticwebtorageachraf002.id
  #error_404_document = "customnotfound.html"
  index_document = "index.html"
}

Once the Terraform deployment is complete, our storage account is created with static website hosting enabled. Azure automatically creates a new container called $web, where we will store our website files. For now, I will place a simple index.html file in this folder.

Step 2: Deploy Azure Front Door with Terraform

Now that we have our storage account ready, the next step is to deploy Azure Front Door Standard. But before jumping into the deployment, let’s briefly understand what Azure Front Door is and why it’s useful.

What is Azure Front Door?

Azure Front Door is a globally distributed service that enhances website performance, security, and availability. Here are some key benefits:

1. Global Load Balancing
   • Distributes traffic across multiple backends (App Services, VMs, AKS, etc.).
   • Ensures high availability by routing traffic to the healthiest/closest backend.
2. Performance Acceleration
   • Uses smart routing to reduce latency and improve response times.
   • Supports caching for static content (available in Azure Front Door Standard/Premium).
3. Security Enhancements
   • Includes a Web Application Firewall (WAF) to protect against DDoS, SQL injection, and XSS attacks.
   • Provides TLS termination for secure HTTPS connections.
   • Offers bot protection to filter malicious traffic.
4. URL-Based Routing & Redirection
   • Routes requests based on path, hostname, or query parameters.
   • Supports HTTP to HTTPS redirection and domain changes.
5. High Availability & Failover
   • Automatically fails over to the nearest available backend.
   • Uses health probes to monitor backend status in real time.

For more details, check out Microsoft’s documentation.

resource "azurerm_cdn_frontdoor_profile" "fqdn_profile" {
  name                     = "achrafbenalayastaticwebsite008"
  resource_group_name      = azurerm_resource_group.rg_demo_static_website.name
  response_timeout_seconds = 16
  sku_name                 = "Standard_AzureFrontDoor"
}

resource "azurerm_cdn_frontdoor_endpoint" "web_endpoint" {
  name                     = "web"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.fqdn_profile.id
}

resource "azurerm_cdn_frontdoor_rule_set" "rule_set" {
  name                     = "caching"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.fqdn_profile.id
}


resource "azurerm_cdn_frontdoor_origin_group" "origin_group_web" {
  name                     = "web"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.fqdn_profile.id

  load_balancing {
    additional_latency_in_milliseconds = 0
    sample_size                        = 16
    successful_samples_required        = 3
  }
  health_probe {
    interval_in_seconds = 100
    path                = "/index.html"
    protocol            = "Http"
    request_type        = "HEAD"
  }
}

resource "azurerm_cdn_frontdoor_origin" "web_origin" {
  depends_on                     = [azurerm_storage_account.storage_staticwebtorageachraf002]
  name                           = "web"
  cdn_frontdoor_origin_group_id  = azurerm_cdn_frontdoor_origin_group.origin_group_web.id
  enabled                        = true
  certificate_name_check_enabled = false
  host_name                      = azurerm_storage_account.storage_staticwebtorageachraf002.primary_web_host
  origin_host_header             = azurerm_storage_account.storage_staticwebtorageachraf002.primary_web_host

  http_port  = 80
  https_port = 443
  priority   = 1
  weight     = 1000
}


resource "azurerm_cdn_frontdoor_rule" "cache_rule" {
  depends_on = [
    azurerm_cdn_frontdoor_origin_group.origin_group_web,
    azurerm_cdn_frontdoor_origin.web_origin
  ]
  name                      = "static"
  cdn_frontdoor_rule_set_id = azurerm_cdn_frontdoor_rule_set.rule_set.id
  order                     = 1
  behavior_on_match         = "Stop"


  conditions {
    url_file_extension_condition {
      operator     = "Equal"
      match_values = ["css", "js", "ico", "png", "jpeg", "jpg", ".map"]
    }
  }
  actions {
    route_configuration_override_action {
      compression_enabled = true
      cache_behavior      = "HonorOrigin"
    }
  }
}


resource "azurerm_cdn_frontdoor_route" "default_route" {
  name                            = "default"
  cdn_frontdoor_endpoint_id       = azurerm_cdn_frontdoor_endpoint.web_endpoint.id
  cdn_frontdoor_origin_group_id   = azurerm_cdn_frontdoor_origin_group.origin_group_web.id
  cdn_frontdoor_origin_ids        = [azurerm_cdn_frontdoor_origin.web_origin.id]
  cdn_frontdoor_rule_set_ids      = [azurerm_cdn_frontdoor_rule_set.rule_set.id]
  enabled                         = true
  cdn_frontdoor_custom_domain_ids = [azurerm_cdn_frontdoor_custom_domain.ihelpyoutodo_domain.id]
  forwarding_protocol             = "MatchRequest"
  https_redirect_enabled          = true
  patterns_to_match               = ["/*"]
  supported_protocols             = ["Http", "Https"]
  link_to_default_domain          = false
}



resource "azurerm_cdn_frontdoor_custom_domain" "ihelpyoutodo_domain" {
  name                     = "yourdomain"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.fqdn_profile.id
  host_name                = "www.yourdomain.com"

  tls {
    certificate_type    = "ManagedCertificate"
    minimum_tls_version = "TLS12"
  }
}


resource "azurerm_cdn_frontdoor_custom_domain_association" "domain_association" {
  cdn_frontdoor_custom_domain_id = azurerm_cdn_frontdoor_custom_domain.ihelpyoutodo_domain.id
  cdn_frontdoor_route_ids        = [azurerm_cdn_frontdoor_route.default_route.id]
}

After deploying Azure Front Door, the next step is to configure a custom domain to serve our website.

Step 3: Configure a Custom Domain

To configure a custom domain, we need to make some changes in our DNS provider (in my case, GoDaddy). The first step is to add a TXT record in the domain’s DNS settings to validate the domain in Azure.

Ps : After you add the Text record , you need also to add 3 cname record that point to your front door default root that end with : .azurefd.net else you will have this error

Domain Validation Process

All domains added to Azure Front Door must be validated. This ensures protection against accidental misconfigurations and prevents domain spoofing. In some cases, Azure prevalidates the domain if it’s already verified by another Azure service. Otherwise, you must manually validate the domain following Azure’s verification steps.

One feature I really appreciate is that Azure Front Door can automatically manage TLS certificates for both subdomains and apex domains. With managed certificates:

• You don’t need to create, store, or manually install certificates.
• Azure automatically renews certificates, preventing downtime due to expired SSL certificates.

Note: The process of generating, issuing, and installing a managed TLS certificate can take several minutes to an hour, sometimes longer.

Once the domain is validated, you’ll see a status of Approved, and the TLS certificate will be deployed.

Final Step: Accessing the Website

Now that everything is set up, we can visit our website using our custom domain, benefiting from Azure’s global load balancing, caching, and security features!

Conclusion

In this tutorial, we successfully deployed a static website on Azure using Terraform. We:

• Created a Storage Account with static website hosting enabled.
• Deployed Azure Front Door to provide global load balancing, security, and performance improvements.
• Configured a custom domain and enabled managed TLS certificates.

This setup ensures high availability, security, and performance while keeping things simple with Terraform automation. Let me know if you have any questions or if you’d like a deeper dive into any of these steps!