☁️ Azure Qumulo File System Terraform Module

Manages an Azure Native Qumulo Scalable File System — a third-party marketplace service whose admin password is force-new, so changing it destroys the file system (azurerm_qumulo_file_system). Targets hashicorp/azurerm ~> 4.0.

• 🗄️ A managed scalable file system, sold through the Azure Marketplace and operated by Qumulo — its Resource ID sits under the third-party Qumulo.Storage namespace, not a Microsoft.* one.
• 🔴 admin_password is force-new. Changing it in Terraform destroys the file system and everything on it, so the field is for the initial password only. Rotate inside Qumulo's own portal.
• 🔴 Which means the value in state goes stale by design after any in-product rotation — and "fixing" that apparent drift would be destructive. That inverts the usual advice, so it is stated rather than implied.
• 🔴 Every argument except tags is force-new. Name, region, email, SKU, subnet, zone and all three marketplace identifiers.
• 🔴 The marketplace plan must be accepted for the subscription first, or the apply fails with a marketplace error that describes neither Azure nor the missing prerequisite.
• 🔴 subnet_id is VNet injection into a subnet delegated to Qumulo.Storage — so that subnet is effectively dedicated to this file system.
• 🔒 The password is never emitted, and sensitive redacts plan output rather than encrypting state.
• ✅ is_zone_redundant is emitted, because only Hot_ZRS survives losing an availability zone.

💡 Why it matters: This module's whole job is to stop one specific accident. Rotating a password is the most routine security action there is, and here it deletes a file system — because the provider marks the field force-new and Terraform will happily do exactly what you asked.

If this module saves you time, please consider supporting its continued development:

• ⭐ Star the repository on GitHub.
• 🤝 Connect on LinkedIn: linkedin.com/in/microsoftexpert
• ☕ Buy me a coffee: buymeacoffee.com/microsoftexpert

flowchart TB
  rg["terraform-azurerm-resource-group"]
  mp["AZURE MARKETPLACE: the subscription must be SUBSCRIBED to the Qumulo SaaS offer, on a chosen plan, before anything can be created. Subscription-scoped, and NOT the same thing as accepting a marketplace IMAGE agreement - no azurerm resource performs it."]
  vnet["terraform-azurerm-virtual-network and its subnet. The subnet must be DELEGATED to Qumulo.Storage and is then effectively dedicated to this file system."]
  fs["terraform-azurerm-qumulo-file-system"]
  qumulo["QUMULO, the third party operating the service. The email is shared with them, and the admin password is ROTATED IN THEIR portal - not through Terraform."]
  kv["terraform-azurerm-key-vault, holding the initial admin password out of band. It still lands in Terraform state in plaintext."]

  rg -->|"resource_group_name and location"| fs
  mp -->|"plan accepted, or apply fails with a marketplace error"| fs
  vnet -->|"subnet_id, VNet injection into a delegated subnet"| fs
  kv -->|"admin_password, initial only"| fs
  fs -->|"operated by, and email shared with"| qumulo
  qumulo -->|"rotate the password HERE - changing it in Terraform destroys the file system"| fs

  classDef mine fill:#0078D4,stroke:#004578,color:#fff;
  classDef keystone fill:#004578,stroke:#001f3f,color:#fff;
  classDef sib fill:#eef2f7,stroke:#b8c4d0,color:#1b1b1b;
  class fs mine;
  class qumulo,mp keystone;
  class rg,vnet,kv sib;

flowchart TB
  fn["EVERY ARGUMENT EXCEPT tags IS FORCE-NEW: name, resource group, location, email, storage_sku, subnet_id, zone and all three marketplace identifiers."]
  pw["admin_password is REQUIRED, SENSITIVE - and force-new. So changing it DESTROYS the file system and everything on it. The field is for the INITIAL password only."]
  rot["Rotate inside Qumulo's own portal instead. Consequence worth a runbook entry: after that, the value in Terraform state is stale BY DESIGN, and reconciling the apparent drift would be destructive - the opposite of the usual advice."]
  state["sensitive redacts plan output and does NOT encrypt state, where the initial password sits in plaintext. The password is never emitted; only its presence is."]
  sku["storage_sku is a closed set of Cold_LRS, Hot_LRS and Hot_ZRS, and is REQUIRED - so no default is invented. Only Hot_ZRS survives losing an availability zone."]
  net["subnet_id is VNet INJECTION into a subnet delegated to Qumulo.Storage. The delegation lives on the subnet, is invisible from here, and its absence fails at apply."]
  mp["And the marketplace PLAN must be accepted for the subscription first. That failure reads like neither an Azure error nor a missing prerequisite."]
  this["azurerm_qumulo_file_system.this"]
  outputs["id, storage_sku, is_zone_redundant, subnet_id, email, has_admin_password, admin_password_rotation_requires_replacement, requires_marketplace_plan_acceptance, subnet_must_be_delegated_to_qumulo"]

  fn -->|"lifecycle"| pw
  pw -->|"so do not rotate here"| rot
  rot -->|"documented"| this
  pw -->|"and note"| state
  state -->|"presence only"| outputs
  sku -->|"resilience"| this
  net -->|"networking"| this
  mp -->|"prerequisite"| this
  this -->|"exports"| outputs

  classDef mine fill:#0078D4,stroke:#004578,color:#fff;
  classDef keystone fill:#004578,stroke:#001f3f,color:#fff;
  classDef sib fill:#eef2f7,stroke:#b8c4d0,color:#1b1b1b;
  class this mine;
  class sku mine;
  class pw,rot,state keystone;
  class fn,net,mp,outputs sib;

Resource inventory

Schema notes that bite — confirmed against the live provider schema and its documentation:

• 🔴 admin_password is force-new, so changing it destroys the file system and its data.
• 🔴 Every argument except tags is force-new.
• 🔴 The marketplace plan must be accepted for the subscription before creation.
• 🔴 subnet_id must be delegated to Qumulo.Storage — VNet injection, and the subnet becomes dedicated.
• ⚠️ zone is required by the provider even when storage_sku is Hot_ZRS — although the service's own documentation says a zone need not be specified for that class. A provider/service divergence, not an oddity.
• ⚠️ storage_sku is a closed set — Cold_LRS, Hot_LRS, Hot_ZRS — and required, so no empty call exists.
• ⚠️ The Resource ID is /providers/Qumulo.Storage/fileSystems/<name>.
• ⚠️ Provider timeout defaults are long: 90 min create, 1 h update, 30 min delete.
• 🔒 admin_password complexity IS enforced by the provider — at least 3 of 4 character classes, then a minimum of 8 characters. This module mirrors both, so both are caught offline.
• 🔴 name is capped at 15 characters (2 minimum, no leading or trailing hyphen). Not in the registry docs.
• 🔴 The resource exports no attributes but id. No mount IP addresses, no cluster login URL, no provisioning state, no marketplace subscription status — all of which the underlying API returns.
• 🔴 The subnet must have at least 256 addresses, and the provider does not check that — only the delegation, and only at apply.
• ⚠️ location is NOT validated against a region list. The region validator degrades to a bare non-empty check when its cached region list is unavailable, which it is in a credential-free run.
• ⚠️ zone is validated for non-emptiness only — any string passes plan.
• ⚠️ No capacity or performance argument exists. Capacity is elastic; the pre-provisioned performance level is set and changed out of band, in both directions, and Terraform never sees it.
• lifecycle is not valid inside a module block, so a caller cannot add prevent_destroy (example 11).

🔒 State access is credential access here, at least initially. admin_password sits in Terraform state in plaintext — sensitive = true redacts plan output and does not encrypt state — so anyone who can read the state can read the file system's initial administrator password (example 4).

💡 The marketplace subscription is subscription-scoped and usually a one-off, so it is not a permission this module's caller needs on every run (example 6).

🔴 The service documents a broader requirement than least privilege suggests, and it is worth reading before planning the first deployment in a subscription. Its prerequisites call for Owner or Contributor on the subscription, stating that only a principal with one of those roles can set up the partner service integration for that subscription. For custom roles it requires Qumulo.Storage/* and Microsoft.Network/virtualNetworks/subnets/join/action in both the subnet's resource group and the file system's, plus write access to both resource groups. So the first deployment in a subscription is a different permissions problem from every later one, and the resource-group-scoped row above is the steady state rather than the whole story.

⚠️ The caller also needs to READ the subnet, not only write where the file system is going: before creating anything the provider fetches the subnet to verify its delegation, and without read access the create fails there — before any Qumulo call, with an error about retrieving the subnet.

• 🔴 The subscription subscribed to the Qumulo SaaS offer, on a chosen plan (example 6). This is a marketplace subscription, not a marketplace image agreement, so no azurerm resource performs it.
• 🔴 A subnet delegated to Qumulo.Storage/fileSystems with the subnet join action, effectively dedicated to this file system (example 5).
• 🔴 That subnet must have at least 256 addresses — a /24 or larger. The provider verifies the delegation and never the size, so an undersized but correctly delegated subnet fails after the check passes.
• A region that offers availability zones and where the Qumulo offer is available. Neither is checked: the provider's region validator degrades to a non-empty check offline, and the service publishes no region list.
• ℹ️ Expect two resources you did not declare. The service creates a managed resource group for its internal networking, and a SaaS resource used for marketplace billing. Neither is managed here; both go when the file system does.
• 🔒 An encrypted, access-controlled state backend (example 4).
• 🔒 A monitored team alias for email, since it is shared with the vendor and force-new (example 7).

terraform-azurerm-qumulo-file-system/
├── providers.tf   # required_version + the pinned azurerm provider. No provider block.
├── variables.tf   # name, resource_group_name, location, admin_password, email, storage_sku,
#                  # subnet_id, zone, offer_id, plan_id, publisher_id, tags, timeouts
├── main.tf        # the keystone `this` + dynamic timeouts
├── outputs.tf     # id first, then placement and marketplace facts, then the password/prereq flags
├── README.md      # this document
├── SCOPE.md       # the cross-module contract
├── LICENSE        # MIT
└── .gitignore

provider "azurerm" {
  features {}
}

module "qumulo" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-qumulo-file-system.git?ref=v1.0.0"

  name                = "qfs-research-data"
  resource_group_name = module.rg.name
  location            = module.rg.location

  # 🔴 INITIAL password only. Changing it later destroys the file system (example 3).
  admin_password = var.qumulo_admin_password # 🔒 from Key Vault / a pipeline variable

  # 🔒 Shared with Qumulo — use a team alias (example 7).
  email = "storage-platform@contoso.example"

  # ✅ Hot_ZRS survives a zone loss; the LRS options do not (example 8).
  storage_sku = "Hot_ZRS"

  # 🔴 Must be DELEGATED to Qumulo.Storage (example 5).
  subnet_id = var.qumulo_subnet_id
  zone      = "1"

  tags = { owner = "storage-platform", data_class = "research" }
}

ℹ️ The caller configures the provider, its authentication, and the mandatory features {} block. This module declares none of them.

🔴 Read example 3 before this reaches production. The one thing you must never do to this resource is rotate its password in Terraform.

Consumes

Emits

🔒 The password is never emitted.

The examples below reference existing resources by ID or name rather than creating them; this module owns only its own resource. Those references are declared inputs:

variable "other_subnet_id" {
  description = "id of an existing other subnet that these examples reference but do not create."
  type        = string
}

variable "qumulo_subnet_id" {
  description = "id of an existing qumulo subnet that these examples reference but do not create."
  type        = string
}

Resource ID:  /subscriptions/.../providers/Qumulo.Storage/fileSystems/qfs-research-data
                                            ^^^^^^^^^^^^^^ not Microsoft.*

# ✅ In place:
tags = { owner = "storage-platform", data_class = "research", pw_rotated = "2026-09" }

# 🔴 Force-new — every single one:
name           = "qfs-research-data-v2"
location       = "westus2"
admin_password = var.new_password    # 🔴 DESTROYS THE FILE SYSTEM (example 3)
email          = "other@contoso.example"
storage_sku    = "Hot_LRS"
subnet_id      = var.other_subnet_id
zone           = "2"
offer_id       = "..."
plan_id        = "..."
publisher_id   = "..."

admin_password = var.qumulo_admin_password
# ⚠️ This is the INITIAL password. It is FORCE-NEW.
# 🔴 Editing it does not rotate anything — it replaces the file system and loses the data.

output "never_rotate_here" {
  value = module.qumulo.admin_password_rotation_requires_replacement # always true
}

admin_password = var.qumulo_admin_password # from Key Vault, or a pipeline variable — never committed

subnet_id = var.qumulo_subnet_id
# The subnet must carry a delegation to Qumulo.Storage — set on the SUBNET, not here.

Error: Invalid value for variable

  subnet_id must be a full subnet Resource ID ending in
  /virtualNetworks/<vnet>/subnets/<subnet>. Passing the virtual network's ID instead of
  a subnet's is the usual mistake. 🔴 The subnet must also be DELEGATED to
  Qumulo.Storage, which this module cannot verify — that failure appears at apply.

# Somewhere in the subscription, ONCE, and NOT in Terraform: subscribe to the Qumulo
# SaaS offer on a chosen plan, through Azure Marketplace or the portal. That creates a
# SaaS resource used for billing, alongside the file system you create below.
#
# 🔴 There is no azurerm resource for this, and reaching for the marketplace-agreement
#    resource will not do it: that one accepts the legal terms of a marketplace IMAGE
#    (Microsoft.MarketplaceOrdering agreements for publisher/offer/plan of an image) and
#    has no effect on a SaaS offer. Nothing below fails validation if you skip the
#    subscription — the apply fails.

# The identifiers this module will send, all provider defaults unless overridden:
# offer_id     — provider default: qumulo-saas-mpp
# plan_id      — provider default: azure-native-qumulo-v3
# publisher_id — provider default: qumulo1584033880660

email = "storage-platform@contoso.example" # ✅ a monitored team alias
email = "alice@contoso.example"            # ⚠️ an individual's mailbox, and force-new

storage_sku = "Hot_ZRS"  # ✅ zone-redundant
storage_sku = "Hot_LRS"  # ⚠️ locally redundant — does not survive a zone loss
storage_sku = "Cold_LRS" # ⚠️ cheaper tier, still locally redundant

output "resilient" {
  value = module.qumulo.is_zone_redundant # assert true for a system of record
}

timeouts = {
  create = "2h" # the provider already defaults to 90 minutes
}

output "qumulo_review" {
  value = {
    id        = module.qumulo.id
    sku       = module.qumulo.storage_sku
    resilient = module.qumulo.is_zone_redundant   # assert true for a system of record
    zone      = module.qumulo.zone
    subnet    = module.qumulo.subnet_id           # the subnet this consumed
    email     = module.qumulo.email               # 🔒 a team alias, not a person
    plan      = module.qumulo.plan_id             # which offer was deployed
    # 🔴 Prompts, not values:
    no_rotate = module.qumulo.admin_password_rotation_requires_replacement
    needs_mp  = module.qumulo.requires_marketplace_plan_acceptance
    needs_del = module.qumulo.subnet_must_be_delegated_to_qumulo
  }
}

terraform destroy on this module:
  removes the FILE SYSTEM  ->  and everything stored on it
  the subnet survives      ->  still delegated, still dedicated
  the marketplace agreement survives

terraform import 'module.qumulo.azurerm_qumulo_file_system.this' \
  "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-storage/providers/Qumulo.Storage/fileSystems/qfs-research-data"

provider "azurerm" {
  features {}
}

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

  name     = "rg-storage-platform"
  location = "eastus" # must offer availability zones
}

# ── A DEDICATED subnet, delegated to Qumulo.Storage (example 5) ──────────────
# ℹ️ module.vnet and module.qumulo_subnet are the caller's network resources. The
#    subnet's delegation is set on the SUBNET and cannot be set from this module.
#
#   delegation {
#     name = "qumulo"
#     service_delegation { name = "Qumulo.Storage/fileSystems" }
#   }

# ── The marketplace SaaS subscription, done once, OUTSIDE Terraform (example 6) ──
# ⚠️ Without it the apply below fails with a marketplace error that describes neither
#    Azure nor the missing prerequisite. No RBAC change fixes it, and no azurerm
#    resource performs it — subscribe to the offer in the marketplace or the portal.

# ── This module: the file system ────────────────────────────────────────────
module "qumulo" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-qumulo-file-system.git?ref=v1.0.0"

  name                = "qfs-research-data"
  resource_group_name = module.rg.name
  location            = module.rg.location

  # 🔴 INITIAL password only — NEVER edit this to rotate (example 3). Rotate in
  #    Qumulo's portal, then leave this value alone even though it goes stale.
  # 🔒 From Key Vault via a pipeline variable; it still lands in state (example 4).
  admin_password = var.qumulo_admin_password

  # 🔒 A monitored alias — shared with the vendor, and force-new (example 7).
  email = "storage-platform@contoso.example"

  # ✅ The only zone-redundant option (example 8). Force-new.
  storage_sku = "Hot_ZRS"

  # 🔴 Delegated and effectively dedicated (example 5).
  subnet_id = var.qumulo_subnet_id
  zone      = "1"

  # Marketplace identifiers omitted so the provider's defaults apply (example 6).

  # The only mutable field — so it carries what changes (example 2).
  tags = {
    owner      = "storage-platform"
    data_class = "research"
    pw_rotated = "2026-09" # 🔴 rotated in Qumulo; the state value is stale by design
  }

  # Leave the long defaults; creation genuinely takes ~90 minutes (example 9).
}

output "qumulo_posture" {
  value = {
    id        = module.qumulo.id
    resilient = module.qumulo.is_zone_redundant # assert true
    subnet    = module.qumulo.subnet_id
    plan      = module.qumulo.plan_id
    # 🔴 The instruction, not a status (example 3).
    no_rotate = module.qumulo.admin_password_rotation_requires_replacement
  }
}

variable "admin_password" {
  type      = string
  sensitive = true
  # 🔴 FORCE-NEW. This is the INITIAL password only — editing it replaces the file system and loses the data, so
  # rotation happens inside Qumulo's own portal and the value here goes stale by design. `sensitive` redacts plan
  # output and does NOT encrypt state. Never emitted. See examples 3 and 4.
  validation {
    condition     = length(var.admin_password) >= 8
    error_message = "admin_password must be at least 8 characters. The provider applies the same floor. And note that changing this field later REPLACES the file system, so choose it deliberately."
  }
  validation {
    # The provider's own complexity rule, mirrored. The fourth class is "neither a letter nor a
    # digit", so an underscore counts as a special character.
    condition = length([
      for class in ["[a-z]", "[A-Z]", "[0-9]", "[^0-9A-Za-z]"] :
      class if can(regex(class, var.admin_password))
    ]) >= 3
    error_message = "admin_password must contain at least 3 of these 4 character classes ... The provider tests complexity BEFORE length, so a password that is also under 8 characters will report only this failure until the complexity is fixed."
  }
}

variable "storage_sku" {
  type = string
  # Closed set, and REQUIRED — so no default is invented: choosing between a cold and a hot tier for a caller would
  # be guessing about both cost and performance. `is_zone_redundant` is emitted instead. See example 8.
  validation {
    condition     = contains(["Cold_LRS", "Hot_LRS", "Hot_ZRS"], var.storage_sku)
    error_message = "storage_sku must be one of: Cold_LRS, Hot_LRS, Hot_ZRS ... ✅ Prefer Hot_ZRS where the region supports it — the LRS options do not survive the loss of an availability zone."
  }
}

variable "subnet_id" {
  type = string
  # Catches the common mistake of passing the VIRTUAL NETWORK's id, and states the delegation requirement the check
  # cannot enforce — the delegation lives on the subnet resource. See example 5.
  validation {
    condition     = can(regex("(?i)^/subscriptions/[^/]+/resourceGroups/[^/]+/providers/Microsoft[.]Network/virtualNetworks/[^/]+/subnets/[^/]+$", var.subnet_id))
    error_message = "subnet_id must be a full subnet Resource ID ... 🔴 The subnet must also be DELEGATED to Qumulo.Storage, which this module cannot verify ..."
  }
}

No password output exists. Not sensitive-marked, not present.

🔴 Six of these outputs exist to name something this resource does NOT do. The mount addresses, the cluster login URL, the marketplace subscription status and the performance level are all real properties of a live file system that the provider does not surface — and every one of those gaps fails silently: the apply succeeds, the outputs look complete, and the absence is discovered only when something needs to connect, or when a bill arrives for a subscription that lapsed.

• admin_password being force-new is the module's reason to exist. Rotating a credential is the most routine security action there is, and here Terraform will destroy a file system to do it. So the fact appears in the overview, in the variable description, in main.tf, and as a constant output — because a comment in one place would not be enough for something this expensive and this counter-intuitive.

• The follow-on consequence is stated because it inverts normal practice. After an in-product rotation the value in state is deliberately stale, so the usual instinct — make Terraform authoritative again — is destructive. A module that flagged the force-new behaviour but not this would leave the second, subtler trap open.

• The password is sensitive on the way in, never on the way out, and the difference is explained. sensitive redacts plan output and does not encrypt state, so the module says that plainly rather than letting the marking imply protection it does not provide. Only has_admin_password is emitted, following this suite's rule against re-emitting a secret already present in this module's state.

• email is deliberately not treated as sensitive, and the reasoning is given. It is not a credential, it is shared with the vendor by design, and redacting it would hide the field most likely to be an individual's mailbox by mistake. This is the same call this library makes for publisher contact details elsewhere: where a value is published by design, hiding it protects nothing and costs a review.

• No storage_sku default is invented. The provider makes it required, so there is no empty call to harden, and guessing between a cold and a hot tier would be guessing about cost and performance. is_zone_redundant is emitted so the resilience consequence of whichever value was chosen is legible without recalling what the suffix means.

• The marketplace identifiers are left null rather than restated. Hard-coding the provider's own defaults would tie this module to a version of the offer and imply the values were reviewed choices. They are emitted so a procurement review still sees what was deployed.

• Two prerequisite facts are emitted as constants because both fail at apply in ways that do not describe themselves. A missing marketplace acceptance produces a marketplace error that looks like neither a permission problem nor a missing dependency; a missing subnet delegation is invisible from this resource entirely, since the delegation lives on the subnet.

• The long timeout defaults are documented as meaningful rather than defensive. A 90-minute create looks broken to somebody who has not seen it, and a pipeline with a short global timeout will kill the apply part-way — which is worse than waiting.

• The lock advice is qualified honestly. A CanNotDelete lock protects against deletion and not against the force-new replacement that is the likelier accident here, so the module says the real control is procedural.

• Before production: never edit admin_password. Rotate in Qumulo.
• Before the first apply: accept the marketplace plan, and delegate the subnet.
• Before choosing a SKU: only Hot_ZRS survives a zone loss, and it is force-new.
• Before trusting the backend: the initial password is in state, in plaintext.
• Before importing: a mismatched password means a replacement, and a replacement means data loss.

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

• Pin the source to a tag — ?ref=v1.0.0 — never a branch.
• Plan-only from here. A human applies from CI.
• ✅ tags is the only field that updates in place.
• 🔴 NEVER change admin_password. It replaces the file system and loses the data.
• 🔴 A plan that says "must be replaced" is a data migration. Read it in full.
• ⚠️ Creation takes ~90 minutes. Do not let a pipeline timeout kill it. The read that follows a create runs inside the create timeout, and the read after an update inside the update timeout, so those budgets cover a little more than their names suggest.
• 🔴 admin_password and email are never read back from the service. The provider repopulates both from your configuration on every refresh, so a change made to either outside Terraform produces no diff and no warning.
• 🔴 Which is exactly why an import proposes a replacement. An import cannot populate those two fields, and both are required and force-new, so they read as empty until the real values are written into the configuration. The plan is not reporting a mismatch it detected — it is reporting the absence of values it could never have fetched.
• 🔴 The resource exports only id. The underlying API returns the private IP addresses, the cluster login URL, a provisioning state and a marketplace subscription status; the provider surfaces none of them. So the mount targets and the administration URL — the two things you need in order to use the file system — come from the portal, and a composition cannot wire this module into anything automatically.
• ⚠️ The create is guarded against overwriting an existing file system, conditionally. The provider looks the name up first and refuses with a "requires import" error if something is there — unless the caller's provider block disables that check, in which case the create proceeds against the existing resource. The switch is the caller's, so the guard is a conditional rather than a property of this module.
• ⚠️ The ID is set during the create, not after it. So a create that fails partway through can leave the file system created and tracked in state while the apply reports an error; re-run rather than assuming nothing happened.
• ⚠️ storage_sku's three values are pinned in the provider, as a literal list carrying a note that it should become a generated enum once an upstream specification issue is resolved. A class the vendor adds later needs a provider upgrade, not a change here — and the set has already moved once between offer generations.
• ⚠️ Subnet ID casing is significant in one direction. The provider parses it case-sensitively when creating and case-insensitively when reading back, so a mis-cased ID is rejected up front rather than silently accepted.
• 💡 A CanNotDelete lock guards deletion, not replacement — and it is the only backstop available, because lifecycle is not valid inside a module block. Note the portal's delete flow asks for the resource name to be typed; terraform destroy asks for nothing.

terraform validate and terraform fmt -check are the offline gate. They confirm:

• name, resource_group_name and location are non-empty;
• admin_password is at least 8 characters and carries at least 3 of the 4 character classes — both mirroring the provider's own rule, so both are caught before any API call;
• email looks like an email address;
• storage_sku is exactly one of Cold_LRS, Hot_LRS, Hot_ZRS;
• subnet_id is a subnet Resource ID, not a virtual network's;
• zone is numeric;
• no password is emitted as an output at all;
• the module declares no provider block.

💡 Which command fires these checks is not interchangeable, and it is easy to state backwards. terraform validate run inside this module's own directory evaluates no variables and therefore fires none of them — it proves type-correctness and nothing more. Run against a calling configuration it fires them all. And terraform console -no-color, given an immediate end-of-input on stdin, fires them all as well, which makes it the practical offline harness: point it at a deliberately bad .tfvars and read the errors.

✅ Every condition above was driven both ways. A virtual-network ID fires the subnet check and a canonical subnet ID passes it; "Hot_GRS" and "hot_zrs" fire the SKU check; a lower-case-only password fires the complexity check while abcdefG1 passes; "1h30m", "1.5h", "500ms" and a bare "0" all pass the timeout check, which is the point of writing it to the full duration grammar rather than a narrower one.

⚠️ What the gate deliberately does not attempt, because each is a vendor or service fact that could change without the provider changing — and a validation {} failure blocks terraform destroy as well as apply, so refusing a legal value could strand a file system that already holds data:

• which regions the offer is available in, and which availability zones a region actually has;
• the delegated subnet's size — the service requires at least 256 addresses, and this module receives an ID rather than a prefix, so it cannot see the mask;
• whether a marketplace plan identifier is one your subscription holds;
• any password policy Qumulo applies on top of the provider's rule.

Each is reported through an output instead. That is the distinction this module draws throughout: enforce what the provider enforces, report what it does not.

What only plan and apply exercise:

• whether the resource group exists and the caller may create the file system in it.

What no Terraform command checks at any stage:

• 🔴 whether the marketplace plan is accepted for the subscription;
• 🔴 whether the subnet is delegated to Qumulo.Storage;
• 🔴 whether the password in state is still the live one — after an in-product rotation it is not, by design;
• 🔴 whether the chosen zone exists in the region;
• whether the file system's contents are backed up.

Outputs:

admin_password_rotation_requires_replacement = true
email                                        = "storage-platform@contoso.example"
has_admin_password                           = true
id                                           = "/subscriptions/00000000-.../providers/Qumulo.Storage/fileSystems/qfs-research-data"
is_zone_redundant                            = true
location                                     = "eastus"
name                                         = "qfs-research-data"
offer_id                                     = "qumulo-saas-mpp"
plan_id                                      = "azure-native-qumulo-v3"
publisher_id                                 = "qumulo1584033880660"
billed_from_creation_whether_used            = true
cluster_login_url_not_exported               = true
creates_managed_resource_group               = true
delegated_subnet_requires_256_addresses      = true
destroy_has_no_name_confirmation             = true
marketplace_subscription_status_not_visible  = true
mount_ip_addresses_not_exported              = true
performance_tier_not_managed_here            = true
provider_pinned_storage_sku_set              = [
  "Cold_LRS",
  "Hot_LRS",
  "Hot_ZRS",
]
requires_marketplace_plan_acceptance         = true
resource_group_name                          = "rg-storage-platform"
storage_sku                                  = "Hot_ZRS"
subnet_must_be_delegated_to_qumulo           = true
subnet_id                                    = "/subscriptions/00000000-.../virtualNetworks/vnet-storage/subnets/snet-qumulo"
tags_are_the_only_updatable_argument         = true
zone                                         = "1"

🔒 There is no password in this output, and that is deliberate (example 4). has_admin_password = true is what a consumer gets.

✅ is_zone_redundant = true with storage_sku = "Hot_ZRS" — the shape to expect for a system of record (example 8).

⚠️ Note id sits under Qumulo.Storage, a third-party provider namespace (example 1).

ℹ️ The three marketplace identifiers show the provider's defaults, because none was supplied — which is what makes emitting them worthwhile (example 6).

🔴 admin_password_rotation_requires_replacement = true is an instruction, not a status (example 3).

🔴 Notice what is NOT in this output: any way to reach the file system. No mount address, no cluster login URL. Both are real properties the underlying API returns, and the provider exports neither — which is what mount_ip_addresses_not_exported and cluster_login_url_not_exported are there to say out loud, because an output block that looks this complete is exactly where the gap would otherwise go unnoticed.

• azurerm_qumulo_file_system — provider documentation, including the SKU values of example 8.
• Azure Native Qumulo overview, including how to subscribe to the offer — the prerequisite of example 6. Note it is a SaaS subscription, not an image agreement, so azurerm_marketplace_agreement does not apply.
• Azure Native Qumulo prerequisites and creation — the subnet delegation, the 256-address minimum and the RBAC requirements.
• Managing an Azure Native Qumulo resource — where the mount IP addresses, the cluster login URL and the pre-provisioned performance level actually live.
• Azure Native Qumulo Scalable File System — what the service is, and its marketplace model (example 1).
• Subnet delegation — the VNet injection of example 5.
• Sibling modules: terraform-azurerm-resource-group, terraform-azurerm-virtual-network, terraform-azurerm-subnet, terraform-azurerm-key-vault (for holding the initial password of example 4).
• This module's SCOPE.md.

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