Pre-flight configuration validator

A pre-flight configuration validator compares proposed settings against the rules your organization already treats as authoritative: security baselines, dependency constraints, and compliance policies. The check runs before change windows open, while edits are still cheap. Findings are quality signals, not deployment verdicts. Each one should name the config field under review and the baseline rule ID that triggered the comparison.

Typical inputs span infrastructure definitions, application manifests, network policies, identity bindings, and environment-specific parameter files. Baselines may live in policy-as-code repositories, CMDB-backed standard builds, or cloud posture libraries maintained by platform engineering. Dependency maps tell the validator which upstream services, secrets stores, or shared subnets a change touches. Compliance policies add obligations that baselines alone may not encode, such as data residency, encryption scope, or audit logging requirements.

The validator does not replace peer review or automated test suites. It narrows what humans must read by surfacing mismatches early. Pair it with a change impact simulator when you need to see blast radius, and with deployment runbook generation when validated configs still need operator steps documented.

Start by pinning the artifact set for the release candidate: the exact revision of each config file, template render output, or exported object from your delivery pipeline. Partial snapshots produce partial findings. If the deploy bundles ten services but the validator only sees three manifests, the report will look clean while risk remains elsewhere.

Load baselines as structured rule records, not prose checklists. Each record needs a stable identifier, the field or path it applies to, the expected constraint, and the severity your governance model assigns. Sources vary by shop. HashiCorp-style policy packs, Prisma Cloud policy libraries, Ansible role constraints, and ServiceNow standard change templates can all feed the corpus if you normalize them into the same schema before comparison.

Dependency maps should be versioned alongside baselines. When a proposed database endpoint changes, the validator needs to know which applications declare that dependency, not just whether the endpoint string is syntactically valid. If maps are stale, flag the staleness as its own finding rather than silently skipping cross-service checks.

Normalize values before compare: trim whitespace, resolve aliases, expand environment placeholders using the target environment's parameter file, and apply the same unit conventions your baselines assume. Without normalization, you will chase false positives that waste reviewer time.

Every finding follows the same skeleton: rule ID, config field path, observed value, expected constraint, and a short explanation a platform engineer can act on without opening the baseline document. Severity comes from the baseline record, not from model confidence.

Example (illustrative, not from a live system):

| Rule ID | Config field | Observed | Expected | |---------|--------------|----------|----------| | NET-014 | spec.ingress.tls.minVersion | TLSv1.0 | TLSv1.2 or higher per edge baseline | | IAM-203 | roleBindings[2].principal | * | Named principal group from approved list | | LOG-007 | audit.sink.destination | (empty) | Non-empty sink URI when audit mode is enforced |

The third row shows an empty field evaluated against a rule that requires a value. The validator reports the gap. It does not invent a CVE, a threat actor story, or a compliance statute number to make the row feel urgent. If the baseline does not map the field to an external control ID, that column stays blank.

Do not auto-block a release because the model "feels" the config is risky. Auto-block only when a cited baseline rule and your change-management policy explicitly require it. Otherwise, route findings to owners with clear fix guidance and let humans decide timing within the release train.

Empty stays empty when the supporting record does not exist. If a finding has no matching rule ID in the loaded corpus, do not fabricate one to satisfy a dashboard widget. Leave the rule ID field blank and mark the finding as uncited or equivalent in your workflow. Reviewers should treat uncited items as triage candidates, not as policy violations.

The same discipline applies to compliance mappings. When a config field has no mapped control in your policy set, report the technical mismatch on its own merits or skip the row. Padding reports with invented framework references trains teams to ignore the tool.

When a baseline rule exists but the config path is ambiguous, cite the closest resolvable field and note the ambiguity in the explanation. Do not guess nested paths that your parser did not actually read. Uncertainty belongs in the text, not in silent assumptions.

For upgrades that touch long-deprecated settings, an upgrade readiness assessor may surface schema drift the validator cannot see. Feed its output into the same review queue rather than merging unrelated concerns into baseline citations.

Validation completes when cited findings are resolved or explicitly accepted under your exception process. Fixing means editing the proposed config to meet the cited constraint, updating the baseline when the rule is wrong, or recording a time-bound waiver tied to the rule ID. The release still deploys after fix: clearing findings is a precondition you define, not an automatic pipeline halt unless policy says so.

Assign findings to owners using the same service map you use for incidents. Platform teams own shared baselines; application teams own manifest fields. Security engineering owns interpretation when two baselines conflict. Keep a single thread per release candidate so fixes do not land in one branch while the validator still reads another.

After fixes, re-run against the same pinned artifact set. Diff the report against the prior run so reviewers see only what changed. A clean second pass means every remaining row has a rule ID and config field, or documented acceptance.

Use a regression test case generator when a config fix should also produce a test that proves the constraint holds in the target environment. Validation tells you the document is wrong; tests tell you runtime behavior matches once deploy finishes.

Findings without rule cites. When reviewers see severity labels with no NET-014-style anchor, they cannot tell policy from model opinion. Over time they stop opening reports. Enforce cite-or-blank at generation time and fail the publish step on noncompliant rows.

Treating validation as deployed. A green validator report means the proposed configuration matched loaded baselines at check time. It does not mean the change reached production, that drift detection will stay green, or that secrets were rotated. Keep deploy status in the pipeline UI separate from validation status.

Invented CVEs and control IDs. Models sometimes hallucinate vulnerability identifiers when ports look unusual or TLS versions lag. Ban CVE fields unless your vulnerability feed supplied the ID for that exact package version. If posture tools like Prisma Cloud or Ansible-driven scans already own CVE correlation, link findings to those systems by reference ID, not by free-text guesses.

Baseline skew across environments. Production and staging rarely share identical rules. Tag each baseline bundle with environment scope and refuse cross-environment compares without an explicit mapping table.

Stale dependency maps. A validator that clears cross-service checks against yesterday's graph approves today's breaking rename. Version maps with baselines and surface map age on every report header.

Design the validator so a skeptical staff engineer can audit any row in under a minute: open the cited rule, open the cited field, compare values, decide. That auditability is the outcome. Quality rises when fixes are obvious, releases keep moving, and nothing in the report pretends to be evidence it cannot cite.