Cisco 300-620 DCACI: Turning Application Requirements into Fabric Policy

Traditional switching designs describe connectivity in terms of ports, VLANs, interface trunks and routed boundaries. Cisco Application Centric Infrastructure adds a policy model intended to express how application groups communicate while the fabric supplies transport and consistent enforcement. The challenge is not that the old networking concepts disappear. It is that an operator must translate them into tenants, VRFs, bridge domains, endpoint groups and contracts without losing sight of the actual traffic path.

Cisco currently lists 300-620 DCACI v1.1, Implementing Cisco Application Centric Infrastructure, as a 90-minute concentration exam for CCNP Data Center. The exam covers implementing and managing Cisco Nexus 9000 switches in ACI mode, fabric setup, policy, external connectivity and management integration. Passing it earns the Data Center ACI Implementation specialist credential and can satisfy the concentration requirement paired with the broader 350-601 DCCOR. DCACI is not a general cloud-controller exam; it tests decisions specific to the ACI fabric and its policy-driven model.

ACI objects represent relationships, not just device commands

An ACI tenant is a logical administrative container. Within it, a VRF provides a Layer 3 routing context, a bridge domain describes a Layer 2 forwarding and gateway relationship, and an application profile can organize endpoint groups representing workloads with comparable connectivity and security requirements. These objects are connected by policy references. Creating them in the wrong order, or misunderstanding the reference between them, can produce a syntactically valid configuration that forwards no application traffic.

Before selecting an ACI deployment, engineering teams should evaluate the cost of managing fabric policy and controller dependencies against their existing switch operations. ACI and independently assembled software-defined networking present different tradeoffs in integration, control and operational skills. ACI is not automatically preferable for every small topology, nor is a custom assembly inherently more flexible when consistency and vendor support become significant requirements. The decision belongs to the application and operations constraints.

An endpoint group, or EPG, describes policy membership rather than a single physical interface. Membership may be associated with VLAN encapsulation, static path bindings or virtual machine management integrations. Contracts specify permitted communication between EPGs through subjects and filters. Crucially, an application cannot be assumed reachable merely because two subnets share the same routing context. Where policy enforcement applies, the relevant EPG relationship and contract must permit the traffic. The ACI policy model is therefore a stronger conceptual foundation than a memorized sequence of fabric GUI clicks.

Use an application example to reason about policy: a frontend service needs HTTPS access to a backend API, which needs a narrow connection to a database tier. Model three appropriate EPGs and contracts that describe only the required traffic. Then test a denied path deliberately. If a frontend host reaches the database directly despite a design that prohibits it, the fabric may be working at Layer 3 while the policy design is wrong. If every connection is blocked, the engineer needs to distinguish membership, contract, filter and routing issues instead of enabling broad any-to-any permissions.

Fabric discovery and underlay health are the foundation

An operator who knows how a VXLAN EVPN fabric carries endpoint reachability has an advantage when reasoning about overlays, although an ACI implementation uses its own controller-driven policy and fabric control-plane mechanisms. Avoid assuming that every EVPN command or troubleshooting procedure applies unchanged to ACI. Learn the ACI-specific endpoint tables and deployment objects before interpreting the result of a packet trace.

The ACI fabric includes spine and leaf switches, an APIC management and policy plane, and an underlay that provides transport for endpoint traffic. During deployment, devices must discover the fabric and receive appropriate addressing and roles. It is a mistake to assume a healthy APIC interface proves that every spine-to-leaf path is healthy or that an endpoint's data traffic can reach its destination. Fabric discovery, node inventory, software compatibility, interface state and endpoint learning provide different pieces of evidence.

A leaf's role is not interchangeable with a spine's. Leaf devices attach endpoints, enforce much of the fabric policy and communicate across the fabric using the ACI forwarding architecture; spines provide transit between leaves in the supported design. The engineer should understand how endpoint location is known and how the fabric reaches remote endpoints. When a host migrates, the timing of endpoint-learning updates matters. A stale endpoint entry can look like an application outage even when the routing design is otherwise correct.

Redundancy must be designed in terms of the actual supported ACI architecture, not merely duplicated cables. Dual-homing can improve availability, but attachment policy, port-channel behavior and node recovery need consistency. The concepts behind data center redundancy with vPC are useful context, while ACI-specific operational validation must confirm the correct fabric bindings and policy deployment on both sides. A fabric failure simulation should evaluate application reachability, not just device uptime.

Bridge domains, subnets and contracts govern application reachability

The relationship among an EPG, bridge domain and VRF determines the forwarding context in which endpoints communicate. A bridge domain can provide gateways and flooding behavior, while the VRF carries routed reachability. Endpoint discovery, ARP and neighbor discovery, route distribution and contract enforcement together determine whether a packet traverses the fabric. An administrator troubleshooting a silent application should inspect these objects before changing random interface settings.

Suppose two application tiers use different bridge domains under one VRF. Route reachability may exist, but inter-EPG communication can require an appropriate contract. A denial may therefore be expected. Conversely, an overly broad contract can accidentally expose a database to application groups that were not supposed to reach it. Test destination ports and direction explicitly; “the servers ping each other” does not prove that the real application flow is allowed, and a blocked ping does not automatically mean that required TCP flows are blocked.

Policy design also requires an understanding of scale. A separate contract for every host-to-host pair is difficult to maintain; one contract that permits everything destroys segmentation. Organize EPGs around actual trust and communication requirements, use reusable filters where appropriate, and document why an exception exists. A contract change deserves the same scrutiny as a firewall rule change, including review of its consumer and provider scope. The general idea of network virtualization using VRF and VXLAN helps explain the underlying isolation model, but ACI object references are still the authoritative control for an ACI tenant.

External L2 and L3 connectivity introduces boundary design

Most application fabrics need access to firewalls, routers, load balancers, shared services and networks outside ACI. External routed connectivity is represented through suitable L3Out constructs, routing peers and security contracts; L2 external connection has different policy and loop-avoidance implications. The operator must distinguish the route imported from an external peer from the policy that allows an internal endpoint to use that route. A correct BGP route does not bypass a missing contract.

External routing decisions include protocol selection, prefix filtering, route control and failure domains. If a default route is accidentally imported into the wrong VRF or exported with excessive scope, multiple tenants can experience unexpected reachability or route selection. The implementation should make customer or application routing contexts explicit and set clear boundaries at every L3Out. For multi-site environments, the design also needs to specify which prefixes are shared and how policy remains consistent when the traffic crosses a site or external firewall.

Troubleshooting should follow one path in both directions. Confirm that the inside endpoint belongs to the intended EPG, its bridge domain and VRF can route toward the L3Out, the contract permits communication, and the external peer has a return route. Asymmetric return paths through a stateful firewall can break applications even when one-way route checks pass. A topology diagram that includes the external services boundary is as important as a list of APIC objects.

Virtualization integration creates dynamic endpoint membership

Virtual machine environments are attractive ACI consumers because workloads move. Integrating a virtual machine manager can synchronize endpoint membership and policies with the virtualization platform, reducing manual port configuration. It also creates an operational dependency: when a hypervisor host is reconfigured or a virtual network mapping changes, the fabric may see a different endpoint location or an unintended security group assignment. Static assumptions about which leaf or VLAN always owns a workload become unreliable.

The engineer should know which system is authoritative for each relationship, including virtual switch mapping, domain association, EPG assignment and VLAN allocation. The most common failure is not necessarily an invalid IP address; it may be a mismatch between a virtual port group and its intended EPG, or a domain binding absent on the leaf that currently hosts the workload. The ability to trace a VM's logical policy membership to its physical path is essential for verifying connectivity after migration.

Automation should make these relationships visible rather than conceal them. Use supported APIs and policy models to check whether the desired tenant and application objects exist, whether endpoint records match reality and whether deployment faults remain unresolved. ACI can simplify repeatable policy rollout, but it does not make tests unnecessary. An API success status is not proof that all affected endpoints have converged.

Measure fabric health through application behavior

A useful lab contains at least two leaf switches, two application groups, an external routed connection and a constrained contract. Move an endpoint, change one contract filter, introduce an L3Out route policy and observe the difference between management-plane status, endpoint learning and end-to-end traffic. Practice proving that an intended denial is functioning just as carefully as proving that an allowed flow works.

Operational visibility should extend beyond screenshots of controller health. Gather relevant interface errors, endpoint movement records, fault lifecycle and application request failures with consistent timestamps. Nexus monitoring through SNMP is one supporting technique in environments that expose suitable counters, while APIC-specific telemetry and fault views remain important. The point is to connect a fabric event to its user-visible outcome, not maximize dashboard count.

Production changes should record affected tenants, EPGs, VRFs, L3Outs and contract scopes. They should include a verification window for application requests and a documented rollback strategy, especially when changing shared resources or cross-tenant policy. In ACI, the correct unit of work is the application connectivity outcome, not the number of objects successfully created. 300-620 DCACI is best approached as the engineering of that outcome: predictable policy, healthy fabric forwarding and evidence that each application flow behaves as intended.