Hard Difficulty Questions

event interface

Why it fails: Interface events fire on line-protocol or interface state changes, not on log output, so a syslog match never reaches the applet. It is tempting because interface events are the standard trigger for reacting to a link going down or coming up, which is a genuinely different requirement.

event cli match

Why it fails: CLI match triggers on commands typed at the console or vty, not on messages written to the logging buffer, so the syslog line is never detected. It is tempting because CLI match suits auditing or blocking specific commands as an operator enters them.

event timer

Why it fails: Timer events fire on an absolute or periodic schedule, so the applet runs regardless of whether the syslog message ever appears. It is tempting because timers suit recurring maintenance tasks such as nightly configuration backups, where no log message needs to occur first.

port-channel load-balance src-ip

Why it fails: src-ip hashes only the source IP address, so flows from a single host to many destinations collapse onto one member link. It is tempting because it is IP-based, but the requirement is source and destination IP, which only src-dst-ip satisfies.

port-channel load-balance dst-ip

Why it fails: dst-ip hashes only the destination IP address, so many sources reaching one server collapse onto a single member link. It is tempting because it is IP-based, but the requirement is source and destination IP, which only src-dst-ip satisfies.

port-channel load-balance src-dst-mac

Why it fails: src-dst-mac hashes source and destination MAC addresses, so all traffic between two IP hosts sharing a next-hop MAC lands on one member link. It is tempting because MAC-based hashing suits switch-to-switch topologies, but the requirement specifies IP-based distribution, which src-dst-ip provides.

NETCONF

Why it fails: NETCONF is a protocol, not a YANG model source/tool.

oc-interfaces

Why it fails: This is a specific OpenConfig model, not a source or tool.

ietf-interfaces

Why it fails: IETF models are standard but OpenConfig is more commonly used for network operations.

Cisco-NX-OS-device

Why it fails: This is a Cisco proprietary model.

Cisco-IOS-XE-native

Why it fails: This is a Cisco proprietary native model.

The application requires a DHCP server, but the configuration uses a static IP address.

Why it fails: Static addressing is valid for app-hosting guest interfaces; nothing in the error indicates DHCP is required. This tempts because DHCP is common in container networking, but it would be correct only if the app explicitly demanded dynamic addressing and the log reported an address-acquisition failure.

The .tar file is corrupt despite appearing valid.

Why it fails: A corrupt .tar would fail at installation or signature verification, not with 'guest interface not ready'. The administrator already confirmed the package is valid. This distractor tempts because packaging faults do break app-hosting deployments, but the error points to the interface-to-port-group binding instead.

The CPU allocation of 1000 units is insufficient for the application.

Why it fails: Insufficient CPU would surface as resource exhaustion or throttling after start, not as an interface-readiness error. The stem confirms resources are sufficient. CPU sizing is the right concern when an app starts then crashes under load, which is not what the log shows here.

Server push

Why it fails: Server push lets the server send resources before the client requests them, reducing round trips, but it performs no header compression. It would be the correct choice if the question asked how HTTP/2 proactively delivers assets the client will soon need.

Binary framing layer

Why it fails: Binary framing splits messages into frames but performs no header compression itself; HPACK is a separate mechanism. It is tempting because framing underpins HTTP/2's wire format, and would be the answer if the question asked how HTTP/2 structures data into typed frames for multiplexing.

Multiplexed streams

Why it fails: Multiplexed streams let many requests share one TCP connection concurrently, eliminating head-of-line blocking at the application layer, but they do not compress headers. It would be correct if the question asked how HTTP/2 avoids opening multiple connections per origin.

Neighbor Advertisement (ICMPv6 type 136)

Why it fails: Neighbor Advertisement (type 136) is the reply sent by the target host; the requesting host must first send a solicitation. It is tempting because it is the Neighbor Discovery message carrying the MAC address, and would be correct as the response the queried host returns.

Router Solicitation (ICMPv6 type 133)

Why it fails: Router Solicitation (type 133) asks routers to advertise prefixes and default gateways; it carries no target address field for MAC resolution. It is tempting because it is a Neighbor Discovery message, and would be correct when a host boots and needs router configuration rather than a peer's link-layer address.

Address Resolution Protocol (ARP)

Why it fails: ARP resolves IPv4 addresses to MAC addresses and is not used for IPv6, which replaces it with Neighbor Discovery. It is tempting because ARP performs the identical function on IPv4 networks, and would be correct if the host held an IPv4 destination address on the same link.

Require all changes to be approved by a change advisory board before merging

Why it fails: A change advisory board approves change requests before merging, adding governance latency but no runtime validation. The failure was a playbook-to-device-model mismatch during execution, which board approval cannot detect. CAB works for controlling change authorisation in ITIL-style processes, not automated device targeting.

Require two-person peer review for all playbook changes

Why it fails: Peer review catches human error in playbook content, but the outage arose from executing the wrong playbook against a device model, not from flawed code. Review would not detect a runtime mismatch between playbook and hardware. It suits governing change quality where mistakes stem from author oversight.

Use a pre-commit hook that checks the playbook syntax and device compatibility

Why it fails: A pre-commit hook runs locally before commit, checking syntax and static compatibility, but the pipeline executes post-merge against live devices. It cannot verify the correct playbook is selected for each device model at deployment time. Pre-commit hooks suit catching formatting and lint errors early in development.

<get>

Why it fails: <get> returns state data and, with an appropriate filter, configuration, but it is not the operation that specifically retrieves running configuration. It is tempting because it is a valid retrieval operation, yet <get-config> with a running source is the precise choice for reading configuration.

<copy-config>

Why it fails: NETCONF's <copy-config> writes a complete configuration datastore to a target, replacing its contents wholesale; it cannot read the running configuration. It is tempting because it does move configuration data, and would be correct when pushing a saved configuration onto a device or restoring a datastore.

<edit-config>

Why it fails: <edit-config> writes configuration changes to the datastore; it retrieves nothing. It is tempting because it is the core NETCONF configuration operation, and it would be correct when pushing or merging a candidate configuration, but reading the running configuration requires a retrieval operation instead.

The pipeline script has a typo in the inventory path

Why it fails: A typo would fail consistently from the first run, not appear only after a commit. The tempting appeal is that path errors do produce missing-file messages, but the trigger here is the commit itself, which points to the inventory file being untracked or excluded by .gitignore rather than a mistyped path.

The Ansible version in the pipeline is incompatible

Why it fails: An incompatible Ansible version produces module or syntax errors, not a missing inventory file. Version pinning is genuinely relevant when playbooks use newer module parameters, but the reported symptom is a file-resolution failure, so the version axis cannot explain it.

The staging environment is not reachable

Why it fails: Unreachable staging hosts cause connection timeouts or SSH failures, not a missing inventory file, which Ansible resolves locally before contacting devices. Reachability checks belong in a separate pipeline stage; the stem's error occurs earlier, at inventory parsing.

Plain text headers

Why it fails: HTTP/2 compresses header fields with HPACK, transmitting them in binary form; plain text headers are an HTTP/1.1 trait. It tempts because HTTP/1.1 headers are human-readable ASCII, and developers debugging with curl still see decoded text, but that readability is lost on the wire under HTTP/2.

Persistent connections

Why it fails: Persistent connections already existed in HTTP/1.1 via keep-alive, so they are not a distinguishing HTTP/2 feature; HTTP/2 instead multiplexes many streams over one connection. It tempts because HTTP/2 does use a single long-lived connection, but that reuse is inherited rather than new.

Webhooks require OAuth 2.0 client credentials grant for security.

Why it fails: Webex webhooks authenticate via a shared secret or signature verification, not the OAuth 2.0 client credentials grant, which secures server-to-server API calls rather than inbound event delivery. It tempts because client credentials genuinely suit machine-to-machine integrations that call Webex APIs directly.

Webhooks use long polling to receive events.

Why it fails: Webhooks deliver events by HTTP POST callbacks to a registered target URL, not by long polling. It tempts because long polling is a real Webex API technique for receiving events, but that mechanism belongs to the events API, not to webhooks.

IPv6 addresses are 32 bits in length.

Why it fails: IPv6 addresses are 128 bits.

IPv6 uses ARP to resolve MAC addresses.

Why it fails: IPv6 uses Neighbor Discovery Protocol (NDP) instead of ARP.

The API endpoint requires a different HTTP method (e.g., POST vs GET).

Why it fails: A wrong HTTP method yields 405 Method Not Allowed, not 401, which specifically signals failed authentication. Method selection would be the answer if the stem reported 405 or 404 responses instead of an authentication failure.

The script is using an incorrect API version path (e.g., /v2 instead of /v1).

Why it fails: An incorrect API version path returns 404 Not Found, since the router cannot match the URI; authentication is never evaluated. Version-path errors would explain a 404, whereas the stem's 401 points to credential or token rejection.

CORS (Cross-Origin Resource Sharing) is blocking the request.

Why it fails: CORS is a browser-enforced policy governing cross-origin fetch requests; a server-side Python script using requests is not subject to it, so it cannot produce a 401. CORS configuration would matter for a JavaScript client calling DNA Center from a different web origin.

Error because PATCH is not allowed on interfaces

Why it fails: PATCH is allowed.

No change, remains as previously configured

Why it fails: PATCH applies the payload.

Administratively up and protocol up

Why it fails: Enabled false means administratively down.

Basic authentication with username/password

Why it fails: Webex does not authenticate bots with username and password Basic credentials; that scheme suits legacy human-facing endpoints. It is tempting because Basic auth is a familiar HTTP mechanism. Bots require an OAuth 2.0 bearer token issued for the bot identity, presented in the Authorization header.

Session ID cookie

Why it fails: Webex APIs are stateless and issue no session cookie for bot authentication; a cookie cannot be obtained or reused by a server-side bot. It is tempting because session cookies authenticate browser users. Bots must present an OAuth 2.0 bearer access token in the Authorization header on each request.

API key in query string

Why it fails: Webex APIs do not accept API keys passed in query strings; credentials in URLs leak into logs, proxies, and browser history. It is tempting because query-string keys appear in some REST APIs. Webex bots authenticate with a bot access token obtained via OAuth 2.0, sent in the Authorization header.

Change the API endpoint to a different region

Why it fails: A 429 signals rate limiting, so switching regions leaves the request volume against the same organisation's limits unchanged. Regional endpoints exist for data residency and latency, and would be the right answer if the script targeted the wrong geographic cluster. Retrying with exponential backoff and honouring the Retry-After header addresses the actual cause.

Check the API token

Why it fails: A 429 signals rate limiting, not authentication, so the token is irrelevant here; the script must back off and retry after the Retry-After interval. Checking the token is tempting because invalid or expired credentials commonly cause failures, and that check would be right for a 401 response instead.

Increase the rate limit on the dashboard

Why it fails: Meraki rate limits are fixed per organisation and cannot be raised from the dashboard, so this action is impossible. The 429 signals the script exceeded the API's call quota, requiring retry with backoff. Dashboard settings do control per-SSID bandwidth limits and traffic shaping, which is a different feature entirely.

GET /dataservice/device/monitor

Why it fails: The /dataservice/device/monitor endpoint returns real-time monitoring statistics such as CPU and tunnel health, not the inventory attributes (site ID, IP address) requested. It is tempting because it sounds like the monitoring endpoint, and it would be correct for retrieving live interface or control-connection counters rather than device inventory.

GET /dataservice/device/device

Why it fails: The /dataservice/device/device endpoint returns device inventory, but it does not expose the site ID attribute, which lives in the vManage device-to-site mapping. It is tempting because it lists devices and their IP addresses, and would be correct when you need hardware, model, or reachability details without site context.

GET /dataservice/device/overlay

Why it fails: GET /dataservice/device/overlay returns overlay tunnel information, not a device inventory with site IDs and IP addresses. It is tempting because overlay monitoring is the stated goal, and this endpoint would be correct when tunnel status and health, rather than device details, are required.

PUT /dna/intent/api/v1/site

Why it fails: PUT replaces an existing resource and requires a site identifier; it cannot create a new site, so the request fails. It is tempting because PUT is used to update site, building or floor attributes once the site already exists and its ID is known.

GET /dna/intent/api/v1/site

Why it fails: GET retrieves site data and cannot create a site, so it fails the creation requirement. It is tempting because GET /dna/intent/api/v1/site is the correct call when the engineer needs to list or read existing sites, buildings and floors rather than add new ones.

POST /dna/intent/api/v1/site/create

Why it fails: The DNA Center site creation endpoint is POST /dna/intent/api/v1/site, not /site/create; the extra path segment does not exist and returns 404. It is tempting because appending an action verb to a resource path feels intuitive, and such verb-style endpoints do appear elsewhere in the API.

RESTCONF events

Why it fails: RESTCONF events are HTTP-based notifications, not gRPC streams, so they cannot deliver the required gRPC telemetry. It is tempting because RESTCONF also pushes YANG-modeled data, and would be correct for an HTTP webhook or notification receiver rather than a gRPC collector.

NETCONF subscription

Why it fails: NETCONF subscription is a separate YANG-based mechanism, not a gRPC service model, so it cannot satisfy a gRPC streaming requirement. It is tempting because NETCONF also supports event notifications, and would be correct if the collector subscribed over NETCONF rather than gRPC.

Dial-in model

Why it fails: Dial-in describes a collector connecting to the router, which reverses the required direction; gRPC telemetry uses dial-out, where the router initiates the session and pushes data to the collector. Dial-in is tempting because it matches traditional SNMP polling, where the management station queries the device.