We know that resources have a type, and that they are continuously getting updated by Azure team either for fixing bugs or implementing new features. The new version might have breaking changes. For example, if you have written a template consisting of resources without providing a specific version number and execute the same template sometime in future, you may get unexpected results in such cases because without a specific version, latest version is used. To ensure that such problems do not arise, the Azure team assigns a version number to each resource and updates it whenever a breaking change is made. The version number is usually a date and is known as the API version in ARM templates. You must assign a value to a resource's API version. It is also important to understand that an API version often has different values for each resource; this is because each resource has its own independent life cycle development process.

The following example illustrates using apiVersion in a storage account:

"apiVersion": "2018-02-01"

Other API versions for the preceding storage account include the following:

2018-03-01-preview
2018-02-01
2017-10-01
2017-06-01
2016-12-01
2016-05-01
2016-01-01
2015-06-15
2015-05-01-preview

In fact, Azure PowerShell has a cmdlet, Get-AzureRmResourceProvider, which provides all existing API versions and locations of a resource.

Executing the following code provides the API versions of a resource supported by an Azure storage account:

(Get-AzureRmResourceProvider -ProviderNamespace Microsoft.Storage).ResourceTypes[0].ApiVersions

The API versions available for a public IP address resource are as follows:

2018-07-01
2018-06-01
2018-05-01
2018-04-01
2018-03-01
2018-02-01
2018-01-01
2017-11-01
2017-10-01
2017-09-01
2017-08-01
2017-06-01
2017-04-01
2017-03-01
2016-12-01
2016-11-01
2016-10-01
2016-09-01
2016-08-01
2016-07-01
2016-06-01
2016-03-30
2015-06-15
2015-05-01-preview
2014-12-01-preview

Astute readers might have noticed a number of API version values that include preview. This is because they are under development, and may change or be cleaned up at a later date. Note that it is not recommended to rely on a preview version of a resource.

As well as providing a specific resource version, it is also possible to assign the latest API version. This will ensure that users enable the most recent API version whenever a template is used in deployment. Once again, it is not recommended to use the latest API version, simply because the resource may have evolved significantly over time.

The find the latest API version, use the following code: "apiVersion": "latest".