Every template has to start with a parameters section. This section takes the shape of a JSON object, which can be empty but cannot be left out. The use of this section is to declare one or more parameters that can be specified by the caller of the ARM template, before deploying it. A common reason for using the parameters section is to use the same template for both the test and production environment, but varying the names of resources between the two. An example parameters section might look like this:

{
  “appServiceName”: {
    “type”: “string”,
    “metadata”: {
      “description”: “a free to choose text”
    }
}

For every parameter, a new key is specified with the parameter's name. The value is an object. This object has one mandatory key, type. The allowed values for type are string, int, bool, object, array, secureString, and secureObject. The secureString and secureObject variations can be used to make sure that the runtime values of these parameters are scrubbed from any log and output. They are intended to hold passwords, keys, or other secrets.

The metadata object, with the description key, is optional and can be used to add a description to the parameter for future reference.

Other properties that can be specified on a parameter object are the following:

• minValue and maxValue for specifying bounds on an integer value
• minLength and maxLength for specifying bounds on the length of a string value
• defaultValue for specifying a default value that will be used if no value is specified when applying the template
• allowedValues for specifying an array of allowed values, limiting valid inputs

Next, let's understand what parameter files are.