Configuration Drift Detection Log Prompt

This prompt is designed for infrastructure and platform engineers who need to convert raw, human-readable configuration drift reports into structured, machine-actionable log entries. The primary job-to-be-done is normalization: taking the output of a drift detection tool (such as a diff between desired state and actual state) and producing a strictly-typed JSON record suitable for ingestion into a centralized inventory, a compliance dashboard, or an automated remediation pipeline. The ideal user is an engineer building a reliability or security workflow where drift events must be tracked, queried, and audited over time, not just observed in a terminal.

Use this prompt when your drift detection system already identifies a discrepancy but expresses it in an unstructured format like a diff output, a CLI summary, or a notification message. The prompt enforces a controlled vocabulary for drift severity (CRITICAL, HIGH, MEDIUM, LOW) and requires a machine-readable representation of the resource's expected and actual state. It is critical that you provide the raw drift report as the [DRIFT_REPORT] input and specify the resource identifier format you require in [RESOURCE_ID_SCHEMA]. Do not use this prompt as a real-time alerting replacement; it is a post-detection normalization step. It does not replace your detection engine (e.g., Terraform, Pulumi, or a custom operator) and should not be the sole trigger for paging on-call engineers.

Before wiring this into a production pipeline, ensure you have a clear contract for the [OUTPUT_SCHEMA] that your downstream systems expect. The prompt is most effective when the target schema is provided inline, allowing the model to map the messy drift report directly to your required fields. Avoid using this prompt for resources whose state cannot be cleanly serialized into the expected JSON structure, or where the drift report contains ambiguous, incomplete data that requires human interpretation. In those cases, route the event to a human review queue instead.

This prompt template is designed to be pasted directly into your system prompt or user message. It instructs the model to analyze two configuration states—an expected state and an observed actual state—and produce a structured drift detection record. The output is a JSON object that identifies the resource, the specific drifted properties, and the detection timestamp, making it suitable for direct ingestion into an infrastructure monitoring pipeline or a compliance audit system.

textCopy
You are a configuration drift detection engine. Your task is to compare an expected configuration state with an actual observed state for a single resource and produce a structured drift record.

## Inputs
- Expected Configuration: [EXPECTED_CONFIG]
- Actual Configuration: [ACTUAL_CONFIG]
- Resource Identifier: [RESOURCE_ID]
- Resource Type: [RESOURCE_TYPE]
- Detection Timestamp: [DETECTION_TIMESTAMP]

## Output Schema
Return a single JSON object with the following structure:
{
  "resource_id": "string",
  "resource_type": "string",
  "detection_timestamp": "string (ISO 8601 format)",
  "drift_detected": "boolean",
  "drifted_properties": [
    {
      "property_path": "string",
      "expected_value": "string",
      "actual_value": "string",
      "severity": "string (enum: CRITICAL, HIGH, MEDIUM, LOW)"
    }
  ],
  "drift_summary": "string (concise human-readable summary of all detected drift)"
}

## Constraints
- If no differences are found, `drift_detected` must be `false` and `drifted_properties` must be an empty array.
- The `property_path` should use dot-notation to indicate nested fields (e.g., `spec.replicas`).
- `expected_value` and `actual_value` must be string representations of the values.
- The `severity` field must be one of the specified enum values. Assign `CRITICAL` for security group or IAM role changes, `HIGH` for instance size or capacity changes, `MEDIUM` for tag or metadata changes, and `LOW` for description or comment changes.
- The `drift_summary` must be a single sentence that is safe for use in a Slack alert or an incident ticket title.
- Do not include any text outside the JSON object.

To adapt this template, replace the bracketed placeholders with your actual data. The [EXPECTED_CONFIG] and [ACTUAL_CONFIG] placeholders can accept a JSON or YAML string representing the full resource configuration. For high-risk environments, such as production infrastructure or regulated systems, always pair this prompt with a post-generation validation step that checks the output against the defined JSON Schema and verifies that the resource_id matches the input. A human operator should review any drift record with a CRITICAL severity before automated remediation is triggered.

This prompt is designed to be called by an automated scanner, not a human chat interface. The typical harness runs after a configuration audit tool (e.g., a Terraform plan diff, an AWS Config snapshot comparison, or a Kubernetes kubectl diff output) detects a discrepancy. The raw diff text is passed as the [DRIFT_DETAIL] input, while the [EXPECTED_STATE] is sourced from the Infrastructure-as-Code (IaC) repository or a golden configuration database. The model's job is to normalize this raw technical data into a structured, machine-readable drift record that can be ingested by your SIEM, compliance database, or on-call alerting platform.

To wire this into an application, wrap the prompt in a function that enforces a strict contract. The function should accept the expected state and the actual state as arguments, format them into the prompt template, and call a model with a low temperature (0.0–0.2) and JSON mode enabled. The response must be parsed and validated against a JSON Schema that checks for the presence of required fields (resource_id, drift_type, detected_timestamp), the format of the timestamp (RFC 3339), and the controlled vocabulary for drift_type (e.g., ADDED, REMOVED, MODIFIED). If validation fails, implement a single retry with the validation error message appended to the prompt as a correction instruction. Log both the raw model output and the validation result before writing the final record to your event bus. For high-risk resources like IAM policies or security groups, route the record to a human approval queue before automated remediation is triggered.

Do not use this prompt for real-time blocking decisions. The model's interpretation of a diff can be lossy, and a hallucinated resource identifier could suppress a critical alert. Instead, use the structured output to enrich an existing deterministic drift detection pipeline. The model adds value by normalizing messy state representations and generating a human-readable summary, but the source of truth for the drift event must always be the deterministic diff tool. Ensure your harness treats the model's output as an annotation on a known event, not as the primary event generator itself.