Best Practice for ADLS Gen2 (HNS) Soft Delete in Terraform: Explicit Configuration vs. Relying on Platform Defaults (blob_properties)

Question

Best Practice for ADLS Gen2 (HNS) Soft Delete in Terraform: Explicit Configuration vs. Relying on Platform Defaults (blob_properties)

S, Maheshwari 0

Hello,

We are currently deploying an Azure Storage Account with Hierarchical Namespace (HNS) enabled (ADLS Gen2) for a production environment using Terraform (azurerm provider).

We are facing a design debate regarding data protection (Soft Delete) and would appreciate the Microsoft community's guidance on best practices.

The Scenario:

Our upstream Terraform module statically defines the restore_policy block inside blob_properties like this:

# Upstream Module Code
resource "azurerm_storage_account" "sa" {
  # ... other configurations ...
  blob_properties {
    delete_retention_policy {
      days = var.delete_retention_policy_days
    }
    restore_policy {
      days = var.restore_policy_days
    }
    versioning_enabled = var.versioning_enabled
  }
}

The Problem:

Since HNS (ADLS Gen2) is enabled, we cannot use Point-in-Time Restore (restore_policy) or Versioning. However, because the restore_policy block is statically defined in the module, running terraform apply fails with the following provider validation error: Error: versioning_enabled must be true when restore_policy is set

Proposed Workaround A (Developer's Approach):

To bypass this error without updating the upstream module code, a team member has proposed setting blob_properties = [] (passing an empty block) in our root configuration inputs.

Their arguments are:

Leaving blob_properties empty allows the storage account to deploy using Azure's native platform defaults.
Since Azure enables Blob Soft Delete by default on new storage accounts, we do not need to explicitly define or manage the 7-day soft delete policy in our Terraform code.

Proposed Solution B (Our Approach - Module Refactor):

We proposed refactoring the upstream module to make the restore_policy block dynamic. This allows us to completely omit the block when restore_policy_days is set to null, while still explicitly managing our 7-day soft delete policy:

# Proposed Module Refactor
resource "azurerm_storage_account" "sa" {
  # ... other configurations ...
  blob_properties {
    delete_retention_policy {
      days = var.delete_retention_policy_days
    }

With this refactor, we can set restore_policy_days = null in our root inputs. The block is completely dropped, the provider validation error is bypassed, and our 7-day soft delete remains explicitly managed in code.

Our Concerns:
We believe that omitting blob_properties and relying on platform defaults is a risk for a production environment.
1. Is it considered an Azure Best Practice to rely on "platform defaults" for critical data protection features like Soft Delete in production, or should they be explicitly declared and managed via Infrastructure as Code (IaC)?
2. What are the risks of leaving blob_properties unmanaged in Terraform?
3. Does ADLS Gen2 (HNS) fully support Blob and Container Soft Delete, and is it recommended to keep them explicitly enabled for production data lakes?

RNareddy 2,515 Reputation points Microsoft External Staff Moderator

2026-08-15T09:25:41.1933333+00:00
Hello @S, Maheshwari

This is a common Terraform/IaC nuance to get right for production data protection.

Does ADLS Gen2 (HNS) support soft delete?

Yes. Azure Data Lake Storage Gen2 (HNS) supports soft delete for blobs and containers. Microsoft recommends enabling soft delete so deleted data can be recovered within the configured retention period.

Point-in-Time Restore (PITR) is not supported for HNS-enabled ADLS Gen2 accounts, so soft delete is the in-account recovery mechanism to rely on for delete scenarios.

Soft delete vs. versioning when HNS is enabled

Microsoft guidance states that soft delete protects against deletes and, depending on the account type, certain overwrite scenarios. The retention period can be configured for up to 365 days.

Blob versioning, however, is not available for HNS-enabled accounts.

Because of this, the Terraform validation error saying “versioning_enabled must be true when restore_policy is set” is consistent with the fact that restore-policy/PITR and versioning semantics do not apply as expected to HNS accounts.

For HNS-enabled accounts, the preferred approach is generally to use soft delete rather than restore_policy/PITR.

Should we rely on platform defaults or explicitly configure soft delete?

The recommended approach is to explicitly enable and configure soft delete as part of the storage account's data protection strategy.

Soft delete is not something I would recommend leaving to implicit platform defaults for a production data lake. Explicitly managing it through Terraform makes the intended retention policy clear and consistent across environments.

Risks of leaving blob_properties unmanaged in Terraform

If blob_properties is omitted, Terraform is no longer explicitly controlling the relevant data protection settings.

Since soft delete needs to be enabled at the storage account level and the retention period is configurable, the practical risk is that an account could end up without the protection you expect or with a retention period that does not match your requirements.

This can become particularly important across dev, test, and production environments, different account creation paths, or changes in Terraform provider/module versions.

Recommendation for the two workaround options

Option A: Set blob_properties = [] and rely on platform defaults

This is less desirable for production because it gives up explicit configuration of the data protection policy.

I would only consider this approach if you can guarantee through another mechanism that the required soft-delete settings, including retention days, are always applied and enforced.

Option B: Remove restore_policy and explicitly configure soft-delete retention

This is the better-aligned approach for HNS.

PITR/restore policy is not the appropriate recovery mechanism for ADLS Gen2 HNS accounts, while soft delete for blobs and containers is supported.

Making restore_policy conditional, or removing it when it is not applicable, also avoids the provider validation issue while allowing Terraform to continue explicitly managing the required delete-retention settings.

Overall, Option B is the better approach: explicitly manage soft-delete retention and avoid configuring restore_policy for HNS accounts where it is not supported or appropriate.

1 answer

Your answer

Answer 1

For an HNS-enabled ADLS Gen2 storage account, the safer approach is to explicitly manage supported data-protection settings and omit unsupported ones.

restore_policy should be omitted for this scenario. Point-in-time restore is not supported for HNS/ADLS Gen2, and blob versioning is also not supported for accounts that have a hierarchical namespace. That aligns with the provider validation failure requiring versioning_enabled = true when restore_policy is set.

Explicitly managing soft delete is the better production practice here:

Blob soft delete and container soft delete are both supported for HNS-enabled accounts.
Blob soft delete is disabled by default and must be enabled at the storage account level.
Microsoft recommends enabling blob soft delete for all storage accounts, with a minimum retention interval of seven days.
Microsoft also recommends enabling container soft delete, with a minimum retention interval of seven days.

For ADLS Gen2 specifically:

Blob soft delete on HNS-enabled accounts protects delete operations.
Blob versioning is not available for HNS-enabled accounts.
Container soft delete is available for Data Lake Storage.
Container soft delete restores deleted containers and their contents, but it does not restore an individual blob deleted from a container.

That means the production-oriented design is:

keep blob_properties.delete_retention_policy explicitly configured
omit restore_policy
do not enable versioning on HNS accounts
also explicitly enable container soft delete if container recovery is required

Risks of leaving blob_properties unmanaged and relying on defaults:

Soft delete may not be enabled, because blob soft delete is disabled by default.
The retention period is not explicitly controlled in code, which weakens repeatability and auditability.
Drift becomes harder to detect because the intended protection posture is not declared in Terraform.
Production recovery expectations can be missed if a deployment succeeds without the required retention settings.

On the specific debate:

Workaround A is not a best-practice choice for production data protection because it leaves a critical recovery setting unmanaged and depends on platform behavior instead of declared configuration.
Solution B is the correct pattern: refactor the module so unsupported features such as restore_policy are omitted for HNS accounts, while supported protections such as soft delete remain explicitly configured.

A practical target configuration for HNS/ADLS Gen2 production is:

Blob soft delete enabled with at least 7 days retention.
Container soft delete enabled with at least 7 days retention.
No blob versioning.
No point-in-time restore.
If stronger protection against deletion or overwrite is required, consider immutability policies or account-level protections such as ARM locks, depending on the scenario.

References:

Best Practice for ADLS Gen2 (HNS) Soft Delete in Terraform: Explicit Configuration vs. Relying on Platform Defaults (blob_properties)

The Scenario:

The Problem:

Proposed Workaround A (Developer's Approach):

Proposed Solution B (Our Approach - Module Refactor):

Our Concerns:

1 answer

Your answer