Your cloud provider's native control already blocks public IPs; should you duplicate that rule in your own engine?
answer
- two copies, but only one is the control
- what does a green pre-flight actually prove
- stricter is safe, weaker is a false green
- plans carry values not known until apply
- apply-time denials are your drift signal
basics
~20 sUsually yes, but only as a pre-flight duplicate that gives earlier, better-worded feedback. The native control stays the enforcement; the duplicate is advisory, never proof of compliance, and must handle plan values that are unknown until apply.
solid answer
~50 sAdd it, and be explicit about its status: the native control is the enforcement, and your rule is a **pre-flight duplicate whose only job is earlier feedback**. That buys the two things native cannot give — a verdict while the change is still in review, and a message you actually wrote, naming the guardrail, the reason and the exception path. What it must never buy is authority: a green pre-flight is not evidence the change is compliant, so do not gate promotion on it as though it were, and do not report it to an auditor as the control. Two practical consequences. First, **drift**: two phrasings of one rule diverge, so keep the native control as the source of truth and review both together. Second, **undecidability**: a plan may not know whether an instance ends up with a public IP, because the value is resolved at apply. Decide deliberately whether unknown warns or fails, and say so in the message.
code
json · 16 lines{
"address": "aws_instance.api",
"change": {
"actions": ["create"],
"after": {
"instance_type": "t3.small",
"subnet_id": "subnet-0ab1c2d3"
},
"after_unknown": {
"associate_public_ip_address": true,
"public_ip": true,
"id": true
}
}
}
...go deeper
Understand why the same rule can sensibly exist twice: one copy stops the change, the other tells the developer early and in words that help. They are not redundant checks.
Explain what a passing pre-flight does and does not prove, and why the copy that gives feedback should be at least as strict as the copy that enforces, never weaker.
Demonstrate the operating detail: an explicit choice for values unknown until apply, a message that names the guardrail and the exception path, and apply-time denials watched as the drift signal.
Own the accountability question: which artifact you name as the control when an auditor asks, and how you stop an advisory pre-flight from quietly becoming the organisation's assurance story.
## The shape of the decision You have one rule — *no compute instance may have a public IP address* — and it is already enforced where it cannot be routed around: inside the provider's control-plane API, on the create call. A team complains that they only discover this at apply time, from an error that names nothing. The question is whether to re-express the rule in your own engine. The answer is usually yes, and the whole skill is in what you claim for the copy. ## Enforcement and feedback are different jobs Give each copy one job. - **The native control is the enforcement.** It covers every caller, has no component to delete, and is the thing that actually makes non-compliant instances impossible. It is what you point at when someone asks whether the guardrail holds. - **Your rule is pre-flight feedback.** It reads the proposed change while it is still a proposal, and fails the change early with a message you wrote: which guardrail this will hit, why it exists, what the supported alternative is, and how to request an exception. Stating this split out loud matters, because the failure mode is quiet: the duplicate slowly starts being treated as the control. Someone adds "policy check passed" to a release checklist. Someone shows a quarter of green pre-flight runs as evidence. Now the organisation's assurance rests on a check that only sees changes routed through one pipeline. ## The duplicate is advisory, and the asymmetry matters The two copies can disagree in two directions, and they are not equally dangerous. - **Pre-flight denies, native would allow** — your rule is stricter. Annoying, occasionally wrong, but safe: the worst case is a change blocked early that the platform would have permitted, and a human can see why. - **Pre-flight allows, native denies** — false green. This is the dangerous one, because the developer has been told the change is fine and finds out otherwise at apply, and because anyone treating the pre-flight as proof is now wrong. So prefer the duplicate to be **at least as strict** as the native control, and never weaker. ## Undecidable inputs are normal, not an edge case A proposed plan is not the final request. Whether an instance ends up with a public address may depend on a value that is resolved only at apply — a subnet setting, a computed attribute, a value produced by another resource. A plan representation marks such attributes as unknown rather than giving a value, and a rule that reads the plan simply cannot decide. You have to choose, deliberately: - **Fail on unknown.** Safe, but noisy, and will block legitimate changes whose values happen to resolve fine. - **Warn on unknown.** Keeps the check useful as feedback and is defensible precisely *because* the native control is the real enforcement — an unknown that turns out badly is caught at apply. When the enforcement genuinely lives natively, warning on unknown is usually right. If you ever promote the pre-flight to the enforcement, that choice has to be revisited, which is a good reason to write it down. ## Managing drift One rule in two languages will drift. Practical measures: keep the native control as the declared source of truth; change the two together in one reviewed change; make the pre-flight rule's message point at the native control by name so anyone reading it knows where the real decision lives; and, where you can, close the loop by watching apply-time denials — every denial that the pre-flight did not predict is a concrete drift report, and it should be rare. ## Is the duplicate ever wrong to build? Sometimes. If the rule is one nobody writes by hand anyway, if apply-time denials are already close to zero, or if the team maintaining the engine is stretched, a second copy is maintenance for very little feedback. And if the pre-flight is going to be trusted as proof no matter what you say, it may be safer not to have one. But where developers are hitting the guardrail regularly and the provider's error teaches them nothing, the duplicate pays for itself in tickets not filed. ## What a strong answer sounds like "Yes, but as feedback, not as the control. Native stays authoritative; my rule fails the merge request early with a message that names the guardrail and the exception path. It is allowed to be stricter, never weaker; it warns rather than fails when the plan value is unknown until apply, because the enforcement is downstream; and I track apply-time denials as my drift signal."
- What do you do when the pre-flight cannot decide because the value is unknown until apply?Choose explicitly and document it. Because the native control is the real enforcement, warning on unknown is usually right: the change still gets denied at apply if it turns out badly, and you avoid blocking legitimate work on undecidable input. If the pre-flight ever became the enforcement, unknown would have to fail instead.
- How do you stop the two copies of the rule from drifting apart?Declare the native control the source of truth, change both in one reviewed change, and have the pre-flight message name the guardrail it is predicting. Then watch apply-time denials: every denial your pre-flight did not predict is a drift report, and the count should stay near zero.
- A team wants to show a quarter of green pre-flight runs as compliance evidence. What do you say?That the pre-flight only sees changes that went through that pipeline, so green runs prove those changes were checked, not that the estate is compliant. The evidence is the native control's configuration and its denial records, since that is the control every caller actually hits.
saying these in an interview costs you the question
- Treats a green pre-flight as proof of compliance
- Makes the duplicate looser than the enforcing control
- Ignores plan values that are unknown until apply
- Removes the native control once the pipeline check exists
- Leaves the two rules to drift with no reconciliation signal