Cisco DCACI 300-620: Understand the Policy Inside the Fabric

An application team moves a payment service into a Cisco ACI data center. The front-end virtual machines are reachable, the leaf switches show healthy fabric links, and the endpoint database has learned the new addresses. Yet the application cannot open its database connection. An engineer proposes adding another VLAN everywhere, while another wants to disable a fabric policy. Both approaches are dangerous because they treat ACI as traditional switching with a decorative controller rather than a policy-driven system.

Cisco 300-620 DCACI, Implementing Cisco Application Centric Infrastructure, is a current CCNP Data Center concentration. Cisco's v1.1 material covers Nexus 9000 switches in ACI mode, configuration, implementation, management, external connectivity, and integration with virtualized environments. The professional task is to map what an application must communicate into fabric tenants, VRFs, bridge domains, endpoint groups, contracts, and operational evidence. The Cisco Data Center core exam 350-601 DCCOR addresses broader data-center architecture; DCACI concentrates on the policy operations of Cisco ACI, where object relationships influence how application traffic is handled.

Distinguish the fabric from the controller's policy model

A Cisco ACI fabric typically uses spine and leaf switches, with Cisco Application Policy Infrastructure Controller (APIC) managing policy and fabric objects. Leaf switches connect endpoints and enforce many policy decisions; spines provide high-capacity fabric connectivity. This physical structure supports scale, but it does not explain why an application flow is permitted. ACI's value is the relationship among declarative policy, endpoint classification, and forwarding behavior.

APIC is a management and policy component, not a magic transit hop through which every application packet must pass. A deployment can display an apparently correct object in the controller while the relevant enforcement state or endpoint attachment is wrong. For troubleshooting, identify the ingress leaf, the endpoint's encapsulation and group, its routing context, and the contract that governs communication. The difference between fabric health and application health is central to a good exam answer.

Data-center designers often compare the fabric with a conventional three-tier switched network. The leaf-and-spine physical layout distributes connectivity and reduces some of the hierarchy found in older topologies, but the policy difference matters more for an ACI specialist. In ACI, a tenant's application can be governed by centrally described endpoint and contract relationships that must reach the correct leaves. Design reviews should keep both views available: an engineer needs the cable and interface path to diagnose transport, and the endpoint-to-policy map to diagnose authorization. Within Cisco certifications, data-center and enterprise networking examinations emphasize different operational assumptions, so teams must be able to defend both physical topology and application policy.

Use tenants, VRFs, and bridge domains for the right boundaries

A tenant is an organizational container for ACI policy and related objects. VRFs provide Layer 3 routing separation. Bridge domains describe Layer 2-related forwarding and connected subnet behavior within an appropriate routing context. They answer different questions; using every object as though it were merely a VLAN creates unnecessary complexity and unclear ownership.

In the payment-service migration, confirm that the application and database endpoints belong to the expected tenant context, that their bridge domains map to the intended VRF, and that subnet/gateway relationships match the design. If the app and database occupy different network segments, determine what routing and contract policy are required. An apparent missing route can instead be a blocked contract or a mistakenly classified endpoint.

The model should follow actual application requirements, not arbitrary labels such as 'everything in Production.' A shared services team, a database owner, and an application team may have different responsibilities. Naming conventions, policy ownership, and change review are useful because a future troubleshooting engineer needs to identify why an object exists and whether it is safe to modify.

Understand endpoint groups and contracts as enforcement logic

Endpoint groups (EPGs) classify workloads according to the policies applied to them. A contract defines permitted communication between relevant providers and consumers, potentially using filters and subjects. An endpoint can be present and routable but still unable to communicate if no suitable contract allows the intended flow. Conversely, a broad contract may technically restore service while granting far more communication than the application requires.

For a web-to-database failure, name the specific source and destination EPGs and the service port and direction. Verify endpoint learning and placement, then read the applicable contracts and filters. A generic 'permit IP' rule is rarely the safest first choice. The application may need a narrowly specified database protocol and a separate monitoring path. Contracts should reflect those communication patterns so least privilege remains visible in fabric policy.

Policy troubleshooting should also distinguish an individual missing contract from an endpoint attached to the wrong EPG through static binding, virtualization integration, or domain configuration. Adding more contract permissions will not fix an endpoint that was classified into an unrelated group; it merely broadens the network for other workloads.

Integrate virtualized workloads without stale attachment state

Virtual Machine Manager integration can automate parts of the relationship between virtual networks and ACI policies. That convenience introduces dependencies on inventory, domain associations, hypervisor changes, and timing. When a virtual machine moves between hosts, its endpoint placement and policy association must remain consistent. A stale mapping or wrong domain can create intermittent connectivity that looks like a routing fault.

Document which team owns virtual domain bindings and which controls may be changed by APIC integration. A manual adjustment in a virtualization environment could be overwritten by centralized policy. Similarly, a fabric-wide configuration change designed for one troubled VM can unintentionally affect many applications sharing the same EPG or attachable domain.

To test a VM migration, follow the workload before and after movement: inspect endpoint classification, IP/MAC learning, leaf attachment, contracts, and application port reachability. Successful registration in the controller does not alone prove that policy was enforced as intended. A useful troubleshooting question is which layer knows the new location and which layer is still acting on the old state.

A particularly subtle ACI problem is contract inheritance through shared objects. A team may create a reusable service contract for database monitoring and then consume it from several endpoint groups. That is efficient only when each consumer truly needs the same communication. If a new production workload requires a narrower profile, reusing the shared contract can silently enlarge its access. Contract reviews should therefore describe actual flows and application ownership, not simply classify rules as 'common.' Validate changes against both newly permitted traffic and traffic that must remain denied. ACI's policy model is powerful precisely because one object can influence multiple workloads; that leverage also raises the importance of change impact analysis.

Connect external networks through controlled L3Out design

Applications in ACI rarely live entirely inside one fabric. They may need access to external WANs, firewalls, cloud connections, or legacy data centers. Layer 3 Outside (L3Out) objects represent external routed connectivity under the appropriate routing context. Operators must consider routing adjacencies, external EPG classification, contracts, and return paths. A route learned through an L3Out is not automatically evidence that every workload should reach it.

A financial application may depend on a partner network reachable through an external firewall. An ACI routing table can show a default route toward that firewall, but a contract may deny the flow, the external EPG may classify it incorrectly, or the return route may be missing. Investigate the boundaries in order: endpoint classification, contract, routing, external interface, remote policy, and reverse path. Do not treat the presence of an adjacency as proof of the business service.

External connectivity also has a failure-domain aspect. Redundant paths need consistent policy and tested convergence. A planned route advertisement change can affect multiple tenants if imported too broadly. Before modifying L3Out settings, identify which applications share that external object and how the change will be verified.

Diagnose with endpoint and policy evidence

ACI operations requires more than asking whether spines and leafs are green in a dashboard. Investigate endpoint location, fabric faults, policy deployment, contract hits or drops where available, routing state, and relevant interface counters. Gather evidence before changing multiple objects; an endpoint that disappears after a mobility event is a different problem from a valid endpoint being denied by a contract.

Telemetry should connect a failed request to a particular flow. A packet capture or policy trace is useful only when collected at the right enforcement point and correlated with the intended source and destination. Time synchronization matters across APIC and fabric devices when reconstructing a change. Health scores can surface symptoms, but a root-cause explanation must name the faulty classification, policy, or transport dependency.

Also test negative permissions. Confirm that an application EPG can reach its database but cannot reach unrelated customer data networks. ACI's model is not validated by making everything mutually reachable. It is validated when allowed flows succeed and undesired flows remain blocked through ordinary changes and failures.

Prepare with a small application policy migration

Build a tenant with a dedicated VRF, at least two bridge domains, web and database EPGs, and a narrow contract. Verify the expected application flow and one intentionally blocked flow. Move an endpoint, or change the EPG binding, and document the new operational state. Add a supported external connectivity scenario and follow the route and contract decisions all the way to the other network.

This lab yields a richer understanding than memorizing APIC menu locations. DCACI questions often ask which policy object or relationship is wrong, not whether the candidate can repeat a product description. The strongest answer preserves application isolation, maintains traceability, and fixes the smallest incorrect relationship. That discipline is what turns an ACI fabric from a healthy-looking collection of switches into a dependable application network.