Q11) Secure calls to device APIs with self-signed certs
Your Python script talks to an IOS-XE device’s RESTCONF API over HTTPS. The device uses a self-signed certificate. What’s the best practice?
A. Pass verify=False in requests.get() to skip TLS checks
B. Import the device (or CA) cert into a trust bundle and pass its path via verify="/path/to/ca.pem"
C. Switch to plain HTTP to avoid certificate errors
D. Add a custom header X-Trust: true so the server allows the call
Detailed explanation:
Disabling verification (A) or downgrading to HTTP (C) weakens security and is discouraged. Custom headers (D) don’t affect TLS validation. The right approach is to trust the certificate properly: export the device (or issuing CA) certificate, add it to a CA bundle, and tell requests to verify using that bundle (e.g., requests.get(url, verify="ca.pem")). This preserves encryption and authenticity without suppressing security controls.
Q12) Modeling interfaces in YANG
You need to represent a collection of interfaces, each uniquely identified by a name (for example, GigabitEthernet1). Which YANG construct is correct?
A. leaf interface { type string; }
B. leaf-list interface { type string; }
C. list interface { key "name"; leaf name { type string; } ... }
D. container interface { leaf name { type string; } }
Detailed explanation:
A list models zero-to-many complex entries, each with one or more keys. Here the key is name. A single leaf (A) can’t hold multiple interface objects. A leaf-list (B) is a list of scalars (no nested structure). A container (D) is a single grouping of leaves, not a set keyed by name.
Q13) RESTCONF RPC vs data resource
You want to trigger an operation (RPC/action) exposed by a YANG module (not set config/state directly). Which RESTCONF target is correct?
A. POST /restconf/data/...
B. GET /restconf/data/...
C. POST /restconf/operations/<module>:<rpc-name>
D. PATCH /restconf/operations/<module>:<rpc-name>
Detailed explanation:
Per RESTCONF (RFC 8040), the /restconf/data/ subtree is for configuration/state resources (A, B), whereas RPCs/actions are invoked under /restconf/operations/ with POST (C). PATCH (D) is for partial updates to resources, not for executing operations.
Q14) Jinja2 templating for safe defaults
In an Ansible template, you want an interface description to default to “Managed by Ansible” if description isn’t provided. Which Jinja2 is best?
A. description {{ description or "Managed by Ansible" }}
B. description {{ default(description, "Managed by Ansible") }}
C. description {{ description | default("Managed by Ansible") }}
D. description {{ description if description else "Managed by Ansible" | safe }}
Detailed explanation:
The idiomatic Jinja2 pattern is the default filter applied to the variable: {{ description | default("Managed by Ansible") }}.
Option A can work but isn’t as explicit and may behave differently with falsy (but valid) values. B is not correct syntax for Jinja2’s filter usage. D introduces unnecessary complexity and the |safe filter is unrelated to providing defaults.
Q15) Model-driven telemetry vs SNMP
Which statement most accurately contrasts model-driven telemetry (MDT) with SNMP on Cisco platforms?
A. MDT uses server-driven push streams (e.g., gNMI/gRPC) of YANG-modeled paths with subscriptions; SNMP is predominantly poll-based using MIBs and has coarser intervals
B. MDT and SNMP are both pull only; the difference is that MDT uses XML while SNMP uses JSON
C. SNMP traps deliver full state continuously; MDT only sends deltas when a CLI change occurs
D. MDT can’t stream counters; it only reports syslog messages
Detailed explanation:
MDT establishes subscriptions to YANG-modeled data and pushes updates (sampled or on-change) over protocols such as gNMI/gRPC, giving lower latency and efficient transport. SNMP typically relies on manager polling of MIB OIDs at intervals; traps/informs exist but are event-based and limited. MDT supports detailed paths (e.g., OpenConfig or native models) and is well-suited to time-series collection of counters and state.
