Drag and Drop Matching Questions

GET - Retrieve a resource

GET is the proper HTTP method for retrieving a resource because it is defined as safe and idempotent, meaning it produces no side effects on the server and can be repeated safely. The request is sent without a body, and the server returns the current state of the resource identified by the URI. GET responses are cacheable, which is essential for efficient network operations. This aligns with the REST architectural constraint of using standardized methods for their intended semantic purpose.

DNS: Translates domain names to IP addresses

The Domain Name System acts as the internet's distributed directory, mapping human-readable fully qualified domain names like www.example.com to the numeric IP addresses needed for packet forwarding. Without this lookup, users would have to memorize and manually enter raw IPv4 or IPv6 addresses, which is impractical. DNS uses hierarchical caching servers to resolve names rapidly and efficiently.

GET - Retrieve data

GET is an HTTP method that requests a representation of the specified resource without modifying server state. It is both safe and idempotent, meaning repeated identical GET requests yield the same result and cause no side effects. In REST APIs, GET is the standard operation for read-only retrieval, typically returning a 200 OK response with the resource body.

STP prevents loops, VTP manages VLANs, EtherChannel aggregates links, Port Security restricts MAC addresses, DTP negotiates trunks, and Rapid PVST+ provides fast per-VLAN convergence.

This option correctly aligns each switching feature with its documented Cisco IOS purpose: STP runs the 802.1D algorithm to block redundant ports and prevent Layer 2 loops; VTP propagates VLAN configuration changes across a domain; EtherChannel bundles multiple physical links into a single logical link to increase bandwidth; Port Security restricts ingress traffic to configured MAC addresses; DTP negotiates trunking mode between Cisco switches; and Rapid PVST+ runs an RSTP instance per VLAN, enabling fast convergence after a topology change.

Level 0 – Emergency: System is unusable

Syslog severity Level 0 (Emergency) is the highest and most critical severity, indicating that the system is completely unusable and cannot perform any functions. In Cisco IOS, this level is reserved for catastrophic events such as a kernel panic, total loss of a routing process, or a hardware failure that halts operation entirely. Because it represents a total failure, messages at this level are typically broadcast to all logging destinations and require immediate human intervention to restore functionality.

Level 1 – Alert: Immediate action needed

Level 1 (Alert) is the second-highest severity, right below Emergency, and it indicates a condition that requires immediate action, such as a critical process repeatedly failing or a security breach that could disrupt operations. However, the description in the question, "System is unusable," belongs exclusively to Level 0, not to Level 1. The system may still be operational at Level 1, albeit in a degraded or dangerous state, so this option does not match the stated severity definition.

Level 2 – Critical: Critical conditions

Level 2 (Critical) indicates severe conditions that need immediate notice, such as a backup process failure, a hardware component warning, or a routing protocol adjacency loss, but the system itself may still be functional. The description "Immediate action needed" actually belongs to Level 1 (Alert), not Level 2. Since the question's description is for Emergency (Level 0), choosing Critical is incorrect; Critical is less severe than Alert and far less severe than Emergency.

Level 3 – Error: Error conditions

Level 3 (Error) is used for error conditions that indicate a problem within the system, such as a failed configuration command, a packet drop due to a missing route, or a duplicate IP address detected on an interface. These errors may affect normal operation but they do not render the system unusable and they are not considered "critical conditions" in the syslog hierarchy. The description "Critical conditions" specifically corresponds to Level 2, so this option is incorrect because it misidentifies the severity level.

Access port: Carries traffic for a single VLAN, configured with switchport mode access.

An access port belongs to exactly one VLAN, called the access VLAN, and sends frames without an 802.1Q tag toward the connected end device. The command switchport mode access explicitly forces the interface to operate as a single-VLAN port, overriding any dynamic trunk negotiation (DTP). This is the standard configuration for connecting PCs, printers, and other hosts that expect untagged traffic.

Trunk port: Carries traffic for multiple VLANs, configured with switchport mode trunk.

A trunk port multiplexes frames from multiple VLANs over a single link, inserting an 802.1Q tag that carries the VLAN ID. By default, a trunk carries all VLANs unless an allowed list restricts it, and the switchport mode trunk command disables DTP negotiation and explicitly forces trunking. Trunks are typically used between switches or to routers with subinterfaces (router-on-a-stick).

Connected routes: AD 0, directly connected networks

Connected routes are automatically injected into the routing table whenever an interface is configured with an IP address and is in the up/up state. Their administrative distance is 0, the lowest possible value, which means they are always preferred over static, EIGRP, OSPF, or any other route source for the same destination network. Because the network is directly attached to the router, no next-hop or dynamic protocol is needed, making this the correct answer to the question.

Static routes: AD 1, manually configured by an administrator

Static routes are indeed manually configured by an administrator and have a default administrative distance of 1. While this is extremely low and makes static routes highly trusted, it is not 0, so static routes are never preferred over directly connected routes if both exist for the same prefix. The question specifically asks for the route type with AD 0, which points to connected routes rather than static routes.

EIGRP internal routes: AD 90, used for routing within the same autonomous system

EIGRP internal routes for the same autonomous system have a default administrative distance of 90, which is lower than OSPF but still higher than both connected (0) and static (1) routes. This means an EIGRP-learned route will only be installed in the routing table if no connected or static route exists to that destination. Since the question requires an AD of 0, EIGRP internal routes cannot be the correct answer.

OSPF routes: AD 110, used for routing within the same autonomous system

OSPF routes within the same autonomous system use a default administrative distance of 110, making them less preferred than EIGRP internal routes (90), static routes (1), and especially connected routes (0). An OSPF route would be selected only when no lower-AD route is available for the same network. The AD of 110 clearly does not match the AD of 0 referenced in the correct option, so OSPF is not the answer.

SSH: Provides secure remote access to network devices using encryption, typically on TCP port 22.

SSH (Secure Shell) is the correct protocol for secure remote administration because it encrypts both authentication and session data, protecting credentials and commands from interception. It operates over TCP port 22 by default, using cryptographic algorithms like AES and key exchange methods such as Diffie-Hellman. Unlike Telnet or HTTP, SSH provides integrity verification and resistance to eavesdropping, man-in-the-middle, and session hijacking attacks, making it the standard for managing network devices such as routers and switches securely.

switchport mode trunk: Configures a trunk port

The Cisco IOS command 'switchport mode trunk', executed in interface configuration mode, forcibly sets the access port to act as an 802.1Q trunk. This enables the port to carry frames for multiple VLANs, each tagged with its VLAN ID, and stops DTP negotiation to establish the trunk unconditionally. It is a common configuration when connecting switches or to a router, ensuring that VLAN traffic is not limited to a single VLAN like an access port.

show vlan brief: Lists VLAN assignments

The privileged EXEC command 'show vlan brief' provides a concise table of all VLANs on the switch, listing their IDs, names, status, and the access ports assigned to each VLAN. It does not show trunk ports or tagging details, making it useful for verifying VLAN creation and port assignments after configuration. This command is often the first step in troubleshooting VLAN membership issues, as it offers a quick snapshot of the VLAN database.

inter-VLAN routing: Enables communication between VLANs typically using a router or Layer 3 switch

Inter-VLAN routing is the process of forwarding packets between different VLANs using a Layer 3 device such as a router or a multilayer switch. Because VLANs isolate broadcast domains, devices in different VLANs cannot communicate without this routing, which requires logical interfaces (subinterfaces or SVIs) and appropriate IP addressing. It is a fundamental concept that enables networks to combine segmentation with connectivity, but it is not a single switch configuration command.

YANG: Data modeling language used to define configuration and state data structures

YANG (RFC 7950) is a data modeling language that describes the structure, constraints, and semantics of configuration and state data in a hierarchical tree. It is transport-agnostic and acts as the schema foundation for both NETCONF (XML) and RESTCONF (JSON), enabling interoperable data exchange between network devices and controllers through standardized models like ietf-interfaces.

NETCONF: Protocol using XML over SSH for configuration management and transactional operations

NETCONF is a network management protocol that encodes RPCs in XML and typically runs over SSH (transport port 830), enabling secure, transactional configuration changes across entire devices. It distinguishes between several datastores (candidate, running, startup), uses a <commit> operation to apply candidate configurations, and supports subscriptions, locking, and an extensible set of operations—making it far more robust than SNMP for day-2 operations.

RESTCONF: RESTful API using HTTP methods (GET, PUT, POST, DELETE) over HTTPS

RESTCONF is a RESTful protocol defined in RFC 8040 that uses HTTP methods (GET, PUT, POST, DELETE) over HTTPS to access YANG-defined data on network devices. It supports both JSON and XML encoding, and relies on the Uniform Resource Locator (URL) path to identify resources, making it a lightweight, stateless alternative to NETCONF for programmatic configuration and state retrieval.

NETCONF <edit-config>: Operation to modify configuration with options like merge, replace, create, delete

The NETCONF <edit-config> operation is a core RPC defined in RFC 6241 that allows a client to change the target configuration datastore (candidate or running) by specifying a set of operations: merge, replace, create, delete, and remove. It uses the 'operation' attribute to control how each data node is applied, and supports options like 'error-option' and 'test-option'—giving network engineers fine-grained transactional control over configuration updates.

RESTCONF PATCH: HTTP method used for partial updates to a resource

The RESTCONF PATCH method, defined in RFC 8040, applies a partial update to a target resource using the media type 'application/yang-data+json' (or XML). Unlike PUT, which replaces the entire resource, PATCH modifies only the fields specified in the request body, preserving all other existing data—ideal for incremental configuration changes in network automation workflows.

GET retrieves data, POST creates new resources, PUT updates/replaces, PATCH partially updates, DELETE removes, and OPTIONS queries available methods.

This is correct because it accurately describes the standard REST API methods and their actions in network automation workflows. GET is used to retrieve configuration or status data, POST to create new resources like interfaces or VLANs, PUT to replace entire resources, PATCH to apply partial updates, DELETE to remove resources, and OPTIONS to discover supported methods.

Unicast: one-to-one communication

Unicast delivers a single packet stream from one source host to one specific destination host, addressed by a unique IPv4 address. It is the fundamental model for client-server and peer-to-peer exchanges such as HTTP requests, where each receiver gets its own copy. Because the destination is a single interface, routers forward using the longest-prefix match to that precise address.

NetFlow - Flow analysis; SNMP - Device management; Syslog - Logging; IP SLA - Performance measurement; SPAN - Local traffic mirroring; RSPAN - Remote traffic mirroring

Ly matches each technology to its primary purpose as defined in Cisco networking: NetFlow analyzes traffic flows, SNMP manages devices, Syslog provides logging, IP SLA measures performance, SPAN mirrors traffic locally, and RSPAN mirrors traffic remotely.

GET - Retrieve, POST - Create, PUT - Replace, PATCH - Partial Modify, DELETE - Remove, HEAD - Headers only

GET is a safe, read-only method used to retrieve a representation of a resource, while POST is the standard method for creating a new resource under a given URI. PUT replaces the entire target resource with the request payload, whereas PATCH applies a partial modification, and DELETE removes the resource entirely. HEAD is identical to GET but returns only response headers, no body.

Application-facing interface to the controller

This is the correct match for a Northbound API. A northbound API is the programmatic interface exposed by an SDN controller to applications, orchestration platforms, or business logic, allowing them to request network services, retrieve telemetry, and configure policies without low-level device details. Because it faces the application layer, 'Application-facing interface to the controller' precisely captures its role.

Controller-facing interface toward managed infrastructure

This is the correct match for a Southbound API. The southbound API is used by the SDN controller to communicate with the managed network infrastructure, such as switches, routers, and wireless access points, using protocols like OpenFlow, NETCONF, or SNMP. The phrase 'Controller-facing interface toward managed infrastructure' accurately describes this downward communication path from the controller to devices.

Structured data format

This is the correct match for JSON (JavaScript Object Notation). JSON is a text-based, structured data format that represents objects as collections of key-value pairs and arrays, making it ideal for exchanging data between REST API clients and servers. Its structure is human-readable while still being easily parsed by programming languages, so 'Structured data format' is the right definition.

Secure transport for API communication

This is the correct match for HTTPS (Hypertext Transfer Protocol Secure). HTTPS encapsulates HTTP traffic within a TLS (Transport Layer Security) session, providing confidentiality, integrity, and authentication for REST API requests and responses over the network. Because it secures the transport channel, the description 'Secure transport for API communication' directly aligns with HTTPS.

Authentication: The process of verifying the identity of a user or device.

Authentication is the initial security step that validates a user's or device's stated identity through provided credentials such as passwords, cryptographic keys, or biometric factors. Unlike identification, which merely asserts who the user is, authentication verifies the claim to establish trust before access decisions can be made. This is the first A in the AAA framework (Authentication, Authorization, Accounting) and is required before authorization or accounting can occur.

Infrastructure as Code: Managing infrastructure through machine-readable definition files

Infrastructure as Code means managing and provisioning infrastructure through machine-readable definition files rather than manual, ad-hoc configuration. Ansible exemplifies this by using agentless YAML playbooks over SSH or WinRM to encode the desired state, allowing versioning, peer review, and automated, repeatable deployments that treat infrastructure like software code.

Idempotence: Repeated operations produce the same result

Idempotence is the property that repeating the same operation produces the same result, so configuration management does not alter a system that already conforms to the desired state. Chef recipes, authored in Ruby DSL rather than YAML, are carefully written to be idempotent, ensuring that re-running them on a node neither duplicates resources nor causes drift from the intended configuration.

Declarative model: Desired state is defined, system achieves it automatically

The declarative model focuses on defining the desired end state of a system, leaving the system itself to determine and execute the steps needed to reach that state. Puppet uses its own declarative DSL for manifests, where administrators specify what packages, services, and files should look like, and the Puppet agent automates the convergence without the user scripting the exact sequence of commands.

Imperative model: Step-by-step instructions to achieve desired state

The imperative model requires the user to explicitly script step-by-step instructions that the system must execute in order to achieve a desired state, granting the system little to no autonomy over the sequence of operations. SaltStack often embodies this model in its master-minion architecture, where the master sends specific commands for minions to run, and even though SaltStack can operate agentless, the imperative approach still demands that the operator dictates the exact commands and their order, not just the outcome.

Idempotent: An operation that can be applied multiple times without changing the result beyond the initial application.

An idempotent operation produces the same final state whether it is applied once or many times; for example, setting a hostname to 'R1' is idempotent, but adding a duplicate network route may not be unless the module checks for existence first. This property gives network automation tools the ability to re-run configs safely without causing errors or configuration drift. The description accurately reflects that repeated applications do not alter the result beyond the initial application.

Declarative: A style where the desired state is defined, and the system determines the steps to achieve it.

Declarative automation lets you specify the desired end state (e.g., 'ensure interface GigabitEthernet0/1 is configured with IP 192.168.1.1/24') without dictating the commands to get there. The tool compares the current state to the desired state and determines the necessary actions, such as Terraform or Ansible's 'state=present' modules. This directly matches the description of defining the desired state while the system chooses the steps.

Imperative: A style where explicit step-by-step instructions are given to achieve a desired state.

Imperative automation is like a procedural script that executes a fixed sequence of commands in a specific order, such as a Python script using Netmiko to push a series of CLI commands to a router. The system does not infer the goal; it simply follows the explicit, step-by-step instructions exactly as written. This aligns with the description of giving explicit steps to achieve a desired state, which is the defining characteristic of imperative automation.

Orchestration: The automated coordination and management of multiple systems or services to achieve a workflow.

Orchestration goes beyond a single automated task by coordinating multiple systems, services, and workflows into a cohesive process, often with dependency sequencing, retries, and error handling. Tools like Kubernetes coordinate containers, or Ansible Tower/AWX manage multi-tier application deployments across servers. The description captures this cross-system coordination and management, which is the essence of orchestration.

Storm Control: Limits excessive broadcast, multicast, or unicast traffic to prevent network storms.

Storm Control operates on a switch port by tracking the ingress rate of broadcast, multicast, or unicast frames and comparing it against a user-defined rising threshold. When the traffic rate exceeds that threshold, the switch drops excess frames or optionally disables the port until a falling threshold is reached. This prevents broadcast storms from consuming excessive bandwidth and CPU resources, thereby maintaining network stability. As a result, Storm Control directly limits excessive traffic of these types, making this the correct description.

IPv6 address: 128-bit identifier for network interfaces

An IPv6 address is a 128-bit binary value, usually written as eight groups of four hexadecimal digits separated by colons, that uniquely identifies a network interface on a global or local scale. The larger address space eliminates the scarcity issues of IPv4 and supports hierarchical addressing, with the first 64 bits typically representing the network prefix and the last 64 bits representing the interface identifier. This structure enables efficient routing, automatic address configuration, and built-in support for features like multicast and anycast.

Global unicast address: Publicly routable IPv6 address similar to public IPv4

Global unicast addresses are assigned from the 2000::/3 range and are globally unique and routable across the public Internet, analogous to public IPv4 addresses. They are structured with a global routing prefix, a subnet ID, and an interface ID, allowing for hierarchical aggregation and efficient routing by ISPs. These addresses are typically allocated by ISPs or regional registries and can be used for direct end-to-end communication without NAT.

Link-local address: Automatically assigned address used for communication within a single network segment

Link-local addresses are automatically configured on every IPv6-enabled interface using the FE80::/10 prefix, typically derived from the interface's MAC address via EUI-64 or randomly generated. They are only valid on the local link and are never forwarded by routers, so they facilitate neighbor discovery, address autoconfiguration, and on-link communication without requiring global configuration. Because they are self-generated and always available, they enable essential link-layer operations even before a global or unique local address is assigned.

Unique local address: Private IPv6 address analogous to RFC 1918 IPv4 addresses

Unique local addresses (ULAs) are defined in RFC 4193 and use the FC00::/7 prefix, with the first 8 bits set to 11111101 (FD00::/8) for locally assigned addresses, making them private and not routable on the public Internet. They include a 40-bit randomly generated global ID to minimize collision risk when networks merge, providing an IPv6 counterpart to RFC 1918 private IPv4 addresses. These addresses are designed for internal network communication, such as within an organization, and can be used for services like DNS and internal servers without requiring public address space.