A parks-and-recreation team wants the platform to keep three healthy replicas of its reservation API without an operator running start and stop checklists. Which cloud-native pillar describes that approach?
Select an answer to reveal the explanation.
Short Explanation
Declarative control is like telling a thermostat the temperature you want, not flipping the heater switch yourself every hour. You publish desired state; the platform converges. Imperative checklists and SSH snowflakes fight that model.
Full Explanation
Declarative APIs are the pillar that lets the parks-and-recreation team publish desired state—for example three healthy replicas of the reservation API—and have the platform continuously reconcile actual state toward that intent. Operators stop running start/stop checklists after every blip because controllers, not humans, are the control loop that creates, replaces, and retires replicas to match the declaration.
Imperative runbooks that execute a fixed CLI sequence after every outage leave people as the reconciler; the system does not converge on its own when a replica dies at 2 a.m. Manual capacity planning that pre-sizes a single large host and never changes replica counts rejects elasticity and desired-state replica management entirely. Snowflake configuration that customizes each replica by SSH after boot guarantees drift so “three healthy replicas” are no longer interchangeable instances of the same declared intent.
Exam caveat: the fundamentals item targets the desired-state pillar itself, not a specific YAML field name, kubectl flag, or OCI console click-path.
Operational check: declare the replica count and health expectations, kill one replica, and verify the platform restores the desired count without an operator executing a start checklist.