Pre-Deployment Configuration Audit Prompt Template

This prompt is designed for SRE and platform teams who need an automated, pre-deployment gate that compares a proposed deployment configuration against a required specification. Its primary job is to halt a CI/CD workflow and produce a structured gap report when required settings, environment variables, security policies, or resource definitions are absent or invalid. The ideal user is an engineer embedding this check into Terraform apply stages, Kubernetes admission controllers, or any deployment orchestration tool where a human or automated system must verify completeness before execution. The prompt acts as a policy-as-code enforcer, but expressed in natural language, allowing teams to define complex, context-aware rules without writing custom validation scripts.

Use this prompt inside a strict, blocking context. It should be wired into a pipeline stage that prevents progression to the next step—such as a terraform plan review, a kubectl apply dry-run, or a GitOps diff—if the audit fails. The required inputs are a complete proposed configuration and a clear specification of what 'complete' means for your environment. The output is a machine-readable gap report, typically JSON, that your pipeline can parse to decide whether to block, warn, or request human approval. Do not use this prompt for runtime configuration drift detection or post-deployment auditing; it is a pre-deployment blocking gate only. For drift detection, use a separate, continuous reconciliation workflow.

Before implementing, define the exact failure modes you want to catch. Common examples include missing security context constraints, absent resource limits, undefined liveness probes, or missing mandatory tags. The prompt's effectiveness depends entirely on the clarity of the specification you provide. A vague specification will lead to false negatives (missed gaps) or false positives (blocking compliant configs). After deploying this prompt, monitor its decisions closely for the first several release cycles. Track the ratio of blocks to successful deployments and review every block to ensure the gate is catching real issues, not creating unnecessary friction. If the block rate is unexpectedly high, refine the specification rather than lowering the gate.

This prompt template is designed to be pasted directly into your orchestration layer, CI/CD pipeline, or agent workflow. It instructs the model to act as a strict configuration auditor, comparing a proposed deployment configuration against a mandatory specification. The model's primary job is to identify missing settings, variables, or policies and produce a structured, machine-readable gap report. It must not proceed with any deployment actions or generate approval language if gaps are found.

textCopy
You are a pre-deployment configuration auditor. Your only task is to compare the provided [DEPLOYMENT_CONFIG] against the [REQUIRED_SPECIFICATION]. Do not execute, approve, or assume defaults for any missing items.

# Steps
1. Parse the [REQUIRED_SPECIFICATION] to create a checklist of mandatory fields, variables, policies, and settings.
2. Inspect the [DEPLOYMENT_CONFIG] for the presence and validity of each item on the checklist.
3. For each missing or invalid item, record the item's name, its expected location or format from the specification, and a severity level of 'BLOCKER'.
4. If no items are missing or invalid, output a clear 'PASS' status.

# Constraints
- [CONSTRAINTS]: Do not hallucinate missing items. Only flag items explicitly required by the specification that are absent or invalid in the config.
- If the specification itself is ambiguous, flag it as a 'BLOCKER' with the reason 'SPEC_AMBIGUITY'.
- Do not output any text other than the final JSON report.

# Output Schema
You must output a single JSON object conforming to this exact structure:
{
  "audit_result": "PASS" | "FAIL",
  "gap_report": [
    {
      "item_name": "string",
      "expected_criteria": "string",
      "severity": "BLOCKER",
      "reason": "MISSING" | "INVALID" | "SPEC_AMBIGUITY"
    }
  ]
}

# Input Data
[DEPLOYMENT_CONFIG]:
[DEPLOYMENT_CONFIG]

[REQUIRED_SPECIFICATION]:
[REQUIRED_SPECIFICATION]

To adapt this template, replace the [DEPLOYMENT_CONFIG] and [REQUIRED_SPECIFICATION] placeholders with your actual data. The [CONSTRAINTS] placeholder can be used to add domain-specific rules, such as requiring exact version strings or forbidding default passwords. For high-risk environments, ensure the output of this prompt is parsed by a validation function in your application code. If the audit_result is FAIL, your harness must block the deployment pipeline and surface the gap_report to the responsible engineer. Never allow an automated system to proceed based on a PASS result without additional, independent verification steps.

This prompt is designed to act as a pre-execution gate inside a deployment pipeline, not as a standalone chat interaction. The most effective integration point is within a CI/CD system (GitHub Actions, GitLab CI, Jenkins), a Kubernetes admission webhook, or a deployment orchestrator (Spinnaker, Argo Workflows) immediately after a deployment manifest is assembled but before it is applied to a target environment. The prompt expects two structured inputs: a required specification defining mandatory fields, policies, and constraints, and a proposed configuration representing the actual deployment artifact. The output is a structured gap report that your harness must parse to decide whether to block, warn, or allow the deployment to proceed.

To build a reliable harness, wrap the LLM call in a validation and retry layer. After receiving the model's response, validate the JSON structure against the expected schema (a status field of PASS or BLOCK, a gap_report array with field, required_value, actual_value, and severity keys). If parsing fails or required keys are missing, retry once with a repair prompt that includes the raw output and the schema. Log every audit result—including the full prompt, response, and parsed decision—as an immutable deployment record. For high-risk environments (production, compliance-bound systems), route all BLOCK decisions and any PASS decisions where severity is WARNING to a human approval queue (ServiceNow, Jira, PagerDuty) before the deployment proceeds. Never allow the model's text output alone to authorize a deployment; the harness must enforce the block programmatically.

Choose a model with strong JSON-following behavior and low latency for this gate. GPT-4o or Claude 3.5 Sonnet are appropriate defaults; avoid smaller models that may hallucinate field names or misclassify severity. Set temperature=0 to maximize determinism. If your specification is large (hundreds of fields), split the audit into logical groups (networking, secrets, resource limits) and run parallel checks, then aggregate the gap reports. The most common production failure mode is a false-positive block caused by an overly strict or outdated specification. Mitigate this by versioning your specification alongside your deployment templates and running the audit prompt against known-good configurations in a pre-merge CI check. If the prompt blocks a deployment that operators override, capture the override reason and feed it back into specification refinement.