Build and Optimize a Data Lakehouse for Unified Data Intelligence
Hello Folks! Welcome back to the ITOpsTalk Blog and the Microsoft Azure Infrastructure Summit 2026 series. In this session James Baker and Sai Runtham, both from the Azure Data Lake Storage product team, take us through what a modern Lakehouse actually is, how to design one on Azure, and then they roll up their sleeves and build one end to end. If you have been hearing “Lakehouse” thrown around in architecture reviews and were not 100% sure what it changes for you as an IT Pro, this one is for you. 📺 Watch the session: Why IT Pros Should Care You might be thinking, “I run infrastructure, not analytics.” Fair point. But here is the thing. The lakehouse is increasingly the platform your business will run BI dashboards, AI agents, and decision support systems on, and you are the one who has to keep the data safe, governed, and reachable. Here is what is in it for you: It is a platform conversation. James spends a big chunk of the session on horizontal platform capabilities (storage, catalog, identity, secrets, network, policy) versus vertical pipeline concerns. That is squarely an IT Pro problem. Data is the asset. Workspaces, query engines, and dashboards are transient. The data lives forever, and protecting it is on your plate. Governance is what stops your data lake from rotting into a data swamp. Scale is a virtuous cycle. More data drives more insight, which drives more data. Your platform cannot become the ceiling. AI agents are the new consumers. They do not just read dashboards, they query gold tables directly. Your network, identity, and access controls have to keep up. What is a data lakehouse A data lakehouse is exactly what it sounds like. You take the cheap, flexible, schema-light scale of a data lake, and you fuse it with the low-latency query performance, update semantics, and governance of a data warehouse. One copy of the data. One place to govern it. No more forking from the lake into a warehouse just to make BI tools happy. Quick contrast: Data lake. Big, cheap, flexible. No schema enforced on write. Historically prone to becoming a swamp. Data warehouse. Low-latency queries, updates, strong governance, structured. Hits a scale ceiling and costs more. Data lakehouse. Lake-scale storage, with a high-performance query layer and warehouse-grade governance sitting over the top. No data fork. The big shift is that the data does not move. Your BI dashboards, your AI agents, your serverless SQL queries, they all hit the same governed tables in the lake. That keeps lineage clean and your security model sane. Building it on Azure James and Sai are clear that the architecture is less a fixed diagram and more a list of platform capabilities you compose. Here is the shape of it on Azure. Storage layer (the asset). Azure Data Lake Storage Gen2 (ADLS) with hierarchical namespace turned on. That is non-negotiable for analytics workloads. It gives you atomic directory operations, POSIX-style ACLs, and the performance Delta Lake relies on. OneLake in Microsoft Fabric if you want a tenant-wide logical lake that is built on ADLS Gen2 and stores everything in open Delta Parquet by default. Table format and pipelines. Open table formats: Delta Lake (and Apache Iceberg as it converges) give you ACID transactions, time travel, schema evolution, and streaming on cheap object storage. Azure Databricks Lakeflow Declarative Pipelines with Autoloader for incremental ingestion of both batch and streaming sources straight into Delta tables. Autoloader handles new file discovery, schema inference, and evolution for you. The medallion architecture for stamping out repeatable pipelines: o Bronze. Raw, append-only landing zone. Source of truth. o Silver. Cleansed, deduplicated, conformed, enriched. o Gold. Business-ready, aggregated, performance-optimized for consumption. Governance and identity. Unity Catalog as the single source of truth for catalog, lineage, and fine-grained access control across bronze, silver, and gold. Entra ID for identity. Managed identities for compute. Key Vault for secrets. Network protection around the perimeter. The data is the crown jewel, so private endpoints, firewalls, and VNet-attached compute are baseline. Consumption layer. Power BI Direct Query against a serverless SQL warehouse on the gold tables. No data copies, governance flows through. AI agents like Databricks Genie pointed at gold tables. Natural-language questions, live lineage, no data movement. The demo that ties it together. Sai walked through a real pipeline: NYC TLC taxi trips enriched with NOAA weather and ESPN/MLB sports events, ingested by Autoloader into bronze, transformed through silver, aggregated into gold. A parallel streaming pipeline handled synthetic live events for a real-time demand view. Power BI dashboards hit gold via Direct Query. And Genie answered questions like “which zones are most sensitive to sport events” by mapping demand around Madison Square Garden, with the query and the chart generated for you. All against the same lakehouse, no data movement, full lineage. Optimizing for cost and performance This is where a lot of lakehouses go sideways. A few things from the session and from the official guidance worth pinning to your wall: Get hierarchical namespace right. It is the difference between atomic directory operations and “copy then delete,” which is slow and expensive at scale. Use storage tiers and lifecycle policies. Hot for working data, Cool or Cold for older partitions, Archive for compliance retention. Lifecycle rules on ADLS do this automatically. Partition and file-size matter. Lots of tiny files kill query performance. Use OPTIMIZE, Z-Order, or liquid clustering on Delta tables, and partition on the columns your queries actually filter on. Lean on vectorized reads. ADLS plus Delta plus modern query engines push a lot of work down to columnar Parquet, which keeps your compute bill in check. Use serverless SQL warehouses where it fits. Direct Query against a serverless endpoint scales compute to demand and lets you keep dashboards fresh without import refreshes. Observe data, not just systems. “Is Databricks up” is necessary but not sufficient. Watch data freshness, row counts, pipeline blockages, and SLAs on the data itself. Govern everything. A well-governed lakehouse drives trust, which drives use, which drives value. Skipping governance early always costs more later. Getting Started If you want to put hands on a keyboard this week: Spin up an Azure Storage account with hierarchical namespace enabled. That is your ADLS Gen2 foundation. Stand up an Azure Databricks workspace, enable Unity Catalog, and point it at your ADLS account. Create a Lakeflow Declarative Pipeline. Use Autoloader to ingest a sample dataset (the NYC taxi data is a classic starting point) into a bronze Delta table. Add silver and gold notebooks or pipelines that clean and aggregate the data. Connect Power BI to a serverless SQL warehouse on your gold tables with Direct Query. If you are a Fabric tenant, mirror or shortcut data into OneLake and try the same pattern there, no infra to manage. Read the Hitchhiker’s Guide to ADLS before you scale up. It will save you future you a lot of grief. Resources Introduction to Azure Data Lake Storage The Hitchhiker’s Guide to the Data Lake Microsoft OneLake documentation Azure Databricks documentation Delta Lake on Azure Databricks Design Delta Lake architecture and medallion patterns Implement medallion lakehouse architecture in Microsoft Fabric Watch the rest of the Summit This session is one stop on a big tour. The full Microsoft Azure Infrastructure Summit 2026 playlist covers everything from sovereign cloud and AKS networking to backup, storage, and AI-assisted operations. If your job touches Azure, there is something in here for you. Head over to the full playlist and binge what is useful: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki Cheers! Pierre RomanStop Hand-Building VMs at 2 AM: Automated Image Pipelines with Azure Image Builder and Compute Gallery
Hello Folks! If you have ever stood up a marketplace Ubuntu VM, SSH’d in, layered on your monitoring agent, security tooling, a couple of CA certs, and a hardening script, then captured the result and called it your “golden image,” I have bad news. That image was already drifting from the next one your coworker built before you finished naming the snapshot. At the Microsoft Azure Infra Summit 2026, Sandeep Raichura (PM for Azure Compute Gallery) and Kofi Forsen (PM for Azure VM Image Builder) rebuilt the whole workflow the right way. Source, customize, validate, distribute, deploy. No clicks. No tribal knowledge. No 2 AM heroics. 📺 Watch the session: Why IT Pros Should Care You carry the pager when a bad image rolls into ten regions. You explain why three teams have three different Ubuntu 22.04 baselines with three different agents. You find out at 2 AM that someone deleted “the old image” and the old image was the one production VMSS was still pulling. This session is in your lane. It covers: Why hand-rolled images stop working the moment a second team needs one. How Azure VM Image Builder (AIB) turns image creation into declarative pipeline code. How Azure Compute Gallery handles versioning, replication, sharing, and accidental-deletion protection. How automatic image creation triggers chain a marketplace update through your golden image, into every downstream image, with zero manual steps. How VM Scale Sets close the loop with rolling upgrades and automatic OS upgrade. In short, this is the practitioner version of “do VM image management properly,” from the PMs who own both services. What is Azure Image Builder and Azure Compute Gallery The two services do different jobs and you really do need both. Azure VM Image Builder is the build engine. You hand it a JSON template that declares: A source (marketplace image, managed image, VHD, or existing gallery version). Customizers (shell, PowerShell, Windows updates, file copies, restart steps). One or more distribute targets (usually a Compute Gallery image definition). AIB spins up a temporary build VM, runs your customizers in order, validates, generalizes, captures, and publishes. Every build runs the exact same way. No SSH, no RDP, no “I forgot to install the monitoring agent this time.” Azure Compute Gallery is the management layer for the resulting artifacts. Formerly Shared Image Gallery, it has three levels: Gallery. The top-level container. Sharing policy lives here: RBAC, Direct Shared Gallery, or Community Gallery. Image definition. The metadata. OS type, generation, security type, publisher / offer / SKU. The SKU of an image family. Image version. The actual replicated artifact. Controls regions, replica counts, storage type (ZRS by default), end-of-life date, and the safety flags. AIB writes the artifact. Compute Gallery stores, versions, replicates, and shares it. Building an automated image pipeline The session walked through the five steps a real pipeline needs, with no manual intervention in the critical path: Source. A marketplace image or any other base. Customize. Scripts that install agents, harden, configure, and validate. Stored in a storage account so AIB can pull them with the right managed identity. Validate. Built-in validation hooks plus your own smoke tests baked into the customizer. Fail fast. Do not silently continue. Distribute. Push the captured image to a Compute Gallery image definition. Pick your regions and replica counts here. Version. Compute Gallery handles semantic versioning, replication, and safety flags. The trick that makes this a real pipeline is the two-template pattern Kofi demoed: A source template builds the org-wide golden image from the marketplace base. Its source reference is set to latest for the marketplace SKU (for example, Canonical Ubuntu 22.04 latest). A distro template layers user-group-specific tooling on top of the golden image. Its source reference is the golden image gallery version, also set to latest. Both templates get an automatic image creation trigger attached. Triggers only fire when the template references latest. From that point on: Canonical publishes a new Ubuntu 22.04. The source template’s trigger fires, AIB rebuilds your golden image, and a new version lands in the source gallery. That new golden image version fires the distro template’s trigger. AIB rebuilds every downstream distro image automatically. VM Scale Sets configured for automatic OS upgrade pick up the new image version and roll it out in batches, pausing if the Application Health probe goes red. You set it up once. After that you only come back when you want to change something on purpose. Safety by design in Compute Gallery A bad image at the top of this chain takes out thousands of VMs at the bottom. Sandeep was clear: safety is not optional, it is built in. The four features worth turning on every time: ZRS storage by default. Image versions stored on zone-redundant storage so a zonal failure does not take the image down. Exclude from latest. Stage an image into a region without making it the default for new deployments. Flip the flag when you are ready to roll. You can set this globally on the version or per region. Block deletion before end-of-life. The image cannot be deleted until its end-of-life date. This is the flag that stops the 2 AM accidental delete. Soft delete. If everything else fails, soft delete gives you a recovery window to restore an image version that should not have been removed. Combine those four with a sane end-of-life date on every version and your blast radius drops dramatically. Real-world scenarios A few patterns that came up in the session and the Q&A: Multi-region fleets. Define your target regions in the AIB template. AIB hands the artifact to Compute Gallery and Compute Gallery does the replication. Your scale sets in every region pull a local replica, not a cross-region copy. Open-source publisher. Use a Community Gallery so anyone in Azure can deploy your image. You provide a contact URL and email at the gallery level so consumers know where to file issues. Partner sharing. Use Direct Shared Gallery to grant specific subscriptions or tenants access without making the image public. VM Scale Sets with rolling upgrade. Reference the image definition (not a specific version) when you create the scale set. The scale set tracks latest. Pair it with a rolling upgrade policy and the Application Health extension. AIB publishes, Compute Gallery replicates, the scale set rolls, and the rollout pauses itself if the Application Health probe goes red. Getting Started Pick the highest-pain item and start there. You do not have to do this all at once. Stand up a Compute Gallery in one region. Create one image definition with proper publisher / offer / SKU metadata. Turn on soft delete at the gallery. Wrap an existing build script in an AIB image template. Use a marketplace image as the source. Distribute to your new gallery. Add excludeFromLatest, endOfLifeDate, and the block-deletion flags to your image version. Default to ZRS storage. Register the Microsoft.VirtualMachineImages and the triggers feature. Attach an automatic image creation trigger to the template. Set the source reference to latest. Build a second template that takes your golden image as its source. Attach a trigger to that one too. Create a VM Scale Set that references the image definition and enable automatic OS upgrade with rolling upgrades and the Application Health extension. That is the loop. Source updates flow through automatically. Bad images do not delete each other. Fleets roll forward in batches. Resources Azure VM Image Builder overview. The service concepts, supported OS, regions, and capabilities. Azure Compute Gallery overview. Gallery, definition, version, replication, and sharing. Azure VM Image Builder best practices. Identity, networking, customizers, and operational guidance from the product team. Automatic Image Creation with Image Builder triggers. Step-by-step to wire up source-image triggers. Create an image definition and image version. Portal, CLI, PowerShell, and REST flows for publishing artifacts. Automatic OS image upgrades for VM Scale Sets. The closing leg of the pipeline. Share images using Community Gallery. Public, non-commercial sharing for open-source publishers. Azure Image Builder samples on GitHub. Reference templates, customization scripts, and end-to-end examples. Watch the rest of the Summit This session was one of many at the Microsoft Azure Infrastructure Summit 2026. If you want the keynotes, the IaC deep dives, the AKS sessions, and the rest of the infra track, the full playlist is here: Microsoft Azure Infra Summit 2026 playlist Cheers! Pierre RomanDeployment Stacks: Treating Your Azure Deployments Like Real Resources
Hello Folks! If you have ever come back from vacation to find a “mystery” storage account no one remembers creating, or watched a junior admin nuke a production resource because they clicked the wrong tile in the portal, this session is for you. Sydney Smith from the Azure Deployments team walked through Deployment Stacks at the Microsoft Azure Infrastructure Summit 2026, and the message is simple: classic Azure deployments are just history records, and history records cannot protect anything. Deployment Stacks change that. A stack is a real Azure resource. It has a resource ID. It supports RBAC. It tracks what it owns. It can refuse to let people break it. That is a real upgrade to how we run Infrastructure as Code in Azure, and IT pros should be paying attention. 📺 Watch the session: Why IT Pros Should Care Let me cut through the noise. Here is why this matters to anyone running Azure infrastructure: Orphaned resources cost real money. Classic deployments do not track ownership. Remove a resource from your template, and the live resource sits in Azure forever, billing you and adding security risk. Deployment history is fragile. Anyone can groom it away. You lose the audit trail. There is no native change protection. Without stacks, the only thing standing between your production VNet and a midnight portal click is RBAC discipline. That is not enough. Drift is invisible. You cannot detect what you cannot define as the source of truth. No unified view. Resources scattered across resource groups or subscriptions are hard to manage as one unit. Stacks give you a single lifecycle aware unit, with built in guardrails, that you can govern with RBAC and policy like any other Azure resource. That is the kind of plumbing IT operations has been asking for. What are Deployment Stacks A deployment stack is a native Azure resource that manages a group of resources as one lifecycle aware unit. It is the modern evolution of Azure deployments. Where a classic deployment is a record of what happened, a stack is a living thing that knows what it owns. Key facts to anchor on: A stack is of type Microsoft.Resources/deploymentStacks. It is a first class Azure resource. A stack can span multiple resource groups and even multiple subscriptions. You feed it a Bicep or ARM JSON template, the same files you already have. No rewrite required. It produces a snapshot of the resources it manages, and uses that snapshot for lifecycle decisions. Two feature sets do the heavy lifting: Resource lifecycle management. Creates, updates, and deletes across scopes are managed as one operation. Resource change protection. Stacks can apply deny assignments on the resources they manage, blocking changes that did not come through the stack itself. That second point is the one that changes how you think about safety in production. How Deployment Stacks change your workflow Honestly, the syntax change is tiny. If you know az deployment group create, you already know az stack group create. Same template, same parameter files, same scope. You just swap deployment for stack and add a couple of new parameters. What changes in the day to day: Your template becomes the source of truth. Remove a resource from Bicep, and the next stack run can clean it up automatically. No more manual hunt and delete. You get a portal view. The stack resource shows you what it manages, what is detached, and what the deny settings look like. You can clean up everything in one step. Deleting a stack with the right unmanage setting tears down all its resources and the empty resource groups, without you mapping out dependency order. Pipelines get cleaner. The bicep-deploy GitHub Action and the equivalent Azure DevOps task speak stacks natively. Create, validate, what-if, delete. Same shared package on the backend, so features hit GitHub and ADO at roughly the same time. The honest tradeoff: stacks are powerful enough to delete things at scale. That is the whole point. So you need to think harder about which mode you pick. Deny settings and lifecycle control Two parameters carry most of the weight, and you need to understand both before you push a stack into production. action-on-unmanage controls what happens when a resource leaves the template: detachAll: resources stay in Azure, the stack stops tracking them. This is the default and the safest. No delete operation. Good when you are still learning stacks. deleteResources: resources are deleted, the resource group stays. deleteAll: full cleanup. Resources go, empty resource groups go. This is what you pair with strict deny settings if you want the template to be the only source of truth. deny-settings-mode controls who can change what: none: no protection. Anyone with RBAC can do anything. Use this only when you really mean it. denyDelete: blocks delete operations. Updates are still allowed. denyWriteAndDelete: the strict one. No changes outside the stack. This plus deleteAll makes your template the absolute source of truth. A handy escape hatch: excludedActions lets you punch specific resource types or operations through the deny wall. For example, you can deny delete across the board but allow deleting your managed identities or storage accounts. Use this sparingly. Every exception is a future ticket. A few honest tradeoffs to keep in mind: denyWriteAndDelete is strict on purpose. Portal admins will get permission errors. That is the feature, not a bug. Train your team. deleteAll is permanent. Pair it with what-if before every change so you do not nuke something by accident. Resources should not be managed by two stacks. The deny assignments from each stack will fight each other and block updates. If two apps share a SQL database, pull it in as an existing resource rather than dual managing it. Stacks are not just for Bicep. They consume ARM JSON templates today. Terraform users do not get the same first party stack experience, so if you live in Terraform world, stacks are not your tool. Getting Started You do not need a giant rollout plan. Pick something small and learn the parameters in a safe environment. A practical path: Pick a non production Bicep template you already trust. Anything that creates a small set of resources in one resource group works. Deploy it as a stack with safe defaults. Use actionOnUnmanage=detachAll and denySettingsMode=denyDelete. You get protection without risking accidental deletes. Try removing a resource from the template and redeploy. Watch how the resource shows up as detached in the portal. Get comfortable with what that looks like. Graduate to deletes. When you trust the workflow, switch to deleteResources or deleteAll in a dev environment. Always run what-if first. Adopt Stacks What-If. The newer Stacks What-If commandlet triangulates the stack snapshot, the live resource state, and the desired state from your template. The result is a far less noisy diff than classic what-if, and the RBAC model only needs read access on the what-if resource for follow up gets. Big win for production review workflows. Wire it into your pipeline. The bicep-deploy GitHub Action and the Azure DevOps task both support type: deploymentStack with create, validate, and delete operations. Start with a create pipeline, then add a what-if pipeline for PR validation, then a cleanup pipeline that uses delete to tear down ephemeral environments. If you hit an out of sync error between your stack and Azure, the bypass-stack-out-of-sync-error parameter lets the pipeline reconverge automatically instead of forcing a manual cleanup. Read the docs before you flip it on, but it saves real time when state drifts. Resources Create and deploy Azure deployment stacks in Bicep Bicep documentation on Microsoft Learn What-If for ARM and Bicep deployments Deploy Bicep files by using GitHub Actions Azure Bicep on GitHub Bicep Deploy GitHub Action and ADO task Bicep and ARM community news and monthly call signup Watch the rest of the Summit If this session helped, there are plenty more where it came from. The full Microsoft Azure Infrastructure Summit 2026 playlist covers everything from Azure Local and Azure Files to AKS networking, SRE agents, and the keynote with Jeremy Winter. Worth a binge if you run Azure infrastructure for a living. Microsoft Azure Infrastructure Summit 2026 playlist Cheers! Pierre RomanLock Down AKS End to End with Application Gateway for Containers and Managed Cilium L7
Hello Folks! If your AKS cluster looks like most production clusters I have walked through, one of two things is true. Either nobody writes any network policies and every pod can talk to every other pod, so one compromised container blows up the entire blast radius. Or somebody wrote a few coarse rules along the lines of “namespace A talks to namespace B over port 80”, which sounds secure right up until an attacker realizes that port 80 is exactly where they were planning to live anyway. Real attacks happen at Layer 7, dressed up like ordinary HTTP traffic, and L3 / L4 plumbing cannot tell the difference. That is the gap session MAIS09 from the Microsoft Azure Infrastructure Summit 2026 closes. Vyshnavi Namani and Darshil Shah from the Azure Networking product team walked through how two AKS-managed add-ons, Application Gateway for Containers (AGC) and Cilium L7 via Advanced Container Networking Services (ACNS), can lock down the entire path from the public internet to a single pod. No NGINX. No external WAF appliance. No third-party CNI to babysit. 📺 Watch the session: Why IT Pros Should Care Let me cut to the chase. If you operate AKS clusters today, this session matters because: You probably still have an ingress controller and an external WAF stitched together with annotations and prayers. AGC plus ACNS collapses that stack into first-party add-ons that AKS owns end to end. Both Application Gateway for Containers and Advanced Container Networking Services are generally available. This is not a preview demo, this is production. Security is finally readable. Every rule is a YAML object. Code review, audit, GitOps. No more “what does this NGINX config map even do anymore” archaeology. It actually works on a real attack pattern. The demo shows WAF killing a SQL-injection-style GET that Cilium would have happily forwarded, because the method (GET) was on the allow list. If you have ever had to explain to an auditor why a single compromised pod could pivot across your whole cluster, this is your exit ramp. The AKS Security Gap This Closes Most clusters are protected by a load balancer at the edge and basically nothing inside. The cluster door looks like a vault, but the hallways are wide open. Cilium calls this the lateral movement problem, and it is exactly how Kubernetes attacks unfold in the wild. Compromise a pod, then phone home, then pivot. What MAIS09 demonstrates is something different. AGC is the L7 front door (the metal detector at the lobby). ACNS Cilium L7 is the lock on every pod’s office door. Both speak HTTP. Both enforce identity. Both are managed by AKS itself. The legacy alternative, Application Gateway Ingress Controller (AGIC), bolted a full Application Gateway onto your cluster through a translator. Two services, two lifecycles, two finger-pointing teams when something broke. AGC is the successor, built from scratch for Kubernetes, speaking the Gateway API natively, enabled with a single AKS flag. AKS provisions the controller, wires the identity, delegates the subnet, and owns the upgrades. You own the policies. AGC + Managed Cilium, End to End Here is the mental model from the session. Picture four concentric layers of defense between the public internet and a pod. AGC front end. One Azure resource, one public DNS name, and (thanks to the Kubernetes Gateway API) multiple hostnames behind the same IP. The demo runs Contoso, Fabrikam, and Adventure Works on a single AGC public IP using three HTTPRoute objects. One infrastructure, three websites. Real cost savings, real ownership clarity (platform owns the Gateway, app teams own the HTTPRoutes). Azure WAF on AGC. This is the content inspector. It runs the OWASP Core Rule Set (DRS 2.1 in the demo) against every incoming request, looks for SQL injection, cross-site scripting, path traversal, and the rest of the OWASP Top 10, and returns a 403 before the packet ever touches your pod. Microsoft maintains the rule set, you bind it to AGC via a SecurityPolicy. ACNS Cilium L7 ingress on every pod. This is where identity-based policy lives. Rules key off pod labels, not IPs, because IPs change every time the cluster autoscaler does its job. The demo uses an allow-agc-l7-get-only CiliumNetworkPolicy that lets the AGC backend reach the tenant pods, but only with GET or GET /products. Anything else, POST, PUT, DELETE, gets a Cilium-synthesized 403 before NGINX ever sees the request. ACNS east-west and egress policy. Two more policies do the heavy lifting inside. client-may-call-contoso-get-only lets the client pod reach Contoso with GET, and only Contoso. A default-deny baseline blocks everything else (pod-to-pod and pod-to-internet) with a single carve-out for kube-dns on port 53. The magic is that the same Cilium engine handles north-south, east-west, and egress with one consistent identity model. eBPF in the Linux kernel does the enforcement on the same node as the pod, so the decision happens before the packet leaves the host. No sidecars, no iptables sprawl, no daemonset you need to upgrade by hand. Real-world Scenarios The demo walks through six tests and the results map directly onto things you are probably trying to solve right now: Multi-site hosting on one IP. Three hostnames, one AGC, three 200 OKs from three different backend pods. If you are paying for three load balancers today, you can stop. WAF blocks a malicious GET that ACNS would have let through. This is the punch line of why you need both layers. The method (GET) is on the Cilium allow list, but the payload is a SQLi pattern. WAF returns 403 at the edge. Defense in depth, working as advertised. Method enforcement at the pod door. GET returns 200, POST/PUT/DELETE return 403, GET /admin returns 403, GET /products returns 200. Cilium is doing actual HTTP inspection, not just dropping packets. East-west enforcement with readable verdicts. Client to Contoso GET is 200. Same client, same destination, POST is 403 (L7 deny, TCP completed). Client to Fabrikam is 000 (L4 drop, no TCP handshake). Reading the difference between 403 and 000 is now a debuggable signal, not a mystery. Default-deny egress kills phone-home. A pod tries to reach bing.com. DNS resolves (the carve-out works), TCP SYN goes nowhere, wget gives up with exit code 1. If that pod was compromised and trying to exfiltrate data, this is where the attack chain dies. Selective allow still works. Same pod, same tools, but a DNS lookup against kube-dns inside the cluster returns instantly. We did not unplug the network. We locked it down with a purpose. Honest tradeoffs to call out. The session does not pretend everything is free. AGC introduces a billed subnet association and a managed identity you do not manage in BYO mode. Cilium L7 needs the Cilium data plane (ACNS Container Network Security features are Cilium-only). The Envoy proxy that handles L7 inspection has a cost only when you actually enforce L7, which is a fair deal in my book. Getting Started If you want to try this on a cluster of your own, three flags do most of the work on az aks create: --network-dataplane cilium (turns on the eBPF data plane) --enable-acns (enables Advanced Container Networking Services, including Hubble observability and Cilium L7 policy) --enable-app-routing or the ALB add-on flag (provisions the AGC controller as an AKS-managed add-on) From there you write four YAML objects: a default-deny CiliumNetworkPolicy, an allow-DNS carve-out, an AGC ingress allow with method and path constraints, and your east-west allow rules. The session repo includes the full set so you can clone and follow along. One bonus worth knowing about. ACNS ships Hubble out of the box, with pre-built Azure Managed Grafana dashboards. Flow logs, service maps, policy hit counts. Even on pods that are not yet under L7 enforcement, you get observability for free. When something breaks at 2 a.m., you have an audit trail instead of a tcpdump. Resources Azure Application Gateway for Containers documentation Set up Layer 7 policies with Advanced Container Networking Services AKS security concepts Cluster security best practices for AKS Container Network Observability for AKS (Hubble, Prometheus, Grafana) Advanced Container Networking Services hands-on lab Use cases of Advanced Network Observability for AKS (Azure Networking Blog) Watch the Rest of the Summit If MAIS09 hit the spot, there are dozens more sessions in the same playlist covering AKS networking at scale, Azure Local, AVM, the new Deployment Agent, and a lot more. Grab a coffee and binge. Microsoft Azure Infrastructure Summit 2026 playlist Cheers! Pierre RomanBest practices for Infrastructure as Code CI/CD on Azure
Hello Folks! If your IaC repo has a dev folder, a test folder, and a prod folder that all started out identical and have since drifted in three different directions, this session is for you. At the Microsoft Azure Infrastructure Summit 2026, Jack Tracey and Jared Holgate (the team behind Azure Landing Zones and Azure Verified Modules) laid out, in plain language, how to ship Infrastructure as Code on Azure without leaking secrets, blowing up production, or duplicating thousands of lines of module code across folders. Here are the bits that matter most for IT Pros and platform engineers. 📺 Watch the session: Why IT Pros Should Care You are the one paged at 2am when a pipeline rolls out a broken NSG rule. You are the one carrying the cert that the deploy service principal still uses. You are the one explaining to audit why the prod plan and the prod apply ran with the same Owner-scoped identity. So this session is squarely in your lane. It covers: Why hand-rolled modules are slowly becoming an anti-pattern on Azure. A repo layout that scales to dozens of environments without copy-paste. How to get rid of static client secrets and federated cert auth, for good. Where approvals actually need to live in GitHub vs. Azure DevOps so they cannot be bypassed. The three-layer Terraform state model that Microsoft uses inside Azure Landing Zones. In short, this is the practitioner version of “do IaC properly,” from the people who write the platform code Microsoft ships. The IaC CI/CD problem Jack opened with a slide that gets a knowing laugh from anyone who has been doing this for more than a year. You start with one repo, one Bicep file, one happy team. Eighteen months later, you have a landingzone-prod-v2-final-USE-THIS-ONE folder, a service principal whose secret expired two days ago, and a pipeline nobody dares touch. The drivers of that pain are consistent: Modules written from scratch, never tested the same way twice. Per-environment folders that diverge silently over time. Long-lived secrets and certificates sitting in pipeline variables. One identity doing both plan and apply, with Owner on the management group. No approvals, or approvals in the wrong place. No tests until the deploy fails in prod. The good news is none of these problems are new, and the patterns to fix them are well understood. The session walks through them in the order you would actually adopt them. Patterns that work in production 1. Don’t write modules. Consume Azure Verified Modules. This is best practice number one, and Jack and Jared spent a full chapter on it for a reason. Azure Verified Modules (AVM) is the official Microsoft initiative that consolidates IaC modules for Azure into a single, supported, Well-Architected-aligned library, available in both Bicep and Terraform. The Bicep versions live in the Public Bicep Registry under the avm/ namespace. The Terraform versions live on the HashiCorp Terraform Registry under Azure/avm-*. What you get for free when you consume an AVM module: Defaults that line up with the Well-Architected Framework (RBAC over access policies, TLS 1.2, private endpoint support out of the box). Semantic versioning so you can pin and review the diff before upgrading. Deployment tests on every module, run by the AVM team. A real Microsoft support path, not a random GitHub issue. A great backchannel question came up about brownfield. Jared’s answer: AVM is just standard IaC, no special tooling. In Bicep, brownfield adoption is straightforward because there is no state. In Terraform, the new import blocks make it less painful than it used to be. 2. One folder, one source of truth Repo layout is where most teams go wrong, and the fix is simple. You should have one set of module code, and per-environment differences should be expressed as data, not as duplicated code. In Bicep, that means a single main.bicep and one .bicepparam file per environment. In Terraform, the same main.tf with one .tfvars file per environment. If you find yourself copying a module folder to dev, test, and prod, stop. Within six months those three folders will not look the same, and at that point you no longer have IaC, you have three handwritten environments that happen to be checked into Git. 3. Kill static secrets. Use Workload Identity Federation. This was the chat highlight. The question came in: “So in short, replace all service principals with credential secrets with user-assigned managed identity?” Jack and Jared both replied within seconds: yes, 10 points to you. Workload Identity Federation (OIDC) lets your GitHub Actions or Azure DevOps pipeline exchange a short-lived token from its own OIDC provider for a Microsoft Entra ID token. No client secrets, no certs to rotate, no Key Vault dance to retrieve them. A couple of things to know: Subject claim format differs by platform. GitHub uses repo:org/repo:environment:prod style claims; Azure DevOps uses sc://org/project/connection. Pick the right one or auth silently fails. Use a user-assigned managed identity as the target. It survives the pipeline being deleted and gives you one place to manage role assignments. The Azure Bicep Deploy GitHub Action and the official AzureRM / AzAPI Terraform providers all support OIDC natively. 4. Split plan from apply Even with OIDC, a single Owner-scoped identity that does both terraform plan and terraform apply is a problem. Plan needs Reader (and a few read-data permissions). Apply needs Contributor or Owner depending on what you deploy. Split them into two identities, federated to two different stages of your pipeline, and you have a real least-privilege story to take to your security team. Securing the pipeline Auth is half the story. The other half is making sure only the right pipelines, with the right approvals, can use those identities at all. Governed templates. Keep reusable pipeline templates in a separate, locked-down repo. Pin federated credentials or service connections to those templates via the job_workflow_ref claim on GitHub or required template checks on Azure DevOps. If someone forks the workflow, the OIDC exchange refuses to issue a token. Approvals in the right place. On GitHub, use Environments and require reviewers on prod. On Azure DevOps, put the approval on the Service Connection, not the Environment. The Environment approval can be bypassed by a clever YAML author. The Service Connection approval cannot. Shift left, hard. Pre-commit hooks for bicep format and terraform fmt, lint on every PR, GitHub Advanced Security for secret and code scanning, automated tests on PRs, and ephemeral test environments spun up per PR and torn down at the end. One attendee mentioned using Pester for end-to-end infra tests against a sandbox sub. That is exactly the pattern. Three-layer state. For Terraform on Azure Landing Zones, the recommended split is: platform landing zone (one state), application landing zone / subscription vending (one state per landing zone), application workload (one state per workload). Never collapse all subs into one state file. You will regret it the first time someone runs apply at the wrong time. Getting Started You do not have to do all of this at once. Pick the highest-pain item first. Still using client secrets in pipelines? Fix that this sprint. Wire up OIDC and a user-assigned managed identity. Drifting per-environment folders? Consolidate to one module plus per-env param files. Writing your own storage account module for the fifth time? Try the matching AVM module from the registry. Put approvals on the Service Connection (ADO) or Environment (GitHub) for prod. Add linting and pre-commit hooks. Split plan and apply identities. Layer your Terraform state. It is a roadmap, not a weekend project. Every step pays back the moment you take it. Resources Azure Verified Modules portal. the official AVM home, with module indexes for Bicep and Terraform, specs, and FAQ. Azure Verified Modules on GitHub. the tracking repo and source of truth for module proposals. Bicep on Microsoft Learn. official language docs, deployment guidance, and references for the public registry. Azure Bicep Deploy GitHub Action. the OIDC-friendly action for deploying Bicep from GitHub Actions. GitHub Actions for Azure on Microsoft Learn. Workload Identity Federation setup for GitHub Actions targeting Azure. Configuring OpenID Connect in Azure (GitHub Docs). the canonical OIDC subject claims and federated credential walkthrough for GitHub. Azure Pipelines documentation. service connections, approvals and checks, required templates, and YAML reference. Watch the rest of the Summit This session was one of many at the Microsoft Azure Infrastructure Summit 2026. If you want the keynotes, the Bicep deep dives, the AKS sessions, and the storage track, the full playlist is here: Microsoft Azure Infra Summit 2026 playlist Cheers! Pierre RomanBuilding Secure, Well-Architected Azure Workloads with Azure Verified Modules and GitHub Copilot
Hello Folks! If you have been writing Bicep or Terraform for Azure over the last few years, you have probably lived this story. You pick a community module, it works great for six months, then the maintainer moves on, issues stop getting answered, and you are stuck owning code you never wrote. At the Microsoft Azure Infra Summit 2026, Jack Tracy and Jarrod Holgate (tech leads on the Azure Verified Modules project) walked us through how AVM solves that, and how pairing it with GitHub Copilot and Spec Kit changes the way IT pros build Azure workloads. 📺 Watch the session: Why IT Pros Should Care This is not a developer-only topic. If you are the person responsible for landing zones, platform engineering, or the IaC pipelines that other teams ship through, this hits you directly. You stop owning home-grown storage account and VNet modules that no two teams write the same way. You get secure-by-default resources without having to draft a 40-page internal coding standard. You can let application teams move fast without sacrificing the Well-Architected Framework guardrails you care about. You get a supported, Microsoft-backed module library with a clear lifecycle, instead of betting on an abandoned repo. You finally have a deterministic way to put AI to work on infrastructure code without it inventing things you do not want in production. If any of that sounds like a Tuesday for you, this session is worth 40 minutes. What are Azure Verified Modules Azure Verified Modules (AVM) is the official Microsoft infrastructure-as-code module library for both Bicep and Terraform. Jack put it plainly in the session: AVM is the one-time solution that is not going to go away, with ownership, a defined lifecycle, structure, and well-defined specifications. Here is what makes AVM different from the previous landscape of community repos: It is supported in multiple IaC languages today (Bicep and Terraform), with consistent specifications across both. Modules are aligned to the Azure Well-Architected Framework by default. Zone redundancy on, public IPs off, sensible TLS minimums, right out of the box. Everything is still flexible, you can override any of it via a parameter or variable. It is open source. People inside and outside Microsoft can contribute and maintain modules. It consolidates the older CARML and Terraform Verified Modules efforts under one roof, owned by Microsoft FTEs and backed by the AVM core team. AVM has three module classifications, and understanding them is half the battle: Resource modules. A one-to-one mapping to a single resource type, like a storage account or a virtual network. Need ten of them, loop the module ten times. Pattern modules. A collection of resources, usually built on top of resource modules, that delivers a bigger slice of an architecture. The Azure Landing Zone is roughly five pattern modules behind the scenes. Utility modules. Helpers you probably never call directly, but that the library uses for things like region lookups, SKU availability, and naming standards. One thing that gets undersold: AVM is not just for you. The Azure Developer CLI templates use it. Azure Landing Zone and Sovereign Landing Zone are built on it. Internal Microsoft service teams use it. When you adopt AVM, you are using the same building blocks Microsoft uses. Pairing AVM with GitHub Copilot This is where the session gets interesting. AVM gives you the trusted Lego bricks. GitHub Copilot gives you a coding assistant. The problem, as Jack called out, is that AI is non-deterministic by default. It is great at solving ambiguous problems, but you cannot just point it at a blank repo and trust it to stamp out production infrastructure. That is the gap spec-driven development is designed to fill. Spec-driven development is a documentation-first approach. Instead of telling Copilot “write me a Terraform module for a hub-spoke network,” you write a structured specification up front that captures intent, quality bar, security requirements, and coding standards. The AI then uses that spec as the contract, generates code, validates against it, and loops until the output matches what you asked for. Jarrod walked through Spec Kit, the open source toolkit maintained by GitHub and Microsoft, which formalizes this into eight steps: Constitution. The non-negotiables. “We must use AVM. We must comply with PCI. Optimize for cost.” This is your project DNA. Specify. What you actually want to build, focused on user goals and outcomes, not implementation details. Clarify. Copilot scans the spec, finds ambiguities, and asks you targeted questions (IP ranges, bastion SKUs, anything that is fuzzy). Plan. A technical plan that maps the spec to your standards and constraints. Checklist. A quality checklist the agent uses later to validate its own work. Tasks. The plan broken down into small, reviewable steps. Analyze. A consolidated report across the spec, plan, and tasks so you can sanity check the whole package. Implement. Copilot finally writes the code, validating against everything above as it goes. The critical detail: at every one of those gates, you review. You are still the human in the loop. The AI is not flying solo, and you are not signing off on a thousand-line code dump. When you wire AVM into the constitution (“use AVM modules wherever possible”), Copilot stops trying to hand-roll raw resource declarations. It composes solutions out of trusted, tested, WAF-aligned modules. That is what makes the combination so powerful. Spec Kit is not the only option. Jack mentioned two others worth knowing about: OpenSpec. Leaner than Spec Kit, brownfield-first, aimed at smaller experienced teams. Squad. A completely different model built by a Microsoft team. No specs. Instead, a virtual team of agent personas (IaC specialist, UX, deployment, an orchestrator called Ralph) that collaborate to deliver work. Worth a look if your style is more agent-team than document-first. Real-world value So what does this actually buy you when Monday morning hits? Speed without sacrificing the bar. Application teams stop writing storage account boilerplate. They focus on what the workload needs to do, and the AVM modules handle the resilient, compliant defaults. Compliance becomes additive, not a rewrite. If you need to add HIPAA or NIST compliance later, you add another spec on top of your existing constitution and iterate. You do not throw out your modules. Less ambiguity loop, fewer tokens burned. A good spec up front means fewer Copilot iterations. You get to a working answer faster, with less back and forth. Trust in the AI output. Because AVM modules are tested, supported, and WAF-aligned, what Copilot stitches together is built on solid foundations. You can review the spec instead of every line of Terraform. Your developers shift up the stack. They stop writing IaC primitives and start designing architectures and requirements. That is where the business value lives anyway. A note on tradeoffs. AVM modules are intentionally generic and flexible, so you sometimes get parameters you do not need, and the well-architected defaults can be opinionated for your scenario. The fix is simple, override the parameter. You are trading some control for a lot of consistency, and for most teams that trade is the right one. Getting Started If you want to try this for yourself, here is the path I would take: Go to aka.ms/AVM and bookmark it. Everything starts there. Browse the Bicep and Terraform module indexes. Find the resource you would normally hand-write and try the AVM version in a dev subscription. Read the AVM specifications so you understand the contract every module follows. It makes the parameter sets a lot less surprising. Install Spec Kit via the Specify CLI (the GitHub repo has the instructions) and try the AVM example under the experimental “AI-Assisted Solution Development” section on the AVM site. Run the eight-step Spec Kit flow against a small workload. Do not start with your production landing zone. Pick something contained, like a single app with a web tier, a database, and a Key Vault. Keep the human in the loop. Review every spec gate. That is where the quality comes from. Resources Azure Verified Modules portal (aka.ms/AVM) Azure Verified Modules on GitHub Azure Verified Modules on Microsoft Learn GitHub Spec Kit Spec-driven development with AI (GitHub Blog) Implement spec-driven development with Spec Kit (Microsoft Learn) GitHub Copilot Azure Well-Architected Framework Watch the rest of the Summit If you found this useful, there is a lot more where it came from. The Microsoft Azure Infra Summit 2026 playlist covers landing zones, deployment stacks, AKS networking, storage, and the AI side of platform operations. Block out an afternoon and binge it. Microsoft Azure Infra Summit 2026 on YouTube Cheers! Pierre RomanDeploy an Azure Landing Zone in About Twelve Minutes with the ALZ IaC Accelerator
Hello Folks! Welcome back to my coverage of the Microsoft Azure Infra Summit 2026. This session is one I have been looking forward to, because if you have ever stood up an Azure Landing Zone (ALZ) by hand, you know it can eat weeks. Management groups, policy assignments, Hub-and-Spoke networking, log analytics, Defender for Cloud, identities, pipelines, governed branches. There is a lot of plumbing. In this session Jack Tracy (he leads the Azure Landing Zones team) and Jarrod Holgate (tech lead on Azure Landing Zones and Azure Verified Modules) walk through the ALZ Infrastructure as Code Accelerator. Then they actually run it, and a bootstrap that used to be a multi-week journey wraps up in about twelve minutes of typing and ticking boxes. 📺 Watch the session: Why IT Pros Should Care If you are the person who has to deliver a secure, governed Azure platform before your dev teams can land their first workload, this matters to you. Here is the short version of why: It bakes in the Cloud Adoption Framework “start right, stay right” pattern so you do not have to invent it. It supports both Bicep and Terraform, and it bootstraps GitHub or Azure DevOps for you (with a local file system option for GitLab, Bitbucket, or whatever else you run). It covers roughly 80% of common customer scenarios out of the box. You do not have to write modules from scratch. It is open source, every module is published, and you can fork or compose as you see fit. It is now built entirely on Azure Verified Modules (AVM), so what you deploy is aligned with the Well-Architected Framework by default. In short, if you have been hand-crafting management group hierarchies and policy assignments in the portal, stop. There is a better way, and the team that designs ALZ ships it as code you can actually read. What is the ALZ IaC Accelerator A quick recap, because it is worth getting the vocabulary right. The Azure Landing Zone lives inside the CAF Ready methodology. It is the shared platform (networking, identity, logging, policy, management groups) that supports the many application landing zones your workload teams consume. Jack uses a great analogy in the session: think of a metropolis. Before residents and businesses can move in, you need water, gas, electricity, and roads. The platform landing zone is the utilities layer. The application landing zones are the buildings. The ALZ IaC Accelerator is the tooling that deploys and manages that platform layer using declarative infrastructure as code. It is composed of: A set of IaC modules in Bicep and Terraform (all of them built on AVM). A bootstrap layer for GitHub or Azure DevOps (or local file system). The ALZ PowerShell module, published to the PowerShell Gallery, which orchestrates everything. Comprehensive docs covering prereqs, scenarios, and options. The accelerator is a Microsoft-supported, open source path to a production-grade landing zone. You should look at it before you decide to roll your own. How it works The accelerator runs in four phases. Jarrod walks through each of them in the demo. Phase 0: Plan. You make decisions: Bicep or Terraform, GitHub or Azure DevOps, single or multi-region, Hub-and-Spoke or Virtual WAN, Azure Firewall or NVA, DDoS on or off, and so on. Phase 1: Prereqs. Before the accelerator runs, you need two things in place: an identity to run the bootstrap, and the platform subscriptions. Traditionally this was four (connectivity, identity, management, security). There is now a new lighter option that needs only two subscriptions for smaller environments. Phase 2: Bootstrap. This is where the magic happens. You feed it a bootstrap configuration file plus a platform landing zone configuration file, then run the Deploy-Accelerator command. The PowerShell module deploys identities, optional Terraform state storage with private networking, optional self-hosted container-instance runners, and then sets up your repositories, pipelines, environments, governed pipeline templates, and OIDC-based service connections using Workload Identity Federation. No manual steps after Phase 2. Phase 3: Deploy. Run the CD pipeline. The platform landing zone deploys. Done. A few things worth highlighting about the bootstrap: The accelerator deploys two identities: one with read-only for plan / what-if, one with write for apply / deploy. Least privilege, out of the box. Pipelines are governed. The actual deployment pipeline lives in a separate template repository, so changes to it require an approval. A CI pipeline runs on pull requests automatically. You get the engineering hygiene without configuring it. Real-world scenarios and when to use it Jarrod calls these “scenarios” and “options”. They are the difference between picking a starting pattern (scenario) and tuning it (options). Scenarios. There are 11 of them out of the box. Pick the one that matches your starting state: Single region, Hub-and-Spoke, Azure Firewall. Multi-region, Hub-and-Spoke, Azure Firewall. Single or multi-region with Virtual WAN. Single or multi-region with a third-party NVA. No-connectivity (governance only, no Hub networking) for organizations who are not ready for centralized networking yet. New scenarios 10 and 11, which are cost-optimized for small and medium businesses with around 10 workloads. Same modules, same orchestration, just a smaller, cheaper starting shape. Sovereign landing zone for customers with data sovereignty and confidential compute requirements. Options. Once you pick a scenario, you can tune it. The 16 documented options are the ones the team sees customers ask about most often: customizing resource names, customizing management group names, turning the DDoS protection plan on or off, choosing the sovereign baseline, and more. Behind those, Terraform alone exposes hundreds of variables. Honest tradeoffs (because Pierre always tells you the rough edges): OpenTofu is not supported today. Just Bicep and Terraform. Personal Access Tokens are still required for Azure DevOps and self-hosted agents at the time of the session. The team has confirmed CLI / managed identity support is on the roadmap. Brownfield is “it depends”. The accelerator is greenfield-friendly. Retrofitting an existing tenant is possible but is going to depend on your current state and your risk appetite. You still own decisions. The Lady Justice slide in the session is a great reminder: balancing dev team freedom with central governance is your job. The accelerator gives you the controls; it does not pick your policy posture for you. Getting Started If you want to try this without waiting, here is the path Jarrod actually demoed: Install the ALZ PowerShell module from the PowerShell Gallery. Create your platform subscriptions (two minimum, four for the classic layout) and an identity for the bootstrap. Run Deploy-Accelerator with no parameters. It will prompt you interactively for everything: region, parent management group, subscriptions, naming convention, self-hosted agents yes or no, private networking yes or no, PAT, project name, and approvers. Review the two generated configuration files: the bootstrap config and the platform landing zone tfvars (or Bicep params). Confirm. The bootstrap runs Terraform behind the scenes and wires up Azure plus your repos. Run the CD pipeline. Approve at the apply stage. Your platform deploys. If you are not ready to drive Terraform directly, the Azure Migrate AI agent (in preview) wraps the exact same accelerator codebase behind a guided chat experience. You answer questions, it produces a zip with the same two config files plus a design document explaining the decisions it made. Then you hand that off to the same pipeline. The Azure MCP server has matching tooling for VS Code, so day-two changes like “turn off the DDoS protection plan” know to also uncomment the dependent policy assignments in the archetype files. That is the kind of context-aware editing that saves you from breaking your own deployment. Resources Azure Landing Zone in the Cloud Adoption Framework ALZ Accelerator hub (entry point for docs, scenarios, options) ALZ Terraform Accelerator on GitHub ALZ-Bicep on GitHub Azure Landing Zones Library (policies and archetypes) Azure Verified Modules Raise issues or feedback for the ALZ team Watch the rest of the Summit If you found this useful, the full Microsoft Azure Infra Summit 2026 playlist has a lot more: deployment stacks, Bicep beyond the basics, IaC CI/CD best practices, AVM with GitHub Copilot, and plenty of AKS and storage sessions. Grab the playlist here: Microsoft Azure Infra Summit 2026 on YouTube. Hit the ALZ team in the comments on the session, or open an issue on the repo. The team is genuinely active there. Cheers! Pierre RomanFrom Prompt to Provisioned: A Closer Look at the Azure Deployment Agent
Hello Folks! If you sat through this session during the Microsoft Azure Infra Summit 2026, you already know that Anand Guruswami and Arun Rabindar from the Cloud Native Experiences team showed us something I have been waiting to see for a while. An AI agent that does not just spit out a Terraform file from a vague prompt, but actually thinks about your workload, talks to you about it, and then hands you something you can put in front of a pull request reviewer without holding your nose. This is the Azure Deployment Agent, and at the time of broadcast it was still in preview inside Azure Copilot, with the same brains shipping as an open source skill you can plug into GitHub Copilot, Claude Code, Cursor, or whatever your team uses. In this post I want to break down what they showed, why it matters for IT pros, and how you can get hands on with it. 📺 Watch the session: Why IT Pros Should Care Let us be honest about the day to day. Most of the time we are not building a brand new workload from a blank canvas. We are stitching resources together one at a time, copying patterns from a previous project, hunting down the right SKU, checking quotas, then arguing with policy on the way out the door. Different admins do it different ways, and that inconsistency is where risk lives. Here is what the Deployment Agent changes for us: It moves the conversation up a level, from “which resource do I click” to “what am I actually trying to build.” It grounds the architecture in the Azure Well-Architected Framework, so the output is not a generic LLM guess, it has reasoning behind it. It separates the plan from the code, so you and your team get to review architecture before any Terraform or Bicep gets written. It plugs into the tools we already use. Azure portal for the guided path, GitHub Copilot and Claude Code for the power user path. In short, it's about taking the boring repetitive parts off our plate so we can focus on the parts that need human judgment. What is the Azure Deployment Agent The Deployment Agent is a capability inside the Agents (preview) experience in Azure Copilot. Think of it as a virtual cloud solution architect that lives in your Copilot chat. You describe the workload in natural language, and it walks you through a multi step process to land on a production ready deployment. A few things that stood out from Anand’s portion of the session: It supports multi turn conversation. You can clarify scale, security posture, resilience, SKU preferences, region constraints, and the agent will fold those into the plan. It produces a human readable infrastructure plan first, complete with trade offs and the reasoning for each resource choice, before it ever writes infrastructure as code. Today it generates Terraform inside the portal, with Bicep support landing in the portal experience shortly. In the GitHub Copilot flow you can already pick Bicep or Terraform. Once the plan is approved, you get a real artifact. You can open it in VS Code for the Web, or have Copilot open a pull request straight into your GitHub repo. The deployment itself still goes through Azure Resource Manager. That is important. Your tenant policies, RBAC, naming conventions, and existing guardrails all still apply. The agent is not bypassing your governance, it is generating code that flows through it. How it Works Arun did a great job pulling back the curtain on the internals. The agent follows a two step pattern that gives you control at every checkpoint. Intent capture. The agent takes your prompt and clarifies the scope, the constraints, and what success looks like. No guessing, no jumping straight to YAML. Plan generation. It produces a structured infrastructure plan with inputs, sub goals, a full resource list, configurations, SKUs, and a per resource reasoning section. Validation in a loop. The plan runs through evaluators backed by the Well-Architected Framework pillars (reliability, security, cost, operational excellence, performance efficiency). If something fails, the agent regenerates and tries again until the plan is solid. Human review. The plan is presented to you in plain language. You can iterate. You can say “prioritize West US 2,” or “swap that SKU,” and the agent will update the plan in place. Code generation. Only after you approve the plan does the agent emit Terraform or Bicep. The generated code goes through syntactic validation as well, again in a loop, so it actually parses and is ready to apply. Under the hood in the GitHub Copilot and Claude Code path, the team has decomposed all of this into an open source skill (the Azure Enterprise Infrastructure Planner) plus the Azure Well-Architected Framework as an MCP tool. The base agent in your editor picks up the skill, runs the phases, calls the MCP tool to ground the output, and then writes the IaC. Same workflow, different host. When to Use it / Real-World Scenarios This is not just a toy for greenfield demos. A few places where I see this paying real dividends: New workload bootstrapping. A team needs a web app, SQL backend, secrets in Key Vault, monitoring, and a sane region strategy. Instead of three days of clicking and copy pasting, you describe it and review the plan. CSV ingestion to SQL automation. The Claude Code demo Arun ran was exactly this. CSV lands, gets processed, rows update in SQL. The agent picked sensible resources, justified each one, and produced Bicep ready to commit. Standardizing across teams. Different admins ending up with different shapes for the same workload is the silent killer of operational consistency. A shared agent with a shared planner skill drags everyone toward the same Well-Architected baseline. Skill leverage for smaller teams. Not every team has a deep Azure architect on staff. The agent encodes a lot of that experience and surfaces it as conversation. Open source customization. Because the skill and MCP tooling are open, platform teams in regulated environments can fork it, add their policy context, their tagging rules, their naming conventions, and ship a tuned version internally. One honest tradeoff. Right now the agent is greenfield first. The team is actively working on brownfield scenarios, pulling insights from existing workloads and referencing existing resources. If you live entirely in a complex existing estate, expect the experience to keep getting better over the next couple of releases. Getting Started If you want to try it this week, here is the short list: Ask your Azure tenant administrator to enable Agents (preview) in Azure Copilot. The toggle lives in the Azure Copilot admin center, and without it you will not see agent mode in chat. In the Azure portal, open Copilot, expand to full screen, and switch on Agent mode at the bottom of the chat panel. Describe a workload in plain language. Be specific about region, scale expectations, and any compliance constraints you care about. Review the generated plan before approving. Look at the trade offs section, that is where the agent shows its work. For the editor path, install the open source Azure Skills plugin from the microsoft/azure-skills repo, point your IDE at the Azure MCP Server, and run the same workflow inside GitHub Copilot or Claude Code. Send feedback. The team is shipping fast and the roadmap (brownfield support, reference workloads, scoped agent permissions, richer architecture diagrams) is shaped by what you tell them. Resources Deployment agent capabilities in Agents (preview) in Azure Copilot: https://learn.microsoft.com/en-us/azure/copilot/deployment-agent microsoft/azure-skills, the open source skill plugin shown in the session: https://github.com/microsoft/azure-skills Azure MCP Server on the GitHub MCP Registry: https://github.com/mcp/com.microsoft/azure Azure MCP Server tools for the Well-Architected Framework: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-well-architected-framework Azure Well-Architected Framework documentation: https://learn.microsoft.com/en-us/azure/well-architected/ Agents (preview) in Azure Copilot overview: https://learn.microsoft.com/en-us/azure/copilot/agents-preview Watch the rest of the Summit If you enjoyed this session, the full Microsoft Azure Infra Summit 2026 playlist is up on YouTube. Sessions on Deployment Stacks, the SRE Agent, Azure Local, AKS networking, and a lot more are all in there. Bookmark this one and share it with your team: https://aka.ms/MAIS/2026-Playlist Drop your questions, your war stories, and your wish list for the Deployment Agent in the comments. I read them, the product team reads them, and your scenarios are exactly what shapes the next preview drop. What would you build with it first? Cheers! Pierre RomanBuild a Sovereign Private Cloud with Azure Local
Hello Folks! Picture this. A regulator hands you a one-pager that says, in essence, “this data does not leave the building.” Or your link to Azure decides to take a nap during a critical batch run. Or you are standing up infrastructure in a remote site where connectivity is a coin flip on a good day. For a long time, our answer to that conversation was a stack of Azure Stack boxes plus a lot of wishful thinking. That story has changed, and it has changed quite a bit. At Microsoft Azure Infra Summit 2026, Thomas Maurer (Global Black Belt for Sovereign Cloud) walked us through what is now called the Microsoft Sovereign Private Cloud, with Azure Local as its foundation. In this post, I want to unpack the session for the ITPros in the room, the folks who have to actually run this stuff on Monday morning. Let us dig in. 📺 Watch the session: Why IT Pros Should Care Sovereignty is no longer a niche conversation. Thomas was very clear that there is no one-size-fits-all answer, and that is exactly why this matters to us as operators. The drivers landing on our desks now include: Regulatory requirements that demand data residency or full operator isolation. Sovereign AI workloads where the model and the data both need to stay in-country. Disconnected and air-gapped sites by design (think defense, manufacturing floors, retail backrooms, ships, mines). Business continuity, meaning a workable Plan B if the public cloud is unreachable for hours or days. Latency-sensitive workloads where the round trip to a region is just too slow. If you build or operate infrastructure that touches any of those bullets, Azure Local is now a first-class option, not a sidecar. And it gets you a cloud-consistent control plane on top of hardware you can put your hands on. What is Azure Local and the Sovereign Private Cloud Let us level-set on the stack, from the metal up. Hardware. Validated and certified through the Azure Local solution catalog, delivered by the OEMs you already buy from. Form factors range from single-node edge boxes up to multi-rack deployments. There is a Premier tier with extra testing, packaged firmware and driver updates, and AI-ready GPU configurations done with NVIDIA. Software-defined data center. Compute, storage, networking, and high availability. As of April 2026, supported SAN storage is GA alongside the existing hyperconverged storage spaces direct model. That gets you up to 64 nodes in disaggregated mode and 16 nodes in hyperconverged mode per instance. Workload plane. Linux and Windows VMs, custom images, your own Kubernetes distribution, or AKS enabled by Arc with the same management experience you have in Azure today. Arc-enabled control plane. This is where Azure Local stops being “another on-prem stack” and starts feeling like Azure. Defender, Azure Monitor, Azure Update Manager, Policy, RBAC, Resource Manager, all of it surfaces against your on-prem instance. Disconnected operations. Microsoft packaged a subset of the control plane (portal, Resource Manager, key management services) into an appliance you deploy on-premises. Connect your Azure Local infrastructure to the local appliance instead of public Azure, and you have a fully air-gapped deployment with a familiar API surface. On top of that base, the Sovereign Private Cloud bundles workloads you can run locally: Foundry Local for AI inferencing, Microsoft 365 Local (Exchange Server, SharePoint Server, Skype for Business Server) for productivity fallback, Azure Virtual Desktop on Azure Local for VDI, and GitHub Enterprise Local (in private preview at the time of the session) for source and CI/CD. How it works in production In the demo, Thomas drove the whole show from the Azure Arc Center in the Azure portal. A few things stood out for me as someone who has spent too many late nights patching clusters. One pane, many sites. The overview page rolls up every Azure Local instance you own. Thomas mentioned customers running thousands of these things, and the Azure Local Lens workbook in Azure Monitor is built to manage at that scale. Resources feel like Azure resources. An instance, a node, a VM, an AKS cluster, they all live inside Azure Resource Manager. RBAC, activity logs, tags, ARM templates, everything you expect. Update is a single button. The Solution Builder Extension packages OS, management software, drivers, and firmware into one validated update. You hit “update,” it orchestrates live migrations node by node, and it blocks the operation if something is not ready. No more cherry-picking driver bundles at 2 AM. Security defaults are real. BitLocker on OS and data volumes, SMB signing, App Control on the hypervisor hosts, drift detection that flags configuration changes back to the portal. Resiliency is layered. Storage spaces direct two-way or three-way mirroring, rack-aware clustering, live migration for maintenance, and Azure Site Recovery for site-to-cloud replication (currently preview). Site-to-site ASR between two Azure Local instances is in development. Veeam, Rubrik, and Commvault all integrate for backup. In short, the boring operational moments are the ones that benefit the most. Patching, monitoring, identity, alerting, they collapse into the tools you already use in Azure. When to use it and real-world scenarios This is not a “rip everything out of Azure” pitch. Thomas was very honest. Azure is still the right home for the vast majority of workloads. Azure Local earns its keep in a few specific places. Regulated or sovereign workloads. Government, defense, financial services, healthcare where the law or the contract says the data stays put. Disconnected or air-gapped sites. Field operations, classified networks, ships, mines, remote infrastructure where reliable connectivity is not in scope. Business continuity for productivity. Microsoft 365 Local as a fallback for Exchange and SharePoint if the cloud service is unreachable. From the session Q&A, M365 Local is GA, and it is the Exchange / SharePoint / Skype for Business trio. Entra ID and Intune are not in scope of the local bundle. Edge and latency-bound workloads. Manufacturing line control, retail in-store inference, healthcare imaging, anywhere a 30-millisecond round trip is a problem. Sovereign AI. Foundry Local on Azure Local lets you serve models on local GPUs without round-tripping to the cloud. Models stay local, data stays local, inference stays fast. Bi-directional workload mobility. With Sovereign Private Landing Zones, you design once and keep workloads portable between Azure and Azure Local based on a service-compatible subset. Getting Started If you are picking this up cold, here is a sensible on-ramp: Start with the official docs on Sovereign Private Cloud and Azure Local. Read them with your architect hat on, not just your operator hat. Design matters here. Browse the Azure Local solution catalog and filter by Premier solutions and by your target scenario (disconnected operations, M365 Local, AI workloads, GPU support). The hardware shape drives a lot of downstream decisions. Talk to your OEM about a validated node, and talk to your Microsoft account team or a sovereign partner. The partner ecosystem in this space is mature, and they will save you weeks. Stand up a small connected instance first to learn the Arc Center experience, the update flow, and Azure Monitor integration. Even a one-node or two-node lab is enough to internalize the model. For disconnected, size for the extra capacity the control plane appliance needs, plan your local identity (Active Directory with AD FS) and your local monitoring integration up front. If you live in Azure today and need workload portability, look at Sovereign Private Landing Zones so you do not paint yourself into a corner with services that have no on-prem equivalent. Resources What is Sovereign Private Cloud? on Microsoft Learn Azure Local documentation Disconnected operations for Azure Local Azure Arc product page Azure Site Recovery product page Foundry Local documentation on Microsoft Learn Foundry Local on GitHub Sovereign Landing Zones on GitHub Watch the rest of the Summit This was just one of the sessions at the Microsoft Azure Infra Summit 2026. If you want more peer-to-peer technical content from the Azure infrastructure community, grab a coffee and queue up the full playlist here: https://aka.ms/MAIS/2026-Playlist There is plenty of good stuff covering Bicep, AKS networking, storage, IaC, and more. If you spin up an Azure Local instance after watching the session, or if you are already running one in anger, drop a comment and let me know how it goes. What works, what hurts, what you wish was better. That is how we all level up. Cheers! Pierre Roman
