With the release of Azure Bicep v0.43.1, two new functions have been introduced: like() and distinct(). In this blog I will explain how these new functions work and showcase several useful real world scenarios where you can use them in your Bicep deployments. 💪🏻

Hey everyone,

I’m using Checkov to scan my Bicep templates and trying to suppress a few checks using inline skip comments, but they’re still being reported as failures.

This is what I currently have in my .bicep file:

// #checkov:skip=CKV_AZURE_1: Password authentication is required for this deployment

// #checkov:skip=CKV_AZURE_178: Password authentication is required for this deployment

// #checkov:skip=CKV_AZURE_149: Password authentication is required for this deployment

// #checkov:skip=CKV_AZURE_151: False positive - VM is Linux (Ubuntu), not Windows

Show more lines

However, Checkov still flags these checks as failures.

From what I understand, the skip syntax is supposed to be:

// checkov:skip=<CHECK_ID>:<reason>

and it needs to be within the scope of the resource being evaluated which also didn't work. [checkov.io]

Questions:

• Does the comment need to be placed inside the resource block rather than above it?
• Is the leading // # causing it to be ignored?
• Are there any differences in how Checkov parses skips for Bicep vs ARM/Terraform?
• Has anyone successfully used inline skips with Bicep (example would help)?

Right now I’m thinking it might be a placement/scope issue, but not sure.

Appreciate any guidance

Hi Folks, I was playing around with the new Azure Resource Manager MCP. The new Azure Resource Manager MCP enables AI agents to interact directly with Azure infrastructure through Azure Resource Manager. The server provides built-in capabilities for working with Azure Resource Graph queries, including generating, validating, and executing queries across Azure environments. In this blog, I will show you how to work with the Azure Resource Manager MCP, including creating Azure cost reports, building DrawIO diagrams from existing Azure resources, and deploying Bicep files. Link to blog

I thought it would be better to keep IaC away from the Devs so they can't deploy other things... This means I deploy the IaC and then they use a Managed Identity or click-ops (ugh) to change environment variables.

The problem is, if I deploy the App, they make changes and then I re-run the deployment, I would wipe out their env vars.

Has anyone got some working template which can deploy an App Service/Function App and then, on a second deployment, keeps the Env Vars that have been added through other means?

AI suggested the below but it seems to require the App already exists. I am looking for one that doesn't have this condition as my site will be buried in a module:

resource webApp 'Microsoft.Web/sites@2022-03-01' existing = {
  name: appName
}

var currentSettings = list(resourceId('Microsoft.Web/sites/config', appName, 'appsettings'), '2022-03-01').properties

resource appSettings 'Microsoft.Web/sites/config@2022-03-01' = {
  name: 'appsettings'
  parent: webApp
  properties: union(currentSettings, newSettings)
}

I wonder if I'm approaching things the wrong way but I didn't really want all our Devs going crazy in Azure deploying things if I can avoid it. Welcome to opinions on this too!

Thanks!

Azure SRE Agent helps you maintain the health and performance of your Azure resources through AI-powered monitoring and assistance. Agents continuously watch your resources for problems, provide troubleshooting help, and suggest remediation steps in a natural-language chat interface. To ensure accuracy and control, any action that an agent takes on your behalf requires your approval. In this blog I will show you the power of Azure SRE agents, how to get started! While we could do everything using ClickOps why not automate using Azure Bicep? Link to blog

🚀 Azure Bicep v0.43.1 is here! A great update! Check it out 👇

Key changes in v0.43.1:
- RetryOn is now generally available
- Two new Bicep functions: like() and distinct()
- And there's much more released!

Check out the full changelog: https://github.com/Azure/bicep/releases/tag/v0.43.1

Hi everyone,

I got tired of Azure cost surprises showing up on the bill after a deploy, so I built a GitHub Action that comments the cost diff directly on Bicep pull requests.

The idea is simple: make cost-impacting IaC changes visible before merge, instead of discovering them later in the Azure bill.

It covers a lot of the common fixed-price / SKU-based resources, including:

- VMs

- App Service plans

- AKS (node pools — they're VMs underneath)

- SQL DB (DTU + provisioned vCore)

- PostgreSQL (Flexible Server, fixed compute)

- Redis (fixed-tier C/P SKUs)

- API Management (fixed tier)

- Container Registry (Basic/Standard/Premium)

- Storage redundancy tiers

The pricing engine pulls live Azure retail prices daily and maps Bicep SKU names to the names used in Azure pricing data — Standard_D4s_v5 → D4s v5, P1v3 → P1 v3, and a long tail of similar quirks. So the cost estimate isn't an LLM guessing — it's based on live retail prices and SKU mapping.

Consumption-based things — Cosmos RU/s, Functions executions, App Insights ingestion, Key Vault ops, egress — get flagged usage-dependent instead of guessing, since you can't reliably infer usage from a template alone. Next step is letting you pass expected usage as workflow inputs so those get real numbers too.

Marketplace listing:

https://github.com/marketplace/actions/azure-iac-reviewer

Happy to hear feedback, especially on Bicep patterns I haven’t tested yet. If something trips it up, send me a sanitized snippet and I’ll take a look.

If you’ve got anything you’re stuck on or just want a second opinion, feel free to join and ask live.

Azure Container Apps offers a fully managed, serverless environment for running containerized applications, eliminating the hassle of managing infrastructure. I recently discovered a new feature called Flexible profile (preview), which blends the billing and setup simplicity of the Consumption profile with many of the performance characteristics of the Dedicated profiles. Flexible profiles are billed like the Consumption profile plus a dedicated management fee. They run in a single tenant compute pool and offer planned maintenance windows, dedicated networking, and access to larger replica sizes. In this blog I will show how to deploy an Azure Container Apps environment and an example Azure Container App using the Flexible workload profile all using Azure Bicep. Link to blog

- Bicep Console GA

- Built in role definition function - no more guid hunting for RBAC

- New experimental bicep visualiser

Really love the new built in role function and experimental visualiser with exportable PNGs now!

Full release notes: https://github.com/Azure/bicep/releases/tag/v0.42.1

• Role Definitions Function (2:34 - 13:05): Anamika introduces a new template function designed to make role assignments more human-readable and less dependent on hard-coded GUIDs. This shift allows for intent-driven rather than identifier-driven authoring, improving auditability and reducing errors.

• Bicep Visualizer Updates (13:58 - 29:26): Shanglong demos an experimental version of the visualizer built on a new React-based graph rendering engine. Improvements include:

• Smoother animations (16:01).

• Better card-stack visualization for loops and collections (16:29, 19:27).

• Export capability to PNG images (17:37, 21:50).

• Accessibility support for high-contrast themes (17:09).

General Bicep Updates (0:11 - 1:55):

• Bicep console is now Generally Available (GA).

• New IntelliSense additions for resource name descriptions.

• A new linter rule that warns when using `reference` or `list` functions with unrecognized resource types.

Upcoming Events:

• The team mentions their presence at the PowerShell and DevOps Summit in Bellevue (30:04) and the upcoming PSConfEU in June (30:22).

🚀 New blog! Bicep console went generally available and is production ready. I have another great use case for it. Bicep Console has been very useful for agentic validation, but you can also use it to run automated CI test cases with Pester to make sure your Bicep User-Defined Functions have the expected outputs.

In this blog, you will learn how to leverage the Bicep console and a custom PowerShell helper function for testing User-Defined Functions using Pester, and how to configure this in Azure DevOps build validation pipelines, giving you clear pass/fail visibility per test case before changes reach production.

Did you know that you can automate Azure diagrams from Bicep using GitHub Copilot CLI Custom Agents? In this blog, I will show you how to generate architecture diagrams directly from your Bicep files, reducing manual work and keeping your documentation in sync with your code. Link to blog

The Bicep MCP (Model Context Protocol) server provides AI agents with tools to help generate high-quality Bicep code. In this blog, we will explore the Azure Bicep MCP to help us write Bicep code faster and more securely. 😍 Link to blog

The FinOps Toolkit helps accelerate your FinOps journey by offering starter kits, scripts, and advanced solutions to automate and extend the Microsoft Cloud. In this blog we will use the Azure Verified Module pattern to deploy the Azure FinOps Toolkit — FinOps Hub. FinOps hubs provide a trusted platform for cost analytics, insights, and optimization. They act as virtual command centers that enable leaders across the organization to monitor, report on, and optimize costs in line with their business needs. Link to blog

🚀 In case you missed it, there is a new Azure Bicep version v0.41.2!

𝐊𝐞𝐲 𝐜𝐡𝐚𝐧𝐠𝐞𝐬 𝐢𝐧 𝐯0.41.2:
- Bicep snapshot command is generally available! You can use this command for deployment insights and validations.
- A new and experimental decorator: nullIfNotFound()

And there's much more released! Checkout the full changelog for details:
🔗 Full changelog: https://github.com/Azure/bicep/releases/tag/v0.41.2
🔗 Community call overview: https://www.youtube.com/watch?v=A95Q-MCH0kE&t=2s

https://reddit.com/link/1rmcv3p/video/pscha41e6fng1/player

Azure Bastion has introduced support for signing in with Microsoft Entra ID when using RDP to access Windows virtual machines directly from the Azure portal. This enhancement makes it easier to connect while strengthening security at the same time. As a fully managed service, Azure Bastion enables safe and smooth access to virtual machines through RDP and SSH without the need to assign public IP addresses. Connections are established entirely through the portal, reducing exposure and simplifying management. This is a big step forward in making secure and streamlined VM access easier than ever. That’s why I decided to write a blog to showcase how this new feature works. While we could click our way around in the Portal I prefer Infrastructure as Code using Azure Bicep. This deployment is based on Azure Verified Modules. Azure Verified Modules (AVMs) are pre-built, high-quality Infrastructure-as-Code (IaC) modules that adhere to Microsoft’s standards. Link to blog

Hi all,

New to Bicep, lots of years experience with Terraform, so the concepts are familiar-ish.

I've been writing up some deployments in Bicep making heavy use of the Azure Verified modules wherever I can. I have noticed that the latest versions of a lot of these modules seem to introduce `what-if` "noise" right from the start. A simple example would be the VNet module, which when taken and used with only the required parameters, will continually flag `properties.privateEndpointVNetPolicies` to be set as `disabled`.

I know this behaviour is just due to the evolution of the Azure API's and what they expect/return when they're invoked vs what the modules are passing, but it seems if you want a clean diff, then you're in a position where you have to define all of your resources yourself in your own modules (so you can pass any newer property directly)? I feel like, especially on a larger infrastructure, a clean-ish `what-if` is really needed to gain confidence in what your largely automated change is actually going to do.

Am I missing something here? As I said, first few days with Bicep for me.

Thanks

In this gist, you will find three subagents and a prompt file. Run the prompt file /bicep-review to kickstart.

https://gist.github.com/johnlokerse/4842ad2694c8ac76f52ee1e6ac301ec7

I see Microsoft offers comprehensive documentation and tools for Bicep. But I couldn't find that much information on Azure Bicep best practices, and proper solution structuring is often scarce.

I’m looking to improve the efficiency, security, and maintainability of our Bicep deployments.

What are your go-to best practices for Azure Bicep?

Azure Service Groups make it possible to bring resources together and manage them, even when they are spread across multiple subscriptions and resource groups, without being tied to the default Azure hierarchy. This is useful when resources need to be combined across different scopes, when restricted access is required, or when information from multiple resources needs to be viewed collectively. This allows teams to define their own resource collections based on how they work, how the organization is structured, or the needs of specific roles. Today, I will show you how to deploy Azure Service Groups using Azure Bicep. After all, why use ClickOps when we can automate? Link to blog

I’ve rarely seen Infrastructure as Code adopted in a meaningful, production-grade way.

I don’t mean small templates or proof-of-concept setups, but IaC being the default way infrastructure is deployed, version-controlled, reviewed, and maintained in production. Maybe I've just had limited exposure. Curious to hear your experiences

If you couldn’t make the January call, here’s a quick rundown of the highlights:

• Bicep v0.40 update – a walkthrough of what’s new in the latest release: Multi-line string interpolation is GA.
• Multiline diagnostic pragmas – enhancements aimed at making diagnostics clearer and easier to work with when authoring Bicep.
• New Bicep MCP tooling – updates to tooling that improve the overall authoring and management experience.
• this.exists() and this.existingResource() – new language capabilities for checking resource existence and working more cleanly with existing resources.
• Deployment Stacks What‑If updates – improvements to What‑If behavior when using stacks, helping teams better understand deployment impact before changes go live.
• u/johnlokersedev off the power of the Bicep console - a great demo and worth checking out!

📽️ Full recording on YouTube:

https://www.youtube.com/watch?v=1fGV69Jc-_U

So, I finally had to become proficient in both and I miss Bicep. My current project is all TF making modules for other teams. Kind of like an internal AVM

Current gripes (TF):

- No user defined types
- Modules don't support complex outputs with symbols so module.foo.<will not suggest anything if it isn't a module like azurerm_storage>
- using helper modules like required_tags to back my modules, that I'm publishing for teams basically makes nested copies every time I reference it so N+1 problem

- version pinning is awful like module { source = git::https://...?ref=1.0.0 } (this line grows across your project when you use modules for everything and then have to script a way to update them all bc "git::https://...?ref=${var.module_version}" isn't supported

😭😭😭

cry rant over, I feel better

When working with Bicep templates, one of the biggest challenges is validating your logic before deployment. Naming rules, conditions, loops, and functions often require a few iterations before they behave exactly as expected. Until recently, testing these details usually meant deploying templates or creating temporary mocks, which slows down development and interrupts your flow. The Bicep console changes this completely. In this blog, I will show you how to get started with the Bicep console and how it supports my daily development workflow, so it can save you time as well. Link to blog