County security wants firewall baselines expressed as the end state the devices should have, leaving the tool to calculate required changes. Which IaC style is that?
Select an answer to reveal the explanation.
Short Explanation
Declarative config is handing the crew a finished street map — ‘this is how the firewall should look’ — instead of a turn-by-turn list of every left and right. The tool figures out the route to that desired state.
Full Explanation
County security wants firewall baselines expressed as the end state devices should have, with the tool calculating required changes. That is declarative desired-state configuration: operators declare allow/deny sets, object groups, or policy documents, and the engine converges reality to that definition. Declarative style reduces brittle ordered scripts and makes drift detection straightforward against a single source of truth.
Imperative runbooks that list every CLI command operators must type in order encode steps, not desired state, and break when device starting conditions differ. Ad-hoc console clicking with no recorded definition cannot be audited or reapplied consistently. Spreadsheets of past changes without a machine-readable desired state document history of actions, not a convergent baseline.
Exam caveat: some bootstrap steps remain imperative; the stem asks for the style of the ongoing baseline, which is declarative. Operational check: encode the baseline in the declarative tool, apply to a lab firewall, intentionally drift a rule, re-apply, and confirm convergence back to the declared policy without rewriting a step list. Declarative firewall baselines also support continuous compliance scans: compare live device config to the declared document and open tickets on drift without reverse-engineering last week’s CLI session.