Cisco DCACI 300-620 common mistakes
Cisco DCACI 300-620 · Understand the traps and how to avoid them.
Treating the APIC cluster as a single control-plane node and answering sizing/availability questions as if one APIC failure simply reduces capacity, without distinguishing which APIC roles (standby, active, controller) exist and how quorum and sharding behave.
Candidates memorize 'three APICs for production' but never learn the sharded, replicated data model, so they cannot reason about what breaks when one or two APICs are lost, or why one- and two-node clusters are lab-only.
What to do instead
Study the APIC cluster as a distributed database with shards and replicas: each APIC holds shards, data is replicated, and a majority of APICs must be reachable for configuration writes. Map each failure scenario (one APIC down, two down, split) to read/write behaviour, and know that a single-node cluster is supported only for lab use.
Assuming the spine layer forwards traffic between leaf switches, and drawing the fabric data path as leaf-to-spine-to-leaf for endpoint-to-endpoint flows.
The spine is compared to a traditional core switch, so candidates apply classic three-tier forwarding logic. In practice spines are stateless VXLAN routers that do not learn endpoint addresses, and leaf-to-leaf traffic is encapsulated and routed by the spine without the spine tracking endpoints.
What to do instead
Trace a packet explicitly: source leaf does proxy and VXLAN encapsulation using the destination leaf's tunnel endpoint address learned from the COOP database, the spine routes on the outer header only, and the destination leaf decapsulates. Remember spines hold no endpoint table, so any question implying spine-based endpoint learning is a trap.
Confusing the roles of the infra, management, and in-band tenants/VLANs, and placing APIC or switch management addresses on the wrong network or VLAN pool.
The three logical networks look similar in the GUI and candidates configure an in-band management address on an interface that has no infrastructure VLAN, or expect APIC reachability through an in-band path that was never provisioned.
What to do instead
Learn the three networks separately: the infra VLAN carries fabric control traffic (COOP, IS-IS) and must be enabled per interface; out-of-band management uses the mgmt0 interface on each node; in-band management requires an in-band EPG with a static path to the correct leaf interface. Know which network APIC uses to reach each switch and how to verify with fabric node addressing.
Configuring an external connection by binding an EPG or L3Out to a leaf interface without first creating the interface policy group, interface profile, and switch profile chain, then expecting the configuration to deploy.
ACI is policy-driven and declarative: nothing reaches a switch until the full object chain resolves to a concrete interface. Candidates coming from CLI-based platforms skip the intermediate policy objects and see no faults or a silently unconfigured port.
What to do instead
Memorize the chain: interface policy (speed, CDP/LLDP, LACP, storm control) plus a leaf interface profile (port selector with block and port range) inside a leaf profile attached to the switch. Bind EPGs or L3Out logical interfaces to that policy group. Verify deployment with the interface configuration and fault screens, not just the EPG screen.
Mixing up the VXLAN encapsulation details in the packet-flow domain, such as which addresses appear in the outer header, whether the outer IP is the leaf tunnel endpoint or the endpoint's gateway, and where the VXLAN network identifier comes from.
The inner and outer headers are easy to conflate when studying from diagrams, and candidates forget that the source leaf uses its own tunnel endpoint address and the destination leaf's tunnel endpoint address, with the VNI derived from the bridge domain or EPG mapping.
What to do instead
Practice writing out both headers for a concrete flow: inner Ethernet and IP with the endpoint addresses, outer IP with leaf tunnel endpoint addresses, UDP destination port 4789, and the VNI. Then state what each leaf does on ingress and egress, and note that the fabric does not use VXLAN for traffic destined outside the fabric until a gateway decapsulates it.
Assuming a bridge domain is a broadcast domain that floods unknown unicast to every leaf, rather than accounting for the endpoint learning and unknown-unicast handling behaviour configured on the bridge domain.
Traditional switching intuition says unknown unicast floods everywhere. ACI instead uses the COOP database and distributed endpoint learning, and behaviours such as unknown unicast flooding, ARP flooding, and unicast routing are per-bridge-domain settings that change the answer.
What to do instead
Learn the bridge domain knobs explicitly: unknown unicast flooding on or off, ARP flooding on or off, unicast routing, and the associated VRF. Then reason about a flow with the setting in question: with unknown unicast flooding disabled, an unlearned destination is dropped rather than flooded, and endpoint learning must be understood per bridge domain and VRF.
Treating contracts as simple permit or deny access lists and forgetting that contracts are applied at the EPG or VRF boundary with provider and consumer roles, filters, and subjects.
Candidates map contracts to firewall rules and miss that both sides must reference the same contract, that the provider must offer it and the consumer must import it, and that filters define direction and ports within subjects.
What to do instead
Study a contract end to end: a provider EPG offers a contract, a consumer EPG imports it, and the contract contains subjects with filters that specify EtherType, protocol, ports, and direction. Know that intra-EPG traffic is allowed by default, that a contract is needed between EPGs in different VRFs or with enforcement enabled, and how taboos and contract scope (application profile, tenant, VRF) change behaviour.
Configuring an L3Out and expecting routes to appear without verifying the routing protocol adjacency, the loopback and router-ID configuration, and the export of routes into the fabric.
The L3Out requires a logical node profile, logical interface profile, and at least one routed interface or sub-interface, plus a routing protocol with matching timers and authentication. Candidates create the external EPG but skip the pieces that make the adjacency form and the routes redistribute.
What to do instead
Build the L3Out in order: VRF, logical node profile with router ID, logical interface profile with routed interface or SVI, external EPG with subnets and route control, then the protocol (OSPF, BGP, or EIGRP) with the correct area or AS and route redistribution. Verify with the routing table, adjacency status, and contract between the external EPG and internal EPGs.
Confusing the fabric management and integration domain by treating the APIC REST API as a simple CRUD interface and ignoring authentication, the distinguished-name object model, and the difference between configuration and operational queries.
Candidates with scripting experience assume REST endpoints are resource paths, but APIC uses a class-based, hierarchical distinguished-name model with token or certificate authentication, and query targets differ for configuration versus statistics.
What to do instead
Learn the APIC REST basics: obtain a token from the login endpoint or use certificate-based authentication, build distinguished names from the object hierarchy (tenant, application profile, EPG), and use class queries versus distinguished-name queries appropriately. Practice reading a fault or health query and know that configuration changes are made against the managed object, not a flat resource path.
Ignoring the fabric connectivity domain's external connectivity options and answering questions as if all external traffic must pass through an L3Out, without distinguishing routed L3Out, stretched Layer 2, and the use of a border leaf or border spine.
The exam tests design choices, and candidates memorize one connectivity pattern rather than the conditions that select among them, such as whether the external device is Layer 2 or Layer 3, whether a VRF is needed, and where the border role sits.
What to do instead
Compare the external connectivity patterns explicitly: routed L3Out on a border leaf for Layer 3 peers, Layer 2 external connectivity via an external bridged domain and external EPG for stretched segments, and the border leaf or border spine role for gateway functions. For each, note the required objects, the failure behaviour if the border node fails, and when a VRF or contract is required.