EMS needs a brand-new jump box built once before any declarative agent can manage it. Which approach is still appropriate for that first bootstrap?
Select an answer to reveal the explanation.
Short Explanation
Bootstrap is the temporary scaffolding around a new firehouse wing — you need those imperative boards up once so the permanent declarative walls can take over. One-time scripts are fine; forever manual chaos is not.
Full Explanation
EMS needs a brand-new jump box built once before any declarative agent can manage it. A one-time imperative bootstrap script remains appropriate for that first preparation—install the agent, join the domain, place bootstrap credentials, or lay down the minimum packages—then hand ongoing management to declarative automation. Bootstrap scaffolding is temporary; permanent configuration should not stay as forever-manual edits.
Refusing any bootstrap and waiting indefinitely for an undeclared host to configure itself leaves the jump box unusable. Applying random manual changes daily so no baseline ever forms prevents declarative convergence and auditability. Declaring the host managed in inventory before it exists on the network creates false inventory and failed runs without solving first-boot reality.
Exam caveat: bootstrap scripts should be minimal, reviewed, and retired from routine use once the declarative agent owns the node. Operational check: run the bootstrap on a fresh VM, verify the agent checks in, apply a declarative baseline successfully, and ensure subsequent changes go through IaC rather than re-running ad hoc shell forever. Keep the EMS bootstrap script in the same reviewed repo as other IaC, with checksums for any agent installers, so the one-time path is still auditable even though it is imperative.