Which Command Should the Administrator Use Practice Questions

Authentication token is missing.

Why it fails: A missing authentication token yields 401 Unauthorized, not 409 Conflict. It is tempting because authentication failures are common RESTCONF issues, and it would be correct when credentials are absent or expired, but 409 signals a resource-state conflict such as a duplicate or concurrent edit.

The resource does not exist.

Why it fails: A missing resource yields 404 Not Found, because the URI path resolves to no existing target. It tempts because developers frequently hit absent paths when first testing RESTCONF, but that condition is reported as 404. A 409 Conflict instead signals a state clash, such as a duplicate create or a lock violation.

The request contains invalid data types.

Why it fails: Invalid data types produce a 400 Bad Request, since the server rejects malformed or wrongly typed payload values during schema validation. It tempts because YANG type mismatches are a common RESTCONF error, but they map to 400, not 409. A 409 arises from a state conflict, such as creating a resource that already exists.

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.

1. Configure Router ID (router-id [id]). 2. Enable OSPF routing process (router ospf [process-id]). 3. Advertise networks (network [network] [wildcard] area [area]).

Why it fails: This is incorrect because you cannot configure a router ID without first enabling the OSPF process; the router-id command is entered in OSPF router configuration mode, which requires the process to be active.

1. Enable OSPF routing process (router ospf [process-id]). 2. Advertise networks (network [network] [wildcard] area [area]). 3. Configure Router ID (router-id [id]).

Why it fails: This is incorrect because although technically you can set the router ID after network statements, best practice and the standard order in Cisco documentation is to configure the router ID before network statements to ensure a stable router ID during neighbor formation.

1. Advertise networks (network [network] [wildcard] area [area]). 2. Enable OSPF routing process (router ospf [process-id]). 3. Configure Router ID (router-id [id]).

Why it fails: This is incorrect because you cannot advertise networks or configure a router ID before the OSPF process is enabled; network statements are entered in router configuration mode, which only exists after the process is started.

ios_ip_interface

Why it fails: No such module exists in the Cisco IOS collection, so the task fails at parse time. The name resembles the real ios_l3_interface module, which is what actually sets IPv4 addresses on IOS XE interfaces; the plausible-sounding naming is the only reason it tempts.

ios_command

Why it fails: ios_command runs show commands and returns their output; it cannot change device configuration, so it cannot set an interface IP address. It is tempting because it is the module for gathering facts or verifying state after changes, and would be correct for a read-only task such as confirming the address took effect.

ios_facts

Why it fails: ios_facts only gathers read-only device information such as interfaces, hardware and configuration state; it cannot modify an interface. Configuring an IP address requires a declarative configuration module, typically ios_l3_interfaces. Gathering facts would be the right choice when auditing existing device state before generating configuration.

Northbound interface

Why it fails: NETCONF sits between the SDN controller and managed devices, so it is a southbound protocol; the northbound interface instead exposes controller capabilities to applications via REST APIs. It is tempting because the developer's script calls a REST API, which is itself a northbound construct, but that describes the script, not NETCONF.

Application layer

Why it fails: The application layer hosts the orchestrating scripts and business logic that call the controller; NETCONF operates below the controller, carrying configuration to devices. It is tempting because the developer writes an application, yet the question asks which layer the protocol itself occupies, not where the script runs.

Control layer

Why it fails: The control layer contains the SDN controller's decision logic and maintains network state; NETCONF is the southbound protocol the controller uses to push configuration to devices, not the control layer itself. It is tempting because NETCONF traffic terminates at the controller, blurring the boundary between protocol and controller function.

docker inspect web

Why it fails: docker inspect shows detailed configuration but not necessarily the logs of why the container exited.

docker exec -it web bash

Why it fails: docker exec cannot be used on a stopped container.

The request fails because the interface already exists.

Why it fails: PUT is idempotent; it can replace existing resources.

The request creates a new interface with the same configuration.

Why it fails: PUT targets a specific resource; it does not create a new one if the URI identifies an existing resource.

The request fails because the JSON is malformed.

Why it fails: The JSON is valid.

Layer 1 (Physical)

Why it fails: Tagging modifies the Ethernet frame header, a Layer 2 construct, whereas Layer 1 carries only raw bits and signalling without frame fields. It tempts because VLANs map to physical switch ports, but the port's membership is logical, and the tag is added at the data-link layer.

Layer 3 (Network)

Why it fails: VLAN tags sit in the Ethernet frame header, which is Layer 2, so Layer 3 never encapsulates them; routing between VLANs is where Layer 3 applies. It tempts because IP addressing is commonly associated with VLAN subnets, but tagging itself is switched, not routed.

Layer 4 (Transport)

Why it fails: VLAN tags are inserted into the Layer 2 Ethernet frame, not into TCP or UDP headers, so Layer 4 plays no part in tagging. It tempts because transport-layer ports are often filtered per VLAN, yet that is policy applied to traffic, not the tagging mechanism itself.

The device requires authentication via SSH keys but password was used.

Why it fails: SSH key versus password authentication is settled during the SSH handshake; since that connection succeeded, credentials are not the cause of the missing capability exchange. Key-based authentication is the correct choice when password logins are disabled by policy.

The firewall is blocking port 830.

Why it fails: Port 830 carries NETCONF over SSH, but the stem states the SSH connection succeeded, so the firewall is not blocking the session. Firewall rules on port 830 are the correct focus when the TCP connection itself cannot be established.

The device is running an older IOS version that does not support NETCONF.

Why it fails: IOS XE releases that support NETCONF are widely deployed, and the SSH transport already succeeded, so an unsupported version would not explain the missing capability exchange. Version checks are relevant when SSH itself fails or the NETCONF subsystem is absent from the image.

No authentication

Why it fails: RESTCONF runs over HTTPS and requires credentials; unauthenticated requests to a CSR1000v return 401. The sandbox still enforces AAA. No authentication applies only to deliberately open lab endpoints or initial discovery of the RESTCONF root, not configuration pushes.

OAuth2

Why it fails: IOS XE RESTCONF uses HTTP Basic authentication against the local or AAA user database; OAuth2 requires an authorisation server issuing bearer tokens, which the CSR1000v does not provide natively. OAuth2 is correct for controller-based APIs such as Cisco DNA Center, not device-level RESTCONF.

API token only

Why it fails: RESTCONF on IOS XE authenticates each request with HTTP Basic credentials (username and password), not a bearer token; there is no token-issuing endpoint. API tokens fit platforms such as Meraki or DNA Center, where a token is issued and presented in a header.

People API

Why it fails: The People API manages user identities and profiles, exposing no subscription mechanism for room activity, so it cannot deliver message events. It is tempting because administrators often begin integration work by resolving people and memberships, and it would be the right resource for looking up a user's details or listing room members.

Messages API

Why it fails: The Messages API creates, lists and deletes messages; it returns data only when polled, so it cannot push real-time notifications. It is tempting because it is the resource that actually handles room messages, and it would be correct for sending a message or retrieving a room's message history.

Rooms API

Why it fails: The Rooms API manages room metadata such as titles and membership, not event delivery. It tempts because rooms are where messages appear, but real-time notifications require registering a webhook via the Webhooks API, which pushes message-created events to a target URL.

The server is unavailable due to maintenance

Why it fails: A 404 means the server received the request but found no matching resource at that URI; maintenance typically yields 503 Service Unavailable. It is tempting because an unreachable or downed server can surface as a client-side failure, but that scenario produces connection errors or 5xx responses, not 404.

The server encountered an internal error

Why it fails: A 500-class status signals server-side failure processing a valid request, whereas 404 indicates the requested resource was not found. It is tempting because both are server-generated responses, but internal errors map to 500 Internal Server Error, so this misattributes the cause.

The client lacks proper authentication

Why it fails: Missing or invalid credentials produce 401 Unauthorized (or 403 Forbidden when authenticated but not permitted), not 404. It is tempting because authentication failures block access to resources, but the server has already located the endpoint; 404 specifically means the URI or resource does not exist.

Configure the routers to use SSH version 1 only.

Why it fails: IOS XE 17.x supports SSH version 2 only, so forcing version 1 breaks connectivity entirely rather than fixing timeouts. Version 1 is relevant only for legacy devices that cannot negotiate version 2; here the intermittent timeout points to SSH session limits or control-persistence settings instead.

Set the 'host_key_checking' option to False in ansible.cfg.

Why it fails: Disabling host_key_checking suppresses SSH host key verification failures; it does not address the intermittent connection timeout, which occurs after authentication. It is tempting as a quick fix for key mismatch errors, and would be correct if the playbook failed with a host key verification warning rather than a timeout.

Use the 'ios_command' module instead of 'ios_config' to perform the tasks.

Why it fails: The ios_command module only issues show commands and returns their output; it cannot push configuration changes, so it fails the playbook's configuration task entirely. It is tempting because it shares the same SSH connection plugin, but the timeout stems from the connection layer, not the module choice.

The network firewall is blocking the request; check firewall logs and allow outbound traffic to the Meraki API.

Why it fails: Incorrect. Other endpoints work, so network connectivity is not the issue.

The request should use POST instead of GET; change the HTTP method to POST to retrieve device data.

Why it fails: Incorrect. The endpoint is defined as GET; using POST would likely return a 405 Method Not Allowed.

The API endpoint URL is incorrect; verify the exact path and version in the API documentation.

Why it fails: Incorrect. A wrong endpoint would typically return a 404, not 403. Also, the path is confirmed correct.

1. Enter global configuration mode, 2. Assign switch ports to the VLAN using 'switchport access vlan', 3. Create the VLAN using the 'vlan' command, 4. Exit and verify.

Why it fails: This is incorrect because you cannot assign ports to a VLAN that has not yet been created. The VLAN must be created first.

1. Enter global configuration mode, 2. Create the VLAN using the 'vlan' command, 3. Exit and verify, 4. Assign switch ports to the VLAN.

Why it fails: This is incorrect because you must assign ports to the VLAN before exiting configuration mode; otherwise, the port assignment step is missed and the VLAN will have no ports.

1. Create the VLAN using the 'vlan' command, 2. Enter global configuration mode, 3. Assign switch ports to the VLAN, 4. Exit and verify.

Why it fails: This is incorrect because the 'vlan' command can only be issued in global configuration mode. You must enter global configuration mode before creating the VLAN.