Add AKS Automatic cluster quickstart sample

[Allen Sudbring (asudbring)]

Summary

Adds a Terraform quickstart sample that deploys an Azure Kubernetes Service (AKS) Automatic cluster with a system-assigned managed identity.

Why AzAPI

The AzureRM provider's azurerm_kubernetes_cluster resource always sets the managed cluster SKU name to Base and can't create the Automatic SKU, so the cluster is declared with azapi_resource. This follows existing AzAPI precedent in the repo (201-aks-clusters-fleet-manager-azapi, 101-azapi-eventhub-network-rules).

Contents

quickstart/101-aks-automatic/

• providers.tf
• main.tf
• variables.tf
• outputs.tf
• readme.md

Testing

This sample was deployed and torn down against a live Azure subscription before submission.

Step	Result
terraform fmt	no changes
terraform validate	success
terraform apply	success — 4 resources added, 16m42s
Verification	sku.name = Automatic, sku.tier = Standard, provisioningState = Succeeded, identity = SystemAssigned, Kubernetes 1.35.6
terraform destroy	success — 4 resources destroyed
Teardown check	resource group confirmed deleted

Region: eastus.

TestRecord.md is intentionally omitted — the CI pipeline generates it.

[Steven Ma (stevenjma)]

Allen Sudbring (@asudbring) this is no longer accurate. we now support azurerm and azapi for aks automatic: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/kubernetes_automatic_cluster
Could you update this to both include azurerm and azapi examples?

[Allen Sudbring (asudbring)]

Thanks for the pointer — you're right, azurerm_kubernetes_automatic_cluster shipped in AzureRM 5.0.0 (July 27, 2026). I've updated the PR to cover both providers:

Sample	Provider	Cluster resource
quickstart/101-aks-automatic	azurerm ~>5.0	azurerm_kubernetes_automatic_cluster
quickstart/101-aks-automatic-azapi	azapi ~>2.0	azapi_resource

Split into two sibling samples so each is independently deployable and gets its own CI run. The readmes cross-link, and the AzAPI one now explains when you'd reach for it (direct control over the managed cluster API payload, or properties AzureRM hasn't surfaced yet) rather than claiming AzureRM can't do it.

The AzureRM sample also drops the now-unnecessary cluster_sku_name variable and exports node_resource_group_id / fully_qualified_domain_name from the native resource.

Testing

Both samples were deployed and torn down against a live subscription after this change.

Step	AzureRM sample	AzAPI sample
terraform fmt -check	no changes	no changes
terraform validate	success	success
terraform apply	success — 4 added, 15m20s	success — 4 added, 12m16s
Verification	sku.name = Automatic, sku.tier = Standard, provisioningState = Succeeded, identity = SystemAssigned, Kubernetes 1.35.6	same
terraform plan -detailed-exitcode (post-apply)	no changes	no changes
terraform destroy	success — 4 destroyed	success — 4 destroyed
Teardown check	resource group confirmed deleted	resource group confirmed deleted

Region: westus2. Note for anyone reproducing — eastus currently returns AKSCapacityHeavyUsage for API Server VNet Integration, so I tested in westus2. The samples still default to eastus; happy to change the default if you'd prefer.

TestRecord.md is intentionally omitted for both — the CI pipeline generates it.

[Allen Sudbring (asudbring)]

Steven Ma (@stevenjma)
Can you review and merge?

Thanks!

[Steven (stemaMSFT)]

The AzureRM-first direction and separate AzAPI escape hatch look good. I found two issues to address before merge:

• The AzAPI sample accepts cluster_sku_name = "Base" and forwards it to sku.name. That can successfully create a non-Automatic cluster even though the directory, README, and cross-link promise an AKS Automatic sample. Please hard-code Automatic and remove the variable/README row, or rename and broaden the sample.
• quickstart/101-aks-automatic-azapi/main.tf still says AzureRM cannot create the Automatic SKU. That now contradicts the new AzureRM sibling and revised AzAPI README. Please update the source comment to the current rationale: direct API payload/version control or properties AzureRM has not surfaced.

The separate runnable directories and provider-native output differences do not seem blocking.

[Allen Sudbring (asudbring)]

Thanks for the review Steven (@stemaMSFT) — both points are addressed in 31a082f4.

1. AzAPI sample accepted cluster_sku_name = "Base"

Hard-coded. sku.name is now the literal "Automatic" in main.tf, and the cluster_sku_name variable and its README row are removed. The sample can no longer create a non-Automatic cluster, so the directory name, README, and cross-link all hold.

2. Stale rationale comment in 101-aks-automatic-azapi/main.tf

Replaced. The comment no longer claims AzureRM can't create the Automatic SKU. It now reads:

# Create the AKS Automatic cluster.
# The AzAPI provider is used here to get direct control over the managed cluster
# API payload and API version. Reach for this pattern when you need a property
# or an API version that the AzureRM provider hasn't surfaced yet. For the
# provider-native equivalent, see the 101-aks-automatic sample.

That matches the revised README and the new AzureRM sibling.

Also changed: default region

You raised this on #490, and it applies equally here, so I made the same change rather than leaving these two samples on the known-failing path. Both now default to westus2, the region they were validated in, and each README carries a note explaining that eastus returned AKSCapacityHeavyUsage for API Server VNet Integration at the time of testing. Happy to revert if you'd rather keep eastus as the default here.

terraform fmt -check, validate, and plan pass for both samples after the change (4 to add each, location westus2).

[Steven Ma (stevenjma)]

Just a few small changes and then we're good to merge

[Steven Ma (stevenjma)]

this should be v4.81 or later

[Steven Ma (stevenjma)]

this note is unnecessary as noise for the customer.

[Allen Sudbring (asudbring)]

Thanks Steven Ma (@stevenjma) — both inline comments addressed in 0b2b2bb7.

readme.md line 5 — "this should be v4.81 or later"

Corrected in 101-aks-automatic/readme.md. You're right and my original note was wrong: I checked the provider repo and website/docs/r/kubernetes_automatic_cluster.html.markdown exists at tag v4.81.0 (July 14, 2026) but returns 404 at v4.80.0. The 5.0.0 changelog entry I'd been going on only adds azurerm_kubernetes_automatic_cluster_datasource, not the resource. So v4.81 is the correct minimum.

readme.md line 24 — tested-region note is noise

Removed from both READMEs in this PR. The westus2 default stays, since that's the validated region, but the explanation is gone.

Also applied here: consistent provider pin

You raised this on #490 and the same mismatch existed here — 101-aks-automatic pinned azurerm ~>5.0 while 101-aks-automatic-azapi pinned ~>4.0. Both are now ~>5.0.

After terraform init -upgrade, both samples resolve azurerm 5.0.1 and pass fmt, validate, and plan (4 to add each).

[Steven (stemaMSFT)]

Validated both AzureRM and AzAPI quickstarts end to end at commit 0b2b2bb in westus2: format/init/validate/plan/apply succeeded, live AKS Automatic SKU and identity assertions passed, post-apply plans showed no drift, and destroy left no residual managed or node resource groups. Approved.