Infrastructure Automation and Programmability
Data formats and REST
JSON and YAML dominate configuration payloads; XML remains the native NETCONF encoding. For REST APIs know the verbs (GET read, POST create, PUT replace, PATCH partial update, DELETE remove) and status classes: 2xx success, 4xx client error (401 bad or missing token, 404 unknown resource), 5xx server error. Cisco controllers typically require a token obtained from an auth endpoint and sent in a header such as X-Auth-Token.
Model-driven programmability
YANG defines the data model - modules containing containers, lists (with keys), leaves, leaf-lists, plus constraints like mandatory, must and when. NETCONF runs over SSH port 830 and uses RPCs: <get> returns configuration and state, <get-config> returns configuration only, <edit-config> changes it with a default operation of merge (other options: replace, create, delete, remove). The candidate datastore requires an explicit commit; running takes effect immediately. RESTCONF is NETCONF's operations over HTTPS, accepting JSON or XML; GET maps to get, POST to create, PUT/PATCH to edit-config, DELETE to delete.
Tooling and telemetry
Ansible is agentless, pushes over SSH, uses YAML playbooks and idempotent modules; Puppet and Chef are agent-based and pull. Python is used with requests, Netmiko and NAPALM. gNMI/gRPC carries streaming telemetry: dial-in means the collector subscribes, dial-out means the device pushes. EEM applets react to syslog, SNMP or timer events.
Traps
Questions deliberately mix transports and operations - for example offering commit in a RESTCONF scenario, or claiming RESTCONF works with unmodelled CLI data. Also watch YANG list keys and whether a leaf is configuration or state.
Worked rule of thumb
If the stem mentions a candidate datastore and a commit step, the answer is NETCONF. If it mentions HTTP verbs with JSON payloads, the answer is RESTCONF.