300-615 DCIT — Cisco Data Center Operations Specialist

Full question text, answer options, and explanations for this practice set — a spoiler-free alternative is the interactive quiz above for scored, shuffled practice.

1. . A network engineer runs 'show vpc consistency-parameters global' on a Nexus 9000 switch and finds a Type-1 inconsistency in the vPC domain. Which statement accurately describes the impact of a Type-1 consistency parameter mismatch?

   • A. A Type-1 inconsistency causes the vPC secondary switch to suspend all vPC member port channels, bringing those interfaces down and stopping traffic on the affected vPC links. Only the primary switch keeps its vPC ports active, but dual-homed hosts lose one uplink.(correct)
   • B. A Type-1 inconsistency logs a warning in the syslog but does not affect vPC operation; the vPC remains active on both switches and all member ports stay up, allowing full traffic forwarding.
   • C. A Type-1 inconsistency causes BOTH switches' vPC member ports to be suspended (err-disabled), completely stopping all vPC traffic until the mismatch is resolved.
   • D. A Type-1 inconsistency only affects BFD sessions between the vPC peers; vPC member ports remain active but BFD keepalives fail, eventually causing a vPC role re-election.

   Explanation: NX-OS vPC consistency checks are classified into two types. Type-1 (global consistency) parameters — such as STP mode, STP region configuration, and vPC domain ID — are parameters that if mismatched would cause traffic forwarding issues; a Type-1 mismatch causes the secondary switch to suspend all of its vPC member port channels, preventing loops and undefined behavior. The primary switch's vPC ports remain active. Type-2 parameters (per-VLAN consistency) — such as allowed VLANs on the peer link, QoS policy — cause the vPC to remain active but the affected VLANs are suspended on the secondary. Administrators must resolve Type-1 mismatches promptly. Options B, C, and D describe incorrect behavior for Type-1 inconsistency.

2. . In a Nexus 9000 vPC deployment, the vPC peer link fails (physical link down) while the vPC peer keepalive link remains operational. Which behavior occurs on the vPC secondary switch for ports that are not 'orphan ports'?

   • A. The secondary switch detects the peer link failure but receives keepalives confirming the primary is still active. The secondary suspends all its vPC member port channels (makes them operationally down) to prevent a split-brain forwarding loop, ensuring only the primary continues forwarding traffic on vPC links.(correct)
   • B. The secondary switch assumes the primary has failed because the peer link is down, promotes itself to primary, and keeps all vPC member ports active — resulting in both switches being active simultaneously and potentially causing a loop.
   • C. The secondary switch converts all vPC member ports to individual non-vPC ports and continues forwarding independently; the vPC domain is dissolved until the peer link is restored.
   • D. Both switches immediately shut down all vPC member ports and revert to individual spanning tree operation (no vPC) until the peer link is restored, minimizing the risk of bridging loops.

   Explanation: When the vPC peer link fails but the keepalive is operational, NX-OS on the secondary switch performs the following logic: the keepalive confirms the primary is alive, so the secondary concludes it is the secondary and the peer link failure is a wiring/physical issue — not a primary failure. To prevent the secondary from forwarding traffic for MAC addresses that the primary would also forward (causing a loop), the secondary suspends its vPC member port channels. Orphan ports (non-vPC ports on the secondary) remain active because they are not part of the dual-active domain. The primary switch continues forwarding on all its vPC and orphan ports normally. This design protects network integrity. Option B describes the dangerous split-brain scenario that keepalive is designed to prevent. Options C and D describe behaviors that do not occur.

3. . A data center engineer is troubleshooting a VXLAN BGP EVPN fabric. A leaf node (leaf-101) cannot communicate with endpoints on leaf-103. The engineer runs 'show nve peers' on leaf-101. The output shows no entries. What does this indicate, and which additional command helps determine if BGP EVPN sessions are established?

   • A. 'show nve peers' showing no entries means leaf-101 has no active VXLAN tunnel peers (VTEPs); the NVE interface may not be up or BGP EVPN has not exchanged VTEP reachability. Run 'show bgp l2vpn evpn summary' to verify BGP EVPN peer states (Established vs Idle/Active) and 'show bgp l2vpn evpn route-type 2' to check if MAC/IP advertisement routes are being received from leaf-103's VTEP.(correct)
   • B. 'show nve peers' showing no entries is normal in a BGP EVPN fabric; NVE peers are not pre-configured and are only populated dynamically when active traffic is flowing; no further troubleshooting is needed.
   • C. 'show nve peers' showing no entries indicates leaf-101's VTEP IP is not in the fabric's multicast group; run 'show ip mroute' to find which multicast group the NVE interface has joined.
   • D. 'show nve peers' showing no entries means the NX-OS license for NV overlay is not installed; run 'show license usage NX_ADVANTAGE' to verify the license before proceeding.

   Explanation: In a VXLAN BGP EVPN fabric, 'show nve peers' displays active VTEP peers — remote leaf nodes with which the local NVE interface has established VXLAN tunnels and exchanged endpoint information. An empty output means no VTEP adjacencies exist, which points to BGP EVPN not being established or the NVE interface not being operational. The troubleshooting sequence: (1) 'show nve interface' to verify NVE interface state (up/up); (2) 'show bgp l2vpn evpn summary' to check BGP EVPN peer establishment (look for 'Established' state, prefixes received); (3) 'show bgp l2vpn evpn route-type 2 0 [mac] [ip]' to verify MAC/IP NLRI routes from remote leaves. Route-type 2 carries MAC+IP bindings; route-type 3 carries VTEP reachability (IMET). Options B, C, and D describe incorrect interpretations.

4. . A Nexus 9000 switch shows that port Eth1/5 is in 'err-disabled' state. The 'show spanning-tree vlan 10' output shows Eth1/5 was a DesignatedPort before the error. The syslog shows: 'BPDU received on port Eth1/5 which has bpduguard enabled'. What happened, and how is the port recovered?

   • A. BPDU Guard was enabled on Eth1/5 (typically an access port connected to an end device); a switch or device sending BPDUs was connected to the port, triggering BPDU Guard to err-disable the port to prevent STP topology disruption. Recovery options: manually shut/no shut the port, or configure 'errdisable recovery cause bpduguard' with an interval to allow automatic recovery.(correct)
   • B. The port received a superior BPDU that would change the STP root bridge; BPDU Guard blocked the topology change by err-disabling the port. The port auto-recovers after the STP convergence timer (50 seconds) expires.
   • C. BPDU Guard is incompatible with Designated ports; the err-disable is triggered automatically on any Designated port that receives a BPDU, regardless of the source. The fix is to convert Eth1/5 to a Root port using STP port cost manipulation.
   • D. The err-disabled state was caused by a BPDU rate exceeding the default threshold of 10 BPDUs per second; the port will auto-recover in 30 seconds when the BPDU rate drops below the threshold.

   Explanation: BPDU Guard is typically enabled on PortFast/edge ports (access ports connected to end devices that should never participate in STP). When a device sending BPDUs (e.g., a rogue switch, a misconfigured VM with vSwitch) connects to a BPDU Guard-protected port, NX-OS immediately err-disables the port to protect the STP topology. Recovery requires either: manual intervention (interface shutdown; no shutdown), or configuring automatic errdisable recovery with 'errdisable recovery cause bpduguard' and a recovery interval (e.g., 'errdisable recovery interval 300'). Option B is wrong — BPDU Guard fires on any BPDU regardless of whether it would change the root. Option C incorrectly associates the trigger with Designated port status. Option D invents a BPDU rate threshold mechanism (that is BPDU rate limiting, not BPDU Guard).

5. . A network engineer troubleshoots a routing issue on Nexus 9000 where a server in VRF PROD cannot reach its default gateway. The engineer runs 'show vrf all' and 'show ip route vrf PROD'. The VRF exists but 'show ip route vrf PROD' shows no routes and no connected networks. What is the most likely cause?

   • A. The SVI (VLAN interface) for the server's access VLAN has not been created or is not in the 'up' state in VRF PROD; without an active SVI associated with VRF PROD, there is no connected route for the subnet and no default gateway reachability.
   • B. The VRF exists but has no interfaces assigned to it; the server's VLAN SVI may exist but is assigned to the default VRF or a different VRF. Run 'show interface vlan X' to verify the 'VRF Membership' field and confirm the SVI is in VRF PROD.
   • C. BGP or OSPF redistribution for VRF PROD is missing in the route-map; without redistribution, connected routes are not installed in VRF PROD's RIB even if the interface is correctly assigned.
   • D. Options A and B both describe possible and complementary root causes: the SVI may not exist, or it may exist but be assigned to the wrong VRF. Both conditions result in no routes in VRF PROD and should be verified.(correct)

   Explanation: When 'show ip route vrf PROD' shows no routes at all (not even connected), two interrelated issues are possible: (1) The SVI for the server's VLAN does not exist (no 'interface vlan X' configured on the Nexus switch), so there is no connected route to install; or (2) the SVI exists but has been assigned to the default VRF or another VRF instead of VRF PROD (missing 'vrf member PROD' under the SVI). In NX-OS, VRF membership on an interface is configured with 'vrf member <name>' in interface configuration mode. 'show interface vlan X' shows the 'VRF Membership' field. Option C is wrong — connected routes do not require redistribution. Options A and B each describe one of the two valid causes, making D the most complete answer.

6. . On a Nexus 9000 VXLAN BGP EVPN fabric, the NVE interface on leaf-102 is up, but 'show bgp l2vpn evpn route-type 2' shows no MAC/IP routes received from leaf-104. BGP sessions are established to the spine route-reflectors. Which command verifies that the spine is receiving and reflecting route-type 2 advertisements from leaf-104?

   • A. On the spine (route-reflector), run 'show bgp l2vpn evpn route-type 2 0 [mac-addr] [ip-addr]' to verify the MAC/IP NLRI is present in the spine's BGP table and check the 'Next Hop' attribute — it should be leaf-104's VTEP IP. If the route is in the spine's table but not reflected, check the route-reflector client configuration under the BGP neighbor statement.(correct)
   • B. On leaf-104, run 'show nve vni' to verify the VNI is in the 'Up' state; if the VNI shows 'Down', no routes are advertised regardless of BGP session state.
   • C. Run 'show ip bgp summary' on the spine to verify the BGP session count; if the count matches the expected number of leaves, route reflection is operating correctly and the missing routes are a leaf-102 issue.
   • D. On leaf-104, run 'show bgp l2vpn evpn route-type 2' to check that leaf-104 is originating the routes; if the routes are present locally on leaf-104, they are guaranteed to be reflected to all clients by the spine.

   Explanation: When troubleshooting missing BGP EVPN routes in a route-reflector design, the correct approach is to verify the route at the spine (route-reflector) to determine whether the issue is in the origination (leaf-104 not advertising) or reflection (spine not reflecting). Running 'show bgp l2vpn evpn route-type 2 0 [mac] [ip]' on the spine shows whether the NLRI is in the spine's BGP RIB and its next-hop (should be leaf-104's VTEP IP). If the route is present but not sent to leaf-102, check the BGP neighbor configuration on the spine — the route-reflector-client statement must be present for both leaf-104 and leaf-102 under the L2VPN EVPN address family. Option B is a useful secondary check but doesn't verify spine reflection. Option C checks session count but not route presence. Option D is step one but doesn't confirm spine reflection.

7. . A Cisco ACI APIC administrator wants to verify the overall health of a leaf node in the fabric. Which APIC show command or GUI path provides a system-level health score for a fabric node, and what does a health score below 90 typically indicate?

   • A. In the ACI GUI, navigate to Fabric > Inventory > Topology > [leaf node]; the node's health score (0–100) is displayed. A score below 90 typically indicates active faults on the node such as interface errors, memory pressure, process crashes, or configuration deployment failures. In the CLI, 'acidiag fnvread' on the APIC shows fabric node health.(correct)
   • B. Health scores in ACI are only available for tenants and EPGs, not for individual fabric nodes; leaf node health must be assessed by reviewing syslog messages from the node's management interface.
   • C. A health score below 90 means the leaf node has reached 90% of its MAC address table capacity; the administrator should redistribute endpoints to other leaves to prevent traffic blackholing.
   • D. APIC does not calculate health scores for individual fabric nodes; health scores are only computed for Application Profiles and their EPGs based on contract violation counts.

   Explanation: Cisco ACI APIC provides health scores (0–100) at multiple hierarchy levels: fabric node (leaf/spine), tenant, application profile, EPG, and endpoint. A fabric node health score below 90 indicates degraded health — active faults such as interface error counters above threshold, process crashes (critical/major faults), hardware health alerts, software configuration deployment failures, or excessive dropped frames. In the GUI: Fabric > Inventory > Topology > click a leaf — the health score is visible in the node summary. Administrators can drill down into the fault list to identify the specific contributing faults. Option B is wrong — per-node health scores are a core ACI feature. Option C confuses health score with MAC table utilization. Option D incorrectly limits health scores to EPGs.

8. . A data center engineer needs to automatically respond to a recurring BGP session flap on a Nexus 9000 by sending a notification email and clearing the BGP neighbor. The engineer uses Embedded Event Manager (EEM). Which NX-OS configuration block correctly triggers the EEM applet when a BGP syslog message matching 'BGP-5-ADJCHANGE.*Down' appears?

   • A. feature eem event manager applet BGP_DOWN event syslog pattern "BGP-5-ADJCHANGE.*Down" action 1.0 cli command "clear ip bgp * soft" action 2.0 syslog msg "BGP neighbor cleared by EEM applet"(correct)
   • B. feature eem event manager applet BGP_DOWN event pattern syslog msg "BGP-5-ADJCHANGE.*Down" action 1.0 run-script /bootflash/notify.py
   • C. ip sla event-monitor bgp-flap syslog-match "BGP-5-ADJCHANGE.*Down" action clear-bgp
   • D. event manager policy BGP_DOWN.tcl type user event syslog pattern "BGP-5-ADJCHANGE.*Down" The EEM policy must be a Tcl script; inline applet actions are not supported on NX-OS for syslog-triggered events.

   Explanation: NX-OS EEM (Embedded Event Manager) requires 'feature eem' to be enabled first. An EEM applet uses 'event manager applet <name>' with 'event syslog pattern <regex>' to trigger on matching syslog messages. The pattern uses a regular expression (e.g., 'BGP-5-ADJCHANGE.*Down') to match the syslog message text. Actions are defined with 'action <label> <type> <args>'; the 'cli command' action runs an NX-OS CLI command in the exec context. The correct syntax in option A is standard NX-OS EEM applet configuration. Option B uses incorrect syntax ('event pattern syslog' instead of 'event syslog pattern'). Option C describes a non-existent 'ip sla event-monitor' construct. Option D is incorrect — NX-OS EEM supports inline applet actions without requiring Tcl scripts.

9. . A DC network engineer configures ERSPAN (Encapsulated Remote SPAN) on a Nexus 9500 to capture traffic from a server port (Eth1/10) and send it to a remote traffic analyzer at 192.168.50.100. Which NX-OS command sequence correctly configures an ERSPAN source session for this purpose?

   • A. monitor session 1 type erspan-source source interface Ethernet1/10 both destination ip 192.168.50.100 erspan-id 100 vrf default ip ttl 64 no shut(correct)
   • B. monitor session 1 type span source interface Ethernet1/10 destination interface Ethernet1/20 erspan-destination 192.168.50.100
   • C. ip access-list ERSPAN_FILTER permit ip any 192.168.50.100/32 monitor session 1 type erspan-source source interface Ethernet1/10 rx destination ip 192.168.50.100 filter access-group ERSPAN_FILTER
   • D. erspan session 1 source ethernet 1/10 destination ip 192.168.50.100 key 100 The NX-OS ERSPAN command syntax uses 'erspan session' not 'monitor session type erspan-source'.

   Explanation: NX-OS ERSPAN source session configuration uses 'monitor session <id> type erspan-source'. The session specifies: source interface(s) with direction (rx, tx, or both), destination IP (the remote analyzer), ERSPAN ID (a label carried in the GRE header identifying the session), VRF for ERSPAN packet routing, and IP TTL. The 'no shut' activates the session. ERSPAN encapsulates mirrored frames in GRE/IP (ERSPAN Type II or III) and sends them as routed packets to the destination IP. Option B uses incorrect 'type span' with a hybrid syntax that doesn't exist. Option C adds an ACL filter pointing to the destination — this is not how ERSPAN filtering works (source filters restrict which traffic is captured, not by destination). Option D uses a fabricated 'erspan session' keyword.

10. . A data center team uses Cisco Nexus Dashboard Insights for ACI fabric monitoring. The tool reports a 'Route Anomaly' event between two EPGs. The event shows asymmetric routing paths for flows between the same pair of endpoints. Which Nexus Dashboard Insights capability enables correlation of this event across the fabric, and what information does it provide to the engineer?

    • A. Nexus Dashboard Insights uses telemetry-based flow analysis and topology-aware correlation: it collects streaming telemetry (interface counters, flow records) from all fabric nodes, correlates events across the topology (leaf, spine, VTEP mapping), identifies anomalies such as asymmetric routing or unexpected path changes, and provides the engineer with a fault timeline, affected flow details, and suggested remediation steps — enabling root cause identification without manually querying each node.(correct)
    • B. Nexus Dashboard Insights only collects SNMP traps from fabric nodes; route anomaly detection requires the engineer to manually correlate BGP routing tables from each node because SNMP does not provide path-level detail.
    • C. Route anomaly detection in Nexus Dashboard Insights requires Cisco Intersight integration; without Intersight, only basic interface up/down events are available.
    • D. Nexus Dashboard Insights provides route anomaly alerts but cannot identify the specific flows affected; the engineer must use 'show ip route vrf all' on each leaf to manually determine which flows are asymmetrically routed.

    Explanation: Cisco Nexus Dashboard Insights (NDI) provides advanced fabric analytics by collecting streaming telemetry (model-driven telemetry, gRPC, or sFlow) from all fabric nodes. Its anomaly detection engine uses topology-aware correlation — it knows the full fabric topology from APIC and can trace how specific flows traverse the fabric (source leaf → spine → destination leaf), comparing observed paths against expected paths. When NDI detects asymmetric routing (packets from A-to-B traverse a different path than B-to-A), it raises a Route Anomaly event with full context: timestamp, affected VRF/EPG, specific flows impacted, and the topology view highlighting the divergent paths. This dramatically reduces troubleshooting time compared to manual per-node CLI queries. Options B, C, and D describe incorrect or incomplete capabilities.

11. . An engineer configures NX-OS NetFlow on a Nexus 9300 to export flow records to a collector at 10.0.0.200:9991. Which NX-OS configuration components are required, and in what order are they applied to an interface?

    • A. Three components are required: (1) Flow Exporter — defines the collector IP, port, and transport (UDP); (2) Flow Record — defines which fields are matched (key fields: src/dst IP, src/dst port, protocol) and which are collected (non-key: byte/packet counts, timestamps); (3) Flow Monitor — binds the Flow Exporter and Flow Record together. The Flow Monitor is then applied to the interface with 'ip flow monitor <name> input' (and/or output) under interface configuration.(correct)
    • B. Only two components are needed: a Flow Exporter (collector IP/port) and a Flow Monitor. The Flow Monitor is applied to the interface; NX-OS uses default flow record fields automatically without requiring explicit Flow Record configuration.
    • C. NX-OS NetFlow requires a Sampler object in addition to Flow Exporter and Flow Monitor; without a Sampler, NX-OS does not send any records to the collector. The Sampler defines the sampling rate (1:N) and is applied to the interface alongside the Flow Monitor.
    • D. NX-OS NetFlow configuration is identical to IOS configuration; the same 'ip flow-export destination', 'ip flow-export version 9', and 'ip flow ingress' interface commands apply without any object-based configuration.

    Explanation: NX-OS flexible NetFlow uses a three-object model. The Flow Exporter (flow exporter <name>) defines the collector endpoint: destination IP, destination UDP port, source interface, and export protocol version (e.g., NetFlow v9 or IPFIX). The Flow Record (flow record <name>) defines the flow key fields (match: src/dst IP, src/dst port, IP protocol, input interface) and non-key fields (collect: bytes, packets, timestamps, TCP flags). The Flow Monitor (flow monitor <name>) binds the flow record and flow exporter together. Finally, under the target interface, 'ip flow monitor <name> input' and/or 'ip flow monitor <name> output' activates monitoring. Option B is wrong — an explicit flow record is required in NX-OS flexible NetFlow. Option C is incorrect — a Sampler is optional (used for high-speed interfaces to sample 1:N packets for performance) but not mandatory. Option D is wrong — NX-OS uses the object-based model, not the legacy IOS command syntax.

12. . An engineer notices that an ACI endpoint's COOP entry on a spine proxy is showing a stale location. The endpoint has migrated from leaf-101 to leaf-103 but the spine proxy still shows leaf-101 as the location. Which ACI mechanism should eventually correct this, and how can the engineer manually verify and force an update?

    • A. COOP entries are updated when leaf-103 learns the endpoint (via data-plane ARP/data frame snooping) and sends a COOP registration to the spine proxy with the new VTEP location. If the update is delayed, the engineer can verify with 'show endpoint tracking db mac <mac>' on the APIC and use 'clear endpoint locator ip <ip>' on the affected leaf to force re-learning. The stale entry on the spine should age out and be replaced by the new registration from leaf-103.(correct)
    • B. Stale COOP entries are never corrected automatically; the engineer must log in to the spine CLI and manually delete the COOP entry using 'clear ip arp vrf <vrf> <ip>' to remove the stale mapping.
    • C. The COOP protocol does not track endpoint location by leaf VTEP; it only stores MAC-to-IP bindings. The leaf VTEP mapping is handled by BGP EVPN and requires 'clear bgp l2vpn evpn * soft' on the spine.
    • D. Stale COOP entries are protected by the 15-minute ARP cache timer; no action can force an update before the timer expires, and the engineer must wait for the full 15 minutes before the endpoint is reachable at its new location.

    Explanation: ACI COOP (Council of Oracles Protocol) uses a proactive registration model: when a leaf detects a new endpoint via data-plane learning (ARP, IP data frame), it immediately registers the endpoint (MAC, IP, VTEP=leaf's TEP IP) with the spine COOP Oracle. When the endpoint moves to leaf-103, leaf-103 learns it and sends a COOP update to the spine, overwriting the stale leaf-101 entry. If the update is delayed (e.g., the endpoint is quiet and no ARP/data has been seen by leaf-103), the COOP entry at the spine will remain stale. Administrators can use the endpoint tracker on APIC ('show endpoint tracking db') to see learning history, and can force re-learning by using 'clear endpoint locator' commands to invalidate the stale entry and prompt leaf-103 to re-register. Option B is wrong — COOP auto-updates. Option C is wrong — COOP does track VTEP/location. Option D invents a 15-minute protection timer.

13. . A UCS administrator receives a critical fault notification in Cisco UCS Manager for a blade server. The UCS Manager GUI shows fault code F0430: 'Server is undergoing a POST failure'. Which fault level does this fault represent, and where in UCS Manager can the administrator view all active faults with their severity levels?

    • A. A POST failure fault is a Critical severity fault (the highest level in UCS Manager's fault hierarchy: Critical > Major > Minor > Warning > Info). All active faults are visible under 'Operations Management > Faults, Events, and Audit Logs > Faults' in UCS Manager, where they can be filtered by severity, acknowledged, and correlated to specific objects.(correct)
    • B. A POST failure is a Major severity fault because Critical faults in UCS are reserved exclusively for hardware failures such as failed PSUs or fans; software and firmware faults like POST failures are always Major.
    • C. UCS Manager does not use named severity levels; faults are coded numerically (F0430) and the numeric suffix indicates severity — lower numbers are more severe than higher numbers.
    • D. UCS Manager faults are viewed only via Cisco Intersight; the local UCS Manager GUI does not provide a fault browser and redirects fault analysis to the cloud-based Intersight portal.

    Explanation: Cisco UCS Manager uses a four-level fault severity hierarchy: Critical (service impacting — requires immediate action), Major (significant degradation), Minor (low-impact issue), and Warning (informational condition that may require attention). A POST (Power-On Self-Test) failure is a Critical fault because the server cannot boot and is non-functional. The UCS Manager fault browser is accessible at Operations Management > Faults, Events, and Audit Logs > Faults (or via the top-right fault icon in the GUI), where administrators can filter by severity, acknowledge faults, and navigate to the affected object. Option B incorrectly limits Critical to hardware-only failures. Option C invents a numeric severity system. Option D is wrong — UCS Manager has a fully functional local fault browser without requiring Intersight.

14. . A UCS administrator attempts to associate a Service Profile to a physical blade server. The association fails with the message: 'Service Profile Association Failed — Resource unavailable: no server available matching the hardware qualifier'. What are the two most likely causes of this failure?

    • A. The hardware qualifier (server pool policy qualification) attached to the service profile specifies requirements (e.g., minimum RAM, CPU sockets, adapter type) that no available unassociated server in the referenced server pool meets. Alternatively, the server pool itself may be empty — all eligible servers are already associated with other service profiles, leaving no available server for the new association.(correct)
    • B. The service profile is missing an iSCSI boot policy; UCS Manager requires all service profiles to have an iSCSI or SAN boot policy configured before server association can proceed.
    • C. The failure indicates a UCSM database corruption; the administrator must re-install UCSM firmware to restore the server pool database before association can succeed.
    • D. The service profile has a VIC (Virtual Interface Card) policy specifying a VIC model (e.g., VIC 1340) that is not installed in any available blade; UCSM enforces VIC model matching before any other hardware qualification.

    Explanation: UCS Manager service profile association with a Server Pool uses hardware qualification policies to match the profile to an appropriate physical server. Two common failure reasons: (1) The hardware qualifier (policy specifying CPU count, memory size, local disk type, adapter type) has requirements that no available server satisfies — for example, requiring 512 GB RAM when all available blades have 256 GB; (2) The server pool referenced by the service profile has no unassociated servers available — all qualifying servers are already bound to other service profiles. The administrator should check the server pool membership, the hardware qualifier's criteria, and available unassociated servers in UCS Manager under Equipment > Rack Servers / Blade Servers to find unassigned units. Options B, C, and D describe unlikely or fabricated causes.

15. . A data center engineer uses Cisco Intersight to manage a UCS domain. An alarm is raised for a server blade: 'Cisco Intersight — Alarm: Server thermal threshold exceeded (Critical)'. The engineer wants to clear the alarm after the thermal issue is resolved. What is the correct procedure to clear a resolved Critical alarm in Intersight?

    • A. Intersight alarms that are tied to a condition (like thermal threshold) automatically clear when the underlying condition is resolved and the device reports normal operating status back to Intersight. If the alarm persists after resolution, the engineer can manually acknowledge and suppress it in Intersight under Alarms > Manage Alarms, or trigger a device re-sync to refresh the alarm state.(correct)
    • B. Critical alarms in Intersight can only be cleared by Cisco TAC; they are locked from manual modification by local administrators to ensure accountability and audit trails.
    • C. The engineer must SSH to the blade's CIMC (Cisco Integrated Management Controller) and run 'clear alarm all' to remove the thermal alarm; Intersight only displays alarms and cannot clear them.
    • D. Intersight alarms are cleared by restarting the Intersight Device Connector service on the UCS Fabric Interconnect; the connector re-establishes the cloud connection and receives a fresh alarm state from Cisco's cloud.

    Explanation: Cisco Intersight alarm lifecycle for condition-based alarms (thermal, power, hardware fault) follows a trigger/clear model: the alarm fires when the threshold is exceeded and automatically clears when the device reports that the condition is resolved (temperature returns to normal range, fault is remediated). Intersight polls device telemetry and updates alarm states accordingly. If an alarm lingers after the physical issue is fixed, the engineer can manually acknowledge it (to indicate it has been reviewed) and can trigger a device re-sync or re-inventory operation to force Intersight to refresh the device's current state. Option B is wrong — local admins can acknowledge/manage alarms. Option C is wrong — Intersight has full alarm management capabilities. Option D is incorrect — restarting the Device Connector is not the alarm clearing procedure.

16. . A HyperFlex engineer needs to verify the storage cluster health after a node maintenance window. Which HyperFlex CLI command provides a comprehensive storage cluster summary including capacity, replication factor, and cluster operational status?

    • A. 'hxcli cluster storage-summary' — this command displays cluster-wide storage information including total capacity, used capacity, free space, replication factor (RF), fault tolerance level, and the current cluster operational state (online/unhealthy/degraded). It is the primary command for a quick health check after maintenance.(correct)
    • B. 'show hx cluster info' — NX-OS style command used from the HyperFlex node's NX-OS CLI to display cluster health; 'hxcli' commands are only available from the HyperFlex Manager GUI, not the node CLI.
    • C. 'stcli cluster info' — the legacy HyperFlex CLI uses 'stcli' (SpringPath CLI) for all cluster operations; 'hxcli' was deprecated in HyperFlex 4.0 and replaced by 'stcli'.
    • D. 'hxcli cluster status' — this is the correct command; 'hxcli cluster storage-summary' displays only disk inventory and does not include replication factor or operational state.

    Explanation: Cisco HyperFlex uses the 'hxcli' command-line interface (available via SSH to the HyperFlex controller VM or admin node). 'hxcli cluster storage-summary' provides a comprehensive storage health view: total raw capacity, usable capacity, used capacity, free capacity, data replication factor (RF2 or RF3), space efficiency (dedup/compression ratio), and cluster operational state (online, unhealthy, offline, degraded). This is the standard post-maintenance verification command. Option B is wrong — 'show hx cluster info' is not a valid NX-OS command for HyperFlex. Option C is wrong — 'stcli' is an older CLI from the SpringPath era; 'hxcli' is the current supported interface. Option D invents an incorrect description of 'hxcli cluster storage-summary' capabilities.

17. . A server in a UCS chassis is inaccessible via its production network interface. A UCS administrator needs to access the server's OS console for diagnostics without network connectivity to the OS. Which UCS management feature enables this, and how is it accessed?

    • A. KVM (Keyboard, Video, Mouse) console access via the server's CIMC (Cisco Integrated Management Controller) provides out-of-band console access independent of the OS network stack. The administrator accesses it via UCSM (Equipment > Servers > [server] > KVM Console) or directly from the CIMC web interface; the KVM session provides a virtual console to the server's graphical or text display, BIOS, and boot process regardless of OS network state.(correct)
    • B. Serial over LAN (SOL) is the only out-of-band console method in UCS; KVM console is not available for blade servers because blades do not have dedicated video hardware.
    • C. Out-of-band OS console access in UCS requires Cisco Intersight; without Intersight enrollment, UCS Manager only provides power management (on/off/reset) and no console access.
    • D. UCS administrators must physically connect a crash cart (monitor and keyboard) to the blade chassis KVM port to access the server console; no remote KVM is supported in UCS Manager for blade servers.

    Explanation: Cisco UCS uses CIMC (Cisco Integrated Management Controller) as the BMC (Baseboard Management Controller) for each server. CIMC provides out-of-band management including KVM (Keyboard, Video, Mouse) virtual console access, which allows an administrator to interact with the server's BIOS, boot process, and OS console over the management network, entirely independent of the server's production NIC connectivity. In UCS Manager, this is accessible via Equipment > [Chassis] > Servers > [Server] > KVM Console, which launches a Java or HTML5 KVM session. This is the standard out-of-band management approach for UCS servers. Serial over LAN (option B) is an alternative text-only console method but KVM is fully supported and provides richer access. Options C and D describe incorrect limitations.

18. . A storage administrator runs 'show flogi database' on a Cisco MDS switch. The output shows several N-port login entries. What information does this command display, and what does each entry represent?

    • A. 'show flogi database' displays all fabric login (FLOGI) entries: each entry shows the interface (FC port) through which the N_Port connected, the VSAN ID, the FC ID assigned by the MDS (24-bit address), and the N_Port's WWPN (World Wide Port Name) and WWNN (World Wide Node Name). Each entry represents a storage initiator or target that has successfully completed FLOGI and been assigned an FC ID in the fabric.(correct)
    • B. 'show flogi database' displays only the zoning database, showing which WWPNs are members of active zones; FLOGI entries for non-zoned devices are not shown.
    • C. 'show flogi database' shows the fabric's switch-to-switch FSPF (Fibre Channel Shortest Path First) adjacencies; N_Port logins are shown with 'show fcns database' instead.
    • D. 'show flogi database' is only available on MDS switches; on Nexus 5000 with FCoE, the equivalent command is 'show fip-snooping flogi database'.

    Explanation: On Cisco MDS switches, 'show flogi database' displays the Fabric Login (FLOGI) database, which contains all end-device N_Ports that have logged into the fabric via their connected F_Port. Each entry includes: the MDS FC interface (e.g., fc1/1), VSAN ID, assigned FC ID (24-bit address, e.g., 0x650001), WWPN, and WWNN. FLOGI is the process by which an N_Port (HBA or storage array port) registers with the fabric and receives an FC address. This is a fundamental diagnostic command for verifying that initiators and targets have successfully connected. Option B describes the zone database, which is 'show zone'. Option C describes FSPF, which is 'show fspf database'. Option D is partly correct about FCoE but incorrectly restricts 'show flogi database' availability.

19. . A fibre channel storage administrator verifies zone configuration on an MDS switch. 'show zoneset active vsan 10' shows the active zone set. A storage host (WWPN: 10:00:00:00:c9:aa:bb:cc) cannot access a storage target (WWPN: 50:06:0b:00:00:c1:d1:00) even though both WWPNs appear in 'show flogi database'. What is the most likely cause?

    • A. The two WWPNs are not in the same zone within the active zone set; for fibre channel communication, an initiator and target must be in a common zone in the active zone set. Either they are in separate zones with no shared membership, or one of the WWPNs is missing from all zones in the active zone set.(correct)
    • B. The two WWPNs are in the same zone but the zone set has not been activated; the administrator must run 'zoneset activate name <name> vsan 10' to push the configuration from the pending zone set to the active zone set.
    • C. The host and storage target are in different VSANs; 'show flogi database' shows entries across all VSANs, so both can appear in the output even if they are in VSAN 10 and VSAN 20 respectively, preventing communication.
    • D. The FC ID assigned to the storage target has expired; FC IDs have a 30-minute lease in Cisco MDS, and after expiration, the target must re-issue FLOGI to receive a new FC ID.

    Explanation: In Fibre Channel zoning, for an initiator (HBA) to communicate with a target (storage array port), both must be members of at least one common zone in the active zone set for their VSAN. If the two WWPNs appear in 'show flogi database' (both have logged into the fabric and have valid FC IDs) but communication fails, the most likely cause is a missing or incorrect zone configuration: either the WWPNs are in different zones with no overlap, or one WWPN is missing from the active zone entirely. 'show zoneset active vsan 10' will show all zones and their members — the administrator should verify that a zone contains both 10:00:00:00:c9:aa:bb:cc and 50:06:0b:00:00:c1:d1:00. Option B is possible but the question states the active zone set IS shown by the command. Option C is a valid alternative but the question specifies both are in VSAN 10. Option D invents a non-existent FC ID lease mechanism.

20. . An engineer troubleshoots an FCoE FIP (FCoE Initialization Protocol) failure. A server with a Cisco VIC configured for FCoE cannot discover the Fibre Channel Forwarder (FCF). 'show fip-snooping vlan 10' on the intermediate Nexus switch shows no FCF entries. Which component failure is most likely causing the FIP discovery to fail?

    • A. FIP snooping requires the FCF (e.g., MDS with NPV or a Nexus 5000/6000 FCoE gateway) to send FIP VLAN Notification or Solicitation frames on VLAN 10 (the designated FCoE VLAN). If 'show fip-snooping vlan 10' shows no FCF, the most likely causes are: (1) the FCF is not sending FIP advertisements on VLAN 10; (2) the FCoE VLAN is not properly trunked between the FCF and the intermediate switch; or (3) the intermediate switch's FIP snooping feature is not enabled on VLAN 10.(correct)
    • B. No FCF entries in FIP snooping indicate that the server's VIC firmware does not support FIP; older VIC firmware versions use legacy FCoE without FIP, and 'show fip-snooping' will always show no entries for these hosts.
    • C. FIP snooping requires the FCOE VLAN to use VLAN ID 1002 (the default FC VLAN reserved by NX-OS); if VLAN 10 is used instead of 1002, FIP snooping does not function correctly.
    • D. The absence of FCF entries in 'show fip-snooping vlan 10' is expected when no FCoE logins have occurred; the FCF entry is only created after the first ENode (server VIC) successfully completes FIP login.

    Explanation: FIP (FCoE Initialization Protocol) enables FCoE fabric discovery by having the FCF (Fibre Channel Forwarder, e.g., Nexus 5000/6000 FCoE gateway or MDS) advertise itself via FIP Discovery Advertisement frames on the FCoE VLAN. 'show fip-snooping vlan 10' on an intermediate Nexus switch (operating as an FCoE transit switch) shows FCF entries when it intercepts these advertisements. Empty output means the FIP advertisements from the FCF are not reaching the switch — likely causes: the FCF is not operational/configured for FCoE on VLAN 10, the FCoE VLAN is not trunked on the uplink between FCF and intermediate switch, or FIP snooping is not enabled globally or on VLAN 10 ('feature fip-snooping' and 'fip-snooping enable' / 'fip-snooping vlan 10'). Option B is wrong — modern VICs use FIP. Option C invents a VLAN 1002 restriction. Option D is wrong — FCF entries appear from advertisements, not from completed logins.

21. . A storage administrator needs to verify whether a Cisco MDS switch is using hard zoning or soft zoning for VSAN 10. What is the key behavioral difference between hard and soft zoning in Fibre Channel?

    • A. Hard zoning enforces zone membership at the hardware ASIC level (switch fabric): the FC switch's hardware filters frames based on the source and destination FC IDs, preventing unauthorized access even if a device uses a spoofed WWPN. Soft zoning enforces zone membership only in the name server (FCNS database) — unauthorized WWPNs can query the name server but will not find out-of-zone targets; however, if a device knows a target's FC ID by other means, the hardware does not block the frame.(correct)
    • B. Hard zoning uses WWPNs exclusively for zone membership; soft zoning uses only FC domain IDs for zone membership. MDS supports both simultaneously, and 'show zone status vsan 10' indicates which type is active.
    • C. Hard zoning and soft zoning are functionally identical on Cisco MDS; the distinction is only in terminology used by storage vendors — Cisco MDS always enforces zoning at the hardware level regardless of configuration.
    • D. Soft zoning is more secure than hard zoning because it uses cryptographic WWN authentication; hard zoning relies on physical port mapping which can be bypassed by hot-plugging a device.

    Explanation: Fibre Channel zoning security model: Hard zoning (also called hardware or port-based/WWN-based enforcement at the ASIC level) enforces access control in the switch hardware. The FC ASIC compares source/destination FC IDs against the zoning policy and drops frames that violate zone membership — providing enforcement even against WWPN spoofing or FC ID guessing. Soft zoning enforces zone policy only through the fabric name server: when a device queries the Name Server (FCNS) for targets, only in-zone targets are returned. If a rogue initiator already knows a target's FC ID (bypassing the name server), soft zoning provides no frame-level protection. Cisco MDS defaults to hard zoning (when 'zone default-zone permit' is not set). Administrators verify with 'show zone status vsan 10' which shows the enforce-mode (hard or soft). Options B, C, and D mischaracterize the distinction.

22. . A developer is testing NX-API on a Nexus 9000 switch. A Python script sends a POST request to the NX-API endpoint but receives HTTP 400 Bad Request. The request body is: '{"ins_api":{"version":"1.0","type":"cli_show","chunk":"0","sid":"1","input":"show version","output_format":"json"}}'. What is the most likely cause of the HTTP 400 error?

    • A. HTTP 400 from NX-API typically indicates a malformed JSON body or an incorrect NX-API wrapper structure. Common causes: (1) missing or incorrect 'ins_api' wrapper key; (2) invalid 'type' field value (valid values: 'cli_show', 'cli_show_ascii', 'cli_conf', 'bash'); (3) missing required fields; or (4) invalid JSON syntax (unescaped characters, trailing comma). The body shown appears structurally correct — the engineer should verify the Content-Type header is 'application/json' and the request method is POST to the correct endpoint (/ins).(correct)
    • B. HTTP 400 indicates authentication failure; the NX-API credentials in the HTTP Basic Auth header are incorrect or the user does not have the 'network-admin' role. NX-API uses HTTP 400 (not 401) for authentication errors.
    • C. HTTP 400 is returned when the 'feature nxapi' is not enabled on the switch; the switch rejects all NX-API HTTP requests with a 400 status code until the feature is activated.
    • D. HTTP 400 indicates the Nexus switch's NX-API sandbox (DevBox mode) is not enabled; the script must set the X-DevBox header to 'true' for NX-API to process POST requests.

    Explanation: NX-API on Nexus 9000 accepts JSON-formatted POST requests to /ins (or /api). HTTP 400 Bad Request is returned for malformed requests — the JSON body is syntactically invalid, required fields are missing, or field values are incorrect. The request body shown appears synturally valid; common real-world issues causing 400 include: incorrect Content-Type header (must be 'application/json' for JSON, or 'application/xml' for XML), wrong HTTP method (must be POST), or subtle JSON encoding errors. The engineer should verify all headers and use NX-API's sandbox (available at https://<switch>/api/aaalogin.json) to test. Authentication failures return 401 (Unauthorized), not 400. If 'feature nxapi' is not enabled, the connection typically fails at TCP level (connection refused), not HTTP 400. Option D invents a DevBox header requirement.

23. . An Ansible playbook uses the cisco.nxos.nxos_vlan module to ensure VLAN 100 exists on a Nexus 9000 switch. The playbook is run twice consecutively. The first run creates VLAN 100 and reports 'changed=true'. What does the second run report, and why?

    • A. The second run reports 'changed=false' because the nxos_vlan module is idempotent: it queries the current VLAN state on the device, finds VLAN 100 already exists with the desired parameters, and determines no change is needed — so it makes no modification and reports no change.(correct)
    • B. The second run reports 'changed=true' again because Ansible always re-applies the configuration to ensure it is correct; the nxos_vlan module does not perform state checking and always executes the 'vlan 100' command regardless of current state.
    • C. The second run fails with 'VLAN 100 already exists' error because NX-OS rejects duplicate VLAN creation commands via Ansible; the playbook must include a 'when: vlan not exists' conditional to avoid this error.
    • D. The second run reports 'skipped=true' because Ansible automatically skips tasks that have been successfully run in a previous playbook execution within the same day, using a local task cache.

    Explanation: The Ansible cisco.nxos.nxos_vlan (now cisco.nxos.nxos_vlans) module is a declarative, idempotent resource module. On each run, the module queries the device's current VLAN state (via 'show vlan' or NETCONF), compares it against the desired state specified in the task, and only makes changes if differences are detected. If VLAN 100 already exists with the correct name and state, the module reports 'changed=false' and issues no CLI commands. This idempotency is a core property of Ansible network resource modules — running the playbook multiple times produces the same result without unwanted side effects. Option B is wrong — state checking is fundamental to resource modules. Option C is wrong — NX-OS does not error on re-specifying an existing VLAN; and nxos_vlan handles this via state comparison. Option D invents a non-existent task cache behavior.

24. . A network engineer wants to run a Python script on-box on a Nexus 9000 switch using the Guest Shell. When the engineer tries to access the Guest Shell, they receive 'Error: guestshell not enabled'. Which NX-OS command enables Guest Shell, and what is Guest Shell's purpose?

    • A. 'feature guestshell' enables the Guest Shell feature in NX-OS; after enabling, the Bash shell is accessible via the 'guestshell' command. Guest Shell is a CentOS Linux container embedded in NX-OS that provides a full Linux environment for running Python scripts, installing packages (yum/pip), and executing automation tasks on-box without modifying the NX-OS control plane.(correct)
    • B. 'feature bash-shell' enables both the Bash shell and the Guest Shell simultaneously; 'feature guestshell' is a deprecated alias and only works on Nexus 7000 platforms.
    • C. Guest Shell is enabled by running 'guestshell enable' from the NX-OS exec mode (not from config mode); 'feature guestshell' is not a valid NX-OS command.
    • D. Guest Shell requires the Nexus 9000 to be registered in Cisco DevNet; without DevNet registration, the 'feature guestshell' command is accepted but the Guest Shell container fails to start.

    Explanation: NX-OS Guest Shell is enabled using 'feature guestshell' in global configuration mode. Once enabled, 'guestshell' from the exec prompt launches an interactive session into the CentOS-based Linux container. Guest Shell runs as a separate container (using NX-OS container infrastructure, formerly Docker/LXC) with access to the management network, Python 2/3 interpreters, and package management (yum/pip). Engineers use it to run Python scripts (including scripts using the NX-OS Python library for on-box API access), install automation tools, and execute cron-scheduled tasks — all without impacting the NX-OS control plane. Note: 'feature bash-shell' enables direct Bash access to NX-OS's underlying Linux shell (different from Guest Shell). Option C is wrong about exec mode. Options B and D contain incorrect information.

25. . A network engineer is troubleshooting a Nexus 9000 POAP (PowerOn Auto Provisioning) failure. A new switch is added to the network but fails to download its configuration. The engineer checks the DHCP server and confirms a scope exists for the management subnet. Which POAP stage-by-stage troubleshooting approach correctly identifies the failure point?

    • A. POAP has three sequential stages. Stage 1 (DHCP): the switch sends DHCP DISCOVER on the management interface; if the switch receives no DHCP offer, verify: the DHCP scope covers the management subnet, DHCP option 67 (bootfile-name) is set to the TFTP script filename, and option 66 (TFTP server IP) or SIADDR is configured. Stage 2 (TFTP/HTTP script download): if DHCP succeeds but the Python script is not downloaded, verify TFTP server reachability from the management network and the script filename matches option 67. Stage 3 (Script execution): if the script downloads but configuration fails, check the Python script for syntax errors and verify the NX-OS image and config URLs referenced in the script are reachable.(correct)
    • B. POAP failure is always caused by an incorrect NX-OS image version; the POAP server must host an image that exactly matches the switch's hardware PID. Run 'show version' on the switch to confirm the required image and verify the TFTP server has the matching image filename.
    • C. POAP uses DNS (not DHCP options) to find the TFTP server; the switch resolves 'poap.cisco.com' via DNS to locate the configuration server. If DNS fails, POAP fails at Stage 1 regardless of DHCP configuration.
    • D. POAP Stage 1 uses LLDP neighbor discovery to find an existing NX-OS switch that acts as the POAP server; if no NX-OS neighbor is present on the management port, POAP cannot proceed to the DHCP stage.

    Explanation: NX-OS POAP (PowerOn Auto Provisioning) follows a well-defined three-stage process. Stage 1 — DHCP Discovery: the switch sends DHCP DISCOVER; the DHCP server must return an offer with DHCP option 66 (TFTP server IP/hostname) and option 67 (bootfile name — the Python POAP script filename). Without these options, POAP fails immediately. Stage 2 — Script Download via TFTP/HTTP: the switch contacts the TFTP server and downloads the script named in option 67; failure here indicates TFTP server unreachable, wrong filename, or access control issues. Stage 3 — Script Execution: Python script runs, downloads the NX-OS image and configuration file from the URLs embedded in the script; failures here include Python syntax errors, unreachable image server, or incorrect image path. Systematic per-stage verification (DHCP offer → TFTP reachability → script content) isolates the failure quickly. Options B, C, and D describe incorrect POAP mechanisms.