Refer to the Exhibit Practice Questions

GET /dna/intent/api/v1/issues

Why it fails: The issues endpoint returns assurance problems and their details, not topology links, so no VLAN adjacency can be derived. It is tempting because issues reference affected devices and VLANs, making it the right call when you want to list open faults, their severity, or the categories of network health problems.

GET /dna/intent/api/v1/site

Why it fails: The site endpoint returns site hierarchy and building/floor metadata, not Layer 2 links, so it cannot map VLAN adjacencies. It is tempting because sites group devices geographically and are the correct choice when you need to enumerate locations, assign devices to a site, or query site health rather than topology.

GET /dna/intent/api/v1/network-device

Why it fails: The network-device endpoint returns device inventory records, not topology links, so it cannot supply per-VLAN Layer 2 adjacency. It is tempting because it lists every managed device and their interfaces, which is the right call when you need hostnames, management IPs, software versions or reachability status rather than connection data.

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.

Multiple links with VSS

Why it fails: VSS is proprietary and not standard for leaf-spine.

Single link with LACP

Why it fails: LACP bundles ports but still single logical link.

Single link with STP

Why it fails: STP blocks redundant links, reducing bandwidth.

"serial": "Q2XX-XXXX-XXXX"

Why it fails: The serial key identifies the physical access point but carries no connectivity state, so it cannot indicate cloud reachability. It is tempting because serial numbers are used to claim devices into a dashboard network or to match inventory records, which is the correct choice when onboarding hardware or correlating a device with its licence.

"lanIp": "192.168.1.100"

Why it fails: lanIp reports the device's local network address, not its cloud connectivity state. It is tempting because it appears in the same status payload as connectivity fields, but the cloud link is indicated by a separate status attribute, so this pair cannot confirm the MR is online.

"model": "MR42"

Why it fails: The model key gives the hardware model (MR42), which says nothing about current cloud reachability; connectivity appears in a status field such as "status": "online". The model is tempting because it describes the device, and would be correct if the question asked which access point type is deployed.

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.

data[0]['softwareVersion']

Why it fails: The DNA Center response wraps devices in a 'response' array, so indexing data directly as a list raises a KeyError or TypeError before reaching any version field. It is tempting because the field name matches the target value, which would work only if the JSON root itself were the device array.

data['response'][0]['version']

Why it fails: The exhibit's device objects expose the value under 'softwareVersion', not 'version', so this key lookup fails despite correct array indexing. It is tempting because 'version' is a common field name in other Cisco API payloads, making the path look structurally right while naming the wrong key.

data['response']['softwareVersion']

Why it fails: 'response' holds a list of devices, so indexing it with the string 'softwareVersion' raises a TypeError; the array element must be selected first. It is tempting because it names the correct container and field, which would work only if the API returned a single device object rather than an array.

The API endpoint is incorrect.

Why it fails: An incorrect endpoint yields HTTP 404 Not Found, whereas the exhibit shows an authorisation-related status. It tempts because mistyped URLs are a frequent developer mistake, but the endpoint clearly resolved and processed the request, so the failure lies in credentials or permissions rather than the path.

The device IP address is already in use.

Why it fails: A duplicate IP would typically return a conflict or validation error, not the authorisation failure shown in the exhibit. It tempts because duplicate device entries are a genuine DNA Center concern, but the response indicates the request was rejected before device state was evaluated, so address reuse is not the cause.

The API token has expired.

Why it fails: An expired token produces HTTP 401 Unauthorised, but the exhibit returns 403 Forbidden, meaning the token authenticated successfully yet lacks the required role or permission. It tempts because token expiry is a common API failure, yet the status code distinguishes authentication failure from authorisation denial.

Increase the number of clients at Branch1.

Why it fails: Adding clients raises load on Branch1's access points and uplinks, which lowers a health score already at 10 rather than improving it. Client count is a capacity input, so this action would suit a scenario where a site is underutilised and needs traffic to justify expansion.

Check the API authentication token.

Why it fails: An authentication token governs whether the API call succeeds at all; a rejected token returns an error, not a healthScore of 10 for Branch1. Token handling is the right focus when requests fail with 401 responses, not when valid data shows poor site health.

Use a different API version.

Why it fails: The API version determines endpoint paths and response schema, not the health value reported for a site. Changing versions is appropriate when fields are missing or the endpoint is deprecated, whereas a returned healthScore of 10 is valid data reflecting genuine network problems.

Enable root guard on the trunk ports

Why it fails: Root guard protects against inferior BPDUs, does not prevent this switch from becoming root.

Enable BPDU guard on the trunk ports

Why it fails: BPDU guard disables ports if BPDU received, not related to root election.

Set the bridge priority to 0

Why it fails: Priority 0 makes it the root.

The device pe1 is unreachable via NETCONF.

Why it fails: Unreachability produces a connection or timeout error during sync, not an out-of-sync result; check-sync reached pe1 and compared configurations successfully. It is tempting because NETCONF failures also block synchronisation, yet out-of-sync specifically reports a configuration mismatch, not a transport failure.

The service model in NSO does not have a configuration for pe1.

Why it fails: Out-of-sync means NSO holds a service configuration for pe1 that differs from what the device reports; a missing configuration would instead show the device as not provisioned or absent from the service. It is tempting because absent config also disrupts service, but check-sync compares existing intended versus actual state.

The device pe1 has a hardware failure.

Why it fails: Out-of-sync means NSO's intended service configuration differs from the device's actual configuration, not that hardware has failed. Hardware faults surface through device alarms or reachability checks. It is tempting because a broken device can also cause sync failures, but check-sync compares configuration state, not physical health.

Every 500 seconds

Why it fails: The exhibit's subscription interval is expressed in centiseconds, so 500 seconds misreads the unit by two orders of magnitude. This would be right if the period field were configured in seconds, which the telemetry schema does not use.

When the management connection is re-established

Why it fails: Re-establishing the management connection is a trigger event, not a subscription cadence; the exhibit specifies a periodic interval for telemetry delivery. This would fit a dial-on-demand or event-driven subscription, where updates flow only when the session state changes.

On-change only

Why it fails: On-change only reports when a monitored value alters, so it cannot express a periodic reporting frequency; the exhibit's interval setting is what defines cadence. It is tempting because on-change subscriptions suit event-driven dashboards where updates should fire only on state transitions, not on a fixed schedule.

The API path is incorrect; verify the endpoint URL.

Why it fails: An incorrect path yields HTTP 404 with a resource-not-found body, while the exhibit indicates the request never authenticated. Verifying the endpoint URL is the right step when the API returns 404 or a routing error, not an authentication failure.

The request body is malformed; check JSON syntax.

Why it fails: A malformed JSON body returns HTTP 400 with a parse error naming the offending token or line, whereas the exhibit shows a 401/403-style authentication failure. JSON validation is the right check when the API rejects a syntactically invalid payload, not when credentials are refused.

The user does not have permission; request admin to grant access.

Why it fails: Permission errors surface as HTTP 403 with an authorisation message, not the credential-rejection status in the exhibit; a valid token lacking a role would show that. Requesting admin access is correct when an authenticated user is denied a specific API operation.

Simpler redundancy with fewer layers.

Why it fails: Leaf-spine delivers predictable any-to-any latency by keeping every leaf one hop from every spine, whereas three-tier aggregation and core layers add hops that vary with path. Fewer layers does reduce complexity, which is why it tempts, but that is a design side-effect, not the low-latency mechanism the scenario asks about.

Easier to deploy with less cabling.

Why it fails: Leaf-spine uses more cabling, not less, since every leaf connects to every spine, so deployment is not simplified. It tempts because fabric topologies can reduce configuration complexity, but the primary advantage here is consistent, predictable any-to-any latency via equal-cost paths, which the three-tier core-aggregation-access hierarchy cannot guarantee.

Reduced number of required switch ports.

Why it fails: Leaf-spine increases port consumption, because full mesh connectivity between every leaf and every spine multiplies uplinks. It tempts because consolidation is a common design goal, but the topology's purpose is bandwidth and latency predictability through equal-cost paths, not port reduction; three-tier designs often use fewer ports.

VLAN 10 will be deleted

Why it fails: The playbook's ios_vlan task uses state: present with a vlan_id and name, which creates or updates the VLAN rather than removing it; deletion needs state: absent. Choosing deletion is tempting because absent is the counterpart state in the same module, and it would be the correct outcome if the task specified state: absent for VLAN 10.

VLAN 10 will be modified to have the name 'voice'

Why it fails: The playbook's task targets the switches group with a configuration that sets the VLAN name, so the change applies to the device configuration rather than modifying an existing VLAN object's name field. Renaming assumes a declarative module such as ios_vlan with a name parameter, which the exhibit does not show.

The playbook will only show the running configuration of VLAN 10

Why it fails: The ios_vlan module applies configuration changes to the device; it does not merely display the running configuration of VLAN 10. Read-only output is tempting because Ansible can gather facts and show commands, and it would be correct if the playbook used ios_command with a show vlan brief command instead of a configuration module.

Cross-site scripting (XSS) via the token.

Why it fails: XSS executes injected script in a victim's browser; it does not defeat an authentication mechanism itself. The exhibit's flaw concerns how credentials or tokens are validated, not output encoding. XSS would be the answer where user input is reflected into HTML without escaping.

Man-in-the-middle attack due to missing HTTPS.

Why it fails: Missing HTTPS permits interception, but the stem attributes the vulnerability to the authentication mechanism, not transport encryption. The exhibit's credential or token handling is the flaw. Man-in-the-middle is the answer when traffic traverses plaintext HTTP and an attacker can intercept or alter it.

SQL injection through the login endpoint.

Why it fails: SQL injection exploits unsanitised database queries, not the authentication logic shown in the exhibit. The audit flags how identity is verified, not query construction. SQL injection would be correct where login input is concatenated directly into a database query without parameterisation.