Azure Image Builder is an Azure managed service (running Packer underneath) that allows you to create customised Virtual Machine images.

By using standardized virtual machine (VM) images, your organization can more easily migrate to the cloud and help ensure consistency in your deployments. Images ordinarily include predefined security, configuration settings, and any necessary software. Setting up your own imaging pipeline requires time, infrastructure, and many other details. With Azure VM Image Builder, you only need to create a configuration that describes your image and submit it to the service where it is built and distributed. With VM Image Builder, you can migrate your image customization pipeline to Azure as you continue using existing scripts, commands, and processes. You can integrate your core applications into a VM image so that your VMs can take on workloads after the images are created. You can even add configurations to build images for Azure Virtual Desktop as virtual hard discs (VHDs) for use in Azure Stack or for ease of exporting.

Book review of Azure Architecture Explained: A comprehensive guide to building effective cloud solutions

Classless Inter-Domain Routing (CIDR) is a method of allocating IP addresses and routing Internet Protocol (IP) packets.

This article includes sample Bicep functions for working with CIDR, for Azure Virtual Network and Subnet creation.

With more support for IPv6 being added to native Azure products, its time to take a closer look into IPv6 and its use within Azure.

The deployment of IPv6, the latest version of the Internet Protocol (IP), has been in progress since the mid-2000s. IPv6 was designed as the successor protocol for IPv4 with an expanded addressing space. IPv4, which has been in use since 1982, is in the final stages of exhausting its unallocated address space but still carries most Internet traffic.

Recently, I was deploying an User Assigned Managed identity, and assigning the managed identity a role assignment with Azure Bicep, and ran into an issue, where the assignment would fail, but then after a rerun would work.

Principal e892476361114c90be141d9bf20cc94b does not exist in the directory 73160ae1-aa4a-48b5-a424-d5e43d808f53. Check that you have the correct principal ID. If you are creating this principal and then immediately assigning a role, this error might be related to a replication delay. In this case, set the role assignment principalType property to a value, such as ServicePrincipal, User, or Group. See https://aka.ms/docs-principaltype

What was happening, was that the User Assigned Identity was created, and immediately after the role assignment was attempted, leaving no time for the role assignment API to be aware that the User Assigned Managed identity existed, even with a hard coded dependson!

The fix was to Set the: principalType into the Bicep, as ServicePrincipal, making sure that the Azure platform can wait for the replication to complete, before trying the role assignment.

The principalType property specifies whether the principal is a user, a group, or a service principal. Managed identities are a form of service principal.

resource uami 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: azUserAssignedManagedIdentity
  location: location
}

resource uamiassignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, 'contributor')
  properties: {
    principalId: uami.properties.principalId
    principalType: 'ServicePrincipal' 
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', 'b24988ac-6180-42a0-ab88-20f7382dd24c') // Contributor
  }
  scope: resourceGroup()
}