☁️ Azure Virtual Machine Automanage Configuration Assignment Terraform Module

Onboards one virtual machine to an Automanage configuration profile — and carries the fact that the provider does not: the service retires on 30 September 2027. Targets hashicorp/azurerm ~> 4.0.

• 🎛️ Enrolls a virtual machine in an Automanage configuration profile.
• 1️⃣ Exactly one assignment per machine — the provider hard-codes the name, so there is no name argument.
• ⏳ Emits the retirement date and the migration target as values, not as prose.
• 🔍 Reports where the profile lives, so the read permission can be granted in the right place.
• ⚠️ Names what the assignment causes: Azure onboards the machine to the services the profile lists, unobserved by Terraform, and removing the assignment undoes none of it.

💡 Why it matters: Microsoft has announced that the Azure Automanage Best Practices service retires on 30 September 2027, with Azure Policy as the documented migration target — and nothing in Terraform says so. The resource is not flagged deprecated in the provider schema and the provider's documentation carries no notice, so a caller reading only Terraform has no way to find out. This module makes that fact part of the plan.

If this module saved you time:

• ⭐ Star the repository — it genuinely helps other people find it.
• 💼 Connect on LinkedIn — linkedin.com/in/microsoftexpert
• ☕ Buy me a coffee — buymeacoffee.com/microsoftexpert

flowchart TB
    CFG["terraform-azurerm-automanage-configuration -- the profile"]
    VM["terraform-azurerm-linux-virtual-machine or -windows-virtual-machine"]
    ASSIGN["terraform-azurerm-virtual-machine-automanage-configuration-assignment"]
    SVC["services the PROFILE enables -- backup, update management, monitoring"]
    POLICY["Azure Policy -- the documented migration target after 2027-09-30"]

    CFG -->|"id to configuration_id"| ASSIGN
    VM -->|"id to virtual_machine_id -- ONE assignment per machine, name fixed to default"| ASSIGN
    ASSIGN -->|"Automanage onboards the machine, unobserved by Terraform"| SVC
    ASSIGN -.->|"THE SERVICE RETIRES 2027-09-30 -- migrate to this"| POLICY

    classDef self fill:#0078D4,stroke:#004578,color:#ffffff
    classDef keystone fill:#004578,stroke:#002B4A,color:#ffffff
    classDef ext fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    class ASSIGN self
    class VM keystone
    class CFG,SVC,POLICY ext

The dotted edge is the one to read. It does not represent anything this module builds — it records where Microsoft says configurations should end up after the retirement date, and it is drawn because a family diagram that omitted it would be quietly out of date.

flowchart TB
    IN1["virtual_machine_id -- force-new"]
    IN2["configuration_id -- force-new, either namespace casing accepted"]
    IN3["timeouts -- THREE keys, there is no update function"]
    RES["azurerm_virtual_machine_automanage_configuration_assignment.this -- name fixed to default"]
    OUT1["id ending in the literal segment default"]
    OUT2["the retirement date and the migration target"]
    OUT3["spans_subscriptions and the parsed names"]
    OUT4["posture -- onboarding is unobserved, removal undoes nothing"]

    IN1 --> RES
    IN2 --> RES
    IN3 --> RES
    RES --> OUT1
    RES --> OUT2
    RES --> OUT3
    RES --> OUT4

    classDef self fill:#0078D4,stroke:#004578,color:#ffffff
    classDef ext fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    class RES self
    class IN1,IN2,IN3,OUT1,OUT2,OUT3,OUT4 ext

Both arguments are force-new and there is no update function, so the timeouts type carries three keys.

• 🔴 The service is retiring on 2027-09-30 and the schema says nothing. deprecated is false on this resource, and the provider documentation carries no notice. Microsoft states that as a result of the retirement, creating a new configuration profile or onboarding a new subscription will return an error.
• 🔴 The assignment name is HARD-CODED to default. The provider's own comment says the API requires it. There is no name argument, and a machine has one Automanage assignment or none.
• 🔴 Changing the profile leaves the machine briefly onboarded to nothing. Both arguments are force-new and the replacement reuses the identical Resource ID, so create-before-destroy is impossible.
• 🟠 The real namespace casing is Microsoft.AutoManage — capital M — in both the provider's import example and the sibling configuration resource. A case-sensitive check on the other spelling would reject the sibling module's own id output, so this module accepts either.
• 🟠 This IS a real ARM record, unlike the gallery application assignment in the same family. Its ID is returned by Azure rather than composed, and its delete is a real delete.
• 🟠 A successful create means the assignment exists, not that the machine is configured. Automanage onboards the machine to the profile's services on its own schedule, and no timeout here bounds that.
• 🟡 The ID uses the CALLER'S provider subscription, with the machine's resource group and name.
• 🟡 No lock is taken on the machine — unlike both of its neighbours in this family, which are read-modify-write operations and do lock it.
• ✅ An import guard exists, and since the name is fixed it is effectively a test of whether the machine is onboarded at all.
• ✅ No tags, no sensitive field, no credential — the resource names two Resource IDs and nothing else.

🔒 The permission understates what applying this does. Onboarding a machine causes Azure to create and configure resources this module never mentions — a Recovery Services vault, an Automation account, a Log Analytics workspace, agents on the machine. None is a Terraform object, none appears in any plan, and terraform destroy removes none of them. Read the profile before assigning it.

⚠️ Microsoft documents wider permissions for first-time enablement: Owner, or Contributor together with User Access Administrator, at the subscription, because the service creates role assignments of its own. The table above covers an assignment on a subscription already onboarded.

ℹ️ Automanage acts continuously with its own identity. It monitors for drift and remediates it, so a setting changed by hand on the machine may be changed back with no Terraform run involved.

• The Microsoft.Automanage resource provider registered in the target subscription.
• The subscription already onboarded to Automanage, or the wider first-time permissions above.
• The configuration profile already created — the sibling module produces one, and Microsoft publishes built-in production and dev/test profiles.
• The machine running, with a healthy Azure VM agent, on a supported operating system.
• 🔴 A plan for 30 September 2027. After that date the service is retired and Microsoft's migration target is Azure Policy.

terraform-azurerm-virtual-machine-automanage-configuration-assignment/
├── providers.tf    # required_version >= 1.12.0, azurerm ~> 4.0, no provider block
├── variables.tf    # 3 inputs, 2 validations -- the machine, the profile, the deadlines
├── main.tf         # one keystone `this`; ID parsing read from the END; a THREE-key timeouts block
├── outputs.tf      # 30 outputs -- id first, then the retirement facts, then posture
├── README.md       # this file
├── SCOPE.md        # the cross-module contract
├── LICENSE         # MIT
└── .gitignore

provider "azurerm" {
  features {}
}

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id
  configuration_id   = module.production_profile.id
}

⚠️ Read the_automanage_service_is_announced_for_retirement before adopting this. See example 1.

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id
  configuration_id   = module.production_profile.id
}

output "automanage_end_of_life" {
  value = {
    retiring   = module.automanage_assignment.the_automanage_service_is_announced_for_retirement
    on         = module.automanage_assignment.automanage_retirement_date
    migrate_to = module.automanage_assignment.automanage_migration_target
  }
}

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id
  configuration_id   = module.production_profile.id
}

# A SECOND assignment on the same machine is not a second assignment.
module "automanage_assignment_devtest" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id       # <-- the same machine
  configuration_id   = var.devtest_profile_id
}

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id

  # Changing this DELETES the assignment and creates a new one.
  configuration_id = var.hardened_profile_id
}

# Both of these are accepted. Azure and the provider emit the FIRST spelling.
configuration_id = "/subscriptions/.../providers/Microsoft.AutoManage/configurationProfiles/prod"
configuration_id = "/subscriptions/.../providers/Microsoft.Automanage/configurationProfiles/prod"

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id
  configuration_id   = var.platform_production_profile_id # a central profile
}

check "cross_subscription_read_was_granted" {
  assert {
    condition     = !module.automanage_assignment.spans_subscriptions || var.platform_profile_reader_granted
    error_message = "The profile is in another subscription and read access must be granted there."
  }
}

# WRONG -- an Arc-enabled server where a virtual machine belongs.
virtual_machine_id = var.arc_machine_id

# WRONG -- a scale set.
virtual_machine_id = var.app_scale_set_id

# WRONG -- a child of the profile.
configuration_id = var.profile_version_id

# WRONG -- a virtual machine ID where the profile belongs.
configuration_id = var.app_vm_id

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id
  configuration_id   = module.production_profile.id

  timeouts = {
    create = "45m"
  }
}

module "production_profile" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-automanage-configuration.git?ref=v1.0.0"

  name                = "conf-production"
  resource_group_name = module.rg.name
  location            = module.rg.location
}

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id
  configuration_id   = module.production_profile.id
}

output "automanage_agent_caveat" {
  value = module.automanage_assignment.monitoring_agent_dependency_was_already_cut
}

# Removing this block stops Automanage MANAGING the machine.
# It does not undo what Automanage configured.

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id
  configuration_id   = module.production_profile.id
}

module "restore_disk" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-implicit-data-disk-from-source.git?ref=v1.0.0"

  name               = "disk-restored-01"
  virtual_machine_id = module.app_vm.id # the SAME machine
  source_resource_id = var.nightly_snapshot_id
  create_option      = "Copy"
  disk_size_gb       = 256
  lun                = 1
}

provider "azurerm" {
  features {}
}

module "rg" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-resource-group.git?ref=v1.0.0"

  name     = "rg-app-eastus"
  location = "eastus"

  tags = {
    environment = "production"
    workload    = "line-of-business-app"
  }
}

module "app_vnet" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-network.git?ref=v1.0.0"

  name                = "vnet-app-eastus"
  resource_group_name = module.rg.name
  location            = module.rg.location
  address_space       = ["10.90.0.0/16"]

  subnets = {
    snet-app = {
      address_prefixes = ["10.90.1.0/24"]
    }
  }

  tags = module.rg.tags
}

module "app_nic" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-network-interface.git?ref=v1.0.0"

  name                = "nic-app01"
  resource_group_name = module.rg.name
  location            = module.rg.location

  ip_configurations = {
    internal = {
      subnet_id                     = module.app_vnet.subnet_ids["snet-app"]
      private_ip_address_allocation = "Dynamic"
    }
  }

  tags = module.rg.tags
}

module "app_vm" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-linux-virtual-machine.git?ref=v1.0.0"

  name                = "vm-app01"
  resource_group_name = module.rg.name
  location            = module.rg.location

  size           = "Standard_D2s_v5"
  admin_username = "azureadmin"

  network_interface_ids = [module.app_nic.id]

  tags = module.rg.tags
}

# The profile decides which services the machine is enrolled in.
module "production_profile" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-automanage-configuration.git?ref=v1.0.0"

  name                = "conf-production"
  resource_group_name = module.rg.name
  location            = module.rg.location
}

module "automanage_assignment" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-virtual-machine-automanage-configuration-assignment.git?ref=v1.0.0"

  virtual_machine_id = module.app_vm.id
  configuration_id   = module.production_profile.id
}

output "automanage" {
  value = {
    id            = module.automanage_assignment.id
    profile       = module.automanage_assignment.configuration_name
    machine       = module.automanage_assignment.virtual_machine_name
    cross_sub     = module.automanage_assignment.spans_subscriptions
    retires_on    = module.automanage_assignment.automanage_retirement_date
    migrate_to    = module.automanage_assignment.automanage_migration_target
    agent_caveat  = module.automanage_assignment.monitoring_agent_dependency_was_already_cut
  }
}

Required: virtual_machine_id, configuration_id Optional: timeouts

There is no name variable — the provider hard-codes the assignment name — and no tags variable, because the resource exposes none.

variable "virtual_machine_id" {
  type = string
  # REQUIRED, FORCE-NEW. Anchored to .../virtualMachines/<vm> at both ends.
  # Arc-enabled servers use a DIFFERENT resource and are refused here.
}

variable "configuration_id" {
  type = string
  # REQUIRED, FORCE-NEW. Anchored to .../configurationProfiles/<name>.
  # EITHER namespace casing is accepted -- Microsoft.AutoManage is what Azure
  # and the sibling configuration module actually emit.
}

variable "timeouts" {
  type = object({
    create = optional(string)
    read   = optional(string)
    delete = optional(string)
  })
  default = null
  # THREE KEYS. Both arguments are force-new, so there is no update operation
  # and no update timeout; Terraform would discard an `update` key silently.
}

The retirement is the first architectural fact. Microsoft has announced that the Azure Automanage Best Practices service retires on 30 September 2027, and states that as a result, creating a new configuration profile or onboarding a new subscription will return an error; the migration target is Azure Policy. Nothing in Terraform says so — the schema's deprecated flag is false and the provider documentation carries no notice. That combination has now been seen three times in this library, and it is why a schema flag is treated as necessary but never sufficient evidence that a resource has a future. The module emits the date as a value so a policy check can act on it.

The module is authored rather than withheld, which is a deliberate departure from how Azure Blueprints and the Key Vault managed storage account were handled. Those were services already gone or already refusing new work. This one has a future end date, a live resource in the pinned provider, and an already-authored sibling that creates the profiles — so withholding it would leave the library able to create a profile it cannot assign. Honest documentation beats an absent module here.

There is no name argument, and that shapes everything. The provider hard-codes the assignment name to default because the API requires it, so a machine has one Automanage assignment or none. Two module instances on one machine compose the same Resource ID and the second fails on the import guard; changing the profile is a delete-then-create on that same ID, which makes create-before-destroy impossible and leaves the machine briefly onboarded to nothing.

This is a real ARM record, unlike its neighbours. The gallery application assignment and the implicit data disk are both read-modify-write operations on the machine with synthetic IDs; this one creates a genuine configurationProfileAssignments object whose ID Azure returns, whose delete is a real delete, and which can be used where an ARM Resource ID is expected. It also takes no lock — and therefore does not serialise against the two that do.

The permission table understates the effect. The profile, not the assignment, decides which Azure services are enabled and how; applying an assignment can create a Recovery Services vault, an Automation account, a Log Analytics workspace and their contents. None is a Terraform object and terraform destroy removes none of them. Read the profile before assigning it — and note that editing the profile changes what every assigned machine gets, without any assignment changing.

The namespace casing nearly became a defect. Azure and the provider emit Microsoft.AutoManage with a capital M; a case-sensitive check on the other spelling would have rejected the sibling configuration module's own id output. Because a validation {} failure blocks terraform destroy as well as apply, that would have been the worst class of defect — a check that refuses legal input. This module accepts either casing, as the sibling snapshot module in this library does for its own ID check.

lifecycle is not valid inside a module block, so a caller cannot add prevent_destroy here.

🔒 The security question here is not a setting on this resource. It is what the profile enables, and who can edit the profile.

terraform init -backend=false
terraform validate
terraform fmt -check

Pin the module by tag — ?ref=v1.0.0 — never a branch.

Plan-only: this repository performs no cloud apply. A human applies from CI — and for this module, after someone has read both the profile and the retirement date.

What terraform validate covers, offline and without credentials:

• The anchored virtual machine ID check, including refusing Arc machines and scale sets.
• The anchored configuration profile ID check, in both namespace casings.

What only terraform plan exercises (credentials required):

• That the machine and the profile exist.
• The import guard, if the machine is already onboarded by any means.

What only terraform apply reveals:

• Whether the subscription is onboarded to Automanage.
• Whether the machine's operating system is supported.
• Whether the identity can read a profile in another subscription.

What nothing reveals at all:

• Whether Automanage has finished onboarding the machine.
• Which of the profile's services are still enforced after the 2025 monitoring-agent change.
• What the profile will create in your subscription.

ℹ️ terraform console fires root-module variable validations, unlike terraform validate on a calling configuration. It is the honest offline harness for the first list and for every derived flag — including both branches of each span flag and both namespace casings.

Outputs:

id                                                = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-app-eastus/providers/Microsoft.Compute/virtualMachines/vm-app01/providers/Microsoft.AutoManage/configurationProfileAssignments/default"
virtual_machine_name                              = "vm-app01"
configuration_name                                = "conf-production"
spans_subscriptions                               = false
spans_resource_groups                             = false
the_automanage_service_is_announced_for_retirement = true
automanage_retirement_date                        = "2027-09-30"
automanage_migration_target                       = "Azure Policy"
monitoring_agent_dependency_was_already_cut       = true
fields_that_can_change_after_creation             = []

ℹ️ Look at the last segment of the id. It is the literal string default, not a name you chose — and the two providers segments mark this as an extension resource living under the machine.

• azurerm_virtual_machine_automanage_configuration_assignment — provider reference
• Azure Automanage machine best practices — including the retirement notice
• Configuration profiles — what a profile decides
• Sibling modules: terraform-azurerm-automanage-configuration, terraform-azurerm-virtual-machine-implicit-data-disk-from-source, terraform-azurerm-linux-virtual-machine, terraform-azurerm-windows-virtual-machine, terraform-azurerm-resource-group
• This module's SCOPE.md — the cross-module contract

💙 "Infrastructure as Code should be standardized, consistent, and secure."