Custom Detection Rules as Code in Sentinel Repositories: What Your Pipeline Owns Now
While going through the June Sentinel updates I almost scrolled past this one, and I think that would have been a mistake: custom detection rules can now be managed as code in Sentinel Repositories, the same way analytics rules, playbooks, parsers and workbooks already are. You connect a GitHub or Azure DevOps repo, enable the Custom Detection Rules content type, and rules are synced on every commit. There is also a standalone path via the Bicep CLI for teams running their own pipelines. The feature is in preview per the Learn documentation, and in my view it matters more than the low-key rollout suggests. Microsoft has been positioning custom detections as the unified experience for building rules over both Defender XDR and Sentinel data since late 2025. If custom detections are becoming the primary detection type, then this preview is the moment your primary detection type becomes pipeline-managed. I spent some time in the documentation to understand what that actually means, and there is one implication I have not seen anyone talk about yet. How it works Custom detection rules use a different mechanism than every other content type in Repositories. Analytics rules deploy as Microsoft.OperationalInsights/workspaces/providers/alertRules resources, with the Microsoft.SecurityInsights provider sitting in the resource name. Custom detection rules instead use a dedicated Bicep extension. You declare it in a `bicepconfig.json` at the repo root: { "extensions": { "MicrosoftSecurity": "br:mcr.microsoft.com/bicep/extensions/microsoftsecurity:v1.0.1" } } The rule itself is a `Microsoft.Security/detectionRules` resource. This is the structure from the Microsoft documentation: extension MicrosoftSecurity resource detectionRule 'Microsoft.Security/detectionRules@2026-06-01-preview' = { id: 'custom-rule-id' displayName: 'Custom Rule Display Name' status: 'enabled' queryCondition: { queryText: 'DeviceProcessEvents | take 10 | project DeviceId, Timestamp, FileName' } schedule: { frequency: 'PT1H' } detectionAction: { alertTemplate: { title: '<ruleTitle>' description: 'Custom detection rule' severity: 'medium' tactics: [ { tactic: 'Execution' techniques: [ { technique: 'T1059' } ] } ] entityMappings: { hosts: [ { id: 'h' deviceIdColumn: 'DeviceId' } ] } } } } Rules are uniquely identified by the `id` property, which you provide in the template. Deployment is either the automatic Repositories sync or a plain `az deployment group create` against a resource group. That last part is what I like most about the design: any CI/CD system that can run Azure CLI can ship these rules. Prerequisites beyond the standard Repositories setup: a Microsoft 365 E5 license or equivalent that includes Defender XDR, and a Sentinel workspace onboarded to the Defender portal. Two preview limitations are documented: custom frequency for Sentinel-only data is not supported yet, and neither are custom details. The part that made me stop reading and think Repositories are designed as the single source of truth. The documentation is explicit that content in your repo overwrites changes made through the portal. That is the whole point of the feature, and for analytics rules it has been mostly harmless. For custom detections I see a wrinkle. When Microsoft renames tables or columns in the advanced hunting schema, those naming changes are applied automatically to queries saved in Microsoft Defender, including the queries inside custom detection rules. The docs are equally explicit that this automatic migration does not cover queries run via API or saved anywhere outside Defender. A Git repo is outside Defender. Play that forward with a current example. The `AIAgentsInfo` table stopped being accessible on July 1, 2026, replaced by the unified `AgentsInfo` table with a changed column set. A portal-managed custom detection referencing the old table got migrated automatically. The same rule managed as code did not, because the authoritative copy of the query now lives in your repo, and nothing in the sync path rewrites your Bicep files. Your repo is now the thing standing between Microsoft's server-side fix and your production detection. Either the sync starts failing, or the stale query gets reasserted over the migrated rule. The documentation does not say which of the two happens, and honestly, neither is good. No alert fires for either. And if smart deployments, which skip files that have not changed since the last deployment, apply to this content type the same way they do to the rest of Repositories, it gets slightly worse in a way I find almost funny: a stale rule would sit untouched until someone happens to edit it. What I would put in front of the merge To be clear, none of this is an argument against the feature. I want detections in Git, and I suspect most people reading this do too. It is an argument that moving custom detections into a repo moves the schema lifecycle responsibility into your review process, because the portal safety net explicitly does not reach into source control. Concretely, a PR touching detection content should be checked for references to deprecated or transitioning advanced hunting tables, for the result columns the custom detection docs recommend (`Timestamp` or `TimeGenerated`, plus `DeviceId` or `DeviceName` for Defender for Endpoint tables, plus `Timestamp` and `ReportId` from the same event for the other Defender tables), and for complete entity mappings, since entities drive how alerts group into incidents. One more detail from the custom detection docs that I suspect will trip up people coming from analytics rules, because it goes against years of muscle memory: avoid filtering on `Timestamp` or `TimeGenerated` in the query itself. The service prefilters data based on the detection lookback using ingestion time. The scheduled-analytics-rule reflex of always pinning a time window works against you here. Whether you enforce these checks with a homegrown script or a linting step in the pipeline matters less than doing it before merge rather than discovering it in the alert queue. The deployment mechanics are now solved. The content governance is yours. Full transparency: I have worked through the documentation and the sample content, but I have not yet run a retired-table scenario through the sync myself. So if you are testing the preview, I would genuinely like to hear how it behaves in your environment when a repo-managed rule references a table like `AIAgentsInfo`. That failure mode is the one I want to understand before this reaches GA. Beyond that specific case, I am curious where you all stand: are you moving custom detections into Git now, or waiting for GA? And if you already run detections as code for analytics rules, what checks have earned a permanent place in your PR pipeline? My used references: Manage content as code with Microsoft Sentinel repositories: https://learn.microsoft.com/en-us/azure/sentinel/ci-cd-custom-content Advanced hunting schema naming changes: https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-changes Create custom detection rules in Microsoft Defender XDR: https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules Custom detections as the unified detection experience: https://techcommunity.microsoft.com/t5/microsoft-defender-threat-protection/custom-detections-are-now-the-unified-experience-for-creating/ba-p/4463875
My Computer doesn't charge consistently
My computer's battery doesn't charge reliably, often stopping and starting unexpectedly or showing inconsistent charge levels. It sometimes refuses to charge even when plugged in properly, and the battery percentage fluctuates rapidly, making it difficult to use the device unplugged or gauge its actual remaining power accurately.The system slows down or crashes when too many applications are open
I'm experiencing significant system slowdowns and occasional crashes on Windows 11 whenever I have multiple applications open simultaneously. The performance degrades rapidly as I add more programs, and the system eventually becomes unresponsive or crashes entirely, which is extremely disruptive to my workflow.Stop 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 RomanThe Dreaded "Hard Drive Not Found" on Win 11
My Windows 11 system occasionally displays a "Hard Drive Not Found" error, causing the drive to become unrecognized and preventing normal operation. Restarting or troubleshooting temporarily resolves the issue, but it keeps recurring, and I need advice on how to fix this problem permanently and prevent future occurrences.Deployment 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 Roman
Designing for cloud sovereignty with Radius and Dapr
In 2026, cloud sovereignty matters more than ever. It has moved from a policy discussion to an operational and architectural problem. The word “sovereignty” gets used loosely, and it can mean different things to different people. While definitions vary, in this post we define “cloud sovereignty” as the ability for an organization to retain control over where its data and compute run, which jurisdictions govern them, who operates them, and how its applications can adapt as regulatory, commercial, or operational requirements shift. This is especially relevant for developers and platform teams building applications that need to run on hyperscaler infrastructure, such as Azure, as well as in sovereign environments. Those requirements may come from regulation, procurement policies, customer expectations, or internal risk management. In Europe, this pressure is already visible through measures such as the EU Data Act, in force since September 12, 2025, which mandates data portability and interoperability between cloud and edge data processing services. More recently, the European Commission proposed the Cloud and AI Development Act (CADA) as part of its broader European Technological Sovereignty Package. For application teams, the practical takeaway is clear: more organizations need applications that can adapt to changing deployment requirements without requiring a rewrite. Portability is therefore a real engineering concern, not a theoretical one. If requirements change, moving a workload that is deeply integrated with provider-specific APIs can mean rewriting application code, not just reconfiguring infrastructure. Portable applications for sovereign environments The goal is to use the right managed service for each environment while keeping application code portable across environments. Microsoft Sovereign Cloud provides the platform foundation for digital sovereignty across sovereign public cloud, sovereign private cloud, and national partner cloud deployment models. Azure managed services provides strong platform capabilities for regulated workloads. Open source can help, especially when the same technology can be used as a managed service in one environment and self-operated in another. CADA also elevates an explicit "open source first" principle, reflecting how inspectable, portable components can reinforce resilience and reduce strategic dependency. Even with those options, portability is not automatic - applications still need a clear architectural boundary between the capabilities they require and the infrastructure selected for each environment. This boundary is what lets organizations use the right services in each deployment model while keeping workloads adaptable as regulatory, commercial, or operational requirements change. See the diagram below: To address building applications that are cleanly separated from their infrastructure, lets look at Radius, a CNCF project that provides a cloud native application model that addresses the boundary at the deployment layer by letting teams define applications in terms of what they need, while platform teams decide how those needs are met in each environment. For the runtime layer, lets consider Dapr, also a CNCF project which complements Radius by giving application code consistent APIs for common distributed application capabilities. Radius: portability at the deployment layer Radius provides a cloud-native application model. It separates the concerns of what an application needs from how those needs are met in each environment. Resource Types define the interface that developers use to build applications. Radius ships with built-in types and supports user-defined Resource Types for an organization's own abstractions. Recipes implement a Resource Type for a given environment. A Recipe is Infrastructure as Code; a Bicep template or a Terraform configuration that provisions infrastructure and returns the connection details. The same Resource Type can have different Recipes for different environments. Environments bind a set of Recipes against the compute target and credentials for a given deployment context (local Kubernetes, AKS, AKS enabled by Azure Arc, or others). Applications define the full set of resources (containers, Dapr building blocks, databases) and their relationships. At deploy time, Radius resolves each Resource Type to the Recipe registered in the target Environment provisions the infrastructure, and captures the result in an Application Graph that developers and operators can query. Dapr: runtime portability for Radius applications Dapr provides building block APIs for common distributed systems concerns: state management, publish and subscribe messaging, service invocation, workflows, secrets, and more. Dapr runs as a sidecar alongside each service and exposes its APIs over HTTP or gRPC. Application code calls the Dapr API instead of the underlying technology directly, which helps keep runtime dependencies more portable across environments. In a Radius application, Dapr building blocks such as state stores, pub/sub brokers, and secret stores can be declared as application resources. Radius binds those resources to the right infrastructure for each environment, while Dapr exposes them to the application through consistent runtime APIs. A concrete example: order-console The order-console sample, available in the official Radius project labs repo, demonstrates this architectural pattern end to end. It is a three-service order-management application (a Next.js frontend, an orders-api, and a fulfillment-worker) wired through Dapr state management and Dapr pub/sub. The sample ships two Radius environments: A Kubernetes environment that provisions PostgreSQL and Apache Kafka in-cluster. An Azure environment that provisions Azure Database for PostgreSQL Flexible Server and Azure Event Hubs in Kafka mode. The same app.bicep deploys against both environments. Container images, Dapr component names, and application code are identical across both. Only the Recipes change. The Recipes are written in Terraform, which Radius supports as a first-class IaC option alongside Bicep. For a step-by-step walkthrough, including the Bicep application model, the Resource Type definitions, the Terraform Recipes, and deployment instructions, see the order-console walkthrough. Don’t let the app become the lock-in What Radius and Dapr contribute is the application architecture layer: a way to ensure the application itself does not become the reason a workload cannot move to a more sovereign environment when requirements change. Radius Resource Types and Recipes allow platform teams to define governance requirements such as data residency, encryption standards, and audit integration as part of the platform definition. This helps ensure that workloads are deployed consistently and in line with organizational policies, regardless of the target environment. Because these requirements are abstracted from the underlying infrastructure, the same application can be deployed across public cloud, on-premises, and sovereign environments without requiring changes to the application itself. Where a workload runs, and under which controls, becomes a deployment decision rather than a redevelopment project. Learn more To learn more about Radius and Dapr, explore the resources below: Radius documentation Radius Resource Types concept Dapr documentation Expanding platform engineering capabilities with Radius Resource TypesLimiting Microsoft 365 Copilot data exposure risk with Zero Trust apps and data controls
Learn how to reduce Microsoft 365 Copilot data exposure risks by governing what Copilot can reach after a user is authenticated. This post maps key Layer 2 risks to Zero Trust apps and data controls, including oversharing reduction, sensitivity labeling, DLP, connector governance, audit visibility, and privileged access management.
