Key Vault Access & Secret-Rotation Review Prompt
Review a Key Vault's access model and secret lifecycle, then propose tighter access, rotation, and monitoring without breaking the apps that depend on it.
- Target user
- Cloud security engineers and platform teams managing Azure Key Vault
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure security engineer who treats Key Vault as a controlled boundary: RBAC over access policies, managed identities over connection strings, rotation over static secrets, and full audit logging. I will provide: - The vault's permission model — access policies or Azure RBAC, and the assignments — `az keyvault show` / role assignments — [PERMISSION_MODEL] - Network config — public access, firewall, private endpoint, trusted services — [NETWORK_CONFIG] - What's stored and who consumes it — secrets/keys/certs and the apps/identities reading them — [CONSUMERS] - Rotation state — which secrets rotate, how, and which are static/old — [ROTATION_STATE] - Any diagnostic/logging setup (AuditEvent to Log Analytics) — [LOGGING] Your job: 1. **Access model** — if still on legacy access policies, recommend moving to Azure RBAC (data-plane roles: Key Vault Secrets User, Crypto User, Certificates Officer) and explain the migration risk. Flag any principal with broad data-plane access it doesn't need. 2. **Identity over secrets** — for each consumer, recommend managed identity + RBAC instead of storing/reading a static credential. Identify secrets that exist only because something didn't use a managed identity. 3. **Network exposure** — if public access is open, recommend private endpoint or firewall with selected networks + trusted services; note what could break (CI runners, app outbound IPs). 4. **Rotation** — for each secret/key, recommend rotation (Key Vault rotation policy for keys, event-grid-driven rotation for secrets), and call out long-lived static secrets that should rotate. 5. **Monitoring** — ensure AuditEvent diagnostics flow to Log Analytics and propose a KQL alert for unusual secret access. 6. **Safe ordering** — sequence changes so consumers keep working: grant new access, switch the app, then revoke old. Output as: (a) findings table — area, current state, risk, recommendation; (b) the exact `az` commands in safe order; (c) a rotation plan per secret; (d) a sample KQL alert; (e) a rollback note. Use only the vault config I provided. Don't assume a private endpoint or RBAC mode that isn't shown — ask.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Key Vault reviews fail when they treat the vault as a checklist instead of a live dependency. The most consequential change — moving from legacy access policies to the Azure RBAC permission model — alters how every single access decision is made, and doing it carelessly breaks app startup across the board. This prompt makes that migration risk explicit and forces a grant-verify-revoke ordering, because the whole point of a review is to tighten security without causing an outage.
It also pushes the right architectural direction rather than cosmetic fixes. The biggest win is usually eliminating static secrets entirely by having consumers authenticate with managed identities and the appropriate data-plane RBAC role, so the prompt asks the model to identify which stored secrets exist only because something skipped managed identity. Layered on top are network exposure (private endpoint or firewall with trusted services), real rotation policies, and AuditEvent logging with a KQL alert for anomalous access — the controls that make a vault genuinely defensible.
The guardrails target the two ways these reviews cause incidents: flipping the permission model before equivalent RBAC is in place, and locking network access without first enumerating every consumer, including the CI/CD agents that everyone forgets. By sequencing changes and keeping a rollback, the prompt keeps the human in control of a boundary that, if mishandled, takes down everything depending on it.
Related prompts
-
Entra ID & Azure RBAC Least-Privilege Review Prompt
Audit a subscription's role assignments and Entra ID privileged access, then propose tighter, scoped, least-privilege replacements without breaking running workloads.
-
Azure Front Door WAF Policy Tuning Review Prompt
Review an Azure Front Door / Application Gateway WAF policy to reduce false positives without weakening protection by analyzing managed rule sets, custom rules, rate limits, and blocked-request logs, then recommending scoped exclusions.
-
Azure Container Registry Security and Geo-Replication Review Prompt
Review an Azure Container Registry (ACR) configuration for network isolation, RBAC/token scoping, image signing and vulnerability scanning, retention/purge policy, and geo-replication topology before it backs production AKS clusters.
-
AKS Workload Identity Federation Review Prompt
Review an AKS Workload Identity setup end to end — OIDC issuer, federated credential subject, service account annotations, and Entra ID role assignments — to fix AADSTS70021 / token exchange failures without falling back to secrets.
More Azure with AI prompts & error guides
Browse every Azure with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.