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

Explanation:
In Cisco ACI, when a default static route (0.0.0.0/0) is configured on one L3Out (L3Out-1), it is not automatically advertised out of another L3Out (L3Out-2) via OSPF. To advertise the default route out of L3Out-2, you must enable the Export Route Control Subnet flag on the subnet associated with the default route. This flag controls which routes are exported (advertised) to external networks through the L3Out.

Correct Option:

A. Enable Export Route Control Subnet:
This is the correct action. The Export Route Control Subnet flag is used to control which routes are advertised externally through an L3Out. By enabling this flag on the 0.0.0.0/0 subnet, the default route will be exported (advertised) out of L3Out-2 via OSPF, allowing external devices (R2) to learn the default route.

Incorrect Option:

B. Enable Shared Security Import Subnet:
The Shared Security Import Subnet flag is used to control which external routes are imported into the ACI fabric for security purposes. It does not control the advertisement of routes out of an L3Out.

C. Enable Shared Route Control Subnet:
The Shared Route Control Subnet flag is used to share subnets between VRFs through route leaking. It does not control the advertisement of routes out of an L3Out.

D. Enable Aggregate Export Subnet:
The Aggregate Export Subnet flag is used to export an aggregate (summary) route to external networks. It is not the flag used to export a specific default route. While it could be used to export a summary, the question specifically asks about advertising the 0.0.0.0/0 prefix, which is controlled by the Export Route Control Subnet flag.

Reference:
Cisco APIC Layer 3 Networking Configuration Guide — "Export Route Control Subnet": The Export Route Control Subnet flag is used to control which routes are advertised externally through an L3Out. Enabling this flag on a subnet allows that subnet (including a default route) to be exported to external routers via the L3Out routing protocol.

Explanation:

The Cisco AV Pair format for ACI RBAC is:

shell:domains = //

To grant User X access to TenantX only with the tenant-admin role (which provides full administrative access within the tenant) and without any extra privilege in the fabric domain, the AV Pair must specify only the TenantX-SD security domain with the tenant-admin role. No additional domains (such as common//read-all) should be included, as that would grant extra privileges.

Correct Option:

B. shell:domains = TenantX-SD/tenant-admin:
This is the correct AV Pair. It assigns the user to the TenantX-SD security domain with the tenant-admin role. The tenant-admin role provides full read/write access to the objects within that security domain (TenantX) but does not grant any privileges outside of it. This meets the requirement of access to TenantX only, with no extra fabric-wide privileges.

Incorrect Option:

A. shell:domains = TenantX-SD/fabric-admin/,common//read-all:
This AV Pair assigns the fabric-admin role to the TenantX-SD security domain, which grants fabric-wide administrative privileges—more than what is required. Additionally, it includes common//read-all, which grants read access to the common tenant, an extra privilege outside TenantX.

C. shell:domains = TenantX-SD/tenant-ext-admin/,common//read-all:
This assigns the tenant-ext-admin role (which includes external tenant administration privileges) and also includes common//read-all, granting extra privileges outside TenantX.

D. shell:domains = TenantX-SD/tenant-admin/,common//read-all:
This assigns the correct tenant-admin role for TenantX but also includes common//read-all, which grants read access to the common tenant—an extra privilege beyond TenantX. The requirement specifies no extra privileges in the ACI fabric domain.

Reference:
Cisco APIC Security Configuration Guide — "Cisco AV Pair Format for RBAC": The format is shell:domains = //. To restrict a user to a specific tenant with no extra privileges, specify only the security domain and role for that tenant, without adding other domains or privileges.

Explanation:
In Cisco ACI, when you want to advertise external networks learned from a BGP neighbor into the ACI fabric, you need to control which routes are imported. The Import Route Control Subnet option is used to create an inbound route map for route filtering. This allows you to specify which external prefixes are allowed to be imported into the fabric, preventing unwanted routes from being learned.

Correct Option:

C. Import Route Control Subnet:
This option is used to filter inbound routes from external BGP neighbors. When enabled on a subnet within an L3Out, it creates an inbound route map that controls which external prefixes are imported into the ACI fabric. This is the correct choice for advertising a selection of external networks learned from a BGP neighbor into the fabric.

Incorrect Option:

A. External Subnets for the External EPG:
This option is used to classify external traffic into an external EPG based on the subnet. It does not control route import filtering.

B. Shared Route Control Subnet:
This option is used to share subnets between VRFs through route leaking. It does not create an inbound route map for filtering external routes.

D. Shared Security Import Subnet:
This option is used for security-related route import control, specifically for importing routes into a shared security VRF. It is not the general-purpose inbound route map for BGP route filtering.

Reference:
Cisco APIC Layer 3 Networking Configuration Guide — "Import Route Control Subnet": The Import Route Control Subnet flag is used to create an inbound route map that filters which external routes are imported into the ACI fabric. This is configured on subnets within an L3Out and is used with BGP, OSPF, or EIGRP.

Explanation:
The exhibit shows the output of a moquery command on the APIC CLI. The key field in the output is the distinguished name (DN): uni/tn-test. In the ACI Management Information Tree (MIT), uni is the root, and tn-test indicates a tenant named "test". The class of object that has a DN beginning with uni/tn- is a Tenant.

Correct Option:

C. Tenant:
The output clearly shows dn: uni/tn-test, which is the distinguished name of a tenant object named "test". The rn: tn-test (relative name) further confirms this. In the ACI object model, tn is the prefix used for tenant objects.

Incorrect Option:

A. Contract:
A contract would have a DN such as uni/tn-/brc-. The output does not show brc- (which stands for "bridge contract").

B. Bridge Domain:
A bridge domain would have a DN such as uni/tn-/BD-. The output does not show BD-.

D. Endpoint:
An endpoint is not a persistent managed object with a DN in the same way. Endpoints are learned dynamically and stored in the endpoint table, not as tenant-level objects.

Reference:
Cisco APIC Management Information Model Reference — The tenant object is identified by the DN uni/tn-. The output in the exhibit confirms this with dn: uni/tn-test.

Explanation:
When migrating the vSphere Management VMkernel from a standard vSwitch to a VDS integrated with APIC, the Management VMkernel EPG must be set to Pre-Provision resolution immediacy. This ensures that the VLAN and EPG configuration are already deployed on the leaf switches before the VMkernel is migrated. Without pre-provisioning, connectivity to the management VMkernel could be lost during the migration.

Correct Option:

A. The Management VMkernel EPG resolution must be set to Pre-Provision:
This is the correct action. Pre-provision immediacy pushes the EPG policy to the leaf switches before the VMkernel is attached to the VDS. This allows the management VMkernel to retain connectivity during and after the migration, as the necessary VLAN and policy are already in place.

Incorrect Option:

B. The administrator must create an in-band VMM Management EPG before performing the migration:
While an in-band management EPG may be needed for other purposes, it is not the specific requirement for migrating a VMkernel to a VMM domain-integrated VDS. The key is the resolution immediacy setting.

C. The administrator must set the Management VMkernel BD resolution immediacy to On-Demand:
On-Demand immediacy means policies are downloaded only when the VMkernel is detected. This could cause a connectivity gap during the migration because the policy may not be in place before the VMkernel starts using the VDS.

D. The VMkernel Management BD must be located under the Management Tenant:
The location of the bridge domain is not the determining factor for the migration. The EPG resolution immediacy setting is what ensures connectivity during the migration.

Reference:
Cisco ACI Virtualization Guide — "Migrating VMkernel to VMM Domain VDS": Pre-provision immediacy must be set on the Management VMkernel EPG to ensure that the VLAN and policy are deployed on the leaf switches before the VMkernel is migrated.

Explanation:
In Cisco ACI VMM domain integration with VMware VDS, the Forged Transmits security policy determines how the ESXi host handles frames whose source MAC address does not match the VM's effective MAC address. When set to Accept, the ESXi host accepts the frames without checking the source MAC, and the ACI fabric enforces the integrity check by dropping the frames when a mismatch is detected. When set to Reject, the ESXi host itself drops the frames at the virtual switch level.

Correct Option:

B. Accept forged transmits:
In the ACI VMM domain security policy, setting Forged Transmits to Accept allows the ESXi host to accept the frames and pass them to the ACI fabric. The ACI leaf switch then performs the integrity check and drops frames when the actual source MAC does not match the effective MAC. This is the correct action to have the fabric apply the security policy and drop the mismatched traffic.

Incorrect Option:

A. Reject MAC changes:
This policy controls whether the VM can change its MAC address. It is not related to checking the source MAC of transmitted frames or dropping mismatched traffic.

C. Accept MAC changes:
This policy allows the VM to change its MAC address. It does not control the integrity check of transmitted frames.

D. Reject forged transmits:
This setting causes the ESXi host to drop frames at the virtual switch level when a mismatch is detected, not the ACI fabric. The question specifically states that the fabric must apply the security policy, so this is incorrect.

Reference:
Cisco ACI Virtualization Guide — "VMM Domain Security Policies": The Forged Transmits policy can be set to Accept or Reject. When set to Accept, the ACI fabric performs the integrity check and drops frames on mismatch. When set to Reject, the ESXi host drops the frames. To have the fabric apply the security policy, set Forged Transmits to Accept.

Explanation:
The engineer must back up the PRODUCTION tenant with two key requirements:

The configuration must be stored on the APIC itself (not remotely).

The backup must use a markup language (JSON or XML) and contain all secure information (which requires AES encryption to be enabled).

Option A meets these requirements as follows:

Target DN: uni/PRODUCTION identifies the tenant to be backed up.

Format: JSON is selected as the markup language.

Export Destination: This field is left empty, which means the backup is stored locally on the APIC.

Modify Global AES Encryption Settings: This is Enabled, which ensures that all secure information (passwords, secrets, certificates) is included in the backup.

Correct Option:

A. Option A:
This configuration correctly specifies the PRODUCTION tenant as the target, selects JSON as the format, stores the backup locally on the APIC (no remote destination configured), and enables AES encryption to include all secure information.

Incorrect Option:

B. Option B:
This option has Target DN set to uni/tn-PRODUCTION, which is the correct DN for a tenant. However, it also has the Export Destination set to rmt-backup-01, meaning the backup would be stored on a remote server, not on the APIC. This violates the requirement to store the backup on the APIC.

C. Option C:
This option has Target DN set to uni/PRODUCTION, which is not a valid DN for a tenant (the correct DN is uni/tn-PRODUCTION). It also has the Snapshot checkbox enabled, but the primary issue is the incorrect DN, which would cause the backup to fail or not target the tenant correctly.

D. Option D:
This option has the correct Target DN (uni/tn-PRODUCTION) and Snapshot enabled, but it also has the Export Destination set to rmt-backup-01, meaning the backup would be stored remotely, not on the APIC. This violates the requirement to store the backup on the APIC.

Reference:
Cisco APIC Management, Monitoring, and Troubleshooting Guide — "Configuration Export Policy": The Target DN must correctly identify the object to be backed up (e.g., uni/tn-PRODUCTION for a tenant). Leaving the Export Destination empty stores the backup locally on the APIC. Enabling AES encryption ensures that all secure information is included in the backup file.

Explanation:
In a Cisco ACI Multi-Pod environment, the APIC cluster should be deployed across pods in a way that avoids placing all replicas of a shard in the same pod. The APIC cluster uses data sharding with replicas distributed across the APIC controllers. If all APIC controllers were deployed in the same pod and that pod failed, all replicas of the shard would be lost, potentially causing data loss or cluster unavailability. Therefore, no more than two APIC controllers should be deployed in the same pod to ensure that replicas are distributed across pods.

Correct Option:

B. to avoid losing all replicas of a shard if a pod fails:
This is the correct reason. The APIC cluster distributes data across controllers in shards, with multiple replicas for redundancy. If too many APIC controllers are placed in the same pod, a pod failure could result in the loss of all replicas of a shard, leading to data unavailability or loss. By limiting the number of APIC controllers per pod, the replicas are spread across pods, ensuring that a single pod failure does not take down all replicas.

Incorrect Option:

A. to enable equal capacity to scale in each pod:
This is not the reason. The number of APIC controllers per pod is not related to scaling capacity equally across pods.

C. to avoid hair-pinning traffic that is destined for the primary APIC controller between pods:
While traffic to the primary APIC controller could traverse pods, this is not the primary reason for limiting APIC controllers per pod. The main concern is data redundancy and shard replication.

D. to ensure that all nodes in all pods have local access to a controller:
While it is beneficial for nodes to have local access to an APIC controller, this is not the reason for limiting the number of APIC controllers per pod. The primary reason is to ensure shard replicas are distributed across pods for fault tolerance.

Reference:
Cisco ACI Multi-Pod Design Guide — "APIC Cluster Deployment": In a Multi-Pod environment, the APIC cluster should be deployed such that no more than two APIC controllers are in the same pod. This ensures that shard replicas are distributed across pods, preventing the loss of all replicas if a single pod fails.

Explanation:
The requirements are:

Authentication goes through the local users if the TACACS+ server is not reachable.

If the APIC is out of the cluster, access must be granted through the fallback domain.

To meet these requirements, the configuration must use TACACS+ as the default authentication realm, enable the fallback check to allow local authentication when TACACS+ is unreachable, and disable ping check to ensure the APIC does not rely on ICMP reachability to determine if the TACACS+ server is available. This allows the APIC to attempt TACACS+ authentication first and fall back to local authentication if the server is unreachable.

Correct Option:

D. Ping Check: False, Default Authentication Realm: TACACS+, Fallback Check: True:
Default Authentication Realm: TACACS+: The primary authentication method is TACACS+, as required.

Fallback Check: True: This enables the fallback to local authentication if the TACACS+ server is not reachable, meeting the first requirement.

Ping Check: False: Disabling ping check prevents the APIC from using ICMP to verify TACACS+ server reachability. This is important because if ping check were enabled, the APIC might skip TACACS+ authentication if the server does not respond to ping, even if it is reachable for authentication. Disabling it ensures the APIC attempts TACACS+ authentication regardless of ping status, allowing the fallback mechanism to work correctly.

Incorrect Option:

A. Ping Check: True, Default Authentication Realm: Local, Fallback Check: True:
The default authentication realm is set to Local, meaning local authentication is used first, not TACACS+. This does not meet the requirement that authentication goes through TACACS+ first.

B. Ping Check: True, Default Authentication Realm: TACACS+, Fallback Check: False:
Fallback Check is False, meaning if TACACS+ is unreachable, the APIC will not fall back to local authentication. This does not meet the requirement.

C. Ping Check: False, Default Authentication Realm: Local, Fallback Check: False:
The default authentication realm is Local, and fallback is disabled. This does not meet the requirement of using TACACS+ first with fallback to local.

Reference:
Cisco APIC Security Configuration Guide — "AAA Authentication": The default authentication realm specifies the primary authentication method. The fallback check enables fallback to local authentication if the primary method is unreachable. The ping check determines whether the APIC uses ICMP to verify server reachability; disabling it ensures authentication attempts are made regardless of ping response.

Explanation:
The Disable Remote EP Learn feature is a fabric-wide setting in Cisco ACI that controls whether leaf switches learn remote IP endpoints from other leaf switches. When enabled, it disables remote IP endpoint learning on leaf switches that do not have an L3Out configured. This is designed to reduce the endpoint table size on leaf switches that do not need to know about remote IP endpoints, such as compute leaf switches that only host endpoints and do not provide external routing.

Correct Option:

B. It disables remote IP endpoint learning on leaf switches that do not have L3Outs:
This is the correct effect. When the Disable Remote EP Learn feature is enabled, leaf switches without L3Outs stop learning remote IP endpoints. This reduces the endpoint table size and improves scaling on leaf switches that do not require knowledge of remote IP endpoints for routing decisions.

Incorrect Option:

A. It disables remote IP endpoint learning on all leaf nodes in the fabric:
This is incorrect. The feature only disables remote IP endpoint learning on leaf switches that do not have L3Outs. Leaf switches with L3Outs still learn remote IP endpoints because they need this information for routing.

C. It limits learning of compute leaf endpoints on border leaves:
This is incorrect. The feature affects leaf switches without L3Outs, not border leaves. Border leaves (which have L3Outs) continue to learn remote IP endpoints.

D. It prevents border leaf switches from receiving routes through peering with external routers:
This is incorrect. The feature does not affect route peering or the receipt of routes from external routers. It only controls remote IP endpoint learning on leaf switches without L3Outs.

Reference:
Cisco ACI Fundamentals — "Disable Remote EP Learn": When enabled, this feature disables remote IP endpoint learning on leaf switches that do not have an L3Out configured. This helps reduce the endpoint table size on compute leaf switches and improves scaling. Border leaf switches with L3Outs continue to learn remote IP endpoints.