NCP-GENL: Automation and Scripting

This domain tests whether your automation is safe to run twice, fail loudly and leave an audit trail. It covers idempotency, API-driven interfaces, error handling, secrets handling and change control - the properties that separate a script from a reliable operational tool.

Core rules

• Idempotency: running the same task twice must produce the same end state, not a duplicate object or a second VLAN.
• Declarative tools describe the desired end state; imperative scripts list steps. Prefer declarative where a tool exists, and write imperative scripts defensively.
• APIs return structured JSON or YAML; parse that rather than scraping human-readable CLI output, which changes between versions.
• In shell, set -euo pipefail makes errors, unset variables and mid-pipeline failures abort the run instead of passing silently.
• Return meaningful exit codes and log each action with a timestamp and target; automation without logs cannot be audited.
• Keep credentials out of scripts - inject them from a secret store or environment at runtime.
• Store scripts in version control, test in a non-production environment, and provide a rollback path.

Worked example

A provisioning script reports success but the target was never created. Reasoning: the failing command was the middle of a pipeline, and without pipefail the shell only checks the last command's status. Add set -euo pipefail, check the command's own exit status, and log the response body so the next failure is diagnosable.

Traps

Hard-coded passwords; no set -e; parsing table output instead of JSON; running untested changes straight to production; scheduling with cron without overlap protection, so a slow run collides with the next.