600-660
Implementing Cisco Application Centric Infrastructure - Advanced (600-660 DCACIA)
Implementing Cisco Application Centric Infrastructure - Advanced (600-660 DCACIA) Exam Guide
The 600-660 DCACIA blueprint validates advanced work with Cisco switches in ACI mode, including configuration, implementation, management, and troubleshooting. It is aimed at candidates who already understand core ACI behavior and need to reason about forwarding, policy, Multipod, Multisite, and traditional-network integration. Before studying, make one important scheduling decision: confirm the current Cisco status and applicable exam code, because Cisco’s later announcement concerns the 300-630 DCACIA exam and recommends 300-620 DCACI for learners pursuing that retired content.
Confirm which exam you can actually schedule
Treat the official Cisco exam-status information as the first preparation task, not an administrative detail. The supplied exam-topics document identifies Implementing Cisco Application Centric Infrastructure – Advanced v1.0 as DCACIA 600-660, while Cisco’s later retirement announcement states that the 300-630 DCACIA exam and its associated specialist certification reached end of life on May 20, 2025, with May 20, 2025 as the last test date.
The code difference matters. The 600-660 document and the 300-630 retirement notice are not interchangeable references, so do not infer availability, certification credit, or a current booking option from a search result alone. Check the current Cisco exam and certification information before committing to study materials or a testing appointment.
Cisco’s announcement recommends the 300-620 DCACI exam for learners interested in the retired DCACIA exam because 300-620 was updated to include key concepts and topics from it. That recommendation gives you a practical branch in your plan: if the intended DCACIA route is unavailable, compare the current 300-620 scope with your career objective rather than continuing with an obsolete booking assumption.
A sensible first-day checklist
Record the exact exam code shown by the current Cisco registration or certification page. Then compare it with the official blueprint you are using, note whether your training provider labels its material for 300-630 or 600-660, and remove resources that describe a different version without explaining the relationship.
Use the official exam-topics PDF as a historical or scope reference only when the current Cisco information confirms that it applies to your intended assessment. Cisco also warns that exam topics are general content guidelines and that related topics may appear on a specific delivery, so a checklist is not a promise of exact questions.
What the assessment is designed to validate
This is an advanced ACI implementation assessment, not a vocabulary test. The official description centers on knowledge and skills involving Cisco switches in ACI mode: configuration, implementation, management, and troubleshooting. Your preparation should therefore connect design intent, policy objects, packet behavior, operational verification, and fault isolation.
A strong candidate can explain why a configuration produces a particular forwarding or policy result, identify where an integration belongs in the design, and choose a troubleshooting path that separates endpoint learning, encapsulation, contracts, external connectivity, and service insertion. Memorizing isolated object names is a weak substitute for that reasoning.
The blueprint is broad enough that you should expect related concepts to intersect. For example, a question about an external connection may require both policy knowledge and packet-forwarding knowledge; a Multipod scenario may involve the IPN, service graphs, and the placement of a firewall or load balancer. Study topics as connected workflows rather than sealed chapters.
The candidate profile this guide fits
This guide is most useful for an engineer who already works with ACI concepts and now needs advanced design and troubleshooting depth. It is less suitable as a first introduction to tenants, application profiles, endpoint groups, contracts, or basic fabric operation; if those objects are still unfamiliar, establish that foundation before beginning the advanced sequence.
Use the guide to decide whether your gap is conceptual, operational, or administrative. A conceptual gap means you cannot predict behavior from a topology. An operational gap means you know the design but cannot verify it in APIC or the fabric. An administrative gap means the target code, status, or training alignment is unclear. Each gap needs a different next action.
How the published blueprint should shape study time
Prioritize Advanced ACI policies and integrations first because that domain accounts for 25% of the published blueprint. ACI packet forwarding, Multipod, and Multisite each account for 20%, while Traditional network with ACI accounts for 15%. Keep the official domain name attached to every percentage; otherwise the numbers are easy to misread as a general difficulty ranking.
The weights are a planning aid, not a guarantee that the largest domain will appear as the most difficult part of your delivery. Cisco describes the list as general content guidance and notes that related topics may also appear. Allocate time by both blueprint weight and personal weakness, then revisit smaller domains often enough to prevent avoidable omissions.
Turn weights into a study allocation
Start with five labeled pages or notes: ACI packet forwarding; Advanced ACI policies and integrations; Multipod; Multisite; and Traditional network with ACI. Under each label, write the official concepts you must explain, the verification commands or APIC views you know, and one failure scenario you can troubleshoot.
Give the longest initial study block to Advanced ACI policies and integrations, but do not treat the 15% Traditional network with ACI domain as optional. A lower blueprint share can still expose a foundation weakness that affects several scenarios, particularly when ACI must coexist with external routing or existing network services.
After each study cycle, mark a topic as ready only when you can describe intended behavior, configuration dependencies, verification evidence, and a likely fault boundary. This standard is more useful than marking a page complete because you have read it once.
Build packet-forwarding intuition before memorizing outputs
ACI packet forwarding accounts for 20% of the published DCACIA v1.0 blueprint and includes VXLAN leaf-to-leaf forwarding, server NIC teaming, and endpoint-learning optimizations. Study these as a packet’s journey: identify the source and destination endpoints, determine where learning occurs, follow the encapsulation and lookup decisions, and then explain what changes when the topology or teaming mode changes.
Draw the forwarding path before looking at an answer or a reference diagram. Label the leaf roles, endpoint location, encapsulation boundary, and any intermediate device. Then ask which observation would prove each step. This forces you to separate a control-plane expectation from a data-plane symptom.
A frequent mistake is to memorize that a feature exists without learning the condition under which it changes forwarding. Another is to troubleshoot only the endpoint or only the fabric. For each scenario, inspect both sides: endpoint attachment and learning state, then fabric policy and forwarding state.
A repeatable forwarding exercise
For every forwarding exercise, write four short answers: where the endpoint is learned; what policy permits the communication; how the packet is carried between relevant leaves; and what evidence would distinguish a policy failure from a forwarding failure. Include server NIC teaming in at least one exercise and explain how endpoint-learning behavior affects diagnosis.
Use a small topology that you can redraw from memory. Add a second leaf, a second endpoint, and a changed attachment or teaming condition one at a time. The point is not to create a large laboratory; it is to observe how one design change alters the expected path and the evidence you would seek.
Master advanced policy and external integrations as design problems
Advanced ACI policies and integrations account for 25% of the published blueprint. The listed subjects include Layer 3 out transit routing, common tenants, VRF route leaking, contracts, and Layer 4–Layer 7 policy-based routing. Prepare by tracing dependencies between objects and traffic flows, not by studying each object in isolation.
For Layer 3 out work, begin with the desired external reachability and identify the relevant tenant, VRF, external network, routing behavior, and contract relationship. For route leaking, state which VRFs exchange routes, what policy permits the exchange, and which traffic should remain isolated. For common tenants, distinguish shared policy intent from accidental overexposure.
Layer 4–Layer 7 policy-based routing deserves an explicit decision table. Record the traffic classification, the selected service or path, the direction of travel, and the expected behavior if the service device is unavailable. Then compare that table with the service-graph design so that policy intent and service placement remain consistent.
Avoid the contract-only troubleshooting trap
A contract problem is only one possible cause of failed traffic. When an external or service-inserted flow fails, check the endpoint and bridge-domain assumptions, routing and reachability, contract direction and scope, service-graph attachment, and the return path. This sequence prevents the common mistake of repeatedly editing a contract when the real fault is routing or placement.
Create one-page dependency maps for each advanced scenario. Use arrows to show which object supplies connectivity, which object supplies permission, and which object selects a service path. If you cannot explain an arrow, consult the official learning material or documentation before treating the scenario as understood.
Study Multipod through the IPN and service path
Multipod accounts for 20% of the published blueprint and covers the IPN, inter-pod packet flow, firewall and load-balancer design, and service graphs. Your goal is to explain what changes when the fabric spans pods, which function belongs to the IPN, and how security or application services are placed without losing track of the end-to-end path.
Begin with a topology that identifies each pod, the IPN, the relevant leaves, and the service devices. Trace traffic between pods in both directions. Then add a firewall or load balancer and determine whether the service is being used as intended, whether the return path is valid, and which policy objects express the desired behavior.
Do not study Multipod as merely “ACI in more locations.” The IPN and inter-pod path introduce boundaries that affect design and troubleshooting. Write down the evidence you would collect at the source pod, destination pod, IPN-facing elements, and service integration points.
A practical Multipod lab sequence
First validate ordinary endpoint communication within one pod. Next validate communication between pods without a service insertion. Only then introduce the firewall or load balancer and a service graph. This order gives you a baseline and prevents a service-policy problem from being confused with an inter-pod transport problem.
For each added component, maintain a fault-isolation table with three columns: expected behavior, observable evidence, and likely fault boundary. Include the return path in every row. Many design explanations look correct in one direction and fail when the response traffic follows a different route.
Treat Multisite as coordination plus communication
Multisite accounts for 20% of the published blueprint. The published topics include Multi-Site Orchestrator, ISN, stretched-component options, and communication across sites. Study the domain by separating what is coordinated across sites from what remains local, then trace how the selected stretched or non-stretched design affects communication and operations.
Draw two sites and label the intersite network, orchestration function, local fabric elements, and any shared or stretched policy. For each application requirement, decide whether the design needs stretched components or only communication between independently managed sites. Record the operational and troubleshooting consequence of that choice.
A common mistake is to assume that centralized policy intent removes the need to understand local behavior. It does not. A site-to-site failure still requires you to identify the local endpoint state, intersite connectivity, policy scope, and return path. Practice explaining the failure boundary without collapsing the two sites into one logical diagram.
Questions to ask for every Multisite scenario
Ask four questions in order: what must be coordinated; what must be stretched; how does traffic cross between sites; and which component would you inspect first when communication fails? Add a fifth question for operations: which change is local and which change is propagated through the orchestration model?
Use contrast exercises rather than one “ideal” design. Compare an application that requires stretched components with one that only requires site-to-site communication. The contrast makes the design choice explicit and helps you avoid treating every Multisite requirement as the same deployment pattern.
Connect traditional networking to ACI behavior
Traditional network with ACI accounts for 15% of the published blueprint. Prepare for this domain by mapping familiar routing, external connectivity, and service assumptions to ACI policy and fabric behavior. The objective is not to abandon traditional networking knowledge; it is to identify where that knowledge must be expressed through ACI constructs and verified through ACI-specific evidence.
Take one conventional network requirement at a time: external reachability, segmentation, route exchange, or service insertion. Write the traditional expectation first, then map it to the ACI tenant, VRF, external connection, contract, and service-policy elements that implement it. Finally, list the ACI and external observations that would confirm the design.
Avoid the opposite errors of treating ACI as ordinary switching or treating it as unrelated to routing fundamentals. A candidate who knows the object names but cannot explain route direction, isolation, or return traffic will struggle with integration scenarios. Keep a two-column comparison in your notes: network intent and ACI expression.
Use integration failures to test understanding
When an external flow fails, state whether the issue is reachability, route exchange, policy permission, service selection, or return traffic. Then identify the smallest set of observations that would separate those causes. This is more efficient than changing several policy objects and losing the original evidence.
Include at least one exercise in which the external network is reachable but the application flow remains blocked. Include another in which policy appears permissive but routing is incomplete. These paired cases teach you not to use successful reachability as proof that the entire application policy is correct.
Use a four-phase preparation roadmap
A practical roadmap has four phases: verify the target exam and sources; establish ACI forwarding and policy foundations; work through Multipod, Multisite, and traditional integrations; then rehearse timed reasoning and troubleshooting. Move forward only when you can explain behavior and evidence, not merely repeat terminology.
The roadmap should be diagnostic. If you already manage ACI fabrics, shorten the foundation phase and spend more time on cross-domain scenarios. If your ACI knowledge is mainly theoretical, keep the forwarding phase longer and build a small repeatable lab or diagram-based simulation before attempting advanced service and multisite cases.
Phase one: scope and baseline
Confirm the applicable Cisco exam code and current availability. Download or review the matching official blueprint, create the five-domain checklist, and write a baseline explanation of how an endpoint communicates with another endpoint through ACI. Note every point where your explanation becomes vague.
Do not buy or schedule anything until the code and status are clear. The supplied DCACIA training document says its training prepared candidates for the 300-630 DCACIA v1.0 exam and provided 40 Continuing Education credits toward recertification; that does not by itself establish that the course is current preparation for 600-660 or for another replacement exam.
Phase two: forwarding and policy foundations
Work through ACI packet forwarding first, then advanced policies and integrations. For each topic, produce a diagram, a configuration dependency list, a verification plan, and a failure variant. This sequence gives you the technical base needed to understand why Multipod and Multisite scenarios behave differently.
End the phase with closed-book explanations of VXLAN leaf-to-leaf forwarding, server NIC teaming, endpoint-learning optimizations, Layer 3 out transit routing, VRF route leaking, contracts, and Layer 4–Layer 7 policy-based routing. Any topic you can name but not explain becomes the next study target.
Phase three: distributed and traditional designs
Study Multipod and Multisite only after you can trace a single-pod flow. Add the IPN, inter-pod communication, service devices, orchestration, ISN, and stretched-component decisions incrementally. Then translate a traditional network requirement into ACI policy and test the return path.
At the end of this phase, compare the domains in a single design review. For example, ask how an application’s external route, contract, service graph, inter-pod transport, and site-to-site communication interact. Cross-domain review is where disconnected memorization is most likely to fail.
Phase four: timed rehearsal and gap repair
The official 600-660 DCACIA exam-topics document lists a 90 minutes duration. Use that fact to rehearse concise reasoning rather than writing long explanations. Practise reading a scenario, identifying the required outcome, eliminating incompatible designs, and selecting the verification evidence that supports your choice.
After each rehearsal, classify the miss: misunderstood requirement, wrong traffic path, missing dependency, weak troubleshooting order, or time lost on an uncertain detail. Repair the category, not just the individual question. Do not use exam dumps or leaked-question claims as a substitute for understanding; memorization cannot establish whether a design works or why it fails.
Conclusion
Your next action should be administrative and technical: confirm the current Cisco exam route, then use the official blueprint to build a five-domain checklist. Study advanced policies and integrations with the largest published share, but give equal analytical attention to the 20% packet-forwarding, Multipod, and Multisite domains and the 15% Traditional network with ACI domain. Finish by tracing complete flows, testing failure boundaries, and checking every resource against the correct exam code.