Enable purge protection on key-vault-certificate-create vault

[msmbaldwin]

Summary

Adds enablePurgeProtection: true to the vault in key-vault-certificate-create/main.bicep (and the regenerated azuredeploy.json).

Why

Without purge protection, a soft-deleted certificate (and its underlying key) can be permanently destroyed during the soft-delete retention window. For a quickstart that demonstrates creating a certificate, the recommended baseline is soft delete + purge protection both on. softDeleteRetentionInDays: 90 was already present.

Validation

Deployed the updated main.bicep to my subscription (the deployment-scripts module under the hood means the deployment takes ~5 minutes):

• correlationId: 05435e1e-63f6-4269-98b1-42955d84a56a
• deploymentName: kvcrt-deploy-29b9ab41
• provisioningState: Succeeded
• region: eastus

metadata.json updated with validationType: Manual and the testResult.deployments block.

[msmbaldwin]

@alex-frankel — first, thanks for your patience and for the clear feedback on the previous round of PRs (#14739, #14740, #14741, #14742). Your write-up of the new testResult requirement was exactly what I needed.

This PR follows the contribution-guide workflow:

• Updated main.bicep was deployed locally against my subscription before the PR was opened.
• metadata.json carries validationType: "Manual" and a testResult.deployments block with the real correlationId and deploymentName from that deployment.
• I also rebased the branch onto current master so the diff is the minimal one-line bicep change + the corresponding regenerated azuredeploy.json + the metadata.json update (no longer showing azuredeploy.json as a new file — that was a fork-staleness artifact in the original push).

Ready for review / /verify whenever you have a moment. Thanks again!

[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 RBAC authorization enabled.

• It also creates a self-signed certificate within the Key Vault using a deployment script.

• The Key Vault is configured with soft-delete and purge protection enabled for enhanced security.

• To deploy, provide parameters including vault name, certificate name, location, SKU, certificate common name, and certificate validity period.

• Deployment can be done through the Azure portal using the provided template or directly via Bicep.

Resources Deployed

• Microsoft.KeyVault/vaults (defined in main.bicep): The Azure Key Vault resource with properties such as RBAC authorization, soft-delete retention for 90 days, and purge protection enabled. The vault uses a SKU of 'standard' or 'premium' and is configured to allow Azure services to bypass network rules by default.

Security Findings

• High Severity Findings:

  1. AZR-000355 (Template Analyzer): The Key Vault's firewall default action is set to Allow, which accepts connections from any network. It is recommended to change the default action to Deny and explicitly configure firewall rules. (File: main.bicep, Line 42)
  2. CKV_AZURE_189 (Checkov): Azure Key Vault does not disable public network access. (File: main.bicep, Line 25)
  3. CKV_AZURE_109 (Checkov): The Key Vault does not allow firewall rules settings properly. (File: main.bicep, Line 25)

• No evidence of hardcoded secrets or public endpoints beyond the network access configuration described above.

Key Parameters

• vaultName: The name assigned to the Azure Key Vault.
• certificateName: The name of the certificate to create in the Key Vault.
• location: The Azure region where resources will be deployed (default is resource group's location).
• skuName: SKU of the Key Vault (standard or premium).
• validityInMonths: Validity period of the self-signed certificate, defaulting to 12 months.

Notes for Reviewers

• The deployment enables purge protection, protecting the vault against accidental or malicious deletion.
• The sample uses RBAC for access control instead of access policies.
• The network access configuration allows all networks by default, which is flagged by security scanners as a high-risk configuration that should be reviewed and potentially hardened.
• The self-signed certificate is created via a deployment script wrapped in a public Bicep module rather than directly through the ARM template, as certificate creation is a data-plane operation.

Files Touched

• main.bicep (updated to enable purge protection on the Key Vault)
• azuredeploy.json (removed/deleted, replaced by Bicep)
• metadata.json (updated metadata)

---

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

[alex-frankel]

@msmbaldwin — quick favor before we merge this one. Two things just happened that make this PR an ideal verification target:

1. @ouldsid fixed commit-generated-on-merge writes azuredeploy.json to repo root, not the sample folder (path-stripping in upload-artifact@v4) #14754 in ca5c529 yesterday — the commit-generated-on-merge path-stripping bug that was corrupting master with phantom root-level azuredeploy.json files. The fix uses a staging-directory pattern; we want to confirm it works end-to-end on a real PR.
2. The auto-gen pipeline only fires when azuredeploy.json is missing from the PR (the compile step short-circuits if the file's already there).

Could you push one more commit to this branch that just deletes azuredeploy.json (keep main.bicep and the stamped metadata.json exactly as they are)? Then I'll /validate again, watch the artifact upload, and merge. If the new flow works, commit-generated-on-merge will regenerate azuredeploy.json from your bicep and commit it to the correct sample folder on master — confirming Ould's fix on a real workload.

If you'd rather not do that, just say so and I'll merge as-is — your call. Either way thanks for the four PRs.

Merging #14759, #14760, #14761 now and holding this one pending your reply.

[msmbaldwin]

@alex-frankel — happy to help. Pushed a commit that deletes azuredeploy.json from the sample folder; main.bicep and the stamped metadata.json (with the original deployment's correlationId/deploymentName) are preserved as-is. Re-run /validate whenever you're ready, and let me know if the regen lands the file in the right folder this time. Thanks for merging the other three!

[alex-frankel]

/validate

[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

[alex-frankel]

@msmbaldwin — quick follow-up to close the loop on this one. The verification you helped with surfaced two real bugs in the auto-gen pipeline (great outcome from the experiment, though not the one I'd planned):

What happened after merge:

1. The commit-generated-on-merge job didn't fire here because this PR was on your fork (msmbaldwin/azure-quickstart-templates) — that job is gated on head.repo == base.repo. My oversight in suggesting this PR as the canary; should've been an upstream-branch PR from the start. So azuredeploy.json ended up missing from the sample on master.

2. I opened Restore azuredeploy.json for key-vault-certificate-create via upstream-branch canary #14764 (upstream-branch canary) to both restore the file AND complete the auto-gen verification. /validate passed cleanly, the artifact zip had the correct path structure (confirming Ould's commit-generated-on-merge writes azuredeploy.json to repo root, not the sample folder (path-stripping in upload-artifact@v4) #14754 fix works) — but on merge, commit-generated-on-merge ran to "success" without actually committing anything. Filed as commit-generated-on-merge skips commit-back step because head-SHA lookup misses the issue_comment workflow run #14765 — separate bug in the Resolve artifact source run step that looks up the workflow run by PR head SHA, but issue_comment-triggered runs are registered against master HEAD, not PR head.

3. I manually pushed azuredeploy.json to master directly (commit 95b316ae) using the file from the verified artifact, so the sample is now back to a working state. The contents are exactly what your stamped deployment would have produced — same templateHash 11850030662128066774.

Net for you: nothing to fix on your end. Your three other PRs (#14759/#14760/#14761) are merged and good. Sorry for the experimental detour — it surfaced a real second-order bug in the pipeline, which is genuinely useful, but cost us a regression-and-manual-restore cycle that I wouldn't have asked for if I'd thought about the fork-branch gate first.

cc @ouldsid