skip to content

A backup-retention rule must run on a pre-merge plan and on a nightly scan of live databases. What makes one rule serve both?

level: middleimportance: should knowfreq 46%

answer

  1. reuse is possible, not automatic
  2. two documents, one fact
  3. agree a shape, map into it
  4. the plan may not know the value yet
  5. preventive at the gate, detective at night

basics

~20 s

Both surfaces must hand the rule the same fact in the same agreed shape, so each enforcement point normalises its input before evaluating. The rule must also state what it does when the plan leaves the value unknown until apply.

solid answer

~50 s

Reuse is not free just because the rule is data. A plan document describes a proposed change and an inventory record describes a running database; the retention value sits under a different name in a different structure. So each enforcement point maps its input into an agreed shape and the rule is written against that shape, not against either surface's raw layout. Second, a plan can carry values that are unknown until apply, and a rule reading a missing field usually produces no result at all rather than a violation — a silent allow. I decide that deliberately: either unknown fails the pre-merge check, or it is explicitly deferred to the nightly scan, which sees the concrete value. Third, the outcome differs: the pre-merge check is preventive and can block, while the nightly scan is detective and can only report on something that already exists.

code

yaml · 13 lines
yaml
# 1. the proposed change, from a plan document
resource_changes:
  - address: "..."
    change:
      actions: ["create"]
      after: { backup_retention_period: 7 }
      after_unknown: { identifier: true }   # not known until apply
---
# 2. the same database, from an inventory record of the live estate
databases:
  - id: "..."
    BackupRetentionPeriod: 7
    status: available

go deeper

for a junior

Know that the same condition can be checked before a change is applied and again against what is actually running, and that the two look at different documents even though the fact is the same.

for a middle

Explain that each enforcement point normalises its input into an agreed shape the rule is written against, and that a plan may carry values unknown until apply, which the rule must handle on purpose.

for a senior

Show that you have hit the quiet failure: a rule referencing a missing or unknown field produces no result and reads as a pass. Say how you would detect a rule that has stopped matching.

for a principal

Argue what the second enforcement point is actually for — drift and resources that predate the rule — and decide who owns the findings it produces when there is nothing left to block.

## "The rule is data, so it is portable" is half true Stating a condition as data is what makes reuse *possible*; it does not make it *automatic*. Three things have to be arranged before one retention rule (at least 35 days of backups) genuinely serves two enforcement points. ### 1. The two surfaces speak different dialects Before a change is applied, the fact lives in a plan document: a list of proposed resource changes, each with the attribute values the change would produce. After it is applied, the same fact lives in whatever describes the running estate: an inventory record or an API description, with its own field names and nesting. Same number, two shapes. A rule that reaches directly into one of those structures is a rule you can only use once. The fix is a normalisation step at each enforcement point: whatever gathers the input flattens it into an agreed document shape — for example, a list of objects each carrying `kind`, an identifier, and `retention_days` — and the rule is written against that agreed shape. The mapping is per surface; the rule is shared. This is also what makes the rule survive a surface changing its layout: one mapper changes, forty rules do not. ### 2. A plan carries values that are not yet known The pre-merge surface has a property the live one does not: some attributes are **unknown until apply** — they depend on something that does not exist yet. A plan can legitimately say "this database will be created, and this field will be resolved later". This is where rules fail silently. In most rule languages a body that cannot be satisfied — because the field it references is absent or not a number — does not evaluate to false and does not raise; it simply produces **no result**. No result reaches the caller as "nothing to report", which is indistinguishable from a pass. So a rule written as "flag it when `retention_days` is below 35" quietly allows every resource whose retention the plan does not know. The rule has to treat that case on purpose. Two defensible choices, and an interviewer wants to hear you pick one and say why: - **Fail on unknown at the gate.** Conservative, and it forces the change author to make the value explicit rather than computed. It also generates noise when unknowns are common and legitimate. - **Allow at the gate, catch at the sweep.** Accept that a plan cannot always know, and rely on the nightly evaluation of the live resource, where the value is always concrete. This is only honest if the sweep actually exists and someone reads its output. Either way, the rule states it. Leaving it implicit means the answer depends on an accident of evaluation. ### 3. The same "no" means different things at the two points The pre-merge check is **preventive**: the database does not exist yet, so refusing the change is enough to stop the condition ever holding. The nightly scan is **detective**: the database is running with seven days of retention right now, and no amount of blocking changes that. Its output is a finding — a ticket, a report line, an alert, or the trigger for a remediation path — not a veto. So one rule, one threshold, two outcomes. Keeping the rule identical while the outcome differs is exactly the property the rule-as-data shape buys you; if you had two scripts, you would have two copies of `35` that drift apart. ### Why bother with the second point at all Because the gate only ever sees changes that go through it. The nightly scan is what covers resources created before the rule existed, resources changed outside the pipeline, and anything whose value the plan could not know. When the scan flags a database the gate passed, all three of those are candidate explanations, and telling them apart is the first diagnostic step. ### The failure to remember The worst outcome here is not a noisy rule; it is a quiet one. A rule reading a field that was renamed, absent or unknown produces nothing, and nothing looks like success on both surfaces at once. Any reuse story should include an answer to "how would we know this rule stopped matching?"

  • Where should the normalisation live — inside the rule or outside it?
    Outside, in whatever gathers the input at each enforcement point. A rule that reaches into a surface's raw structure is welded to that surface. Keeping the mapping outside means one mapper changes when a document layout changes, instead of every rule that reads it.
  • The nightly scan flags a database at seven days that the pre-merge check passed. What are the explanations?
    Three: the value was unknown at plan time and the rule allowed it, the database was changed outside the pipeline after apply, or it predates the rule entirely. All three are drift, and distinguishing them tells you whether to fix the rule, the access path, or just remediate.
  • Should the nightly scan block anything?
    It cannot prevent what already exists, so blocking is not the outcome available to it. It reports — a finding, a ticket, an alert, or a trigger for a remediation workflow. Same rule and same threshold as the gate, different answer to "now what".

saying these in an interview costs you the question

  • Assumes a rule is portable across surfaces automatically
  • Reads surface-specific field paths directly inside the rule
  • Treats a value unknown until apply as compliant
  • Expects a missing field to make a rule evaluate false
  • Says the nightly scan is redundant once the gate exists

context

resolving links…