Restore azuredeploy.json for ADLS backup sample (fork-PR canary for #14769)

[alex-frankel]

Why

Two purposes:

1. Restore azuredeploy.json for backup-create-adls-storage-account-enable-protection. This sample was merged in September/November 2025 (PRs Add template for Azure Data Lake vaulted backup #14616, ADLS vaulted backup uses BlobBackupDatasourceParameters instead of AdlsBlobBackupDatasourceParameters #14630 #14631) before the new pipeline contract existed. It has no azuredeploy.json on master and no testResult in its metadata.json, so its "Deploy to Azure" button is broken today.

2. Verify the fork-PR end-to-end path through commit-generated-on-merge (the path discussed in commit-generated-on-merge skipped for fork PRs leaves master without azuredeploy.json #14769). This PR is from alex-frankel/azure-quickstart-templates (a fork), so on merge we'll learn empirically whether commit-generated-on-merge fires for fork PRs or skips them per the same-repo guard.

What's in this PR

• main.bicep: trailing newline only (no semantic change). Classifies the PR as deploy-affecting for selected-pipeline's preflight.
• metadata.json: adds testResult.deployments with correlationId and deploymentName from a verified deployment (templateHash 13943866408139100773, executionStatus Succeeded).

azuredeploy.json is intentionally not committed — letting CI compile and commit it via commit-generated-on-merge is the whole point of the canary.

Deployment details

• correlationId: 070c2fcc-1d41-4289-84f9-f8ae46cf981b
• deploymentName: adls-backup-canary-20260513-142256
• Region: southcentralus
• Bicep version: v0.42.1 (CI will re-derive and recompile per b7d5acb, so version match isn't required)
• ADX record visible in armprodeus (verified via direct Kusto probe)

Expected behavior

1. validate-samples-results passes (early gate: template + metadata both updated in diff).
2. Maintainer comments /validate.
3. selected-pipeline compiles main.bicep → azuredeploy.json (file is absent from PR diff because it's absent from master), reads generatorVersion from ADX, recompiles with matching Bicep, hashes, compares — should match.
4. On merge: this is the open question. Either:
   • commit-generated-on-merge fires for the fork PR (per @ouldsid's read) → master gets azuredeploy.json and commit-generated-on-merge skipped for fork PRs leaves master without azuredeploy.json #14769 closes as "won't fix / misread."
   • Or commit-generated-on-merge skips due to the same-repo gate (per the YAML I read) → master is left without azuredeploy.json and commit-generated-on-merge skipped for fork PRs leaves master without azuredeploy.json #14769 stays open with concrete evidence.

Either outcome is informative.

Related

• commit-generated-on-merge skipped for fork PRs leaves master without azuredeploy.json #14769 (fork-PR commit-back gate) — this PR is the empirical test.
• commit-generated-on-merge skips commit-back step because head-SHA lookup misses the issue_comment workflow run #14765 / commit-generated-on-merge writes azuredeploy.json to repo root, not the sample folder (path-stripping in upload-artifact@v4) #14754 / /validate fails with templateHash mismatch when contributor's local Bicep version differs from CI runner's bundled version #14753 (recent pipeline fixes that should all work in this PR).

cc @ouldsid

[alex-frankel]

/validate

[github-actions]

🤖 Quickstart Sample Summary

Sample Summary

• This sample deploys an Azure Data Lake Storage account and configures it for protection by enabling backup through an Azure Backup Vault.

• It creates a backup vault, backup policy, configures necessary permissions, and enables vaulted backup of specified storage containers.

• The deployment is parameterized to allow customization of names, retention policies, backup schedules, and storage redundancy.

• To deploy, use the main.bicep ARM Bicep template along with its parameters file.

• Deployment happens in the resource group with configurable location and resource names.

Resources Deployed

• Microsoft.DataProtection/backupVaults - Backup Vault resource serving as the container and management point for backup instances.
• Microsoft.DataProtection/backupVaults/backupInstances - Represents a backup instance associated with the backup vault to enable protection on the storage account.
• Microsoft.DataProtection/backupVaults/backupPolicies - Backup Policy governing backup retention durations and schedules.
• Microsoft.Storage/storageAccounts - An Azure Data Lake Storage account deployed with backup protection enabled.
• Microsoft.Storage/storageAccounts/blobServices/containers - Blob containers inside the storage account that are selected for backup protection.
• Microsoft.Authorization/roleAssignments - Role assignments granting the backup vault permission to access and backup the storage account containers.
• All above resources are defined inside main.bicep.

Security Findings

• High severity:

  • AZR-000398: Immutable vault setting for Backup Vaults is not enabled by default. This setting protects backup data from being deleted or tampered with by locking backup vault configuration.
    • File: main.bicep, starting line 67
  • AZR-000202: Storage account firewall default action allows connections from any network, potentially exposing it publicly. Configuring network rules is recommended for restricting access.
    • File: main.bicep, starting line 249
  • AZR-000200: Older TLS versions are accepted by default on the Storage account for blob storage. TLS 1.2 enforcement is recommended for industry-standard security compliance.
    • File: main.bicep, starting line 249
  • AZR-000198: Blob storage containers might allow public anonymous access if allowBlobPublicAccess is not set to false. Disabling this setting enhances security.
    • File: main.bicep, starting line 249

• No hardcoded secrets were detected in the templates.

• Public access and network access control on the Storage Account and backup vault are notable security-sensitive patterns.

Key Parameters

• vaultName - Name of the Backup Vault.
• vaultStorageRedundancy - Storage redundancy option for the vault (LocallyRedundant or GeoRedundant).
• backupPolicyName - Name of the backup policy to be created.
• storageAccountName - Name of the Azure Data Lake Storage account.
• containerList - Array of container names inside the storage account to be protected.

Notes for Reviewers

• Reviewers should verify the lack of immutable vault setting activation and consider potential impact.
• It is recommended to configure Storage Account network rules for restricted access rather than open to all.
• TLS minimum version enforcement and disabling public blob access are recommended enhancements for security compliance.
• Documentation mentions "Manual" validation type in metadata, ensure deployment steps are clear for users.

Files Touched

• main.bicep - Defines all deployment resources and parameters.
• metadata.json - Sample metadata including update date and validation info.
• README.md (key file but not read here)
• azuredeploy.parameters.json (key file but not read here)

---

Generated by the quickstart summarizer agent (v2 — agentic + MSDO security) · triggered by /validate