Configuration Drift Detection Prompt Template

This prompt is for operations teams, platform engineers, and SREs who need to detect and analyze configuration drift across environments. It compares an intended configuration state—sourced from a Git repository, a configuration management database, or an Infrastructure as Code (IaC) definition—against an actual configuration state pulled from a running environment via an API, CLI tool, or monitoring agent. The primary job-to-be-done is turning raw, unstructured diffs into a structured drift analysis that identifies discrepancies, assesses their operational risk, and recommends reconciliation actions. Use this prompt when manual diffing is too slow, when you need a consistent format for drift tickets, or when you are building an automated configuration compliance workflow that feeds into your incident management or change control systems.

This prompt is most effective when you already have a reliable mechanism for extracting both the intended and actual configuration states. The intended state should come from a single source of truth, such as a Terraform state file, a Kubernetes manifest in a Git repository, or a CMDB record. The actual state should be pulled from the live system using a command like kubectl get deployment -o yaml, an AWS Config snapshot, or an agent query. The prompt acts as an analysis layer that sits between this raw configuration data and the human or system that must act on it. It is not a replacement for a configuration management tool like Ansible, Puppet, or Crossplane; it will not remediate drift automatically. Instead, it produces a risk-scored, human-readable report that can be used to open a ticket, trigger a notification, or inform a manual reconciliation decision.

Do not use this prompt when the configuration states are too large for a single context window without chunking, when the drift is expected and intentional (such as during a canary deployment), or when you need real-time enforcement rather than post-hoc analysis. For high-risk environments—such as healthcare, finance, or critical infrastructure—always require human review of the drift analysis before any automated reconciliation action is taken. The prompt's risk assessment is a heuristic, not a guarantee. If you are building a fully automated closed-loop remediation system, this prompt should be one component in a pipeline that includes policy-as-code validation, approval gates, and rollback safeguards.

This prompt template is designed to compare an intended configuration specification against an actual observed state from a target environment. It produces a structured drift analysis that identifies discrepancies, assesses their severity, and recommends remediation actions. The template uses square-bracket placeholders that you must replace with data from your configuration management system, infrastructure-as-code repository, or monitoring tools before sending to the model. Each placeholder represents a critical input that shapes the accuracy and actionability of the drift report.

textCopy
You are a configuration drift detection analyst. Your task is to compare the intended configuration state against the actual observed state for a specific environment and produce a structured drift analysis.

## INTENDED CONFIGURATION
[INTENDED_CONFIG]

## ACTUAL OBSERVED STATE
[ACTUAL_STATE]

## ENVIRONMENT CONTEXT
- Environment Name: [ENVIRONMENT_NAME]
- Configuration Source: [CONFIG_SOURCE]
- Observation Timestamp: [OBSERVATION_TIMESTAMP]
- Previous Drift Status: [PREVIOUS_DRIFT_STATUS]

## ANALYSIS CONSTRAINTS
- Severity Classification Rules: [SEVERITY_RULES]
- Known Acceptable Drift Patterns: [ACCEPTABLE_DRIFT_PATTERNS]
- Reconciliation Workflow Safety Checks: [RECONCILIATION_SAFETY_CHECKS]
- Noise Filtering Rules: [NOISE_FILTERING_RULES]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "drift_detected": boolean,
  "drift_summary": {
    "total_discrepancies": number,
    "critical_count": number,
    "warning_count": number,
    "info_count": number
  },
  "discrepancies": [
    {
      "id": "string",
      "config_path": "string",
      "intended_value": "string or object",
      "actual_value": "string or object",
      "severity": "critical|warning|info",
      "category": "missing|mismatch|extra|stale",
      "reconciliation_risk": "safe|requires_drain|requires_freeze|destructive",
      "recommended_action": "string",
      "false_positive_likelihood": "low|medium|high",
      "evidence": "string"
    }
  ],
  "reconciliation_plan": {
    "safe_to_proceed": boolean,
    "recommended_order": ["string"],
    "rollback_plan": "string",
    "estimated_duration_minutes": number
  },
  "noise_analysis": {
    "filtered_discrepancies": number,
    "filtering_rationale": "string"
  }
}

## INSTRUCTIONS
1. Compare every config path present in the intended configuration against the actual state.
2. Flag any config path present in actual state but missing from intended configuration as "extra" category.
3. Flag any config path present in intended configuration but missing from actual state as "missing" category.
4. Apply noise filtering rules to suppress known false positives before reporting.
5. Classify each discrepancy using the provided severity rules.
6. For each discrepancy, assess reconciliation risk based on the provided safety checks.
7. If previous drift status exists, highlight any newly introduced or resolved discrepancies.
8. Do not fabricate discrepancies. Only report differences supported by the provided data.
9. If the intended and actual states are identical, set drift_detected to false and return empty discrepancies array.

## HUMAN REVIEW REQUIRED
If any discrepancy has severity "critical" or reconciliation_risk "destructive", append a prominent warning to the reconciliation_plan indicating that human approval is mandatory before remediation.

To adapt this template, replace each square-bracket placeholder with data from your configuration sources. The [INTENDED_CONFIG] should contain the desired state from your infrastructure-as-code repository, configuration management database, or approved specification. The [ACTUAL_STATE] should contain the observed state collected from your monitoring agents, API queries, or configuration audit tools. The [SEVERITY_RULES] placeholder should define your organization's classification criteria, such as treating security group changes as critical and log-level changes as info. The [NOISE_FILTERING_RULES] are essential for suppressing known transient states, auto-scaling variations, or timestamp differences that would otherwise flood the report with false positives. After generating the drift analysis, validate the JSON output against the schema before feeding it into your reconciliation workflow or ticketing system. For high-risk environments, always route discrepancies with reconciliation_risk: "destructive" through a human approval queue before any automated remediation executes.

This prompt is designed to be called by an automated drift detection pipeline, not as a one-off manual review. The harness should fetch the intended state from your infrastructure-as-code repository or configuration management database and the actual state from your live environment's API or agent-collected snapshots. Both must be normalized into a consistent schema before injection into the [INTENDED_CONFIG] and [ACTUAL_CONFIG] placeholders. The prompt expects structured JSON inputs; passing raw YAML or untyped key-value dumps will degrade output quality and increase false positives.

After the model returns a drift analysis, the harness must validate the output against the expected [OUTPUT_SCHEMA] before acting on it. At minimum, confirm that every drift entry includes a resource identifier, the specific parameter that diverged, intended and actual values, a severity classification, and a reconciliation action. Drift entries missing any of these fields should trigger a retry with a more constrained prompt variant. For high-severity drifts—especially those involving security group rules, IAM policies, or encryption settings—route the finding to a human review queue rather than auto-remediating. The harness should log the full prompt, model response, validation result, and reviewer decision for auditability.

Model choice matters here. Use a model with strong structured output support and a large context window if you are comparing hundreds of resources in a single call. For production pipelines, prefer models that support JSON mode or tool-calling with a strict schema. Implement exponential backoff retries for malformed responses, and set a maximum of three retry attempts before escalating the entire batch to a human operator. Avoid wiring this prompt directly to an auto-remediation webhook without a human-in-the-loop gate for any drift classified as CRITICAL or HIGH severity. Start with a dry-run mode that logs intended actions without executing them, and only enable automated reconciliation for LOW severity, well-understood parameter classes after at least two weeks of clean dry-run results.