Cisco CCIE Data Center Preparation: Expert Questions & Answers for 2026
Keywords: CCIE Data Center Preparation • CCIE DC Questions Answers • 350-601 DCCOR Exam • Cisco ACI Interview Questions • CCIE DC Lab Preparation • NX-OS VXLAN EVPN Questions • Cisco UCS CCIE • Data Center CCIE Study Guide • CCIE DC 2026 • Cisco HyperFlex CCIE • ACI Fabric Configuration • BGP EVPN Data Center • CCIE DC Automation • Nexus 9000 CCIE Questions
The CCIE Data Center lab is eight hours of configuring a technology domain that spans fabric networking, storage, compute, cloud integration, and automation — all on the same exam. The questions that trip candidates aren’t always the hardest concepts; they’re the ones where you think you know the answer and you’re almost right. This guide covers the questions where “almost right” costs you points, organized by exam topic domain.
May 2026 | ⏱ 40 min read | CCIE DC v3.1 • Exam 350-601 DCCOR • 8-Hour Lab | ⚙ CCNP DC Holders • CCIE DC Candidates • Senior DC Engineers
CCIE Data Center Exam Structure (Current 2026)
|
Qualifying Exam: 350-601 DCCOR |
DCCOR Topic Weights: |
10 Topic Categories — Questions & Expert Answers
|
① ACI Fabric Architecture ② NX-OS and Nexus Switching ③ VXLAN & BGP EVPN ④ Cisco UCS & Compute ⑤ Storage Networking (FC, FCoE, NVMe-oF) |
⑥ HyperFlex & Hyperconverged Infrastructure ⑦ Data Center Security ⑧ Cloud & Multi-Site ⑨ Automation & Programmability ⑩ Lab Strategy & Study Plan |
|
Category 1 — Networking Domain ACI Fabric Architecture |
|
Q1. Explain the ACI policy model: Tenant, VRF, Bridge Domain, EPG, and Contract — and how they relate to each other.
Tenant is the administrative unit — a customer, a department, or a service. Everything below lives inside a Tenant. VRF (Virtual Routing and Forwarding) is the Layer 3 routing domain within a Tenant. A Tenant can have multiple VRFs to provide L3 isolation. Bridge Domain (BD) is a Layer 2 forwarding domain bound to exactly one VRF. It defines the subnet gateway IP and controls flooding behavior (ARP flooding, unknown unicast flooding, L2 unknown unicast). EPG (Endpoint Group) is a logical grouping of endpoints (VMs, bare-metal servers, external networks) with common policy requirements. EPGs are associated with Bridge Domains. Contract defines which traffic is permitted between EPGs, replacing IP-based ACLs. A Contract has Subjects which contain Filters (matching on protocol/port). Traffic between two EPGs is denied by default unless a Contract explicitly permits it (preferred group is the exception).
CCIE Lab tip: The exam expects you to understand that one BD can contain multiple EPGs. EPGs in the same BD share the same broadcast domain but still need Contracts (or Preferred Group) to communicate at Layer 3. Forgetting the BD-to-VRF relationship when configuring inter-tenant communication is one of the most common ACI lab mistakes.
Q2. What is the difference between Flooding and Proxy mode in an ACI Bridge Domain, and when does each apply?
ACI’s COOP (Council of Oracle Protocol) maintains a distributed endpoint database. When an endpoint is known, the spine can answer ARP requests by proxy without flooding — this is ARP Proxy (also called Proxy mode or Unicast Routing with ARP suppression). When flooding is enabled in the BD, ARP broadcasts are flooded through the fabric using multicast (GIPo addresses). In most deployments with L3 Out and routing enabled, disable flooding and enable ARP flooding only when needed for specific applications that rely on broadcast behavior. Unknown Unicast flooding should be disabled when the BD has hardware proxy enabled — spine proxies unicast to unknown MACs via the COOP database instead of flooding.
# ACI BD configuration via CLI on APIC
moquery -c fvBD -f 'fvBD.name=="App-BD"' | grep -E "arpFlood|unkMacUcastAct|unicastRoute" arpFlood : no # ARP proxy enabled (no flooding) unkMacUcastAct : proxy # Unknown unicast: proxy (not flood) unicastRoute : yes # L3 routing enabled on this BD
Q3. A VM is in EPG-Web and cannot reach EPG-App in the same VRF. Both EPGs are in different BDs. The Contract is configured. What do you check first?
Step-by-step verification: (1) Confirm the Contract is deployed in the correct direction — EPG-Web provides or consumes the Contract, and EPG-App provides or consumes the opposite role. A common mistake is both EPGs consuming the same Contract instead of one providing and one consuming. (2) Check the filter is correct — does it match the actual traffic (protocol, destination port)? (3) Verify the Subject has the filter in the correct direction (filter-chain direction matters for asymmetric rules). (4) Confirm both EPGs have endpoints (non-empty EPGs won’t have policy rendered in the leaf’s ASIC). (5) Use show zoning-rule on the leaf to verify the policy is compiled into hardware. A Contract that isn’t visible in show zoning-rule won’t match any traffic.
# On the leaf switch where the VM lives (NX-OS ACI mode) show zoning-rule scope <VRF-vnid> show endpoint vrf <tenant>:<vrf> # Verify endpoint is learned # APIC contract verification moquery -c vzFilter -f 'vzFilter.name=="App-Filter"' moquery -c vzEntry # Check filter entries (protocol, port) # Atomic counter for traffic analysis # APIC GUI: Operations → Endpoint Connectivity → Troubleshoot
Q4. What is the ACI L3Out and when is it required?
An L3Out (Layer 3 Outside) connects ACI to external routed networks — WAN routers, internet edge, other data centers, or non-ACI networks. It defines the routing protocol (OSPF, BGP, EIGRP, or static), the physical interface or SVIs used for the peering, and the external EPGs that represent external prefixes. The L3Out is associated with a BD to provide routed connectivity between internal endpoints in that BD and external networks. Without an L3Out, ACI is a closed fabric — endpoints can communicate within the fabric but not with the outside world. L3Out also requires an external EPG with Contracts to control what internal EPGs can reach external prefixes.
Q5. Explain ACI Multi-Site vs Multi-Pod. What are the key design differences?
Multi-Pod extends a single ACI fabric across multiple physically separate pod locations connected by an IPN (Inter-Pod Network). All pods share the same APIC cluster (3+ APICs spread across pods), the same policy domain, and the same control plane. The IPN carries OSPF (for underlay) and MP-BGP EVPN (for overlay). BDs and EPGs span across all pods transparently. Failure of the IPN isolates the pods but each pod continues operating independently. Multi-Site is a federation of independent ACI fabrics (sites), each with its own APIC cluster, managed by a Multi-Site Orchestrator (MSO/Nexus Dashboard Orchestrator). Policies are authored in NDO and pushed to each site. Sites can have the same or different APIC versions. Communication between sites uses BGP EVPN over an inter-site network. Key difference: Multi-Pod = one fabric extended; Multi-Site = multiple independent fabrics federated.
|
Category 2 — Networking Domain NX-OS and Nexus Switching |
|
Q6. What is vPC and what are the specific failure scenarios it addresses?
Virtual Port Channel allows a downstream device (server, switch, FEX) to form a port channel to two different Nexus switches simultaneously. Without vPC, a standard port channel requires all member links to terminate on the same switch — losing that switch loses all connections. vPC provides: active-active forwarding across both uplinks (no spanning tree blocking), dual-chassis redundancy, and hitless failover when one vPC primary fails. vPC components: vPC domain (shared ID on both peers), vPC peer link (dedicated trunk carrying control and synchronization traffic — minimum two 10G links), vPC peer keepalive link (management or routed path for heartbeat), vPC member ports (the actual links to downstream devices). A critical NX-OS CCIE question: if the peer link fails but keepalive is up, the secondary vPC switch suspends its vPC ports to prevent split-brain forwarding. If the keepalive also fails, both switches continue operating independently (potential duplication of traffic).
# Verify vPC status show vpc show vpc consistency-parameters global show vpc peer-keepalive # Must show "alive" show vpc brief # Port channel health # vPC basic configuration feature vpc vpc domain 10 peer-keepalive destination 192.168.1.2 source 192.168.1.1 interface port-channel10 vpc peer-link # Peer link designation interface port-channel20 vpc 20 # vPC member port channel
Q7. What is NX-OS Fabricpath and how does it differ from standard 802.1Q Ethernet?
FabricPath is Cisco’s proprietary Layer 2 multipath protocol (based on TRILL — Transparent Interconnection of Lots of Links). It replaces STP with a routed core using IS-IS, enabling ECMP at Layer 2. In a FabricPath network, every switch gets a unique switch ID, and frames are encapsulated with a FabricPath header containing source and destination switch IDs. Traffic takes ECMP paths through the core — all links carry traffic. Outer MAC addresses are the ingress and egress switch MACs, not the actual endpoint MACs, which means only the edge switches need to learn endpoint MACs. The FabricPath spine switches learn switch IDs only (not endpoint MACs), making the MAC address table at the spine dramatically smaller. Note: FabricPath has been superseded by VXLAN/EVPN in modern deployments and is no longer the primary exam focus in CCIE DC v3.1, but still appears in comparison questions.
Q8. What is OTV (Overlay Transport Virtualization) and what problem does it solve?
OTV extends Layer 2 VLANs across geographically separate data centers over any IP transport (including the internet) without creating a spanning tree domain across sites. Each site has an OTV Edge Device (ED). The OTV ED encapsulates Layer 2 frames in OTV headers (MAC-in-IP, UDP 8472) and forwards them over the IP transport. OTV uses IS-IS for MAC routing between sites — the ED learns local MACs via normal bridging and advertises them to remote EDs via IS-IS. Key properties: STP is bounded per-site (OTV doesn’t leak STP BPDUs across sites), unknown unicast is suppressed (only known MACs are forwarded across the overlay, avoiding broadcast storms), and ARP suppression is available. OTV is still implemented on Nexus 7000 and ASR 1000 platforms for DC interconnect.
Q9. Describe NX-OS In-Service Software Upgrade (ISSU) and its prerequisites on Nexus 7000.
ISSU upgrades the NX-OS software on a Nexus 7000 without dropping any traffic by upgrading the redundant supervisor first, then performing a supervisor switchover (less than 1 second of disruption), then upgrading the other supervisor. For ISSU to work: (1) Dual supervisors required (one active, one standby in SSO mode). (2) Stateful Switchover (SSO) must be operational. (3) Non-disruptive upgrade path must exist from current to target version (check the Cisco ISSU matrix). (4) For line card upgrade, ISSU also supports in-service line card module upgrade (ISLU) on compatible line cards. ISSU does not work across major NX-OS train jumps — only within compatible releases. Verify with show system issu state before starting the upgrade procedure.
|
Category 3 — Networking Domain VXLAN & BGP EVPN |
|
Q10. Explain EVPN Route Types 2, 3, and 5. What does each carry?
Type 2 (MAC/IP Advertisement Route): Carries a MAC address and optionally an IP address from a specific VTEP. Used for endpoint reachability — when a VM connects to a leaf, the leaf advertises its MAC (and IP if known from ARP snooping/proxy) via Type 2. Remote VTEPs receive this and populate their MAC+ARP tables, enabling ARP suppression. A Type 2 with only MAC (no IP) is a pure L2 advertisement. A Type 2 with both MAC and IP enables distributed anycast gateway function.
Type 3 (Inclusive Multicast Ethernet Tag Route, IMET): Signals which VTEPs are interested in a specific VNI. Used for BUM (Broadcast, Unknown unicast, Multicast) traffic distribution. When a leaf joins a VNI, it advertises a Type 3 route so other VTEPs know to send BUM traffic to it. In ingress replication mode, Type 3 routes build the replication list.
Type 5 (IP Prefix Route): Carries routed IP prefixes (network routes), not tied to a specific endpoint MAC. Used for inter-subnet routing advertisement between VTEPs and for connecting to external networks. L3 VNI traffic uses Type 5 routes. When a leaf has a route to an external prefix via an L3Out, it advertises it as Type 5 to other VTEPs.
Q11. What is the difference between symmetric and asymmetric IRB in VXLAN EVPN?
Asymmetric IRB: Routing happens on ingress; bridging on egress. The ingress VTEP routes the packet from the source subnet to the destination subnet and bridges it to the destination. Both source and destination VNIs must exist on both VTEPs for this to work. This doesn’t scale: a 1000-subnet fabric requires all 1000 VNIs on every leaf. Symmetric IRB: Both ingress and egress VTEPs route the packet. The ingress VTEP routes into an L3 VNI (a dedicated per-VRF VNI, not tied to any subnet), sends over the fabric, and the egress VTEP routes again from the L3 VNI to the destination subnet. Only the L3 VNI needs to be present on all VTEPs — L2 VNIs only on leaves that have local hosts in that subnet. This is the scalable model and the exam default.
# Symmetric IRB NX-OS configuration on leaf vlan 100 vn-segment 100100 # L2 VNI for VLAN 100 vlan 3967 vn-segment 50001 # L3 VNI for VRF vrf context PROD vni 50001 rd auto address-family ipv4 unicast route-target both auto evpn interface Vlan100 vrf member PROD ip address 10.1.1.254/24 fabric forwarding mode anycast-gateway # Anycast GW for this subnet interface nve1 no shutdown source-interface loopback0 member vni 100100 mcast-group 239.1.1.100 # Or ingress-replication protocol bgp member vni 50001 associate-vrf # L3 VNI
Q12. What is Anycast Gateway in VXLAN EVPN and why does it eliminate the need for FHRP?
FHRP (HSRP/VRRP) works by having one router be Active and respond to ARP for the gateway IP — only one device forwards traffic at a time. In a VXLAN fabric with distributed anycast gateway, every leaf switch that serves a VLAN is configured with the same IP address and the same MAC address for that subnet’s gateway. This is possible because each leaf makes an independent routing decision for its locally-attached hosts. A VM’s default gateway ARP is answered locally by whatever leaf it’s connected to — there’s no active/standby. Every leaf is simultaneously the gateway for its local hosts in that subnet. This eliminates HSRP/VRRP, removes suboptimal routing through a specific active router, and provides sub-second failover (the VM simply connects to a different leaf if its current leaf fails). The duplicate MAC is intentional and managed by NX-OS’s fabric forwarding mode.
Q13. How does BGP EVPN handle ARP suppression and what are the benefits?
Each leaf maintains a local ARP suppression database populated from EVPN Type 2 MAC/IP routes received from all VTEPs. When a local host sends an ARP request for a MAC/IP combination already in the suppression database, the leaf answers locally without flooding the ARP broadcast across the fabric. Benefits: eliminates BUM traffic for known endpoints (no broadcast floods across thousands of VTEPs), reduces load on all VTEPs, enables faster ARP resolution (local response vs. waiting for remote reply), and allows silent hosts (that don’t respond to ARP) to have entries pre-populated from their last known state. ARP suppression requires EVPN Type 2 routes to carry the IP address alongside the MAC — leaves must be configured to perform ARP snooping and populate the BGP EVPN database with MAC-IP bindings.
|
Category 4 — Compute Domain (30%) Cisco UCS & Compute |
|
Q14. Describe the UCS architecture. What is the role of the Fabric Interconnect, IOM, and Service Profile?
Fabric Interconnect (FI): The central component of UCS. Runs UCS Manager (UCSM) which manages the entire UCS domain from a single pane. FIs connect to the upstream network fabric (Nexus switches or ACI leaf) and to blade chassis or rack servers. Always deployed as a pair (FI-A and FI-B) for redundancy. Handles all I/O traffic — Ethernet, FCoE, and management — in a unified fabric. IOM (I/O Module): In blade chassis (UCS 5108), the IOM connects blades to the FI. Two IOMs per chassis connect to FI-A and FI-B respectively. The IOM multiplexes blade traffic onto fewer physical uplinks (the oversubscription ratio depends on IOM model and the number of fabric uplinks configured). Service Profile: A software definition of a server’s identity and configuration — MACs, WWNs/WWPNs, boot policy, firmware policy, BIOS policy, network adapter settings, storage access. Associating a Service Profile to a blade configures it automatically. Migrating a Service Profile to a different blade migrates the entire server identity — the network sees the same MACs and the SAN sees the same WWPNs.
Q15. What is the difference between a Service Profile and a Service Profile Template in UCS?
Service Profile Template: A master definition. Two types: Initial Template (updating the template only affects new profiles derived from it; existing profiles are not updated) and Updating Template (changes to the template propagate to all derived Service Profiles instantly — important for deploying policy changes to all servers simultaneously). Service Profile: Derived from a template or created standalone. When derived from an Updating Template, the profile is locked to template changes for all template-managed fields — you can’t override individual fields without breaking the template link. For CCIE lab: templates with updating mode are the recommended approach for managing large pools of identical servers. The template vs. standalone Service Profile distinction is a frequent exam question because the behavior difference directly affects how changes propagate.
Q16. What is UCS VIC (Virtual Interface Card) and how does it implement vNICs and vHBAs?
The UCS VIC (Virtual Interface Card, e.g., Cisco VIC 1340, 1387, 1455) is a mezzanine card in blade servers (or PCIe card in rack servers) that presents virtual interfaces to the operating system. From a single physical 40G or 2×40G connection to the FI, the VIC can create up to 256 vNICs (virtual Ethernet) and vHBAs (virtual Fibre Channel over Ethernet) in any combination. The OS sees these as standard Ethernet or FC HBAs — no awareness of the VIC abstraction. The number and configuration of vNICs/vHBAs is defined in the Adapter Policy within the Service Profile, not on the VIC itself. This allows the same hardware to be reconfigured remotely without touching the server. The VIC uses SR-IOV (Single Root I/O Virtualization) for VM direct access in virtualized environments, providing hardware-level isolation between VMs sharing the same physical card.
Q17. Explain the UCS boot from SAN process and the policies involved.
Boot from SAN in UCS requires: a Boot Policy (in the Service Profile) that specifies the boot order (SAN primary, SAN secondary, local disk fallback), the WWPN assigned to the server’s vHBA (from the WWN Pool in the Service Profile), and SAN connectivity configured via Fabric Interconnect through FCoE or native FC uplinks to the SAN fabric. The storage array must have the server’s WWPN in its zoning configuration. The Boot Policy specifies target storage arrays’ WWPNs (target and LUN ID). During POST, the VIC’s boot ROM contacts the SAN fabric, logs in with the assigned WWPN, zones are checked, and the OS boots from the configured LUN. A common CCIE scenario: boot policy is correct but the server still can’t boot — the answer is usually missing or incorrect SAN zoning for the server’s WWPN.
Category 5 — Storage Domain (15%) Storage Networking — FC, FCoE & NVMe-oF
Q18. Explain Fibre Channel zoning: hard zoning vs soft zoning, and WWN vs port-based zoning.
Soft zoning is enforced at the Name Server level — the FC switch’s Name Server only responds to queries from devices within the same zone. A device can technically still send frames to ports outside its zone (the frame will be forwarded if the correct port ID is used), but discovery and login are controlled. Hard zoning is enforced in hardware on the switch ASIC — frames from a source to a destination outside their common zone are dropped at line rate. Hard zoning is the secure default on MDS switches. For WWN zoning (also called World Wide Name or Soft zoning in some contexts): zones are defined by the WWN of the device. The zone is port-independent — if a host HBA moves to a different switch port, the zone still applies. Port-based zoning: zones are defined by the switch port number (domain, port pair). More secure (even if someone replaces the HBA, the new WWN won’t be zoned) but requires zone reconfiguration when cabling changes. Best practice: use WWN zoning for ease of management with hard zoning enforcement enabled on the switch.
Q19. What is FCoE and how does it handle lossless Ethernet requirements?
Fibre Channel over Ethernet encapsulates FC frames inside Ethernet frames (EtherType 0x8906). Since native Ethernet is lossy (congestion causes tail drops) and FC requires a lossless transport (no dropped frames, ever), FCoE depends on DCB (Data Center Bridging) extensions: PFC (Priority Flow Control, IEEE 802.1Qbb) applies PAUSE frames per-CoS priority instead of per-port, allowing FC traffic (on a dedicated CoS, typically CoS 3) to be paused independently from IP traffic. ETS (Enhanced Transmission Selection, IEEE 802.1Qaz) assigns bandwidth percentages to traffic classes, ensuring FC traffic gets guaranteed bandwidth. DCBX (DCB Exchange Protocol) negotiates and synchronizes PFC/ETS settings between connected FCoE devices. MDS switches and Nexus switches running FCoE must have DCB configured correctly for FCoE to function reliably.
# NX-OS FCoE QoS configuration system qos service-policy type queuing output fcoe-default-out-policy service-policy type queuing input fcoe-default-in-policy feature fcoe feature npiv # Verify DCB/PFC status show interface ethernet 1/1 priority-flow-control show queuing interface ethernet 1/1
Q20. What is NVMe-oF and how does it compare to iSCSI and FC for storage connectivity?
NVMe over Fabrics extends the NVMe protocol (designed for PCIe SSDs) over a network fabric instead of the PCIe bus. Unlike SCSI-based protocols (iSCSI, FCoE) which have SCSI command overhead and queue depth limitations (iSCSI has 1 queue of 32 commands per LUN; NVMe has 65535 queues of 65535 commands each), NVMe-oF maintains native NVMe performance and latency over the network. NVMe/TCP: runs NVMe-oF over standard TCP/IP, working on any Ethernet infrastructure. Easiest to deploy. NVMe/RDMA (RoCEv2): uses RDMA for kernel-bypass, achieving sub-microsecond latency. Requires PFC/DCQCN for lossless Ethernet. NVMe/FC: NVMe-oF over Fibre Channel. Preserves existing FC investment. The CCIE exam expects understanding of NVMe-oF transport types, the queue model differences from SCSI, and why enterprises are adopting it for all-flash and NVMe-based storage arrays.
|
Category 6 — Compute Domain HyperFlex & Hyperconverged Infrastructure |
☁️ |
Q21. What is Cisco HyperFlex? How does the HX Data Platform distribute and protect data?
HyperFlex is Cisco’s hyperconverged infrastructure platform built on UCS hardware. The HX Data Platform (HXDP) is a distributed file system that pools the local SSDs and HDDs from all HyperFlex nodes into a shared storage cluster. Key concepts: Replication Factor (RF2 or RF3): data is written to 2 or 3 nodes simultaneously. RF2 tolerates 1 node failure; RF3 tolerates 2. Compression and Deduplication: performed inline before data is written to disk. Read/Write acceleration: SSDs (or Intel Optane) provide write caching and read acceleration; HDDs or capacity SSDs provide bulk storage. Cluster healing: when a node fails, HXDP automatically re-replicates data from the remaining copies across surviving nodes. Minimum cluster size: 3 nodes for RF2, 4 nodes for RF3. HyperFlex integrates with VMware vSphere (via HX Data Platform VIBs installed on ESXi) and supports Kubernetes via HX platform for containerized workloads.
Q22. What is the HyperFlex Stretch Cluster and when would you deploy it over a standard cluster?
A HyperFlex Stretch Cluster spans two physical sites with a witness node at a third site. Nodes are evenly split between the two sites (e.g., 3+3 or 4+4). Data is written with RF2 or RF3 across both sites simultaneously — a write must be confirmed by nodes in both sites before it’s acknowledged. This means every write is synchronously replicated to the remote site, providing an RPO of 0 (no data loss if one site fails). The witness node at the third site provides the quorum decision when connectivity between the two primary sites is lost — the witness prevents split-brain. Requirements: low round-trip latency between sites (<5ms RTT recommended for optimal performance, <10ms maximum), a dedicated inter-site network with sufficient bandwidth. Deploy stretch clusters when you need zero-RPO storage replication without a separate DR storage solution. The penalty is write latency (every write waits for both sites to confirm).
|
Category 7 — Security Domain (5%) Data Center Security |
|
Q23. What is ACI microsegmentation and how does it differ from VLAN-based segmentation?
VLAN-based segmentation puts all devices in the same VLAN in the same broadcast domain — they can communicate freely within the VLAN. Security between VLANs requires an external firewall. ACI microsegmentation applies security policy at the EPG level: two VMs in the same VLAN (same Bridge Domain) can be placed in different EPGs and restricted by Contract policy, without any external firewall. The policy is enforced in the Nexus ASIC at line rate. ACI also supports uSeg EPGs (microsegmentation EPGs): endpoints are dynamically assigned to EPGs based on attributes (VM name, IP address, OS type, VM tag, physical location). This allows security policy to follow workloads automatically as they migrate, without changing the network configuration.
Q24. How does Cisco TrustSec integrate with ACI for end-to-end policy enforcement?
TrustSec uses SGTs (Security Group Tags) to carry policy group identity in packet headers (CMD header in Cisco Ethernet). ACI can receive SGT information from Cisco ISE via RADIUS and apply policy based on the SGT value. Integration modes: ACI as enforcer: ISE assigns SGTs to users/devices; ACI fabric enforces policy based on SGT. SGACL enforcement: ACI imports SGACL policies from ISE and enforces them in the leaf hardware. This allows a unified policy model: a user authenticated anywhere in the network carries their identity via SGT, and ACI enforces access control to data center resources based on that identity without needing per-IP ACL rules. The CCIE exam tests the ISE integration configuration, SGT import into APIC (External EPG with SGT attribute), and the Contract configuration that maps to SGT-based policies.
|
Category 8 — Networking Domain Cloud & Multi-Site Architecture |
☁️ |
Q25. What is Cisco Nexus Dashboard and what functions does it consolidate?
Nexus Dashboard (ND) is Cisco’s unified management platform for data center infrastructure. It replaces and consolidates multiple previous platforms. Key services running on ND: Nexus Dashboard Orchestrator (NDO), formerly Multi-Site Orchestrator — manages policy across multiple ACI fabrics (Multi-Site) and standalone NX-OS fabrics. Nexus Dashboard Insights (NDI) — provides telemetry analysis, anomaly detection, and flow analytics across ACI and NX-OS fabrics. Nexus Dashboard Fabric Controller (NDFC), formerly DCNM — manages NX-OS fabrics (non-ACI), including VXLAN EVPN fabric provisioning, SAN analytics for MDS, and LAN/SAN automation. ND runs as a cluster of virtual machines or physical appliances providing the platform; services are deployed as ND applications on top. For CCIE DC, understanding which service does what (NDO vs NDI vs NDFC) is a common distinction question.
Q26. What is Cloud ACI and how does it extend ACI policy to public cloud?
Cloud ACI runs Cisco’s APIC controller in the public cloud (AWS or Azure) and maps ACI policy constructs (Tenants, VRFs, EPGs, Contracts) to native cloud constructs. On AWS: VRFs map to VPCs, EPGs map to Security Groups, Contracts map to Security Group rules. On Azure: VRFs map to VNets, EPGs map to Application Security Groups. NDO (Nexus Dashboard Orchestrator) provides the single management plane across on-premises ACI sites and Cloud ACI sites. A workload migrated from on-premises to AWS retains its EPG membership and Contract policy — the policy follows the workload. Inter-site connectivity uses IPsec tunnels between Cloud APIC and on-premises ISN (Inter-Site Network). The CCIE exam tests Cloud ACI topology, the mapping of constructs, and NDO policy stretching.
|
Category 9 — Automation Domain (15%) Automation & Programmability |
烙 |
Q27. How do you use the ACI REST API to create a Tenant programmatically?
The ACI APIC exposes a full REST API. Authentication uses a POST to /api/aaaLogin.json with username/password, which returns a token. Subsequent API calls include the token in the cookie. Configuration uses JSON or XML payloads posted to the API. The payload structure mirrors the MIT (Management Information Tree) object model.
# Python example: Create ACI Tenant via REST API
import requests import json APIC = "https://10.0.0.1" # Step 1: Authenticate login_payload = {"aaaUser": {"attributes": {"name": "admin", "pwd": "password"}}} r = requests.post(f"{APIC}/api/aaaLogin.json", json=login_payload, verify=False) token = r.json()["imdata"][0]["aaaLogin"]["attributes"]["token"] cookies = {"APIC-cookie": token} # Step 2: Create Tenant tenant_payload = { "fvTenant": { "attributes": { "name": "Production", "descr": "Production Tenant" } } } r = requests.post(f"{APIC}/api/node/mo/uni.json", json=tenant_payload, cookies=cookies, verify=False) print(r.status_code, r.json())
Q28. What is YANG and how does it relate to NETCONF and RESTCONF?
YANG (Yet Another Next Generation, RFC 6020/7950) is a data modeling language that defines the structure, syntax, and semantics of configuration and operational data. It defines what data exists and what it looks like. NETCONF (RFC 6241) is a protocol that carries YANG-modeled data over SSH, using XML encoding. It provides operations: get-config, edit-config, commit, lock, validate. RESTCONF (RFC 8040) provides the same YANG data over HTTP/HTTPS using JSON or XML, using REST methods (GET, POST, PUT, PATCH, DELETE). The CCIE exam expects you to: navigate YANG models using tools like pyang, write NETCONF RPC calls in XML, understand the YANG path structure for NX-OS and IOS-XE models, and use Python’s ncclient library for NETCONF operations. YANG models are either native (vendor-specific, e.g., Cisco-IOS-XE-interfaces) or standard (IETF models, e.g., ietf-interfaces). Native models have more features; IETF models are portable across vendors.
Q29. How does NX-OS support Python scripting on-box and what are the limitations?
NX-OS includes a Python 3 interpreter accessible directly from the NX-OS CLI (python3) or via the NX-OS EEM (Embedded Event Manager) for event-triggered automation. The cli module in NX-OS Python lets you run NX-OS commands and parse output. Scripts run in the NX-OS Linux container (the NX-OS guest shell provides a full Linux environment). Limitations: on-box Python executes in the control plane — CPU-intensive scripts can impact device stability; libraries are limited to what’s installed in the guest shell; outbound connectivity from the script requires routing from the management VRF. For production automation, off-box tools (Ansible, Nornir) connecting to NX-OS via NETCONF/SSH are preferred for scale. On-box Python is suitable for device-local automation (health checks, reactive configuration changes triggered by EEM).
|
Category 10 — Exam Strategy Lab Strategy, Study Plan & Additional Q&A |
|
Q30. What is the structure of the CCIE DC Lab exam and how should you approach time management?
The CCIE DC Lab is 8 hours with a break. It consists of multiple modules covering the exam topic domains. There are no partial-credit hints about what’s wrong — a task either works or it doesn’t. Time management approach:
(1) Read the entire exam first (15 minutes). Note dependencies between tasks — Task 5 might require what you configure in Task 2.
(2) Start with tasks you know cold. Don’t spend 45 minutes on a complex ACI task you’re uncertain about when 3 storage tasks worth the same points are straightforward. (3) Keep a mental note of what you skipped. Verify completed tasks before moving to the next — a task that seems done but has a misconfiguration will fail verification.
(4) Leave 30–45 minutes at the end for a verification pass. Many candidates lose points on tasks they thought were correct but had a missed detail.
Q31. What is Cisco DCNM (now NDFC) and how does it automate VXLAN EVPN fabric provisioning?
NDFC (Nexus Dashboard Fabric Controller) provides intent-based fabric management for NX-OS-based VXLAN EVPN fabrics (Easy Fabric) and MDS SAN fabrics. For VXLAN provisioning: you define the fabric parameters (underlay protocol, loopback ranges, VTEP IP pools, BGP AS numbers, VRF routes), and NDFC pushes the complete underlay and overlay configuration to all switches automatically. You add VLANs, VRFs, and networks through the NDFC UI; it renders the NX-OS configuration and deploys it. Key NDFC concepts: Fabric Templates (Easy Fabric, Easy Fabric eBGP, External Fabric), Policies (device-level configuration that NDFC manages), Brownfield import (importing existing manually-configured fabrics into NDFC management). The exam tests NDFC fabric creation, VRF/network addition workflow, and SAN fabric management tasks.
Q32. What are the Cisco CCIE DC recommended lab practice resources?
Resources that actually matter for CCIE DC preparation:
| Resource | What It Covers |
| Cisco dCloud | Free ACI, UCS, MDS, NX-OS labs from Cisco. Essential for hands-on practice without expensive hardware. |
| Cisco ACI Simulator | Virtual APIC + leaf simulation. Available on Cisco’s developer portal. Practice ACI policy configuration at scale. |
| NX-OS in Containerlab / GNS3 | Virtual Nexus 9000v for NX-OS and VXLAN EVPN practice. Requires Cisco account for NX-OS image download. |
| Cisco Learning Network | Official Cisco CCIE forums. Candidates share recent exam topics. Most valuable resource for understanding what’s currently on the lab. |
| Third-party training (INE, CBT Nuggets, Nick Russo) | Structured video training and workbooks. Nick Russo’s CCIE DC blog contains deep technical content frequently aligned with real exam topics. |
Additional High-Value CCIE DC Questions
| Question | Key Answer Points |
| What is APIC HA and how does the APIC cluster maintain quorum? | 3-node APIC cluster minimum. Quorum requires (>N/2) nodes reachable. Policy is replicated across all nodes. If quorum is lost, reads continue but writes fail. A 3-node cluster can lose 1 node; loses 2 = no writes to fabric. |
| What is VTEP flooding in a VXLAN fabric and when does ingress replication replace multicast? | BUM traffic uses multicast (requires PIM in underlay) or ingress replication (headend replication via EVPN Type 3). Most deployments avoid multicast in the underlay due to complexity; BGP EVPN with ingress replication is the modern preferred approach. |
| What is POAP (PowerOn Auto Provisioning) on NX-OS? | Zero-touch provisioning. Switch boots with no config, contacts DHCP, gets IP + TFTP server, downloads a Python POAP script. Script downloads the appropriate NX-OS image and config file based on serial number. Used by NDFC and ACI bootstrap. |
| What is the Cisco MDS 9000 series role in modern DC storage? | MDS is Cisco’s Fibre Channel SAN switch. Provides FC switching, zoning, FCoE, FCIP (FC over IP for SAN extension), NPIV (N-Port ID Virtualization for virtual HBAs), NPV (N-Port Virtualization for edge switches), and SAN analytics. Still widely deployed for mission-critical FC storage fabrics. |
| What is ACI Contract Scope and how does it limit policy application? | Scope determines where a Contract can be consumed: Application-EPG (only within the EPG, meaningless), Application-Profile (within same profile), VRF (within the VRF, most common), Tenant (all VRFs in tenant), Global (any tenant). Wider scope = more EPGs can consume the Contract without re-creating it. |
| What is PBR (Policy-Based Redirect) in ACI and what use case does it enable? | PBR redirects traffic between two EPGs through a service device (L4–L7: firewall, load balancer, IDS) using a Service Graph. Instead of traffic flowing directly from provider to consumer EPG, the fabric redirects through the service. Traffic is redirected at line rate by the leaf ASIC without requiring the service device to be in the L3 path. Critical for inserting firewalls without changing IP addressing. |
| What is UCS Director and how does it relate to UCSM? | UCS Director is an IT orchestration platform that automates the provisioning of compute, network, storage, and virtualization resources. It sits above UCSM (which manages UCS hardware) and provides multi-domain workflows: create a VM → provision a Service Profile → configure SAN zoning → update VMware vCenter, all in one automated workflow. UCSM manages hardware; UCS Director orchestrates multi-domain workflows. |
| How does ACI handle ESXi VMware integration (VMM Domain)? | ACI VMM Domain connects APIC to vCenter. APIC creates a DVS (Distributed Virtual Switch) in vCenter and manages port groups for each EPG. When a VM is placed in an EPG port group, ACI automatically provisions the correct VLAN on the leaf port connected to the ESXi host. Policy follows the VM as it vMotions to another host. |
CCIE DC Study Plan — 12-Month Roadmap
| Phase | Duration | Focus Areas |
| Phase 1 | Months 1–3 | Blueprint study: Cisco documentation for each topic. Cisco Press books for ACI and NX-OS. Pass the 350-601 DCCOR qualifying exam by end of phase. |
| Phase 2 | Months 4–7 | Deep lab practice: ACI on dCloud or simulator, VXLAN EVPN on Nexus 9000v/Containerlab, UCS on dCloud. Build each topology from scratch, break it, troubleshoot it. |
| Phase 3 | Months 8–10 | Timed practice labs: set an 8-hour timer and work through full scenario labs. Automate routine tasks with Python/Ansible. Weak area remediation based on gaps identified in timed labs. |
| Phase 4 | Months 11–12 | Final preparation: speed drills on known tasks, verification techniques, time management. Schedule lab exam. Review Cisco Learning Network for recent candidate reports. Book the lab 4–6 weeks out to maintain momentum. |
What Separates CCIE DC Passers from Repeat Candidates
| Lab speed, not just knowledge | Knowing how to configure ACI isn’t enough. You need to configure it in 12 minutes, verify it in 3 minutes, and move to the next task. Speed comes only from repetition. |
| Verification discipline | Never mark a task complete without verifying it. Know the specific verification command for every feature. The grader script tests the exact outcome, not the config commands you typed. |
| Cross-domain breadth | Most candidates are strong in networking but weak in storage or automation. CCIE DC requires genuine competence across all domains — you can’t compensate for storage gaps with networking excellence. |
| Calm under pressure | Eight hours is long enough to panic, recover, and still pass. If a task isn’t working, note it and move on. Come back with fresh eyes. Panic-spending 90 minutes on a 2-point task is how candidates fail with good technical knowledge. |
