300-620 DCACI — Cisco Data Center ACI Implementation 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. . An engineer is reviewing the ACI logical model. Which hierarchical order correctly represents the ACI object model from the top-level container to the most specific policy unit for client segmentation?

   • A. Tenant → VRF → Bridge Domain → Application Profile → EPG(correct)
   • B. Tenant → Bridge Domain → VRF → EPG → Application Profile
   • C. VRF → Tenant → Application Profile → Bridge Domain → EPG
   • D. Tenant → Application Profile → EPG → VRF → Bridge Domain

   Explanation: The ACI logical model hierarchy is: Tenant (administrative domain) → VRF (routing domain / IP namespace) → Bridge Domain (L2 flood domain with an associated subnet) → Application Profile (logical grouping of EPGs) → EPG (Endpoint Group — the policy unit defining which endpoints share a contract enforcement boundary). A single Tenant can have multiple VRFs; each Bridge Domain belongs to one VRF; EPGs are organized within Application Profiles. Options B, C, and D all misplace one or more levels in the hierarchy.

2. . During APIC cluster commissioning, an engineer checks the APIC cluster health. The APIC management guide states that a 3-node APIC cluster requires a quorum. Which statement is TRUE regarding APIC cluster quorum and the role of the policy manager?

   • A. A 3-node APIC cluster requires all 3 nodes to be healthy for policy writes; if any single node fails, the cluster enters read-only mode and no configuration changes are permitted until quorum is restored.
   • B. A 3-node APIC cluster requires 2 out of 3 nodes (quorum) for policy reads and writes; one APIC shard acts as the 'Policy Manager' (shard leader) and processes configuration changes; with only 1 node available, the cluster loses quorum and enters read-only mode.(correct)
   • C. APIC clusters do not use quorum; each APIC node processes policy writes independently and synchronizes with peers asynchronously, so any single APIC can accept and apply configuration changes at all times.
   • D. A 3-node APIC cluster designates one node as Active and two as Observer; only the Active node processes policy, and the Observers replicate state but cannot accept configuration changes even if the Active node fails.

   Explanation: Cisco ACI APIC uses a distributed object store (the policy management infrastructure) with shard-based replication across the cluster. A 3-node cluster requires a majority quorum (2 of 3) to allow policy writes. The APIC cluster internally elects shard leaders (Policy Manager role per shard) that process configuration operations. If only 1 APIC is available, the cluster loses quorum and transitions to read-only mode — existing policy continues to run on the fabric, but no new configuration changes are accepted. Option A requiring all 3 for writes is too strict. Option C incorrectly claims no quorum. Option D describes an incorrect Active/Observer model that does not match APIC architecture.

3. . An ACI fabric uses in-band management to reach the APIC cluster from within the fabric. An engineer configures a new APIC node and must specify its in-band management IP address. Where is the in-band management address configured in the ACI logical model?

   • A. Under Fabric > Access Policies > Node Management Addresses, using the in-band management EPG in the 'mgmt' tenant under the oob-mgmt-addr configuration object.
   • B. Under Tenants > mgmt > Node Management Addresses > In-Band Management Addresses; the IP address is applied to the APIC's in-band EPG (inb), which connects the APIC to a bridge domain in the mgmt tenant specifically reserved for fabric management traffic.(correct)
   • C. In-band management IPs for APICs are configured via DHCP only; static in-band management addresses are not supported in ACI fabric management policies.
   • D. The APIC in-band management IP is configured directly on the APIC's eth0 interface via the initial setup script; no ACI policy objects are involved after initial commissioning.

   Explanation: ACI management addressing is handled as a policy object under the management tenant. For in-band management, the engineer navigates to Tenants > mgmt > Node Management Addresses > In-Band Management Addresses (MO class: mgmtInBStNode) and creates an entry specifying the node ID range and the IP/gateway. The mgmt tenant contains a built-in inb Bridge Domain and inb EPG that connects to the fabric's in-band management VLAN. Out-of-band management uses a separate oob EPG and external connectivity. Option A mixes in-band and out-of-band (oob-mgmt-addr). Option C incorrectly states static IPs are unsupported. Option D is incorrect for in-band policy — eth0 is the APIC's out-of-band physical interface.

4. . During an ACI fabric upgrade, a maintenance group is used to stage the upgrade. An engineer creates a maintenance group containing leaf nodes 101–110 and initiates a firmware upgrade via a firmware policy. The pre-upgrade validation check fails with 'vPC Peer Incomplete'. What does this validation failure indicate, and how should the engineer resolve it?

   • A. The validation failure indicates that the maintenance group contains both vPC peer leaf nodes (e.g., leaf 101 and leaf 102 form a vPC pair); ACI upgrade validation prevents both peers in a vPC pair from being upgraded simultaneously to avoid traffic loss. The engineer must split the maintenance group so that only one peer per vPC pair is in each upgrade group, then upgrade the second peer after the first successfully upgrades and comes back online.(correct)
   • B. The validation failure means one of the leaf nodes in the maintenance group does not have a valid LLDP neighbor relationship with a spine node; the engineer must re-cable the leaf to the spine and wait for fabric rediscovery before proceeding.
   • C. vPC Peer Incomplete is a cosmetic warning that does not block the upgrade; the engineer can safely ignore it and proceed with the upgrade by clicking 'Override Validation' in the APIC GUI.
   • D. This error indicates the firmware package has not been downloaded to the APIC; the engineer must manually SCP the firmware image to the APIC's bootflash before the maintenance group upgrade can proceed.

   Explanation: ACI's pre-upgrade validation (pre-check) specifically detects when a maintenance group includes both nodes in a vPC domain pair. Upgrading both vPC peers simultaneously would bring down the vPC peer-link and all associated vPC uplinks, causing traffic loss for dual-homed hosts. The validation blocks this scenario and reports 'vPC Peer Incomplete' or similar. The resolution is to separate vPC pairs into different maintenance groups (or use staggered upgrade windows): upgrade one peer, confirm it rejoins the fabric and vPC is operational, then upgrade the other peer. ACI handles the upgrade in a rolling fashion within a maintenance group to minimize disruption, but the peer-separation logic must be respected. Options B, C, and D are incorrect.

5. . An engineer queries the APIC REST API to retrieve the configuration of an Application Profile named 'WebApp' in the 'Production' tenant. Which Distinguished Name (DN) correctly identifies this object, and what is the Relative Name (RN) component for an Application Profile?

   • A. DN: uni/tn-Production/ap-WebApp | RN for Application Profile: ap-<name>(correct)
   • B. DN: uni/tenant-Production/profile-WebApp | RN for Application Profile: profile-<name>
   • C. DN: uni/tn-Production/app-WebApp | RN for Application Profile: app-<name>
   • D. DN: uni/tn-Production/appProfile-WebApp | RN for Application Profile: appProfile-<name>

   Explanation: ACI uses a hierarchical Management Information Tree (MIT) with Distinguished Names built from concatenated Relative Names. The ACI object model uses specific RN prefixes for each class: Tenant uses 'tn-', Application Profile uses 'ap-', EPG uses 'epg-', VRF uses 'ctx-', Bridge Domain uses 'BD-'. Therefore: uni (root) / tn-Production (fvTenant) / ap-WebApp (fvAp). The full DN is 'uni/tn-Production/ap-WebApp'. This DN can be used directly in APIC REST API GET or POST requests. Options B, C, and D use incorrect RN prefixes ('tenant-', 'app-', 'appProfile-') that do not correspond to actual ACI object classes.

6. . In an ACI fabric, a new endpoint (VM1 with IP 10.1.1.10, MAC aa:bb:cc:dd:ee:01) sends its first ARP request after coming online on leaf 101. Which statement describes how ACI learns this endpoint locally on leaf 101?

   • A. Leaf 101 learns VM1's MAC and IP by snooping the ARP request packet arriving on the access port; it records the source MAC (aa:bb:cc:dd:ee:01) and source IP (10.1.1.10) from the ARP request, adds the entry to its local endpoint table (COOP), and installs a host route /32 for 10.1.1.10 pointing to the access port.(correct)
   • B. Leaf 101 does not perform data-plane endpoint learning; all endpoint MAC and IP associations must be statically provisioned in the APIC before a VM can communicate in the fabric.
   • C. Endpoint learning happens only on the spine proxy; leaf 101 forwards the ARP to the spine's COOP database, and the spine returns the IP-to-MAC binding to leaf 101, which then programs its local table.
   • D. ACI learns endpoints only via DHCP snooping; ARP-based learning is disabled by default and must be explicitly enabled under the Bridge Domain's ARP flooding policy.

   Explanation: ACI performs data-plane endpoint learning at the leaf node. When VM1's ARP request arrives on leaf 101's access port, the leaf hardware snoops the Ethernet frame's source MAC and the ARP payload's sender IP address. It records this binding in the local endpoint table (EPM — Endpoint Manager), creates a /32 host route for the IP, and also registers the endpoint with the COOP (Council of Oracles Protocol) database on the spine proxy so remote leaves can learn the endpoint's location. Option B is wrong — static provisioning is optional (uSeg can use dynamic learning). Option C is wrong about spine-initiated learning for local endpoints. Option D is wrong — ARP-based learning is enabled by default when ARP flooding is on.

7. . In an ACI fabric, leaf 101 needs to send a unicast frame to endpoint EP2 (IP 10.2.2.20) which is connected to leaf 103. Leaf 101 has no local knowledge of EP2's location. Which ACI mechanism resolves EP2's location without flooding the frame?

   • A. Leaf 101 sends a COOP query to the spine proxy database (Oracle); the spine returns EP2's VTEP (RLOC — the TEP IP of leaf 103); leaf 101 encapsulates the frame in VXLAN with the destination VTEP set to leaf 103's TEP, forwarding the unicast frame without flooding.(correct)
   • B. Leaf 101 floods the frame to all leaves in the VRF using the GIPo multicast group; leaf 103 receives the copy, finds EP2 locally, and responds with EP2's location; leaf 101 then caches the mapping and sends future frames unicast.
   • C. ACI requires ARP flooding for all inter-leaf unicast traffic; leaf 101 must send an ARP to discover EP2's MAC before any unicast forwarding can occur, even if the IP is already known.
   • D. Leaf 101 sends a LISP map-request to the APIC; the APIC acts as the LISP map-server and returns EP2's RLOC directly to leaf 101, which then encapsulates using LISP instead of VXLAN.

   Explanation: ACI uses COOP (Council of Oracles Protocol) as its distributed endpoint directory. All leaf nodes register locally learned endpoints with the spine COOP database (each spine acts as an Oracle). When leaf 101 has a packet destined for 10.2.2.20 and no local entry, it sends a COOP query to the spine proxy. The spine returns EP2's binding: leaf 103's TEP (Tunnel Endpoint, VXLAN outer destination IP). Leaf 101 then sends the frame encapsulated in a VXLAN unicast tunnel to leaf 103's TEP — no flooding required. Option B describes BUM traffic handling (GIPo multicast), not unicast proxy. Option C is wrong — ACI's proxy-ARP capability at the BD level eliminates flooding for known IPs. Option D incorrectly substitutes LISP for COOP.

8. . A network engineer creates a Contract between a Provider EPG (Web servers) and a Consumer EPG (App servers). The Subject contains a Filter with ethertype 0x0800, IP protocol 6, and destination port 443. Which traffic flow does this contract permit, and what happens to traffic in the reverse direction?

   • A. The contract permits TCP traffic on destination port 443 from App servers (Consumer) to Web servers (Provider). Return traffic (TCP replies from Web to App) is automatically permitted by the implicit stateful tracking in ACI's contract enforcement, which allows return traffic based on the established TCP connection state.(correct)
   • B. The contract permits TCP port 443 from App servers to Web servers. Return traffic is blocked unless a second contract is created from the Web EPG as Consumer to the App EPG as Provider with a filter permitting TCP source port 443.
   • C. The filter's directionality means the contract permits traffic in BOTH directions — App to Web on TCP/443 AND Web to App on TCP/443 — because ACI contracts are inherently bidirectional with a single subject.
   • D. The contract only applies to frames with ethertype 0x0800 that enter through the fabric uplinks; traffic between endpoints on the same leaf is not subject to contract enforcement and passes freely.

   Explanation: ACI contracts specify policy in terms of Consumer-to-Provider direction: the Consumer EPG (App servers) initiates traffic TO the Provider EPG (Web servers). The filter (ethertype=IPv4, protocol=TCP, dport=443) permits HTTPS connections from App to Web. ACI performs stateful contract enforcement using connection tracking — return TCP traffic (SYN-ACK, ACK, responses from Web to App on ephemeral ports) is automatically permitted without requiring a reverse contract, because ACI tracks the TCP session established in the permitted direction. Option B is incorrect — ACI handles return traffic automatically. Option C is incorrect — contracts are directional (Consumer→Provider), not bidirectional by a single filter. Option D is wrong — ACI enforces contracts on all traffic including intra-leaf EPG flows.

9. . An ACI fabric engineer configures vzAny on a VRF. A new EPG (DB-EPG) is added to the same VRF but is NOT a member of the vzAny consumer/provider contract. Which statement accurately describes vzAny's scope and its impact on DB-EPG?

   • A. vzAny applies the associated contract to ALL EPGs in the VRF as consumers or providers (depending on configuration) at the moment of policy evaluation. However, if DB-EPG has no explicit contract relationship with vzAny, it is excluded from the vzAny contract scope; EPGs must be explicitly added to vzAny to receive its policy.
   • B. vzAny automatically applies to ALL EPGs currently present in the VRF without any per-EPG configuration; when DB-EPG is created in the same VRF, it inherits the vzAny contract relationship (consumer or provider) automatically, receiving or providing the contracted services without additional configuration.(correct)
   • C. vzAny applies only to EPGs in the default Application Profile within the VRF; EPGs in custom Application Profiles like a 'DatabaseApp' profile are not affected by vzAny contracts unless the Application Profile is explicitly associated with vzAny.
   • D. vzAny is a VRF-level object that only applies to inter-VRF (shared services) traffic; intra-VRF EPG-to-EPG traffic is not affected by vzAny and continues to use explicit EPG-to-EPG contracts.

   Explanation: vzAny is an ACI construct that represents all EPGs within a given VRF collectively. When a contract is associated with vzAny as either consumer or provider, that contract policy is automatically applied to every EPG in the VRF — existing and newly created. When DB-EPG is added to the same VRF, it immediately inherits vzAny's contract relationships without any additional configuration. This makes vzAny useful for shared services (e.g., DNS, NTP, monitoring) that all endpoints need to access. Option A incorrectly states EPGs must be explicitly added — that is not how vzAny works. Option C invents an Application Profile restriction. Option D is wrong — vzAny applies to intra-VRF traffic as well.

10. . An engineer enables 'Preferred Group' on a VRF in an ACI fabric. Two EPGs in that VRF are configured as Preferred Group members. A third EPG in the same VRF is NOT a Preferred Group member. Which traffic behavior results?

    • A. Preferred Group members communicate freely with each other without requiring explicit contracts (contract enforcement is waived between members). Traffic between the non-member EPG and any Preferred Group member EPG still requires an explicit contract — the non-member is not excluded from all communication, but it must use standard contract enforcement.(correct)
    • B. When Preferred Group is enabled on a VRF, all EPGs in that VRF automatically become members; the 'Preferred Group member' flag on an EPG is informational only and has no functional effect on contract enforcement.
    • C. Preferred Group members can only communicate with the default gateway EPG; inter-EPG communication between two Preferred Group member EPGs still requires a contract if they are in different Application Profiles.
    • D. The non-member EPG is completely isolated — it cannot communicate with Preferred Group members OR with other non-member EPGs in the VRF, even with explicit contracts, until the VRF's Preferred Group policy is disabled.

    Explanation: ACI Preferred Group (also called Contract Preferred Group) allows designated EPGs to communicate freely within a VRF without requiring explicit contracts between them — think of it as an 'allow any-to-any' zone for trusted EPGs. EPGs that are Preferred Group members skip contract enforcement when communicating with other PG members. EPGs that are NOT members of the Preferred Group continue to use standard contract-based enforcement: they need explicit contracts to communicate with PG members or with each other. The non-member EPG is not in lockdown — it can still communicate if appropriate contracts exist. Option B is wrong — not all EPGs are automatically members. Option C invents an Application Profile restriction. Option D incorrectly claims non-members lose explicit contract capability.

11. . An engineer configures an L3Out on an ACI leaf node to connect to an external router running OSPF. The L3Out logical configuration includes a Logical Node Profile and a Logical Interface Profile. What does the Logical Node Profile define, and what does the Logical Interface Profile define?

    • A. Logical Node Profile defines which leaf nodes participate in the L3Out (node ID, router ID, and optional static routes); Logical Interface Profile defines the physical or sub-interface paths on those nodes (interface type, VLAN encapsulation, IP address, and routing protocol parameters like OSPF interface policy).(correct)
    • B. Logical Node Profile defines the routing protocol type (OSPF, BGP, EIGRP); Logical Interface Profile defines the leaf node IDs that participate in the L3Out.
    • C. Both Logical Node Profile and Logical Interface Profile contain identical information; they are redundant objects that Cisco retained for backward compatibility with ACI 1.x configurations.
    • D. Logical Node Profile defines the External EPG subnets for contract enforcement; Logical Interface Profile defines the OSPF area type and authentication parameters.

    Explanation: The ACI L3Out uses a two-level logical structure. The Logical Node Profile (l3extLNodeP) specifies which fabric nodes (leaves or border leaves) participate in the L3Out, along with their router IDs, BGP router IDs, and any static routes to be advertised or used for next-hop resolution. The Logical Interface Profile (l3extLIfP) defines the actual physical/sub-interface paths on those nodes: the interface type (routed interface, routed sub-interface, or SVI), VLAN encapsulation, interface IP addresses, and attaches routing protocol policies (e.g., OSPF interface policy for area, network type, authentication). The separation allows multiple interface profiles under one node profile. Options B, C, and D misassign the roles.

12. . An ACI fabric engineer configures a Bridge Domain subnet (10.10.10.0/24) for a web-tier EPG. The engineer wants this subnet to be advertised to external routers via the L3Out. Which Bridge Domain subnet configuration flag must be set to enable L3Out advertisement of this subnet?

    • A. Set the subnet scope to 'Public' (advertised externally); this flag marks the subnet for redistribution into the L3Out routing protocol. Without this flag, the BD subnet is private (used for ARP proxy / routing within the fabric) but is not redistributed to external routers.(correct)
    • B. Set the subnet scope to 'Shared Between VRFs'; this flag causes the subnet to be advertised both within the fabric and externally via all configured L3Outs.
    • C. Enable 'No Default SVI Gateway' on the Bridge Domain; this flag forces traffic to the default gateway in the external router, causing the external router to learn the subnet via dynamic routing.
    • D. The BD subnet is automatically advertised via the L3Out once the BD is associated with the same VRF as the L3Out; no additional flag is required.

    Explanation: In ACI, Bridge Domain subnets have a 'scope' attribute that controls advertisement behavior. Setting the subnet scope to 'Public' (advertised externally) causes APIC to program the ACI fabric to redistribute this subnet into the L3Out routing protocol (OSPF, BGP, or static) for external advertisement. Without the Public flag, the subnet is 'Private to VRF' — it is used for fabric-internal routing and ARP proxy/gateway but is not redistributed to external peers. Option B describes 'Shared Between VRFs', which is for inter-VRF shared services and does not guarantee external L3Out advertisement. Option C enables a different BD behavior (no SVI gateway). Option D is incorrect — automatic advertisement does not occur without the public flag.

13. . An engineer configures an L3Out with an External EPG containing subnet 0.0.0.0/0 (catch-all). A contract is applied between an internal application EPG (Consumer) and the External EPG (Provider). The contract has 'scope' set to 'VRF'. A second tenant wants to use the same external network via a shared L3Out. Which contract scope setting would be required to allow inter-tenant access to the external network?

    • A. Change the contract scope to 'Global'; a globally-scoped contract can be consumed by EPGs in any tenant that imports the contract, allowing inter-tenant access to the shared external network via the L3Out.(correct)
    • B. Change the contract scope to 'Tenant'; a tenant-scoped contract allows all VRFs within the same tenant to use the L3Out, and cross-tenant access is handled automatically by APIC's inter-tenant routing engine.
    • C. No contract scope change is needed; APIC automatically promotes VRF-scoped contracts to Global scope when it detects that an external EPG is referenced by multiple tenants.
    • D. Inter-tenant L3Out sharing requires a separate L3Out in each tenant; ACI does not support shared L3Outs across tenants regardless of contract scope.

    Explanation: ACI contract scope determines which EPGs and tenants can import and use a contract. VRF scope limits the contract to EPGs within the same VRF. Tenant scope allows all VRFs within the same tenant to use the contract. Global scope allows EPGs in any tenant to import the contract using 'vzAny' or explicit contract import, enabling inter-tenant shared services. For a shared L3Out used by multiple tenants, the L3Out's External EPG contract must be set to Global scope, and the importing tenant's EPG must use an 'imported contract' (vzCPIf) referencing the exported contract. Option B (Tenant scope) only works within the same tenant. Option C is incorrect — automatic scope promotion does not exist. Option D is wrong — ACI explicitly supports shared L3Outs with Global scope contracts.

14. . An ACI L3Out is configured with OSPF on a Logical Interface Profile. The engineer must configure the OSPF area type as NSSA for the L3Out connection to a remote site. Where is the OSPF area type configured in the ACI GUI, and which object contains the OSPF interface authentication configuration?

    • A. OSPF area type (Stub, NSSA, Regular) is configured in the L3Out's OSPF External Policy object (ospfExtP), which is attached to the L3Out itself. OSPF interface parameters (hello/dead intervals, network type, authentication) are configured in an OSPF Interface Profile Policy object attached to the Logical Interface Profile.(correct)
    • B. OSPF area type is configured in the Logical Node Profile's routing protocol policy; OSPF interface authentication is configured globally on the leaf node under Fabric > Access Policies > Interface OSPF Settings.
    • C. OSPF area type is set per-interface in the Logical Interface Profile; OSPF authentication is configured in the VRF's OSPF policy object shared by all L3Outs in the same VRF.
    • D. OSPF area type and authentication cannot be configured in ACI's L3Out GUI; they must be pushed via CLI on the border leaf nodes using 'feature ospf' and 'router ospf 1' NX-OS commands.

    Explanation: ACI L3Out OSPF configuration uses two separate policy objects. The L3Out's OSPF External Policy (ospfExtP, accessible under the L3Out in Tenants > [Tenant] > Networking > L3Outs > [L3Out] > OSPF) specifies the OSPF area ID and area type (Regular, Stub, NSSA). The OSPF Interface Profile Policy (ospfIfPol) is a reusable policy object created under Tenant > Policies > Protocol > OSPF > OSPF Interface and attached to the Logical Interface Profile; it defines per-interface parameters: OSPF network type (P2P, broadcast), hello/dead intervals, priority, cost, and authentication (MD5 or simple, with key ID and key). This two-level separation allows reuse of interface policies across multiple L3Outs. Options B, C, and D misplace these configurations.

15. . An ACI fabric uses an L3Out SVI (Switched Virtual Interface) path for external connectivity. The engineer verifies the path configuration and notices the path type is 'vpc'. What is the significance of path type 'vpc' in an L3Out SVI context, and what encapsulation is required?

    • A. Path type 'vpc' for an L3Out SVI means the SVI is configured on a vPC domain (both leaf nodes in the vPC pair); the VLAN encapsulation is a floating SVI — both leaves share the same SVI IP and MAC address via HSRP/VRRP-like active-active forwarding, providing redundant Layer 3 gateway connectivity to the external router.(correct)
    • B. Path type 'vpc' for an L3Out SVI uses a port-channel bundle between the two vPC leaf nodes as the routing interface; the external router connects to both leaves with a single LAG and the SVI IP is anchored to the leaf with the lower node ID.
    • C. Path type 'vpc' is not supported for L3Out SVIs; SVI-based L3Outs only support single-port (non-vPC) interfaces, and vPC paths are reserved for L2 external connectivity.
    • D. Path type 'vpc' for an L3Out SVI requires the external router to run OSPF with BFD; BGP and static routing are not supported on vPC-based L3Out SVI paths.

    Explanation: When an L3Out SVI uses path type 'vpc', ACI programs both leaf nodes in the vPC pair with the same SVI VLAN interface. ACI uses a 'floating SVI' mechanism — rather than per-leaf individual IPs with HSRP/VRRP, ACI can assign the same gateway IP and a shared anycast MAC to both leaves. The external router connects to both leaves (typically via a port-channel/LAG to the vPC domain) and communicates with a single logical SVI. This provides active-active Layer 3 gateway redundancy without requiring HSRP/VRRP. The vPC path requires a VLAN encapsulation (802.1Q tag) specified in the path configuration. Option B describes a different (incorrect) forwarding model. Option C is wrong — vPC paths for L3Out SVIs are fully supported. Option D invents routing protocol restrictions.

16. . An ACI administrator integrates VMware vCenter with ACI using a VMM domain. After the integration, where does APIC automatically create port groups for EPGs in vCenter?

    • A. APIC creates a Distributed Virtual Switch (DVS) in vCenter under the datacenter object specified during VMM domain configuration; for each EPG associated with the VMM domain, APIC automatically creates a port group on the DVS with the name format '[TenantName]|[AppProfileName]|[EPGName]'.(correct)
    • B. APIC creates port groups on all existing standard vSwitches (VSS) in the vCenter inventory; APIC cannot create a new DVS and only manages existing standard vSwitch port groups.
    • C. APIC creates port groups in vCenter under a Distributed Virtual Switch that the vCenter administrator must manually pre-create; APIC can only modify existing DVS port groups, not create the DVS itself.
    • D. APIC creates port groups only on vSphere hosts that have the Cisco ACI VIC (Virtual Interface Card) firmware installed; standard Intel NICs are not compatible with ACI VMM integration.

    Explanation: When a VMware vCenter VMM domain is configured in APIC with valid vCenter credentials, APIC automatically creates a Distributed Virtual Switch (DVS) in the specified vCenter datacenter. For each EPG that is associated with this VMM domain (via the EPG's 'Domains' configuration), APIC automatically creates a corresponding port group on the DVS. The port group name follows the convention '[TenantName]|[AppProfileName]|[EPGName]'. The ACI leaf nodes connected to ESXi hosts are automatically configured with the appropriate VLAN encapsulations. Option B is wrong — APIC creates a DVS, not modifying standard vSwitches. Option C is wrong — APIC creates the DVS without pre-creation. Option D is wrong — standard NICs work with ACI VMM via DVS.

17. . An ACI administrator deploys microsegmentation (uSeg EPG) to isolate a subset of VMs in a standard EPG based on their IP addresses. The uSeg EPG uses an IP-based attribute filter (subnet 10.1.1.128/25). Which statement describes how uSeg enforcement differs from standard EPG enforcement?

    • A. uSeg EPG enforcement happens at the ACI leaf during endpoint learning: when a VM's IP matches the uSeg EPG's attribute filter (10.1.1.128/25), the leaf dynamically reassigns that endpoint from the base EPG to the uSeg EPG, applying the uSeg EPG's contracts and policy class ID (pcTag) rather than the base EPG's. The VM does not need to move to a different port group in vCenter.(correct)
    • B. uSeg EPG enforcement requires the vCenter administrator to manually move the VMs to a new port group created by APIC for the uSeg EPG; APIC cannot automatically reassign endpoints without a port group change.
    • C. uSeg EPG enforcement uses Cisco ISE as the enforcement point; APIC sends the IP-based filter to ISE, which dynamically assigns SGTs to matching flows and programs ACI switch hardware via pxGrid.
    • D. uSeg EPGs apply policy based on VM MAC addresses only; IP-based filtering is performed by an external firewall that must be inserted via ACI service graph before contracts can be enforced on the uSeg subnet.

    Explanation: ACI microsegmentation (uSeg EPG) enables dynamic policy assignment without requiring network reconfiguration or VM migration. The uSeg EPG defines attribute-based filters (IP address/subnet, MAC OUI, VM name, guest OS, hypervisor, etc.). When a leaf learns an endpoint whose IP falls within the uSeg EPG's attribute (10.1.1.128/25), the EPM dynamically reclassifies that endpoint from the base EPG to the uSeg EPG's pcTag (Policy Class Tag). All contract enforcement and zoning rules then apply based on the uSeg EPG's policy — no port group change needed in vCenter. This is a fabric-enforced, data-plane reclassification. Options B, C, and D describe incorrect enforcement mechanisms.

18. . A network engineer configures an ACI Service Graph for a firewall device in routed mode. The service graph uses two abstract nodes and inserts the firewall between a consumer EPG (WebFront) and a provider EPG (AppTier). After deployment, traffic from WebFront to AppTier does NOT traverse the firewall. What is the most likely configuration issue?

    • A. The service graph is not attached to the contract between WebFront (Consumer) and AppTier (Provider); a service graph must be explicitly associated with a contract subject to redirect traffic through the device cluster. Without this association, the contract permits traffic directly between EPGs without service insertion.(correct)
    • B. The firewall device cluster must be configured with 'managed' mode for Layer 4–7 policy to be applied; if the device is in 'unmanaged' mode, ACI provisions the graph topology but does not insert the firewall in the forwarding path.
    • C. Service graphs require a minimum of 3 abstract nodes (consumer connector, firewall node, provider connector); a 2-node graph is invalid and ACI silently ignores the service insertion, forwarding traffic directly between EPGs.
    • D. The firewall's management IP must be reachable via the ACI in-band management network; if APIC cannot reach the firewall management interface via HTTPS, the service graph deployment is skipped and traffic bypasses the firewall.

    Explanation: ACI Service Graph insertion requires a two-step configuration: (1) create the Service Graph template referencing the device cluster, and (2) associate the Service Graph template with a specific contract subject. Without step 2, the contract exists and permits/denies traffic normally between EPGs, but the service graph is not invoked — no traffic redirection occurs. The engineer must navigate to the contract subject and attach the service graph under 'In Service Graph Template' and 'Out Service Graph Template'. Option B is incorrect — 'unmanaged' vs 'managed' mode controls whether APIC pushes config to the device, but both modes perform traffic insertion once the graph is applied to a contract. Option C is wrong — a single abstract node (the firewall) with consumer-side and provider-side connectors is a valid 1-node graph. Option D invents an HTTPS reachability prerequisite for path insertion.

19. . An ACI administrator integrates Cisco ISE with ACI using pxGrid. After integration, ISE pushes an SGT-to-EPG mapping for a new user group. Which ACI object is created or updated as a result of this push, and how does ACI use it for policy enforcement?

    • A. ISE uses pxGrid to push TrustSec SGT-to-EPG (or SGT-to-pcTag) mappings to APIC; APIC translates the SGT into an ACI pcTag and programs ACI leaf nodes to classify traffic tagged with that SGT into the corresponding EPG for contract enforcement, bridging TrustSec and ACI microsegmentation policy domains.(correct)
    • B. ISE pushes the SGT mapping to APIC, which creates a new static EPG membership rule tying the SGT number to a specific VLAN; all ACI leaf ports in that VLAN are assigned to the SGT-mapped EPG.
    • C. ISE's pxGrid integration with ACI is read-only; ACI pushes endpoint data (IP, MAC, EPG) to ISE for use in ISE policy decisions, but ISE cannot write SGT-to-EPG mappings back to ACI.
    • D. SGT-to-EPG mapping via pxGrid requires each ACI leaf to be enrolled as a TrustSec network device in ISE; without TrustSec enrollment, the SGT tag in incoming frames is ignored and the endpoint is classified by VLAN only.

    Explanation: The Cisco ISE-ACI integration via pxGrid enables bidirectional policy synchronization. ISE, as the TrustSec policy server, assigns SGTs to users/devices based on identity and posture. Via pxGrid, ISE pushes SGT-to-EPG (or SGT-to-pcTag) mappings to APIC. APIC programs this translation into the ACI leaf pipeline — when a frame with a CTS (Cisco TrustSec) CMD tag arrives at an ACI leaf, the SGT is translated to the corresponding ACI pcTag (policy class), enabling ACI contract enforcement based on the ISE-assigned identity. This creates an integrated identity-based segmentation policy spanning both ISE TrustSec domains and ACI fabric boundaries. Option B invents a VLAN-SGT static mapping mechanism. Option C incorrectly states the integration is read-only. Option D invents a TrustSec enrollment prerequisite for SGT processing.

20. . An ACI-CNI (Container Network Interface) deployment is used to connect Kubernetes pods to ACI fabric EPGs. A Kubernetes namespace 'payments' must be mapped to the 'PaymentsEPG' in ACI. Which mechanism enables this namespace-to-EPG mapping?

    • A. The ACI CNI plugin (acc-provision generated) uses Kubernetes namespace annotations: the engineer annotates the 'payments' namespace with 'opflex.cisco.com/endpoint-group: "uni/tn-Production/ap-K8sApp/epg-PaymentsEPG"'; the ACI CNI daemon reads this annotation and dynamically assigns pods in the namespace to the PaymentsEPG in the ACI fabric.(correct)
    • B. Namespace-to-EPG mapping in ACI CNI is configured exclusively in the acc-provision input YAML file; runtime annotation of namespaces is not supported, and all EPG assignments must be pre-configured before the cluster is deployed.
    • C. ACI CNI uses Kubernetes labels (not annotations) for EPG mapping; the label 'aci-epg=PaymentsEPG' on a namespace object triggers the ACI opflex agent to move the namespace's pods to the specified EPG.
    • D. ACI CNI does not support per-namespace EPG mapping; all pods in a Kubernetes cluster share a single EPG regardless of namespace, and pod isolation must be implemented using Kubernetes NetworkPolicy objects.

    Explanation: ACI CNI (using the opflex-agent and acc-provision framework) supports dynamic namespace-to-EPG mapping via Kubernetes namespace annotations. When the namespace is annotated with the opflex.cisco.com/endpoint-group annotation containing the ACI EPG DN (uni/tn-.../ap-.../epg-...), the opflex agent (running as a DaemonSet on each Kubernetes node) reads this annotation and programs the ACI leaf to assign all pods in that namespace to the specified EPG. Pod traffic is then subject to ACI contract enforcement as defined for the EPG. This allows Kubernetes-native tooling (kubectl annotate) to drive ACI policy assignment dynamically. Option B is incorrect — runtime annotation is supported. Option C is wrong about labels vs annotations. Option D incorrectly claims single-EPG limitation.

21. . A Cisco ACI Multi-Site deployment uses Nexus Dashboard Orchestrator (NDO) to stretch a Bridge Domain across Site 1 and Site 2. An endpoint (EP-A) is at Site 1 and needs to communicate with an endpoint (EP-B) at Site 2 in the same stretched BD. What is a 'shadow EPG' in this context, and why is it needed?

    • A. A shadow EPG is an automatically created read-only EPG that NDO deploys at the remote site (Site 2) to represent the stretched EPG from Site 1; it allows contracts associated with the EPG to be enforced locally at Site 2 without requiring all policy lookups to traverse the inter-site link (ISN), reducing latency and providing local policy enforcement.(correct)
    • B. A shadow EPG is a backup EPG that is activated only when the primary EPG at Site 1 becomes unreachable; it provides failover endpoint classification when the ISN link fails.
    • C. A shadow EPG is created in the 'shadow' tenant — a special tenant automatically created by NDO; engineers cannot manually configure shadow EPGs and they have no operational significance.
    • D. Shadow EPGs are deployed only for stretched VRFs, not stretched Bridge Domains; for stretched BDs, inter-site contract enforcement always requires a packet round-trip to the originating site's APIC.

    Explanation: In ACI Multi-Site with Nexus Dashboard Orchestrator, when an EPG is stretched across sites, NDO creates shadow objects at each remote site. A shadow EPG at Site 2 is a local representation of the stretched EPG from Site 1, enabling Site 2 leaves to enforce contracts locally without inter-site lookups. When EP-A (Site 1) sends traffic to EP-B (Site 2), the inter-site VXLAN encapsulation includes the source EPG pcTag; Site 2 uses the shadow EPG to map the pcTag to the correct local policy class for contract enforcement. Similarly, the shadow EPG allows Site 2 to participate in endpoint learning and contract evaluation for inter-site flows. Option B describes a failover EPG, which is not what shadow EPGs are. Option C invents a 'shadow tenant'. Option D is incorrect — shadow EPGs are used for both stretched BDs and VRFs.

22. . A Cisco ACI Multi-Pod deployment requires Inter-Pod Network (IPN) connectivity between Pod 1 and Pod 2. An engineer configures the IPN routers. Which protocols and specific requirements must the IPN satisfy for ACI Multi-Pod to function correctly?

    • A. The IPN must support OSPF or BGP for routing between pod spines (to exchange TEP pool routes and VTEP reachability); DHCP relay must be configured on the IPN to forward CAPWAP/DHCP discovery packets from spine and leaf nodes of one pod to the APIC and infra DHCP server in the other pod; and the IPN MTU must be at least 9150 bytes to accommodate VXLAN-encapsulated frames between pods without fragmentation.(correct)
    • B. The IPN requires only a static default route pointing to the remote pod's spine IP; no dynamic routing protocol is needed because ACI handles all pod-to-pod path selection via COOP without IPN routing information.
    • C. The IPN must run IS-IS; OSPF and BGP are not supported between ACI pod spines in a Multi-Pod design because IS-IS is the native underlay routing protocol for ACI fabrics.
    • D. Multi-Pod IPN requires MPLS LSP between the pods; the IPN cannot use IP-only routing because VXLAN encapsulation requires an MPLS label to distinguish inter-pod traffic from intra-pod traffic.

    Explanation: ACI Multi-Pod IPN requirements are well-defined. The IPN must provide IP routing between pod spines, typically using OSPF (most common) or BGP, to exchange the fabric's TEP (Tunnel Endpoint Pool) prefixes and ensure VTEP reachability across pods. DHCP relay is critical: new nodes (spine or leaf) in one pod need to discover the fabric's infra DHCP server (run by APIC) which may reside in a different pod, so the IPN must relay DHCP DISCOVER packets. MTU of 9150 bytes is required to support the VXLAN outer header (50 bytes) plus inner jumbo frames (9100 bytes). PIM (Protocol Independent Multicast) for BUM traffic may also be required if multicast is used for intra-pod flooding, but the IPN needs OSPF/BGP for unicast VTEP routing. Options B, C, and D all specify incorrect or fabricated requirements.

23. . An engineer deploys a Cisco ACI Remote Leaf at a branch office. The Remote Leaf (RL) is connected to the main fabric via a routed WAN link. A local server at the branch sends traffic to another local server, both connected to the same Remote Leaf. What forwarding behavior does 'direct traffic forwarding' enable for this intra-RL communication?

    • A. Direct traffic forwarding allows the Remote Leaf to switch traffic locally between two endpoints that are both connected to it and in the same EPG/BD without sending the traffic back to the main fabric; this avoids the WAN round-trip for local east-west traffic, significantly reducing latency and WAN bandwidth consumption.(correct)
    • B. Direct traffic forwarding routes traffic from the Remote Leaf through the WAN to the main fabric spine for policy enforcement, then back to the Remote Leaf; this ensures centralized policy application but doubles WAN traffic.
    • C. Direct traffic forwarding on Remote Leaf is only enabled for multicast traffic; unicast traffic between endpoints on the same Remote Leaf must still traverse the WAN to the main fabric for endpoint learning and contract enforcement.
    • D. Direct traffic forwarding requires the Remote Leaf to have a local APIC controller node; without a local APIC, traffic is always forwarded to the main fabric for policy resolution.

    Explanation: ACI Remote Leaf 'direct traffic forwarding' (enabled per Remote Leaf configuration) allows the Remote Leaf to forward unicast traffic between locally connected endpoints without hairpinning through the main fabric. When both source and destination endpoints are connected to the same Remote Leaf (or same Remote Leaf pod), the RL performs local switching using its programmed endpoint table and contract policies downloaded from APIC. This is critical for branch deployments where the WAN link may have limited bandwidth or high latency — local server-to-server communication should not consume WAN capacity. Without direct traffic forwarding, the Remote Leaf would tunnel all inter-endpoint traffic to the main fabric spine for processing. Options B, C, and D describe non-optimized or incorrect behaviors.

24. . Cisco ACI CloudSec is deployed in a Multi-Site environment to encrypt inter-site traffic over the ISN. An engineer asks about the key exchange mechanism. Which statement accurately describes how CloudSec manages encryption keys in an ACI Multi-Site deployment?

    • A. CloudSec uses an APIC-orchestrated key exchange where the Nexus Dashboard Orchestrator (or APIC in each site) generates and distributes symmetric encryption keys (AES-256-GCM) to the border spines. The keys are exchanged over the APIC-to-APIC communication channel (control plane), and the spines use these keys to encrypt inter-site VXLAN tunnels at line rate using hardware acceleration. Key rotation is managed by APIC on a configurable schedule.(correct)
    • B. CloudSec uses IEEE 802.1AE MACsec with DH key exchange directly between the border spines via the ISN; no APIC involvement is required for key generation or distribution after initial CloudSec enablement.
    • C. CloudSec requires a dedicated PKI server that each APIC cluster registers with; the PKI server issues X.509 certificates to border spines, which perform certificate-based mutual authentication before establishing the encrypted tunnel.
    • D. CloudSec encryption keys are static and must be manually configured by the engineer on each border spine using NX-OS CLI; APIC does not participate in CloudSec key management.

    Explanation: Cisco ACI CloudSec provides inter-site encryption using AES-256-GCM for VXLAN encapsulated traffic between sites. The key management is centralized through APIC/NDO: the APIC at each site generates session keys and exchanges them with peer sites via the APIC inter-site control plane (not the data plane ISN). These keys are programmed into the Nexus 9000 border spine ASICs (specifically the Cloud Scale ASIC with hardware encryption support), enabling line-rate encryption without performance degradation. APIC manages key rotation on a configured interval. This is conceptually similar to MACsec (hence sometimes called 'MACsec-like') but operates at the VXLAN layer rather than at Layer 2, making it suitable for routed ISN interconnects. Options B, C, and D mischaracterize the key exchange mechanism.

25. . A Cisco ACI Multi-Site deployment stretches a Bridge Domain across Site 1 and Site 2 via NDO. An endpoint moves from Site 1 to Site 2 (VM live migration). After the move, the endpoint appears in Site 2's leaf endpoint table. What happens to the 'stale' endpoint entry at Site 1, and what mechanism ensures proper cleanup?

    • A. When the endpoint is learned at Site 2's leaf, Site 2's COOP database is updated and the new location is propagated to the spine. Site 2's APIC sends an endpoint mobility notification to Site 1's APIC via the NDO inter-site control plane. Site 1's fabric marks the endpoint as remote (not local) and the stale local entry is aged out or explicitly removed; subsequent traffic from Site 1 to the moved endpoint is encapsulated toward Site 2 using the updated VTEP information.(correct)
    • B. ACI Multi-Site does not have automatic stale endpoint cleanup for cross-site VM migrations; the network administrator must manually delete the endpoint from Site 1's endpoint table using the APIC GUI after each VM migration to prevent forwarding loops.
    • C. The stale endpoint at Site 1 causes a split-brain condition where both sites believe they are the authoritative location; traffic destined for the moved VM is ECMP-load-balanced between the two sites until the endpoint table aging timer (default 300 seconds) expires at Site 1.
    • D. ACI Multi-Site does not support stretched Bridge Domains for endpoints that undergo live migration; the BD must be pre-split before migration to avoid stale endpoint conflicts.

    Explanation: ACI Multi-Site with NDO supports endpoint mobility across sites for stretched Bridge Domains. When an endpoint is learned at Site 2 after a live migration, Site 2's leaf updates its COOP database and notifies its spines and APIC. The inter-site endpoint mobility signaling (via NDO/APIC-to-APIC communication over the ISN control plane) informs Site 1 that the endpoint has moved. Site 1 transitions the endpoint classification from 'local' to 'remote' (pointing to Site 2), removes the local forwarding entry, and future traffic from Site 1 uses the inter-site VXLAN tunnel to reach Site 2. The endpoint aging mechanism also handles cleanup for cases where the move notification is delayed. Option B is wrong — cleanup is automatic. Option C is wrong — there is no ECMP split-brain for endpoint locations. Option D is wrong — stretched BDs explicitly support live migration.