300-610 Designing Cisco Data Center Infrastructure Exam Topics and Questions

Network Design carries the largest share of the exam, and it earns that weight. This is where architectural decisions compound: a wrong call on Layer 2 redundancy affects convergence, which affects QoS, which affects whether your AI workload can sustain lossless throughput. The domain spans everything from GPU-cluster fabric requirements through VXLAN EVPN multi-site interconnects. Get comfortable making design trade-offs, not just naming technologies.

– AI/ML workloads and the hardware underneath them

The exam treats AI/ML as a design driver, not a background concept. You need to understand why training jobs and inference jobs make different demands on the network: training is all-to-all and bandwidth-hungry, inference is latency-sensitive and often bursty. That difference changes which fabric technology you recommend. GPUs dominate the compute side, but DPUs and SmartNICs are increasingly relevant because they offload network processing that would otherwise steal GPU cycles. Operational sustainability sits here too: a design that runs hot or wastes power fails on a longer timescale than a configuration error. Know how these hardware choices feed into network requirements before you touch any protocol.

– High-performance fabric technologies

ROCEv2, InfiniBand, and standard Ethernet are not interchangeable, and the exam will put you in scenarios where you have to justify the choice. ROCEv2 carries RDMA semantics over Ethernet and depends on a lossless fabric to function correctly; a single dropped packet during a collective operation can stall the entire job. InfiniBand offers lower latency and native RDMA but brings its own cabling, switch ecosystem, and cost profile. RDMA itself reduces CPU involvement in memory transfers, which matters enormously at scale. The testing angle is almost always a scenario: given a workload type and a budget or infrastructure constraint, which transport is the better fit and what must the network guarantee to make it work?

– Layer 2 and Layer 3 connectivity options

Layer 2 design questions centre on what happens when things move or fail. Endpoint mobility determines how MAC and IP state follows a workload; redundancy and high availability determine how quickly the fabric recovers; convergence time is the measurable outcome of both. Services insertion at Layer 2 means knowing where a firewall or load balancer can be placed without breaking the forwarding model. vPC and LACP appear together because vPC relies on LACP to form port channels across two switches, and misunderstanding that relationship is a common source of errors.

At Layer 3, the same themes reappear with different mechanisms. IP mobility, graceful restart, and NSF all address continuity during a control-plane event. VRF Lite is the lightweight path to routing virtualization when a full MPLS deployment is not warranted. Services insertion at Layer 3 brings load balancing and security into the routing domain, and the design question is always about symmetric return traffic.

– QoS, VXLAN EVPN, management, and segmentation

Lossless Ethernet for storage and AI workloads requires Priority Flow Control and DSCP markings applied consistently end to end. A single hop that drops the wrong traffic class can corrupt an RDMA session. QoS design is therefore a policy consistency problem as much as a bandwidth problem.

VXLAN EVPN for data-center interconnect adds an overlay layer where MAC and IP reachability is distributed through BGP. The design decisions involve control-plane scale, BUM traffic handling, and how stretched Layer 2 segments interact with Layer 3 gateways.

Management redundancy covers in-band versus out-of-band access, active/active versus disaster-recovery site topologies, and centralised tools such as Nexus Dashboard. Network segmentation via VXLAN and Cisco ACI rounds out the domain: understand VRF-to-VNI mapping and how ACI enforces policy at the endpoint group boundary, because those are the points where segmentation design either holds or breaks.

How Network Design is tested

At 35% of the exam, this domain will appear in more items than any other. Expect scenario-driven questions that give you a specific workload profile, a failure condition, or a business constraint and ask which design decision best satisfies it. Items reward candidates who can reason about second-order effects: choosing ROCEv2 implies lossless Ethernet, which implies PFC, which implies specific QoS configuration. Knowing the chain matters more than knowing any single protocol.

Candidates lose marks most often in two places. First, they treat Layer 2 and Layer 3 options as separate checklists rather than interacting choices. A vPC design decision affects where Layer 3 adjacencies form, which affects convergence. Second, they underestimate the AI/ML sub-area. GPU and DPU distinctions, and the training-versus-inference split, are not background colour: they drive the answer on fabric technology selection. Spend time on the VXLAN EVPN interconnect material too; multi-site scenarios are a reliable source of items that reward understanding the control plane, not just the encapsulation.

Where Network Design asks you to reason about the fabric, Compute Design asks you to reason about what attaches to it. The domain is dominated by Cisco UCS architecture: how servers connect to Ethernet and storage networks, how the fabric interconnect shapes traffic, and how virtualisation abstracts the physical adapter into policy-driven constructs. AI/ML compute requirements tie this domain back to the previous one, so gaps here tend to show up as wrong answers in both areas.

– Ethernet and storage connectivity through the fabric interconnect

The fabric interconnect is the pivot point for both Ethernet and storage traffic, and its operating mode changes the forwarding behaviour fundamentally. In end-host mode, the fabric interconnect does not participate in Spanning Tree and presents itself as a host to the upstream network; in switch mode, it behaves as a standard switch and STP is active. That distinction drives several downstream design decisions around redundancy and loop prevention.

For Ethernet connectivity, bandwidth and oversubscription ratios determine whether a blade chassis can sustain the traffic its workloads generate under load. For storage connectivity, the same fabric interconnect carries Fibre Channel over FCoE or direct FC ports alongside iSCSI, and the port type determines which adapter policies apply. Direct-attached storage options, including FC appliances and FCoE ports, each carry different bandwidth and latency profiles that the exam expects you to match to a deployment scenario.

– Virtualisation with Cisco VIC adapters and UCS-X design

Cisco VIC adapters are the mechanism by which a single physical adapter presents multiple virtual NICs and virtual HBAs to the operating system. The exam focuses on how policy objects control that behaviour. Service profiles bind a server's identity, including MAC addresses, WWNs, boot order, and adapter configuration, to a physical blade. Ethernet adapter policies govern queue depth, interrupt handling, and offload settings for virtual NICs. Fibre Channel adapter policies do the same for virtual HBAs. The key design insight is that these policies are portable: a service profile can move to a replacement blade and the server comes up with the same identity.

UCS-X design questions layer performance and deployment requirements on top of that policy model. You need to evaluate chassis and fabric module combinations against workload density and redundancy requirements. AI/ML compute requirements appear here as a design constraint: GPU-heavy nodes have different connectivity and power profiles than general-purpose blades, and the design must account for that from the fabric interconnect upward.

How Compute Design is tested

At 25%, Compute Design is the second-largest domain. Items here tend to be scenario-based: a deployment has a specific redundancy requirement or a workload has a specific bandwidth need, and you select the configuration or architecture that satisfies it. The fabric interconnect operating mode is a reliable source of difficulty because the consequences of choosing switch mode versus end-host mode ripple through STP behaviour, upstream switch configuration, and failover timing. Candidates who have memorised the mode names without understanding the forwarding implications pick the wrong option in context.

Service profiles and adapter policies are another area where marks are lost. The exam rewards understanding which policy object controls which behaviour, and what happens when a local policy overrides a global one. Items on UCS-X often require you to weigh two valid design options against a stated constraint, such as maximising compute density while maintaining redundant fabric paths. The AI/ML compute sub-topic connects directly to Network Design: an item may describe a GPU cluster requirement and expect you to reason about both the adapter configuration and the upstream fabric simultaneously.

Storage Network Design is the domain where protocol knowledge has to translate directly into port-level and fabric-level decisions. iSCSI and Fibre Channel are not interchangeable paths to the same outcome: they differ in addressing, multipathing behaviour, QoS requirements, and oversubscription tolerance. Candidates who treat this as a memorisation exercise tend to stumble when the exam presents a scenario that mixes FC zoning constraints with iSCSI multipathing requirements in the same design.

– iSCSI deployment and QoS requirements

iSCSI runs storage traffic over standard IP networks, which means addressing and multipathing work differently than in a native FC environment. Multipathing for iSCSI relies on software initiators or hardware offload engines presenting multiple paths to the same target, and the addressing scheme, whether using dedicated VLANs, jumbo frames, or separate subnets, affects both performance and fault isolation. A design that skips dedicated storage VLANs or ignores MTU consistency across the path will produce intermittent errors that are hard to diagnose.

QoS requirements differ between Fibre Channel and iSCSI because their loss tolerance differs. FC is inherently lossless through buffer-to-buffer credits; iSCSI running over Ethernet needs explicit QoS policy, including DSCP markings and, in high-performance environments, Priority Flow Control, to approximate lossless behaviour. The exam expects you to know which QoS mechanisms apply to which protocol and why dropping a single iSCSI frame has consequences that a dropped Ethernet data frame does not.

– Fibre Channel interfaces, ISLs, and storage deployment options

Fibre Channel port types carry specific roles: N-ports connect hosts, F-ports connect to switches, E-ports form ISLs between switches, and getting the type wrong means the link does not come up. ISL design is where oversubscription becomes a fabric-level concern rather than a server-level one: too few ISL ports between directors or edge switches creates a bottleneck that no host-side multipathing can fix.

Oversubscription ratios in FC fabrics are a design constraint, not just a performance metric. A 7:1 oversubscription ratio acceptable for general-purpose file access is not acceptable for a high-performance database or an AI training checkpoint workload. Storage deployment options for high-performance networks may involve NVMe over Fabrics, which brings its own latency and queue-depth expectations. The exam places you in scenarios where you must choose a deployment model based on stated performance requirements, redundancy needs, and the existing fabric infrastructure, rather than defaulting to the most feature-rich option.

How Storage Network Design is tested

Storage Network Design accounts for 20% of the exam. Items in this domain reward candidates who can move between protocol characteristics and practical design outcomes. A question may describe a symptom, such as storage timeouts during peak load, and expect you to identify the design flaw, whether that is an ISL oversubscription problem, a missing QoS policy, or an iSCSI addressing error.

The Fibre Channel port type and ISL material is precise: the exam distinguishes between port roles and expects you to apply that knowledge to a described topology. Candidates lose marks by conflating E-port and F-port behaviour, or by applying iSCSI multipathing logic to an FC scenario. The QoS sub-topic is another trap: the mechanisms that protect iSCSI traffic are not the same as those that protect FC, and items often describe a mixed environment where you need to apply different policies to different traffic classes. Oversubscription calculations appear in scenario form; knowing the acceptable ratio for a given workload type is more useful than knowing the formula in isolation.

Automation Design shares the 20% weight with Storage Network Design, but it tests a different kind of thinking. Here the exam is not asking whether you can write a Python script or a Terraform plan: it is asking whether you can evaluate which automation approach fits a given operational model and scale requirement. The domain spans network orchestration, compute orchestration through UCS policy templates, and deployment automation via Nexus Dashboard. Candidates who have only hands-on CLI experience often find this domain uncomfortable.

– Network orchestration and programmability tools

Cisco Intersight is the cloud-based management plane that ties compute and network automation together, and the exam treats it as a design choice with trade-offs, not just a product name. REST API knowledge here is functional: you need to understand that NX-API exposes Nexus switch configuration programmatically, that JSON and XML are the encoding options, and that the choice between them affects how a tool consumes the response. Model-driven programmability through YANG models and NETCONF or RESTCONF is a distinct approach from NX-API, and the exam distinguishes them by use case.

Ansible and Python represent two points on the automation spectrum: Ansible is agentless and declarative, Python is imperative and flexible. The design question is which fits the operational team's capability and the task's complexity. Terraform CLI brings infrastructure-as-code patterns to data-centre provisioning, treating network and compute resources as state to be declared and reconciled. Knowing when each tool is the right fit matters more than knowing its syntax.

– Compute orchestration through UCS policy templates

Service profile templates, vNIC templates, and vHBA templates are the mechanisms by which UCS scales consistent configuration across dozens or hundreds of servers without per-server manual work. The design distinction between global policies and local policies is where the exam tests understanding rather than recall: a global policy applies across the domain and a local policy overrides it for a specific object. Getting that relationship wrong in a design means one group of servers behaves differently from the rest in ways that are difficult to audit.

vNIC templates define the Ethernet adapter characteristics that get stamped into a service profile, and vHBA templates do the same for Fibre Channel. The exam expects you to know which template type controls which adapter behaviour, and how template updates propagate to bound service profiles. These are not abstract policy objects: they are the mechanism by which a compute design scales without configuration drift.

– Intersight Cloud Orchestrator and Nexus Dashboard deployment

Cisco Intersight Cloud Orchestrator introduces workflow-based automation: a sequence of tasks, conditions, and rollback steps that execute against Intersight-managed infrastructure. The exam covers this at the design level, meaning you need to understand what a workflow can orchestrate and where its scope ends, not how to build one from scratch.

Nexus Dashboard as an automatic network deployment platform brings Day 0 and Day 1 provisioning into a centralised interface. The design question is how Nexus Dashboard fits into an existing operational model: which deployment tasks it can automate, how it integrates with external orchestration systems, and what the failure modes look like when automation encounters a device in an unexpected state. Items in this area reward candidates who understand the operational boundary between what Nexus Dashboard manages and what still requires direct device interaction.

How Automation Design is tested

Automation Design at 20% tends to produce items that mix tool knowledge with operational reasoning. The exam will describe a team's existing toolchain or skill set and ask which automation approach best extends it, or it will describe a failure scenario in an automated workflow and ask what the design should have included to prevent it.

Candidates lose marks most often by treating tool selection as a matter of preference rather than fit. Ansible versus Python versus Terraform is not a free choice in a scenario: the described environment constrains the answer. The global-versus-local policy distinction in UCS compute orchestration is another reliable source of errors; candidates who understand the hierarchy avoid the trap of selecting a configuration that appears correct but silently gets overridden.

Intersight Cloud Orchestrator workflow items reward understanding scope and sequence. The Nexus Dashboard deployment sub-topic rewards knowing the boundary of what centralised automation handles versus what falls outside it. Neither sub-topic requires you to produce configuration; both require you to evaluate a described design against a stated requirement and identify the stronger option.