Deploying resources to azure has evolved over the years, and has recently seen a couple of important iterations. Initially, Azure Resource Manager deployments through JSON templates were the best solution for managing resources through code. Because of the difficult syntax and lack of built-in functions, many of us moved towards adopting the relatively new Bicep language. Even though it now provides us with more user-friendly features, the Microsoft team has been (and still is) working hard on extending the possibilities with Bicep, while also exploring multiple ways of making the management of Azure resources through code an easier process.

I was fortunate enough to be able to attend the 2025 PowerShell & DevOps Summit in Bellevue/Seattle, where the agenda contained multiple sessions regarding the deployment of Azure resources. Microsoft themselves were numerously represented, with Product Managers of both Resource Deployment and PowerShell teams presenting sessions on the various topics within their domain.

During one of these sessions, the product team would elaborate on the direction they will be taking when it comes to deploying resources in azure. In this write-up I want to capture the discussed future of deploying Azure resources and how this can be simplified and secured for infrastructure teams, as well as provide the motivations behind them, as presented during these sessions.

Deployment Stacks

One of the main concerns infrastructure teams (managing environments through code) currently have is the uncertainty of manual changes on the resources. When working with Infrastructure as Code, it is fundamentally important that all resources defined in code, should also be maintained in code, and so not through manual changes in the portal or other alternatives.

The current solutions don’t really provide a reliable and easy-to-use way of preventing manual changes for resources defined in code. Resource locks come to mind, but these will also block code deployments to the resources that fall under their scope. Limiting access to manual changes through RBAC on the other hand, requires a high level of operational maturity within the team, and is often not achievable due to the overhead introduced with the ever evolving need to enable your independent consuming teams.

Deployment stacks have been around for quite a while now, and are also generally available for you to use. However the features showcased during the Deployment deep-dive session on the Summit aim to simplify the problems mentioned above.

Deployment Stacks can be created with a “DenySettingsMode” configured on them. This mode will represent the restrictive measure when it comes to manually updating or deleting resources within the stack:

• DenyDelete: Will prevent any manual deletion of resources deployed within the Deployment Stack
• DenyWriteAndDelete: Will prevent any deletion or change of resources deployed within the Deployment Stack

Essentially, this means that these resources can only be deleted or updated through redeploying the Stack. This instantly solves the aforementioned issue of uncertainty when it comes to maintaining resources through IaC.

There are a few important notes to be made when using these flags:

• Seeing as they aim to provide more control over the resources themselves (and not the data within), these restrictions will only apply on the management plane of the scoped resources. This strategy allows your consuming teams uninterrupted access to the resources, without being able to tamper with the configuration of them.
• 2 additional options are provided when using these restrictive measures, to still allow flexibility:
  • DenySettingsExcludedPrincipals: Any principal listed here, will be excluded from the restrictive stack measures
  • DenySettingsExcludedActions: Any RBAC action listed here will be excluded from the restrictive stack measures

In order to be able to update the Stack configuration, or redeploy it to manage the resources within, the user must be assigned the “Azure Deployment Stack Owner” role, which is not included in the already existing contributor role. When configuring the access on your stack, it is perfectly possible to assign contributor to the consuming teams, while still being in control of the restrictive measures you put on the Deployment Stack.

Bicep Extensibility

Another topic discussed in detail was the operation scope of Bicep itself. It is and will always be a strong language for interfacing with the Azure Resource Manager. However the team at Microsoft is now exploring ways to extend the functionality of Bicep beyond just deploying Azure resources.

Recently, we’ve already seen advancements in EntraID, where it is now possible to deploy the following entities through bicep:

• Applications
• App role Assignments
• Federated Identity Credentials
• Groups
• OAuth permission grants
• Service principals
• Users

Note, this functionality can only be accessed when enabling the experimental features in bicep, by adding the “experimentalFeaturesEnabled” flag in your bicepconfig.json configuration file. Furthermore, the Graph extension needs to be included within this file as well.

The session gave valuable insights into the future of this extensibility idea, and where Microsoft is intending to take the bicep language.

One of the upcoming feature extensions will be Azure DevOps. Though it might sound vague at first, the goal is simple: Manage the setup of your Azure DevOps projects, group rules, repositories, pipelines, … through Bicep code and deployments. The details here are not fully known, but active deployment on this feature has been started.

Another already mentioned extension is the management of the Key Vault Data Plane through Bicep code. This would allow you to create and manage secrets, certificates and keys through the use of Bicep modules and deployments. Again, details here are not yet out there, but the feature has been confirmed.

Lastly, the latest DSCv3 feature will support bicep as input, allowing engineers to configure DSC rules through bicep as well.

What-If Validation

Validating code before deploying can be tricky. Bicep provides the What-if functionality, however this still comes with some flaws. The main 2 that were discussed, are quite important for confidently detecting errors or mistakes before deploying your bicep code:

• Bicep What-if might not always (if ever) take nested modules into account. This is detrimental to the validation, as usually, your deployment flow depends on these nested modules.
• Very noisy and sometimes unnecessary flagging of  (un)changed resources. This is most commonly seen when deploying Azure Firewall rules or Application Gateway Listeners. In these cases, the what-if validation fails to match the checked entity to the already existing one, resulting in a “changes detected in every entity” scenario.

When integrating this what-if functionality into a PR validation pipeline or deployment prerequisite, false positives might needlessly fail your release flow.

The Product team let us know that development towards this what-if functionality is actively ongoing, and will initially take form under the Deployment Stack umbrella. This means that the new and improved what-if features will first be available in the Deployment Stack commandlets, before being integrated into the regular bicep deployment methods.

This further highlights the growing importance of Deployment Stacks, and continuous increase in valuable features it offers.

Takeaways

Overall, the showcased features look to add some much requested, and needed features to Bicep which will change the way infrastructure as code is shaped and maintained in the future. The open possibility of extending the bicep language we all come to know, proves it is here to stay and will keep evolving over time. As for the already existing features, improvements are also actively being worked on, providing more robust and reliable workflows, which will eventually mirror into a more robust and reliable Azure environment.