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

Explanation:
In Cisco ACI, the bridge domain must have Unicast Routing enabled for the leaf switches to learn the IP addresses of endpoints. When unicast routing is enabled, the bridge domain acts as the default gateway for its subnets, and the fabric performs IP-based endpoint learning, populating the endpoint table with both MAC and IP address information.

Correct Option:

C. unicast routing:
Enabling Unicast Routing on the bridge domain activates the distributed anycast gateway function and allows the fabric to learn endpoint IP addresses. Without unicast routing enabled, the bridge domain operates in pure Layer 2 mode, and only MAC addresses are learned in the endpoint table.

Incorrect Option:

A. L2 unknown unicast:
flood: This setting controls how unknown unicast frames are handled (flooded vs. proxy). It does not affect IP address learning in the endpoint table.

B. GARP based detection:
GARP (Gratuitous ARP) based detection is a separate feature used for IP endpoint learning in specific scenarios, but it is not the primary requirement for the endpoint table to learn IP addresses. The base requirement is unicast routing.

D. subnet scope:
Subnet scope is a property of a subnet within a bridge domain that defines whether the subnet is advertised externally (public) or kept internal (private). It does not control IP address learning in the endpoint table.

Reference:
Cisco ACI Fundamentals — "Endpoint Learning": The bridge domain must have Unicast Routing enabled for the fabric to learn IP addresses of endpoints. When unicast routing is enabled, the leaf switches perform IP-based endpoint learning and store both MAC and IP information in the endpoint table.

Explanation
Cisco ACI Multi-Pod allows multiple pods to operate as a single fabric while maintaining isolated control planes within each pod. To extend Layer 2/3, VXLAN, and network policy across locations, specific design requirements must be met: the underlay protocols span across pods and require QoS prioritization, and the Inter-Pod Network (IPN) must support PIM-Bidir for multicast traffic replication.

Correct Option

A. ACI underlay protocols, i.e. COOP, IS-IS and MP-BGP, spans across pods. Create QoS policies to make sure those protocols have higher priority.
Cisco ACI Multi-Pod uses COOP, IS-IS, and MP-BGP EVPN as control-plane protocols that span across pods. In Multi-Pod topologies, traffic passes through an IPN that is not managed by Cisco APIC. This means QoS settings like CoS values can be modified by IPN devices. A DSCP translation policy is needed to preserve proper QoS levels and ensure control-plane traffic gets higher priority .

C. ACI Multi-Pod requires an IP Network supporting PIM-Bidir. For Layer 2 Broadcast, Unknown Unicast, and Multicast (BUM) traffic to be replicated across pods, Cisco ACI Multi-Pod requires the IPN to support PIM Bidirectional (bidir) mode. Ingress replication is not supported with Multi-Pod; PIM Bidir is the only validated and supported option for inter-pod BUM traffic. This requires configuring the bridge domain GIPO range (default 225.0.0.0/15) and 239.255.255.240/28 as PIM bidir group ranges on the IPN .

Incorrect Option

B. A single APIC Cluster is required in a Multi-Pod design. It is important to place the APIC Controllers in different locations in order to maximize redundancy and reliability.
While it is true that Multi-Pod uses a single APIC cluster for all pods , this option is not one of the two specific design requirements being asked about. It describes a characteristic of the architecture rather than a requirement that must be considered for extending L2/L3, VXLAN, and policy across locations. The question asks for requirements to be considered, and the underlay/QoS and PIM-Bidir are the critical design considerations.

D. ACI Multi-Pod does not support Firewall Clusters across Pods. Firewall Clusters should always be local.
This statement is incorrect. Cisco ACI Multi-Pod does support firewall clusters across pods. Active/Standby pairs can be deployed across pods, and Active/Active firewall clusters stretched across sites (single logical firewall) are supported from ACI release 3.2(4d) with Service-Graph with PBR . Firewall clusters do not need to be local.

Reference
Cisco ACI Multi-Pod design requirements include QoS/DSCP translation policies for underlay protocol prioritization and PIM-Bidir support on the IPN for BUM traffic replication .

Explanation:
In Cisco ACI Multi-Pod, each physical pod within the fabric must have a unique Tunnel Endpoint (TEP) pool. These pools cannot overlap because the TEP addresses are used as the source and destination for VXLAN traffic between pods across the Inter-Pod Network (IPN). Overlapping TEP pools would cause routing ambiguity and break inter-pod communication.

Correct Option:

B. A different TEP pool must be assigned to each Pod:
This is accurate. Every pod is assigned its own internal and external TEP pools, and these address ranges must be unique and non-overlapping across the entire Multi-Pod fabric. This allows each pod to be individually addressed for control-plane communication and data-plane forwarding.

Incorrect Option:

A. The IP addresses used in the IPN network can overlap TEP pool of the APIC:
This is incorrect. The IPN (Inter-Pod Network) addresses must be routable and cannot overlap with any pod's TEP pool, as overlapping addresses would prevent proper routing between pods.

C. The Pod1 TEP pool must be split and a portion of the TEP pool allocated to each Pod:
This is incorrect. The Pod 1 TEP pool is unique to Pod 1 and is not split or shared with other pods. Each pod receives its own dedicated TEP pool.

D. The same TEP pool is used in all Pods:
This is incorrect. Using the same TEP pool across pods would cause IP address conflicts and is explicitly prohibited in Multi-Pod deployments.

Reference:
Cisco APIC Layer 3 Networking Configuration Guide — "Multi-Pod: Every pod must be assigned a unique TEP pool and it must not overlap with any other TEP pool in the fabric."

Explanation:
To determine if a human intervention introduced a change in the ACI fabric, the administrator must review the audit logs in the APIC UI. Audit logs record all user-initiated actions (configuration changes, logins, policy modifications) performed through the APIC GUI, REST API, or CLI, providing a clear trail of who did what and when.

Correct Option:

C. Inspect audit logs in the APIC UI to see all user events:
Audit logs in the APIC UI are specifically designed to track user activities and configuration changes. They provide a historical record of all actions performed by users, including the user identity, timestamp, and the specific object that was modified. This is the correct way to identify if a human introduced a change.

Incorrect Option:

A. Inspect event records in the APIC UI to see all actions performed by users:
Event records in the APIC UI typically refer to system events and faults, not user actions. They show operational events such as interface up/down, protocol state changes, and fault lifecycle events, but they do not provide a comprehensive audit trail of user-initiated configuration changes.

B. Inspect /var/log/audit_messages on the APIC to see a record of all user actions:
While audit messages may exist in log files, this is not the recommended or standard method to inspect user actions. The APIC UI provides a structured and easily accessible audit log view, and direct file inspection is typically reserved for advanced troubleshooting under Cisco TAC guidance.

D. Inspect the output of show command history in the APIC CLI:
The CLI command history shows only commands entered in that specific CLI session. It does not provide a fabric-wide record of all user actions across all interfaces (GUI, API, CLI) and all users.

Reference:
Cisco APIC Management, Monitoring, and Troubleshooting Guide — "Audit Logs": The APIC audit logs record all user-initiated actions, including configuration changes and login events. They are accessible through the APIC UI under the Audit Logs section.

Explanation:
When traffic is received from an L3Out on an egress leaf switch, the leaf learns the source IP address of the traffic as a remote endpoint. This is because the traffic originates from outside the ACI fabric, and the source IP is used to populate the endpoint table for return traffic routing. The source MAC address is not learned as an endpoint because the L3Out interface operates at Layer 3, and the MAC address belongs to the external router, not an ACI endpoint.

Correct Option:

D. The source IP address of the traffic is learned as a remote endpoint:
This is accurate. For traffic received from an L3Out, the leaf switch performs IP-based endpoint learning and records the source IP address as a remote endpoint (also known as a "remote" or "L3Out" endpoint). This allows the fabric to route return traffic back to the external network through the correct L3Out.

Incorrect Option:

A. The source MAC and IP address of the traffic is learned as a local endpoint:
This is incorrect. The traffic is coming from an external network via an L3Out, not from a locally attached endpoint. It cannot be learned as a local endpoint.

B. The source MAC address of the traffic is learned as a remote endpoint:
This is incorrect. ACI does not learn the source MAC address of traffic from an L3Out as a remote endpoint. Only the IP address is learned for L3Out traffic.

C. No source MAC or IP address of the traffic is learned as a remote endpoint:
This is incorrect. The source IP address is learned as a remote endpoint to facilitate return traffic. If no learning occurred, return traffic would not be routed correctly.

Reference:
Cisco ACI Fundamentals — "Endpoint Learning from L3Out": When traffic is received from an L3Out, the leaf switch learns the source IP address as a remote endpoint. The source MAC address is not learned because the L3Out interface is a Layer 3 boundary.

Explanation:
The exhibit shows a Stats Threshold configuration for transmit B2B credit cumulative on a Cisco ACI fabric interconnect. The Critical threshold is set to 500 for the Rising direction, and the Reset field for Critical is empty (highlighted with a red box). To clear a critical fault, the Reset value must be configured. The Reset value must be lower than the Set value but higher than the Warning threshold to provide a proper hysteresis.

Correct Option:

B. 410:
The Critical Set threshold is 500, and the Warning threshold is 400. A Reset value of 410 is lower than 500 (so the critical fault can clear) and higher than 400 (so it doesn't immediately trigger the warning threshold again). This provides a proper hysteresis band between the Warning and Critical thresholds. When the B2B credit value falls below 410, the critical fault will clear.

Incorrect Option:

A. 300:
This is the Normal Value and also the Warning Reset value. Setting the Critical Reset to 300 would be too low and would create a large gap, but more importantly, it would fall below the Warning threshold, causing the critical fault to clear only after the value drops below the warning level. This is not the intended behavior for a proper hysteresis.

C. 350:
This value is below the Warning Set threshold of 400. If the Critical Reset were set to 350, the critical fault would clear only after the value dropped below 350, which is already in the warning zone. This would delay the clearing of the critical fault unnecessarily and could keep the system in a warning state longer than needed.

D. 510:
This value is higher than the Critical Set threshold of 500. A Reset value must always be lower than the Set value; otherwise, the fault would never clear (or would clear immediately after being set, causing flapping). This is invalid.

Reference:
Cisco Nexus Dashboard Insights / Cisco ACI Monitoring Guide — "Stats Threshold Configuration": The Reset value for a threshold must be set lower than the Set value to allow the fault to clear. The Reset value should be chosen to provide hysteresis and avoid fault flapping. In this case, 410 is the correct value as it is below the Critical Set (500) and above the Warning Set (400).

Explanation:
Storm control in Cisco ACI is configured to protect against excessive broadcast, multicast, and unknown unicast traffic. It should be applied on endpoint-facing interfaces where user traffic enters the fabric, not on fabric uplinks or APIC-facing interfaces. The two correct interface types are a port channel on a single leaf switch and an endpoint-facing trunk interface.

Correct Option:

B. port channel on a single leaf switch:
Storm control can be configured on a port channel interface that connects to endpoints (servers, storage, etc.) on a single leaf switch. This protects the leaf from broadcast storms originating from the connected endpoints without affecting fabric uplinks.

D. endpoint-facing trunk interface:
An endpoint-facing trunk interface carries traffic from endpoints into the fabric. Applying storm control here prevents broadcast storms from consuming fabric bandwidth and CPU resources. This is the primary interface type where storm control should be configured.

Incorrect Option:

A. APIC facing interfaces:
APIC-facing interfaces carry management traffic between the APIC and leaf switches. Storm control is not configured on these interfaces because they are not endpoint-facing and do not carry user data traffic

C. all interfaces on the leaf switches in the fabric:
Applying storm control to all interfaces would include fabric uplinks, which is not recommended. Fabric uplinks carry inter-switch traffic and should not be rate-limited for broadcast traffic, as this could disrupt fabric operations.

E. fabric uplink interfaces on the leaf switches:
Fabric uplinks connect leaf switches to spine switches. Storm control should not be configured on these interfaces because they carry internal fabric traffic, including control-plane and data-plane traffic between switches. Rate-limiting broadcast traffic on uplinks could cause unintended fabric behavior.

Reference:
Cisco APIC Layer 2 Networking Configuration Guide — "Storm Control": Storm control is configured on endpoint-facing interfaces, including access ports, trunk ports, and port channels connected to endpoints. It is not recommended on fabric uplinks or APIC-facing interfaces.

Explanation:
The COOP (Council of Oracle Protocol) database is located on the spine switches in a Cisco ACI fabric. The COOP protocol is used to distribute endpoint reachability information across the fabric, and the spine switches maintain the authoritative COOP database that maps endpoint addresses to the leaf switches where they are located.

Correct Option:

B. spine:
Spine switches host the COOP database. When a leaf switch learns a new endpoint, it registers the endpoint with the spine switches via COOP. The spine maintains a database of all endpoints and their locations, which is used to provide endpoint location information for traffic forwarding decisions, particularly for hardware proxy and spine proxy functions.

Incorrect Option:

A. leaf:
Leaf switches maintain a local endpoint table but do not host the authoritative COOP database. They register endpoints with the spine and query the spine for endpoint location information.

C. APIC:
The APIC controllers are management and policy controllers. They do not participate in the COOP protocol or maintain the COOP database.

D. endpoint:
Endpoints are the devices (servers, VMs, etc.) connected to the fabric. They do not host any database; they are the objects being tracked in the COOP database.

Reference:
Cisco ACI Fundamentals — "COOP Database": The COOP database is maintained on spine switches. Leaf switches register endpoints with the spine via COOP, and the spine provides endpoint location information to leaf switches for forwarding decisions.

Explanation:
Cisco ACI allows administrators to manage faults that are not relevant to their environment by using the Ignore Fault feature. When you right-click a fault in the APIC UI and select Ignore Fault, the APIC creates a Fault Severity Assignment Policy that changes the severity of that specific fault to "squelched" or "ignored" . This prevents the fault from appearing in the fault list and from affecting the health score.

Correct Option:

C. Under System -> Faults, right-click on the fault and select Ignore Fault to create a fault severity assignment policy that hides the fault:
This is the correct procedure. The Ignore Fault action creates a Fault Severity Assignment Policy (also called a Fault Squelch Policy) that suppresses the fault. The fault is no longer raised or displayed in the APIC UI, and it does not contribute to the health score of the affected object. This is the standard method to prevent non-relevant faults from appearing.

Incorrect Option:

A. Under System -> Faults, right-click on the fault and select Acknowledge Fault so that acknowledged faults will immediately disappear:
Acknowledging a fault does not prevent it from being raised. It simply marks the fault as acknowledged, and the fault may still appear in the fault list. Acknowledged faults do not automatically disappear; they remain until the condition is cleared or the fault is squelched.

B. Create a stats threshold policy with both rising and falling thresholds defined so that the critical severity threshold matches the squelched threshold:
Stats threshold policies are used to define thresholds for statistical counters (such as B2B credits, interface errors, etc.). They are not used to suppress specific faults. While a threshold policy can control when a fault is raised or cleared, it does not provide a mechanism to ignore or squelch a specific fault code.

D. Create a new global health score policy that ignores specific faults as identified by their unique fault code:
Global health score policies are used to define how the health score is calculated for different objects. They do not provide a mechanism to ignore or hide specific faults. The correct way to ignore a fault is through the Ignore Fault action, which creates a Fault Severity Assignment Policy.

Reference:
Cisco APIC Faults, Events, and Audit Log Management Guide — "Ignoring Faults": To prevent a fault from being raised and displayed, right-click the fault in the APIC UI and select Ignore Fault. This creates a Fault Severity Assignment Policy that squelches the fault. The fault will no longer appear in the fault list and will not affect the health score.

Explanation:
Cisco APIC supports exporting configuration backups to remote locations using several protocols. For accessing backup files on a remote server, the supported protocols are FTP (File Transfer Protocol) and SFTP (Secure File Transfer Protocol). These protocols are configured in the APIC backup policy to specify where configuration backups are stored and retrieved.

Correct Option:

B. FTP:
FTP is a supported protocol for exporting and importing configuration backups to/from a remote server. It allows the APIC to transfer backup files to an FTP server. However, FTP is not encrypted, so it is less secure than SFTP.

C. SFTP:
SFTP (SSH File Transfer Protocol) is a secure protocol supported for configuration backup and restore. It uses SSH encryption to protect the backup files during transfer. SFTP is the recommended protocol for secure backup operations.

Incorrect Option:

A. TFTP:
TFTP (Trivial File Transfer Protocol) is not supported for APIC configuration backup to remote locations. It is a simple, unsecured protocol used for other purposes, such as firmware upgrades on some devices, but not for APIC backup policies.

D. SMB:
SMB (Server Message Block) is a file-sharing protocol commonly used in Windows environments. It is not supported by APIC for configuration backup operations.

E. HTTPS:
HTTPS is used for secure web access to the APIC GUI and REST API. It is not used as a protocol for exporting or importing configuration backup files to a remote location.

Reference:
Cisco APIC Management, Monitoring, and Troubleshooting Guide — "Configuration Backup and Restore": The APIC supports exporting configuration backups to remote locations using FTP, SFTP, SCP, and TFTP. For secure transfers, SFTP and SCP are recommended.