Free Cisco 300-620 Practice Questions 2026 | Implementing Cisco Application Centric Infrastructure (300-620 DCACI)

Explanation:
In a Cisco ACI filter entry, the Name is mandatory to identify the entry. Ether Type and IP Protocol are also required fields because they define the fundamental match criteria for the traffic (e.g., IPv4, ARP, TCP, UDP). ARP Flag is only applicable when the Ether Type is ARP, making it optional. Source Port From is optional because port-based matching only applies to specific protocols like TCP or UDP, and you can choose to match only on the destination port.

Correct Option:

Required (Name, Ether Type, IP Protocol):
These parameters must be configured for every filter entry. The Name identifies the object. Ether Type specifies the Layer 2 protocol (e.g., 0x0800 for IPv4). IP Protocol specifies the Layer 3 protocol (e.g., 6 for TCP, 17 for UDP). Without these, the filter cannot properly classify traffic.

Optional (ARP Flag, Source Port From):
The ARP Flag is only used when filtering ARP traffic (Ether Type 0x0806), so it is not needed for IP traffic. The Source Port From is only relevant for TCP/UDP traffic and is often omitted if you only want to match on destination ports or if you are matching ICMP traffic where ports are not used.

Incorrect Option:

Placing Name in Optional:
Name is always a required parameter for any managed object in ACI. You cannot create a filter entry without a name.

Placing Ether Type or IP Protocol in Optional:
These are core match fields. A filter entry must define what type of traffic it is matching (e.g., IP vs ARP), making these required.

Placing ARP Flag or Source Port From in Required:
If these were required, you could not create a simple IP filter without also defining ARP flags or TCP/UDP source ports, which is not the case.

Reference:
Cisco APIC Basic Configuration Guide — "Filter Entry Options": The required parameters for a filter entry are Name, Ether Type, and IP Protocol. ARP Flag and Source Port From are listed as optional parameters.

Explanation:
When the VMM resolution immediacy is set to Pre-Provision, the APIC is instructed to push policies (such as VLANs and EPG configurations) down to the leaf switches before the hypervisor is even attached or discovered. This is specifically designed for scenarios where a discovery protocol neighborship might not exist yet or where the hypervisor management traffic needs the policy to be in place first.

Correct Option:

C. Policies are downloaded to the ACI leaf switch regardless of Cisco Discovery Protocol neighborship:
This is accurate. According to the Cisco ACI Virtualization Guide, when using pre-provision immediacy, the policy is downloaded to the leaf switch regardless of CDP/LLDP neighborship. It pre-provisions the configuration on the switch even without a hypervisor host connected to the VMM switch .

Incorrect Option:

A. No policies are downloaded because LLDP is the only supported discovery protocol:
This is incorrect. While LLDP or CDP is typically used for dynamic policy resolution, pre-provision mode is specifically designed to bypass the need for discovery.

B. Policies are downloaded when the hypervisor host is connected to the VMM VDS:
This describes the "Immediate" or "On Demand" resolution modes, which rely on the hypervisor attachment or VM events to trigger policy deployment .

D. No policies are downloaded because there is no discovery protocol neighborship:
This is incorrect. Pre-provision mode removes the need for neighbor adjacencies or OpFlex permissions, ensuring the policy is applied regardless .

Reference:
Cisco ACI Virtualization Guide, Release 5.3(x) — "EPG Policy Resolution and Deployment Immediacy": "When using pre-provision immediacy, policy is downloaded to Cisco ACI leaf switch regardless of CDP/LLDP neighborship. Even without a hypervisor host that is connected to the VMM switch."

Explanation
To meet the requirements of controlling application data flow and allowing auto-negotiation, the engineer needs to configure a Data Plane Policing (DPP) policy to manage bandwidth limits and a Link Level Policy to set the port speed and negotiation settings. These policies are combined into a Leaf Access Port Policy Group and applied to the interface.

Correct Option

B. link level policy:
This policy is used to define the interface speed and enable auto-negotiation. It directly addresses the requirement to "auto-negotiate link speed" with the connected device.

E. ingress data plane policing policy:
This policy (DPP) is specifically designed to monitor and control the amount of traffic entering the interface. It enforces a maximum data rate and takes action (such as dropping or marking) if the traffic exceeds the configured limit, which fulfills the requirement to "control the amount of application data".

Incorrect Option

A. L2 interface policy:
This policy is typically used for Layer 2-specific settings like VLAN encapsulation, not for link negotiation or bandwidth policing.

C. slow drain policy:
This is used to manage congestion and prevent slow-drain scenarios in the fabric, not to control the total data flow into the system.

D. ingress control plane policing policy:
This policy is designed to protect the switch CPU by limiting control plane traffic (like protocol packets), not application data flow.

Reference

Cisco APIC Security Configuration Guide: Data Plane Policing controls ingress and egress bandwidth on access interfaces.

Cisco APIC Layer 2 Networking Configuration Guide: The Link Level Policy within an Access Port Policy Group is used to define port speed and auto-negotiation settings.

Explanation:
Cisco ACI uses a fabric-wide forwarding mechanism called Forwarding Tag Trees (FTAG) to load-balance multidestination traffic (such as broadcast, unknown unicast, and multicast). FTAG ensures that multidestination frames are delivered efficiently to all necessary leaf switches while preventing loops and enabling optimal path utilization across the spine layer.

Correct Option:

D. forwarding tag trees:
FTAG is the core mechanism ACI uses for multidestination traffic distribution. The fabric builds a set of tag trees (typically two per fabric), and each leaf switch is assigned as the "root" for one of the trees. When a leaf needs to send multidestination traffic, it uses the tag tree where it is not the root, which prevents traffic from being reflected back. This allows the fabric to load-balance multidestination flows across all available spine switches.

Incorrect Option:

A. PIM routing:
PIM (Protocol Independent Multicast) is a traditional multicast routing protocol used in external networks. While ACI can interoperate with PIM externally for multicast routing, it is not the internal mechanism ACI uses to load-balance multidestination traffic within the fabric.

B. spanning trees:
Spanning trees are used in traditional Layer 2 networks to prevent loops. ACI does not use spanning tree for multidestination forwarding; in fact, ACI eliminates the need for STP within the fabric.

C. shortest-path trees:
Shortest-path trees are used in routing protocols like OSPF or IS-IS to build loop-free topologies. This is not the mechanism ACI uses for multidestination load-balancing.

Reference:
Cisco ACI Fundamentals — "Forwarding Tag Trees (FTAG)": The ACI fabric uses FTAG to load-balance multidestination traffic. Each leaf switch is assigned as a root for one of the tag trees, and traffic is forwarded using the tree where the leaf is not the root, ensuring efficient distribution and loop prevention.

Explanation:
To redistribute externally learned OSPF routes within the ACI fabric, you must configure a Route Control Profile and apply it as an Interleak Route Map. This policy controls which routes from the OSPF process are redistributed into the MP-BGP protocol for propagation across the fabric to other leaf switches. Without this policy, all OSPF routes may be implicitly imported, but a profile is required for granular control.

Correct Option:

A. Route Control Profile:
The Route Control Profile references Action Rules Profiles to define route-map match and set clauses. When applied as an Interleak Route Map on an L3Out, it controls the redistribution of OSPF routes into BGP. This ensures that only authorized external OSPF routes are propagated within the fabric, preventing routing loops and enforcing route policy.

Incorrect Option:

B. BGP Route Reflector:
This is a separate policy used to propagate iBGP routes between leaf switches within the fabric. It does not control the redistribution of OSPF routes; it is the transport mechanism for the redistributed routes, not the redistribution policy itself.

C. BGP Inter-leak Route Map:
While "Interleak Route Map" is the mechanism that performs redistribution, the actual configuration object that defines the policy is the Route Control Profile. The Interleak Route Map is generated from the Route Control Profile applied to the L3Out.

D. PIM Sparse Mode:
PIM is a multicast routing protocol used for external multicast connectivity. It has no role in unicast OSPF route redistribution within the ACI fabric.

Reference:
Cisco APIC Layer 3 Networking Configuration Guide — "Interleak Redistribution for MP-BGP": "The border leaf switches redistribute eligible L3Out routes into the MP-BGP IPv4 and IPv6 address families for distribution across the ACI fabric. A tenant Route Control Profile policy filters routes or sets attributes when eligible L3Out routes are redistributed into MP-BGP".

Explanation:
To represent an external bridged network in Cisco ACI, you use an L2Out (Layer 2 Outside) configuration, which extends the bridge domain to an external Layer 2 switch. The connection is then established by using Static Path Binding, which maps the external switch ports to the L2Out external EPG using VLAN encapsulation.

Correct Option:

B. Layer 2 outside:
This is the correct construct for extending a bridge domain beyond the ACI fabric to an external bridged network. An L2Out is created under the tenant's External Bridged Networks and is associated with a bridge domain and an external bridged domain.

D. Static path binding:
This is the method used to deploy the L2Out external EPG on specific leaf switch ports. You configure static bindings on the L2Out node profile's interface profile, mapping the physical port (path) with a VLAN encapsulation to the external EPG.

Incorrect Option:

A. Layer 2 remote fabric:
This is not a valid ACI configuration term. There is no "remote fabric" construct for Layer 2 connectivity.

C. Layers 2 internal:
This is not a valid configuration. Layer 2 connectivity is either internal to the fabric (standard EPG/bridge domain) or external (L2Out).

E. VXLAN outside:
VXLAN is the fabric's internal overlay encapsulation. External bridged networks use standard 802.1Q VLAN tagging, not VXLAN.

Reference:
Cisco APIC Layer 2 Networking Configuration Guide: "L2Out Configuration using the Routed Bridged Network Method" describes creating External Bridged Networks and applying static bindings.

Explanation:
To deploy an access port policy group, you must create an Attachable Entity Profile (AEP). The AEP acts as a container that groups together interface policies, including access port policy groups, and associates them with specific nodes and interfaces. The AEP is then applied to leaf switch ports to enforce the configured policies.

Correct Option:

A. attachable entity:
An Attachable Entity Profile is the required construct for deploying access port policy groups. The AEP contains the interface policy groups and is associated with a node profile or interface profile. When an AEP is applied to a leaf port, it pushes the access port policy group configuration to that interface.

Incorrect Option:

B. Pod:
A Pod is a physical grouping of leaf and spine switches in the ACI fabric. It is not a profile type used to deploy access port policy groups.

C. module:
A module refers to a line card or expansion module in a switch chassis. It is not a profile type for deploying interface policies.

D. leaf interface:
A leaf interface is a physical or logical port on a leaf switch. While the policy group is applied to a leaf interface, the profile that enables the deployment is the Attachable Entity Profile, not the interface itself.

Reference:
Cisco APIC Basic Configuration Guide — "Attachable Entity Profile": The AEP is used to group interface policies and apply them to leaf switch ports. Access port policy groups are referenced within the AEP.

Explanation:
Microsegmentation EPGs (uSeg EPGs) are a special type of EPG in Cisco ACI that dynamically assigns endpoints to EPGs based on their attributes, such as IP address, MAC address, VM name, operating system, or custom tags. This allows for granular policy enforcement without manual reconfiguration when virtual machines move or change.

Correct Option:

D. uSeg EPGs:
uSeg EPGs use attribute-based policies to dynamically assign or modify the EPG association of virtual machines. When a VM's attributes match the uSeg EPG's criteria, the VM is automatically placed into that EPG, and the corresponding contracts and policies are applied. This is especially useful in virtualized environments where VM attributes change frequently.

Incorrect Option:

A. vzAny contracts:
vzAny is a construct that represents all EPGs within a VRF. It is used to simplify contract configuration by allowing a single contract to apply to all EPGs in the VRF, but it does not dynamically assign EPGs based on VM attributes.

B. standard contracts:
Standard contracts define the rules for communication between EPGs. They do not dynamically assign or modify EPG associations.

C. application EPGs:
Application EPGs are standard EPGs that group endpoints with similar policy requirements. They do not dynamically assign EPG membership based on VM attributes.

Reference:
Cisco APIC Fundamentals — "Microsegmentation (uSeg) EPGs": uSeg EPGs enable dynamic endpoint assignment based on attributes such as IP, MAC, VM name, and custom tags. When an endpoint's attributes match a uSeg EPG, it is automatically associated with that EPG.

Explanation
ACI Multi-Site is an architectural approach for interconnecting and managing multiple ACI fabrics. Each site functions as an independent fabric, and each site maintains its own dedicated APIC cluster domain. The solution does not consolidate management under a single APIC cluster; instead, a separate Multi-Site Orchestrator is used to manage policies across the sites. This distributed management model preserves fault isolation between sites.

Correct Option

C. ACI Multi-Site is a solution that supports a dedicated APIC cluster per site:
This is accurate. In a Multi-Site architecture, each ACI fabric (site) has its own independent APIC cluster domain. The Multi-Site Orchestrator manages policies across these separate APIC domains.

D. ACI Multi-Site is a solution that allows one APIC cluster to manage multiple ACI sites:
This is also correct. While each site has its own APIC cluster, the Multi-Site Orchestrator acts as the centralized policy manager that can push configurations and policies to all sites simultaneously. It provides a single pane of glass for managing multiple ACI fabrics.

Incorrect Option

A. The Multi-Site orchestrator must be directly attached to one ACI leaf:
This is incorrect. The Multi-Site Orchestrator (typically a cluster of VMs) only requires IP connectivity to the out-of-band (OOB) management IP addresses of the APIC clusters. It does not need to be connected to the ACI leaf nodes.

B. Routers in the Inter-Site network must run OSPF, DHCP relay, and MP-BGP:
This is partially correct regarding OSPF and MP-BGP, but DHCP relay is not a requirement. The routers in the Inter-Site Network (ISN) use OSPF to peer with the ACI spines and MP-BGP EVPN for the control plane between sites.

E. The Inter-Site network routers should run OSPF to establish peering with the spines:
While this statement is technically true—spines establish OSPF peering with ISN devices for underlay connectivity—it is not one of the two best answers describing the fundamental nature of ACI Multi-Site. Option B is also a valid statement, but the question asks for true statements about the solution, and C and D capture the core architectural concepts.

Reference
Cisco ACI Multi-Site Fundamentals Guide: "Each site is an availability zone (APIC cluster domain)." "An inter-site policy manager, named Cisco ACI Multi-Site, is used to manage the different fabrics and to define inter-site policies." "The ESXi hosts do not need to be connected to the ACI leaf nodes, because it is only required to establish IP connectivity between the VMs and the OOB IP addresses of the different APIC cluster nodes."

Explanation:
In Cisco ACI Multi-Site, the spine nodes use MP-BGP EVPN to exchange endpoint routing information across sites. By default, these control plane packets are generated with a size of 9,000 bytes. For this traffic to traverse the Inter-Site Network (ISN) successfully, the ISN must be configured to support a slightly larger MTU to accommodate the packet size without fragmentation.

Correct Option:

D. 9000-bytes / 9100-bytes:
This option correctly identifies the default control plane packet size (9,000 bytes) and the recommended ISN MTU (9,100 bytes). Cisco documentation specifies that the ISN should be configured to support an MTU of at least 9,100 bytes when the default 9,000-byte control plane MTU is used . The additional 100 bytes provide a buffer for encapsulation overhead.

Incorrect Option:

A. 9000-bytes / 9000-bytes:
This option is incorrect because it states the ISN only needs to carry 9,000-byte packets. While the spine generates 9,000-byte packets, the ISN requires a higher MTU (9,100 bytes) to handle the packets effectively without fragmentation or drops, as per Cisco's design recommendations .

B. 1500-bytes / 1800-bytes:
This option is incorrect because the default control plane packet size in ACI Multi-Site is not 1,500 bytes. The default is 9,000 bytes .

C. 1500-bytes / 1500-bytes:
This option is incorrect for the same reason as option B. The default control plane MTU is 9,000 bytes, not 1,500 bytes .

Reference:
Cisco ACI Multi-Site Design Guide: "The MTU of MP-BGP EVPN control-plane communication between spine nodes in different sites: By default, spine nodes generate 9000-byte packets for exchanging endpoint routing information. If the default value is not changed, the Inter-Site network should be able to support an MTU size of at least 9100 bytes."