Can you use module deployment without referencing any parameters

[uky2019]

Hello everybody, since you were so helpful with my last two question here is another that has been bothering me:

I have several bicep deployment files such as:

Deploy_VPN_gateway.bicep
Deploy_VM_Databases.bicep
Deploy_Application_servers.bicep ...

Since modules provide a cool way to read Azure Key vault secrets and deploy several resources at the same time I would like have a single module file to deploy whole environment (vms, vnets, VPN etc):

let say I have a DeployEnvironment.bicep file with following content:

//reading here existing key vault
resource keyvault 'Microsoft.KeyVault/vaults@2019-09-01' existing = {

  name: AzureKeyVault
  scope: Test-RG 

}

//Deploying Application servers
module DeployApplicationServer 'Modules/Deploy_Application_servers.bicep' = {
  
  name: 'DeployApplicationServer'
  params: {
  
  adminUsername: keyvault.getSecret('adminUsername') 
  adminPassword: keyvault.getSecret('adminPassword')

  }

}

//Deploying VPN
module DeployVPNGateway 'Modules/Deploy_VPN_gateway.bicep' = {
  
  name: 'DeployVPNGateway'
  params: {
  
??
??

  }

}

So first part is fine where I am deploying VMs which read secret from key vault.
But for the second one where I am deploying VPN I do not read any secrets etc. from KeyVault and I have all necessary parameters for VPN in *.json parameter file and I do not want to state them in module section. But using module for it expects some parameters to be stated, you cannot use module without parameters... or I am wrong?

Ultimately the Idea is to deploy whole environment with just one file that reads other smaller bicep files, deploy resources concurrently, so some things get read from key vault others needed are read from parameter file.

New-AzResourceGroupDeployment `
-Name 'Deploy_Environment' `
-TemplateFile 'C:\DeployEnvironment.bicep' `
-TemplateParameterFile 'C:\DeployEnvironment.parameters.json'

Thanks

[johnlokerse]

@uky2019 You don't have to specify parameters if your template doesn't have any. Does your Deploy_VPN_gateway.bicep contain parameters?

For example, when you want to deploy a resource group and you don't have parameters you can call this module without specifing parameters:

ResourceGroup.bicep

targetScope = 'subscription'
resource resNewRg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'my-rg'
  location: 'westeurope'
}

Orchestration using a module referring the ResourceGroup.bicep:

targetScope = 'subscription'
module modNewRg 'ResourceGroup.bicep' = {
  name: 'deploy-rg'
}

[uky2019]

Yes it does, but they are stated in parameter file DeployEnvironment.parameters.json I am providing when deploying this DeployEnvironment.bicep module.

[kevball2]

If parameter values are used in your module, then you will need to declare them there. There is not a way around this

[johnlokerse]

You have to add parameters to your DeployEnvironment.bicep and then refer these in your VPNGateway module in the 'params' block.

Also, the parameters in your *.parameters.json must map on the parameters in the Bicep file.

I can't give an example for you right now because I am writing this on the mobile GitHub app. When I am able to I will provide an example if it's unclear.

[johnlokerse]

My last comment, but now visualised using examples:

@description('VPN Gateway settings parameter input.')
param parVpnGatewaySettings object = {
  name: 'MyVpnGatewayName'
}

<keyvault here>

module DeployVPNGateway 'vpngateway.bicep' = {
  name: 'DeployVPNGateway'
  params: {
    parVpnGatewayName: parVpnGatewaySettings.name
  }
}

This parameter file maps onto the DeployEnvironment.bicep:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "parVpnGatewaySettings": {
            "value": {
                "name": "MyVpnGatewayName"
            }
        }
    }
}

I used an object as parameter, but this is not required. It can be multiple parameters for name etc...

[uky2019]

Ok I get it now, even though they are stated in parameters file and vpn bicep file you have to state them again in module you are using, I will test this tomorrow but thanks everybody.

[uky2019]

I spoke too soon, I don't get it :D

Ok I will post my exact scenario, lets say I am only trying to deploy VPN gateway with DeployEnvironment.bicep to not overcomplicate things.

DeployEnvironment.parameters.json is my Parameters file,
Deploy_VPN_gateway.bicep is Bicep file containing VPN gateway related code,
DeployEnvironment.bicep is Bicep file that contains module that uses Deploy_VPN_gateway.bicep

I have stated parameters in DeployEnvironment.parameters.json as such:

{
	"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
	"contentVersion": "1.0.0.0",
	"parameters": {
		"VPN": {
			"value": {
				"VPNVNETaddressPrefix": "XXX",
				"vpngatewaysubprefix": "XXX",
				"localnetworkgwprefix": "XXX",
				"localnetworkgwipaddress": "XXX",
				"S2SVPNsharedkey": "XXX"
			}
		}
	}
}

So my DeployEnvironment.bicep should look like:

@description('VPN Gateway settings parameter input.')
param vpn object = {
  
  VPNVNETaddressPrefix: 'XXX',
  vpngatewaysubprefix: 'XXX',
  localnetworkgwprefix: 'XXX',
  localnetworkgwipaddress: 'XXX',
  S2SVPNsharedkey: 'XXX'

}

var keyvaultname = 'KeyVault-Test'
resource keyvault 'Microsoft.KeyVault/vaults@2019-09-01' existing = {

  name: keyvaultname
  scope: Test-RG

}

module DeployVPNGateway 'vpngateway.bicep' = {
  name: 'DeployVPNGateway'
  params: {
    ???
    ???
  }
}

maybe it has something to do how Deploy_VPN_gateway.bicep is written, where did you pull your parVpnGatewayName: from? Maybe I can't explain well but ask me and I will try.

module DeployVPNGateway 'vpngateway.bicep' = {
name: 'DeployVPNGateway'
params: {
parVpnGatewayName: parVpnGatewaySettings.name
}
}

I already state all my parameters in Deploy_VPN_gateway.bicep as below, so how/why I need to state them again in my DeployEnvironment.bicep. I just want to pull different "sub" bicep files into one bicep files reference them as modules and deploy everything at once.

param vpn object

//I then use it to construct values in the bicep file

  vpn.VPNVNETaddressPrefix
  vpn.vpngatewaysubprefix: 
  vpn.localnetworkgwprefix: 
  vpn.localnetworkgwipaddress: 
  vpn.S2SVPNsharedkey: 

//and so on in various parts of bicep 

I'm kind of clueless what needs to be done, maybe I am getting the logic of usage wrong...

[kevball2]

every parameter you want your module to use will need to be passed to it from another bicep template. This can be the main template of your deployment or even another module if nested modules are required for your deployment

If your module needs Param x, y, z. Then those need to be provided from the template calling the module. This does cause you to have to list parameters in multiple files, but that is where using arrays and objects to minimize the number of parameters you are required to list.

for your VPN gateway module, you have a couple options

Options 1

Deploy_VPN_gateway.bicep

param VPNVNETaddressPrefix string
param vpngatewaysubprefix string
param localnetworkgwprefix string
param localnetworkgwipaddress string
param S2SVPNsharedkey string

resource vpnGateway 'Microsoft.Network/vpnGateways@2021-05-01' = {
  name: 'vpngw-Name'

  properties:{

  }
}

DeployEnvironment.bicep

@description('VPN Gateway settings parameter input.')
param vpn object = {
  
  VPNVNETaddressPrefix: 'XXX',
  vpngatewaysubprefix: 'XXX',
  localnetworkgwprefix: 'XXX',
  localnetworkgwipaddress: 'XXX',
  S2SVPNsharedkey: 'XXX'

}

var keyvaultname = 'KeyVault-Test'
resource keyvault 'Microsoft.KeyVault/vaults@2019-09-01' existing = {

  name: keyvaultname
  scope: Test-RG

}

module DeployVPNGateway 'Modules/Deploy_VPN_gateway.bicep' = {
  name: 'DeployVPNGateway'
  params: {
    localnetworkgwipaddress: vpn.localnetworkgwipaddress
    localnetworkgwprefix: vpn.localnetworkgwprefix
    S2SVPNsharedkey: vpn.S2SVPNsharedkey
    vpngatewaysubprefix: vpn.vpngatewaysubprefix
    VPNVNETaddressPrefix: vpn.VPNVNETaddressPrefix
  }
}

Option 2

Deploy_VPN_gateway.bicep

param vpn object

resource vpnGateway 'Microsoft.Network/vpnGateways@2021-05-01' = {
  name: 'vpngw-Name'

  properties:{
    connections:[
      {
        name:'connection1'
        properties:{
          sharedKey: vpn.S2SVPNsharedkey
        }
      }
    ]
  }
}

DeployEnvironment.bicep

@description('VPN Gateway settings parameter input.')
param vpn object = {
  
  VPNVNETaddressPrefix: 'XXX',
  vpngatewaysubprefix: 'XXX',
  localnetworkgwprefix: 'XXX',
  localnetworkgwipaddress: 'XXX',
  S2SVPNsharedkey: 'XXX'

}

var keyvaultname = 'KeyVault-Test'
resource keyvault 'Microsoft.KeyVault/vaults@2019-09-01' existing = {

  name: keyvaultname
  scope: Test-RG

}

module DeployVPNGateway2 'Modules/Deploy_VPN_gateway2.bicep' = {
  name: 'DeployVPNGateway2'
  params: {
    vpn: vpn
  }
}

[johnlokerse]

The Deploy_VPN_gateway.bicep needs some parameters, these parameters can be mapped with a parameter file directly. But, in your case you are orchestrating multiple resources from one file (DeployEnvironment.bicep).

The module you are declaring is referring to the Deploy_VPN_gateway.bicep file. Because you declared input parameters in this Deploy_VPN_gateway.bicep file the module needs these input parameters too. You need to declare the parameters you need in DeployEnvironment.bicep and give these to the declared module parameters.

In my example I added an object parameter so I don't have to declare multiple parameters for the VPN module. This is a choice, you can add multiple 'param' declarations instead of one object.

[uky2019]

Hi sorry to bother you all with my questions, but I am just trying to understand it.

If you ask me it defeats the purpose of having one central parameter file with organized object structure, so other bicep files that read this parameter file can be more "clean" looking.
I understand now that this parameters need to be stated throughout all files that are in chain of deploy, but why? Why does not modul behave in a way: I am deploying DeployEnvironment.bicep using module for VPN gateway, which "calls" Deploy_VPN_gateway.bicep and this file "calls" parameters file DeployEnvironment.parameters.json where everything is already specified, why do I need to bring and combine mess from both files into DeployEnvironment.bicep ? I guess for some reasons that are not relevant in my use case but are maybe in others.

@kevball2 I tried with your "Option 2" and it does work. I do not want to use "Option 1" as it bring mess into my bicep file with all that stated parameters, I want to use DeployEnvironment.parameters.json where parameters are organized in objects.

My goal mainly is (and why to even use "modules":

• To have have another "clean" looking file in form DeployEnvironment.bicep, to change stuff in the background and just add/ remove modules,
• deploy resources at the same time,
• be able to read Azure Key Vault secrets for each module.

So my way of deploy looks like this:

New-AzResourceGroupDeployment `
-Name 'Deploy_Environment' `
-TemplateFile '.\deployenvironment.bicep' `
-TemplateParameterFile '.\DeployEnvironment.parameters.json' `
-ResourceGroupName 'Test-RG'

My Deploy_VPN_gateway.bicep looks like this:

param vpn object

resource vpnGateway 'Microsoft.Network/vpnGateways@2021-05-01' = {
  name: 'vpngw-Name'

  properties:{
    connections:[
      {
        name:'connection1'
        properties:{
          sharedKey: vpn.S2SVPNsharedkey
        }
      }
    ]
  }
}

I would expect DeployEnvironment.bicep to look like this:

param vpn object

var keyvaultname = 'KeyVault-Test'
resource keyvault 'Microsoft.KeyVault/vaults@2019-09-01' existing = {

  name: keyvaultname
  scope: Test-RG

}

module DeployVPNGateway2 'Modules/Deploy_VPN_gateway2.bicep' = {
  name: 'DeployVPNGateway2'
  params: {
    vpn: vpn
  }

Maybe I need to rethink how I designed this whole deploy.

[brwilkinson]

I use this exact same strategy that you mentioned, I love it, because 1 environment = 1 parameter file.

You have the option to deploy a whole environment OR just 1 layer e.g. a single resource type per environment.

Here is a param file for 1 environment:

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/tenants/AOA/ACU1.T5.parameters.json#L408

• Everything is there is an array of object e.g. the line highlighted is an array of storage account.

Here is a sample of different way to deploy:

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/tenants/AOA/aoa-azure-Deploy.ps1#L47

Then you have a parent deployment Module, that deploys ALL of the laters.

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/01-ALL-RG.bicep

Then you have an individual layer: lets say storage.

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/SA.bicep

The only way this works is that the parent deployment shares the exact same parameters as the individual/children modules.

Each resource types has the parent deployment template that iterates over the array from the param file.

Then that calls a child module for the individual resource, with all of the actual details

e.g. storage account individual

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/SA-Storage.bicep

I do have some docs on this, however obviously it's not trivial to understand.

https://brwilkinson.github.io/AzureDeploymentFramework/

[uky2019]

this is a lot more complex than my case, but I will be able to pull many useful things out of it - thanks, and this topic can be also marked as solved.

[Demic198]

@brwilkinson just stumbled upon your project and this post. I’m new to bicep and was wondering if could explain this in more details?

Basically if deploymentinfo contains sainfo store it and if not it’s an empty array
var storageInfo = contains(DeploymentInfo, 'saInfo') ? DeploymentInfo.saInfo : []

var SAInfo = [for (sa, index) in storageInfo: {
match: (Global.CN == '.') || contains(array(Global.CN), sa.name)
}]

Here is where I get lost
Again I’m new to this
Wondering if you can help a noob out
module SA 'SA-Storage.bicep' = [for (sa, index) in storageInfo: if (SAInfo[index].match) {
name: 'dp${Deployment}-SA-${sa.name}'
params: {

[brwilkinson]

Hi @Demic198

Thank you for taking the time to reach out. I would be happy to cover this topic.

I will use this repo for a simple example.

https://github.com/brwilkinson/Bicep-Demo/tree/prod/bicep

In that sample, this is the main deployment script.

https://github.com/brwilkinson/Bicep-Demo/blob/prod/bicep/0-demo-deploy.ps1

$rgname = 'bicepdemo'
$region = 'CentralUS'
Write-Warning -Message "RG is: [$rgname] in Region: [$region]"

$MyParametersDeployALL = @{
    ResourceGroupName     = $rgname
    TemplateParameterFile = "C:\Repos\Bicep-Demo\Bicep-Demo\bicep\0-param-env1.json"
    Verbose               = $true
    WhatIf                = $false
}

break

New-AzResourceGroup -Name $rgname -Location $region -Force

# Orchestrate the deployment of all resources - VM and Storage or other
New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\ALL.bicep

# Deploy Single layer, inner dev loop - VM only
New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\VN.bicep

# Deploy Single layer, inner dev loop - Storage only
New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\ASP.bicep

# Deploy Single layer, inner dev loop - WA only
New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\WA.bicep

# Deploy Single layer, inner dev loop - SA only
New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\SA.bicep

Now lets take a look at a parameter file that represents a single Resource Group or Environment.

https://github.com/brwilkinson/Bicep-Demo/blob/prod/bicep/0-param-env1.json

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "stage": {
            "value": {
                "SA": 1,
                "VN": 1,
                "WA": 1,
                "NSG": 1,
                "ASP": 1
            }
        },
        "DeploymentInfo": {
            "value": {
                "vnInfo": [
                    {
                        "name": "bicepdemo-vnet"
                    }
                ],
                "aspinfo": [
                    {
                        "name": "bicepdemo-asp"
                    }
                ],
                "waInfo": [
                    {
                        "name": "bicepdemo-webapp",
                        "asp": "bicepdemo-asp"
                    },
                    {
                        "name": "bicepdemo-webapp2",
                        "asp": "bicepdemo-asp"
                    }
                ],
                "saInfo": [
                    {
                        "name": "bicepdemo1253",
                        "skuName": "Standard_LRS",
                        "kind": "StorageV2"
                    }
                ]
            }
        }
    }
}

In this file I can have as many different resource types that I like, this one has:

• appserviceplan
• webapp
• storage
• virtualnetwork

Notice how they are all nested under the same parent Parameter called DeploymentInfo

Now before I go on the idea behind this method, is that I can clone this parameter file, rename it to UAT, then I have a new Resource group and a new Environment. I don't have to change any values in the file, plus if I have two environment files, I can do a diff on them to know any differences between my Dev,Test and Prod environment. The goal is to add new resources to Dev, then Test and eventually get them to Prod. However if over time you have alot of differences between these environment files, that means Dev and Prod are not the same and that is not ideal.

--

In the Bicep files, there is a module file called ALL

https://github.com/brwilkinson/Bicep-Demo/blob/prod/bicep/ALL.bicep

That is an orchestration module, it calls all other child modules, in the correct order based on dependencies.

I can as you see in the PowerShell above all that single Module and it will deploy the FULL Environment.

Now what I i just want to deploy part of it ?

Well I can also do that by just calling the Storage module

https://github.com/brwilkinson/Bicep-Demo/blob/prod/bicep/SA.bicep

The reason that works is because ALL of the top level modules have the same parameters.

That is:

• ALL
• appserviceplan
• webapp
• storage
• virtualnetwork

Okay hopefully you are follow up to there?

--

Now lets look in the storage module

You can see the following line of code. It takes the deploymentinfo array that was passed in as a parameter and takes the sub property of that object that is relative to what the file cares about, which is storage.

So that works great.

var saInfo = deploymentInfo.saInfo

Now as my deployments go larger and more complex, I have different parameter files for different types of Environments.

So we add a bit of a safeguard...

So now just do some extra checks. ... when the storage Module runs, lets check if deploymentInfo actually contains the array sainfo

var storageInfo = contains(DeploymentInfo, 'saInfo') ? DeploymentInfo.saInfo : []

If it doesn't just assign storageInfo as an empty array, rather than having an error.

Now this is just a safeguard, what you really want to do is go to the stage in the parameter file and set the SA stage to 0.

that way it will not deploy that later if you don't need storage in that environment.

        "stage": {
            "value": {
                "SA": 0,
                "VN": 1,
                "WA": 1,
                "NSG": 1,
                "ASP": 1
            }

However mainly since you can deploy by calling ALLor SA this stops the error if you deploy SA.bicep and saInfo does not exist in the parameter file. If you are deploying directly, it should be into a dev or sandbox anyway, so the deployment will run and nothing really happens. You will notice nothing happened, when there is no storage account created.

Okay hopefully that makes sense?

--

The next bit is one of my favorite features, however it is not included the sample repo that i shared above.

let me try to keep it simple.

param deploymentInfo object
param stage object
param CN string = '.'

var storageInfo = contains(DeploymentInfo, 'saInfo') ? DeploymentInfo.saInfo : []

var SAInfo = [for (sa, index) in storageInfo: {
match: (Global.CN == '.') || contains(array(Global.CN), sa.name)
}]

module SA 'SA-storageaccount.bicep' = [for (sa, index) in saInfo:  if (SAInfo[index].match) {
  name: 'dp-sa-storage-${sa.name}'
  params: {
    saInfo: sa
  }
}]

trying to explain what the above code does.

                "saInfo": [
                    {
                        "name": "bicepdemo1253",
                        "skuName": "Standard_LRS",
                        "kind": "StorageV2"
                    },
                    {
                        "name": "bicepdemo456",
                        "skuName": "Standard_LRS",
                        "kind": "StorageV2"
                    },
                    {
                        "name": "test456",
                        "skuName": "Standard_LRS",
                        "kind": "StorageV2"
                    }
                ]

If I deploy and I don't pass in any CN then the '.' will match on all names in the array, however if I pass in a single name of a storage account it will loop through and only deploy the storage accounts that match CN.

New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\SA.bicep -CN .     // this deploy all 3 storage accounts

New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\SA.bicep     // this deploy all  3 storage accounts

New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\SA.bicep -CN bicepdemo1253  // those only deploys 1 storage account

New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\SA.bicep -CN bicepdemo  // those only deploys first 2 storage account

So now you have 3 main deployment options

1. Deploy the whole environment...

New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\ALL.bicep

1. Deploy 1 layer...

New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\SA.bicep

1. Deploy a subset of resources in a layer...

New-AzResourceGroupDeployment @MyParametersDeployALL -TemplateFile .\bicep\SA.bicep -CN test

This kind of precision, without editing or modifying any parameter files REALLY streamlines your ability to quickly deploy and do testing and template development on the commandline locally and still fits exactly to the pipeline deployments, which mostly runs the ALL.bicep

Actually for my environments I have 2 pipelines, 1 is a deploy all and the other is a STAGE pipeline.

I make special Stage files for different types of Environments, to give you limited options to deploy certain things, based on what kind of environment it is.

sample of a yaml parameter where I limit what stage can be exectuted

  - name: CN
    displayName: Deployment Stage
    type: string
    default: '.'
    values:
      - '.'
      - BE
      - SFM

Anyway I won't go into more detail, however please feel free to ask more questions Etc, if I missed anything or something needs more explanation.

[Demic198]

Oh wow the first two sections i got. That was a dope explanation!

now for that third feature you have Global.cn but we reference CN ( my assumption is that this object comes from the parameter file as Well. You said it’s not in this repo but it must be in the ADF. )

haha I kind of don’t want the explanation to stop as this was pretty cool.

side note, when learning bicep online, they tend to create rg and then the modules reference the rg as the scope. This requires the targetscope as subscription.

Would following that pattern not work with this? My guess creating the RG and the way you have the deployments laid out gives you more flexibility ?

[brwilkinson]

You can choose to do deployments into the Management Group, Subscription or Resource Group.

Depending what your focus is, will depend on which scope is the best.

I.e. if you are deploying landing zones, which is high level architecture for Azure, the focus is on creating subscriptions via Management group deployments.

If your focus on IT related tasks, then you maybe creating just simply things like Resource Groups and Virtual Networks, then the Subscription deployment works well.

However if you are focused on Application Stamps, then you can deploy into the Resource group.

Since my focus on deploying Application environments, I do 2 separate deployments, using 2 separate Service Principals.

1. Deploy with subscription owner principal, Create the RG and User assigned identities and also Role based access role assignments only.
2. Deploy into the Resource group, using a specific service principal that only has Contributor access to that Resource Group only, plus some other related resources such as DNS ones in a Hub or storage or keyvaults that maybe outside of the local resource group.

So any of these work. It just depends. I try to limit any permissions that any single deployment service principal has.

As far as the CN thing goes.....

This is the actual script that is the same equivalent to the one I shared for that other demo.

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/tenants/AOA/aoa-azure-Deploy.ps1#L83

That script contain many example individual command line options to depoy different resources.

AzSet -App AOA -Enviro T5  #<-- set the environment first, this is an RG and also how it find the parameter file
AzDeploy @Current -Prefix ACU1 -TF ADF:\bicep\SA.bicep -CN logs

That is line 83...

now what is AzDeploy ? it is a script that was written to take a few arguments, which mainly just find the correct paramter file and template to deploy with.

This is the actual script that is called and that I use for all of my deployments. it covers all of the scenarios for local deployment and also pipeline deployment.

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/release-az/Start-AzDeploy.ps1

in that file it just adds whatever value that you passed in on the command line and sets it on global

$Global.Add('CN', $CN)

That is where Global gets the value that you see below. it doesn't really get passed in as a parameter exactly, it's more like it's injected into Global i the deployment script.

So it gets from here

AzDeploy @Current -Prefix ACU1 -TF ADF:\bicep\SA.bicep -CN logs  #<--- here

via the parameter.

        [alias('ComputerName')]
        [string] $CN = '.',

$Global.Add('CN', $CN)

Then it's available in Global in every template.

param deploymentInfo object
param stage object

var storageInfo = contains(DeploymentInfo, 'saInfo') ? DeploymentInfo.saInfo : []

var SAInfo = [for (sa, index) in storageInfo: {
match: (Global.CN == '.') || contains(array(Global.CN), sa.name)
}]

module SA 'SA-storageaccount.bicep' = [for (sa, index) in saInfo:  if (SAInfo[index].match) {
  name: 'dp-sa-storage-${sa.name}'
  params: {
    saInfo: sa
  }
}]