A water utility wants a maintainable NetDevOps loop that combines structured encoding, local on-box reaction, and controller APIs for fleet changes. Which integrated approach best fits?
Select an answer to reveal the explanation.
Short Explanation
Think of the water network like a plant control loop: clean data formats in the pipes, a local trip for the pump that must stop now, and a central desk for citywide setpoints. YANG/JSON, EEM, and controller APIs each cover one part. Email-only or EEM-only leaves the loop broken.
Full Explanation
Water utilities seeking a maintainable NetDevOps loop that combines structured encoding, local on-box reaction, and controller APIs for fleet changes should use YANG/JSON encoding for automation payloads, EEM for local fast events, and controller APIs for reviewed fleet-wide changes in a staged pipeline. That integrated approach assigns each tool to the timescale and blast radius it fits. Encoding discipline, local reaction, and staged fleet control together form a coherent civic automation architecture.
Relying only on unstructured email instructions to NOC staff with no APIs or encoding standards does not create a maintainable loop. Putting every civic change exclusively in on-box EEM with no controller or source control fails fleet consistency. Disabling encoding validation, EEM, and controllers to keep operations purely manual abandons NetDevOps goals.
Exam caveat: reconciliation policy must define when EEM temporary changes are overwritten by controller intent so local fixes do not become permanent snowflakes. Operational check: demonstrate a JSON/YANG API change in staging, an EEM local notify on a tracked failure, and a controlled promotion to production with evidence in tickets. Review the loop quarterly for the water utility automation board.