A Summary of 23 Days of IaC Challenge: Infrastructure as Code

An ARM Template

Infrastructure as Code (IaC) is an important concept to grasp in a DevOps team, indirectly, it ends up being fundamental in security discussions, such as DevSecOps.

I decided then to take a pragmatic approach to get started with IaC and started documenting my findings and learnings on .

1: Kicking off with concepts of Infrastructure as code:

2: Starting my journey with IaC for Azure, powered by BICEP:

How Azure Resource Manager (ARM) Works:

  • From MS Learn:

There are two types of ARM template files: JSON and Bicep.


Bicep is a Resource Manager template language that’s used to declaratively deploy Azure resources. Bicep is a domain-specific language, which means that it’s designed for a specific scenario or “domain.” Bicep isn’t meant to be used as a standard programming language for writing applications. Bicep is used only to create Resource Manager templates. Bicep is intended to be easy to understand and straightforward to learn, regardless of your experience with other programming languages. All resource types, API versions, and properties are valid in Bicep templates.

BICEP isn’t the best tool to use in Multi-cloud environments though as it is Azure specific. Terraform would be the alternative in this scenario.

So the question is, how will BICEP benefit DevSecOps?

3: One of the values I want to get out of #iac for #cybersecurity is the ability to utilize automated scanning and creating a healthy #DevSecOps culture.

I’ll be using this github repo to store my learnings:

4: Started building my own .

Notes with:

— Handy AZ CLI and BICEP commands and

— First resource templates

5: A CI/CD pipeline of IaC will require use of Parameter files in order to properly handle automated deployments.

Variables will reference information in these files. Expressions will help with naming based on information from when the template runs.

6: Use expressions and parameters to create random resource names.

Planting a good seed will ensure names in a deployment are consistent.

7: A Bicep template can be made of modules for even more scale and reuse.

Good Module Design Practices ():

  • A module should have a clear purpose. You can use modules to define all of the resources related to a specific part of your solution. For example, you might create a module that contains all of the resources used to monitor your application. You might also use a module to define a set of resources that belong together, like all of your database servers and databases.
  • Don’t put every resource into its own module. You shouldn’t create a separate module for every resource you deploy. If you have a resource that has lots of complex properties, it might make sense to put that resource into its own module. But in general, it’s better for modules to combine multiple resources.
  • A module should have clear parameters and outputs that make sense. Consider the purpose of the module. Think about whether the module should be manipulating parameter values, or whether the parent template should handle that and then pass a single value through to the module. Similarly, think about the outputs a module should return, and make sure they’re useful to the templates that will use the module.
  • A module should be as self-contained as possible. If a module needs to use a variable to define a part of a module, the variable should generally be included in the module file rather than in the parent template.
  • A module should not output secrets. Just like templates, don’t create module outputs for secret values like connection strings or keys.

8: Advanced parameters capabilities:

  • Can be defined by objects (oh how I’ve missed OOP! RIP Java!)
  • Limiting max and min length is best practice.
  • Arrays!
  • Descriptions! Details on my notes and official documentation.
  • Parameter Files allow for customization of parameters at time of execution, from a JSON file. About Parameter Files:

Generally, you’ll create a parameter file for each environment. It’s a good practice to include the environment name in the name of the parameter file. For example, you might have a parameter file named main.parameters.dev.json for your development environment and one named main.parameters.production.json for your production environment.

Source: Microsoft

Check out code .

9: Bicep Visualizer within Visual Studio is a must-use feature!

Visual Studio code “Bicep Visualizer” is really handy for personal use, but also to document what your Bicep file does.


10: Secure Parameters (for API keys and Passwords)

First off, the most secure option, :

The best approach is to avoid using credentials entirely. can enable the components of your solution to securely communicate with one another without any credentials. Managed identities aren’t available for every resource, but it’s a good idea to use them wherever you can.

Use the @ secure decorator to include “secure parameters” in secret fields/values of a parameter file. Advantages of using it include, :

When you define a parameter as @secure, Azure won't make the parameter values available in the deployment logs. Also, if you create the deployment interactively by using the Azure CLI or Azure PowerShell and you need to enter the values during the deployment, the terminal won't display the text on your screen.

Best practice tip:

Avoid specifying default values for usernames, passwords, and other secrets. Otherwise, if someone deploys your template and doesn’t realize they should override the value, they’ll weaken their security because they’ll get the default value instead of something they’ve chosen themselves.

11: Tracking deployment from Azure is simple with descriptive “success” and “fail” messages.

While the command line output can be helpful:

Checking the status of deployment from the GUI makes the results very clear:

12: Know the basics of troubleshooting via CLI — you’ll need it, trust me. If using Az CLI, remember:

$ az account show

is your friend!

For your reference, all AZ CLI commands .

13: A deployment can stay active for a long time. Cancelling a job from AZ CLI (ctrl+C) does not guarantee it from being cancelled in Azure.

When this happens, you can check error messages in full in the Azure GUI — and cancel it completely from there.

14: Bicep allows for the use of loops and condition statements for templating scaling and reuse that satisfies different deployment stages.


15: A big part of Bicep scripting is knowing Azure Resources’ API capabilities.

If you know the resource type, you can go directly to it with the following URL format!

Learn how and more about this .

16: Splitting up a script in different modules might not be obvious.

To help people writing Bicep scripts, the Bicep plugin for VS helps visualize potential modules in your script.

Learn more about it:

17: What is Transpilation?

It’s the conversion that happens when we deploy a Bicep file: Bicep converts it to a JSON ARM template. Any and All modules that the template uses are embedded into a single JSON file.

18: Completing Bicep training from Microsoft Learning.

19: Preview Deployment when pushing via PowerShell.

When pushing a Bicep template via PowerShell you can use the “-c” modifier to preview the deployment.

This enables a What-IF validation. You can preview the deployment operation before doing the actual deployment.

20: Azure templates are critical to customizing and writing your own templates.

I’m working on Automating a Linux VM using the information provided here:

21: Intellisense in VScode is a godsend for non-devs to work with IaC and Bicep.

Just use ‘ctrl + space’ in VSCode with the Bicep plug-in to bring contextualized suggestions for you Bicep template.

Learn more:

22: Reverse engineering an Azure resource

It might be necessary to “reverse engineer” an ARM template to BICEP in order to create a template for the specific workload you need, case in point, a Debian VM. Use Decompile for this.

Learn More:


to assist with creating Azure Resource Manager templates, you can export a template from existing resources. The exported template helps you understand the JSON syntax and properties that deploy your resources. To automate future deployments, start with the exported template and modify it for your scenario. The export template process attempts to create a usable template


23: How Azure Bicep works — Graphical representation


Learn more about my Cloud and Security Projects:

to access more content that will empower you!

Thank you for reading and leave your thoughts/comments!


Scattered throughout the document



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andre Camillo

Cloud and Security technologies, Career, sometimes Music and Gaming easter eggs. Technical Specialist @Microsoft. Opinions are my own.