One way for specifying the parameter values when deploying a template is through a variable file. Often, a single template is accompanied by more than one parameter file, for example, one for test and one for production. The JSON for a parameter file appears as follows:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "exampleParameter": {
      "value": "exampleValue"
    }
  }
}

Just like an ARM template, every parameter file is a JSON object with mandatory $schema and contentVersion properties. The third property parameter is used to specify one or more parameter values. For each parameter, specify its name as the key and an object as the value. This object can hold the value key for providing the actual value of the parameter.

While very valuable for specifying names for resources, scaling options, and other things that have to vary between environments, this solution is not useful for secrets. Keys, passwords, and other secrets should not be stored as plaintext in source control in a parameter file. For secrets, another notation is available:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "exampleParameter": {
      "reference": {
        “keyvault”: {
          "id": "/subscriptions/…/Microsoft.KeyVault/vaults/<vaultname>"
        },
        “secretName”: “myKeyVaultSecret”
      }
    }
  }
}

With this notation, instead of specifying the value directly, there is a pointer to a location in an Azure key vault where the correct value is stored. When deploying the template, this secret is (within Azure!) taken from the key vault and used in deployment. This is allowed only if the user or service starting the deployment has either an owner or contributor role in relation to the key vault and the key vault is enabled for template deployment.