Restore azuredeploy.json for key-vault-certificate-create via upstream-branch canary

[alex-frankel]

Why

This PR has two purposes:

1. Restore azuredeploy.json for key-vault-certificate-create. It was inadvertently deleted in PR Enable purge protection on key-vault-certificate-create vault #14762 — a verification experiment I'd asked @msmbaldwin to run for the new auto-gen pipeline. The merge of Enable purge protection on key-vault-certificate-create vault #14762 didn't trigger commit-generated-on-merge because his branch was on a fork (msmbaldwin/azure-quickstart-templates), and that job is gated on head.repo.full_name == github.repository. My oversight, not his.
2. Be the upstream-branch canary for the auto-gen commit-generated-on-merge path now that @ouldsid's commit-generated-on-merge writes azuredeploy.json to repo root, not the sample folder (path-stripping in upload-artifact@v4) #14754 fix (ca5c529) has landed. This PR is from a branch in Azure/azure-quickstart-templates itself, so the on-merge auto-commit job will fire.

What's in this PR

• main.bicep: trailing newline only (no semantic change). Byte-identical compiled JSON verified locally against bicep v0.42.1 — both produce templateHash 11850030662128066774, matching the ADX-logged hash from @msmbaldwin's deployment (correlationId 05435e1e-63f6-4269-98b1-42955d84a56a, kvcrt-deploy-29b9ab41, eastus2, succeeded). The trailing newline exists to make selected-pipeline's preflight classify the PR as deploy-affecting.
• metadata.json was already updated on master with the testResult stamp — no change needed in this PR.

Expected behavior

1. validate-samples.yml passes structural checks.
2. Maintainer comments /validate.
3. selected-pipeline compiles main.bicep → azuredeploy.json (file is absent from PR diff because it's absent from master), computes templateHash 11850030662128066774, queries ADX, asserts match.
4. The new staging-directory artifact upload (Ould's commit-generated-on-merge writes azuredeploy.json to repo root, not the sample folder (path-stripping in upload-artifact@v4) #14754 fix) lands azuredeploy.json under the correct repo-relative path in the artifact zip — verified against PR Enable purge protection on key-vault-certificate-create vault #14762's run 25820961383 artifact, which had the right structure.
5. On merge, commit-generated-on-merge downloads the artifact and pushes azuredeploy.json to quickstarts/microsoft.keyvault/key-vault-certificate-create/ — completing the end-to-end verification of commit-generated-on-merge writes azuredeploy.json to repo root, not the sample folder (path-stripping in upload-artifact@v4) #14754 that PR Enable purge protection on key-vault-certificate-create vault #14762 couldn't (fork branch).

Related

• Closes the regression introduced by Enable purge protection on key-vault-certificate-create vault #14762.
• Verifies the fix from ca5c529 end-to-end (the artifact-zip structure check was done out-of-band; this PR runs the full commit-on-merge step too).

cc @ouldsid @msmbaldwin

[azure-quickstarts]

@msmbaldwin - check this PR for updates that may be needed to documentation that references this sample. [This is an automated message. You are receiving it because you are listed as the docOwner in metadata.json.]

[azure-quickstarts]

@msmbaldwin - check this PR for updates that may be needed to documentation that references this sample. [This is an automated message. You are receiving it because you are listed as the docOwner in metadata.json.]

[alex-frankel]

/validate

[github-actions]

🤖 Quickstart Sample Summary

Sample Summary

• This sample deploys an Azure Key Vault with configurable SKU, network access policies, and RBAC authorization enabled.
• It creates a self-signed certificate inside the Key Vault using an external deployment script module that runs az keyvault certificate create.
• The certificate's common name, validity period, and vault name are parameters, allowing customization.

Resources Deployed

• Microsoft.KeyVault/vaults (defined in main.bicep): Deploys an Azure Key Vault with soft delete, purge protection, RBAC authorization, and network ACLs configured. The default network access is set to allow Azure services.
• Deployment script module br/public:deployment-scripts/create-kv-certificate:3.4.2 (referenced in main.bicep): Used for creating the Key Vault certificate as an ARM template cannot directly create certificates.

Security Findings

• High severity:
  • AZR-000355: Key Vault default network ACL allows connections from any network; recommend changing default action from Allow to Deny and configuring firewall rules. (line 42 in main.bicep)
  • CKV_AZURE_189: Azure Key Vault does not disable public network access. (line 25 in main.bicep)
  • CKV_AZURE_109: Key Vault does not enforce firewall rules settings. (line 25 in main.bicep)

No other security-sensitive patterns, such as hardcoded secrets, were detected in the template.

Key Parameters

• vaultName: Specifies the name of the Key Vault.
• certificateName: The name of the certificate to create in the Key Vault.
• location: Resource location; defaults to the resource group's location.
• skuName: SKU of the Key Vault (standard or premium).
• validityInMonths: Validity duration of the certificate (1-1200 months).

Notes for Reviewers

• The Key Vault network ACL settings currently allow all networks by default, which triggers security scanner alerts recommending locking down network access.
• The template uses a user-assigned managed identity and a public deployment script module to create Key Vault certificates since ARM does not support certificate creation natively.
• No explicit warnings about hardcoded secrets or sensitive outputs other than certificate thumbprint and secret identifiers.
• No README.md content was provided but is generally included in the sample.

Files Touched

• main.bicep
• metadata.json

---

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