What this prompt does
This prompt hands the AI a full specification for an infrastructure drift detection system rather than asking a vague "how do I detect drift" question. You set [infrastructure_scope] and [iac_tool] so the design targets a real estate, then [resource_count] and [account_count] give it the scale to design for. The model returns a layered system: scheduled detection running every [scan_interval] using [detection_method], a classification engine that sorts findings into [severity_levels], notifications to [alert_channels], a dashboard backed by [dashboard_storage], and automated remediation for [auto_remediate_categories].
The structure works because drift is not one problem but several. The [security_drift_examples] need to scream while [config_drift_examples] only need a ticket, and tag-only changes can often self-heal. By forcing the AI to separate detection, classification, escalation via [escalation_path], root-cause tracking against [audit_source], and prevention via [prevention_strategies], you get a pipeline that distinguishes signal from noise instead of one giant alert firehose. The [resource_count] and [account_count] inputs also matter, because a system that scans 50 resources in one account looks nothing like one sweeping hundreds across several, and the design adapts the batching and parallelism accordingly.
When to use it
- You manage IaC-defined infrastructure where people still occasionally make console changes
- You want drift caught on a schedule, not discovered during the next failed
plan - You need to justify severity tiers so on-call is paged only for real risk
- You are building a drift dashboard and need a data model and metrics to track
- You want to wire
[audit_source]correlation in so each drift event names who changed what - You are designing prevention controls like SCPs and want them scoped sensibly
- You need time-to-remediation metrics to show leadership drift is actually shrinking
Example output
Expect a structured design document: numbered sections matching the seven parts of the prompt, a classification rule table mapping change types to [severity_levels], a suggested schema for the [dashboard_storage] backend, and sample notification payloads for [alert_channels]. It typically includes a sketch of the CI pipeline steps that run [detection_method] and parse the output, plus a remediation decision tree showing which categories auto-apply and which get flagged for review. You usually also get a description of the dashboard panels — drift count by severity, trend over time, and the most frequently drifting resources — so the metrics layer is concrete rather than aspirational.
Pro tips
- Make
[detection_method]concrete — namingterraform plan -detailed-exitcodewith JSON output gets you parsing logic instead of hand-waving - Tune
[scan_interval]to your change velocity; every 4 hours is reasonable, but hourly on a hot estate or daily on a stable one both have a place - Keep
[auto_remediate_categories]conservative at first — tag and non-prod config drift only, never security-relevant changes - Spell out
[security_drift_examples]precisely, since this is the list that decides what pages[escalation_path]at 3am - Pair detection with real
[prevention_strategies]; a system that only reports drift you keep re-introducing is treating the symptom - Route
[alert_channels]so medium and low drift lands somewhere quiet and only critical drift interrupts people, or alert fatigue sets in fast - Iterate by feeding back the actual
planJSON shape your tool emits so the parsing logic matches reality, not a generic example
