Lets continue to more advanced or intermediate stuff! All the files are stored at folder ..\arm\med_deployment at github

1 Deploy a local ARM template

[…] deploys a storage account, app service plan, and web app

Do, did done.

$resourGr = New-AzResourceGroup -Name "bxoose-rg" -Location "west europe" -Force
Write-Host "rg: " + $gr.ResourceGroupName

$tempFile = "C:\giti\powershell-cmd-bash\arm\med_Deployment\1-deploy-local\azure-deploy.json"

New-AzResourceGroupDeployment -Name deployLocalTemplate -ResourceGroupName $resourGr.ResourceGroupName -projectName "deplocal" -TemplateFile $tempFile -Verbose #  -WhatIf

Now clean it MS says, why this tutorial anyway, well repetition is always good.
2 Deploy a linked template

Previous tutorial, we deployed from local machine.
To deploy complex solutions, you can sub divide the templates, and deploy from main.
Now we will do that.
Deploy main template, that triggers the linked template and also store and secure the linked template with SAS token.

A shared access signature (SAS) provides secure delegated access to resources in your storage account. With a SAS, you have granular control over how a client can access your data. (What resources to access, what permission, how long the SAS can be used.)

We will use the same template as we used in Deploy local, but now we will separate the storage account into a linked template.

We will take all that is used for the storage acc. out from the main template.

Save a copy of the main template to your local computer with the .json extension, for example, azuredeploy.json. You don’t need to save a copy of the linked template. The linked template will be copied from a GitHub repository to a storage account.

The following template is the main template. The highlighted Microsoft.Resources/deployments object shows how to call a linked template. The linked template cannot be stored as a local file or a file that is only available on your local network. You can only provide a URI value that includes either HTTP or HTTPS. Resource Manager must be able to access the template. One option is to place your linked template in a storage account, and use the URI for that item. The URI is passed to template using a parameter. See the highlighted parameter definition.

"linkedTemplateUri": {
      "type": "string",
      "metadata": {
        "description": "The Uri of the linked template."

"resources": [
      "name": "linkedTemplate",
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2018-05-01",
      "properties": {
        "mode": "Incremental",
        "templateLink": {
          "uri": "[parameters('linkedTemplateUri')]"
        "parameters": {
          "storageAccountName": {
            "value": "[variables('storageAccountName')]"
          "location": {
            "value": "[parameters('location')]"

"outputs": {
      "storageEndpoint": {
        "type": "object",
        "value": "[reference('linkedTemplate').outputs.storageEndpoint.value]"

The template at git

So first we will create the storage.acc, container, and copy the linked git template to the container.

(Do some testing to see if you the response from the first calls before the next calls in ps1, when you are done, you can deploy all in one, like this)

Here is the rg, with the storage account and the container with the linked template

To deploy the template, generate a SAS token and include it in the URI for the template, set expiry time long enough. When you create SAS anyone with URI can access it, not just the owner. So do not include sensitive information in the template.

First check it with whatif, then run verbose

And here it is deployed

Header over to ARM Lab 105 MS (Create a pipeline)