How do you configure hundreds of switches consistently without logging into each one individually and typing repetitive commands? ACI policy-based automation solves exactly that problem by letting you define your network rules once and having the fabric automatically apply them everywhere, which is a core skill tested in the 350-601 exam because it replaces fragile manual configurations with scalable, centralised control.
Jump to a section
A simple way to picture ACI Policy-Based Automation
A luxury hotel’s central booking office controls every room, every service, and every guest preference. Each guest is a 'tenant', each room is an 'endpoint', and the services they request—turn-down service, spa access, room service—are 'policies'.
In the old way, every hotel department (front desk, housekeeping, maintenance, billing) had its own computer system that didn’t talk to the others. When a VIP guest checked in, the front desk would type the details into their system, then have to separately call housekeeping to say 'prepare the penthouse', call the kitchen to say 'prepare the vegan breakfast', and call security to say 'allow VIP access to the pool'. Each department had to manually configure its own rules for the guest. This is like traditional networking: every switch and router is configured individually with CLI commands or SNMP—it works, but it is slow, inconsistent, and error-prone.
Now, the hotel deploys a central 'booking agent'—a single brain for the entire hotel. When the guest books, the agent receives one instruction: 'Guest: VIP, Room: 502, Preferences: All premium services, Security clearance: Full.' The agent automatically pushes that policy to housekeeping, the kitchen, billing, and security—without any separate phone calls. No department needs to know the individual steps; they just receive the final rule. This is ACI policy-based automation: one policy definition is centrally applied to every network device (switches, firewalls, load balancers) that touches that traffic, ensuring consistent, automated configuration across the entire data centre fabric.
ACI stands for Application Centric Infrastructure. It is a Cisco technology that changes how data centre networks are designed and managed. To understand policy-based automation, you first need to grasp what a 'policy' is in this context.
A policy is a set of rules that defines how traffic should be treated. In traditional networking, these rules are written individually on each device. For example, you might type a command on Switch A to allow traffic from Server 1 to Server 2, then type a similar command on Switch B for the same thing. If you have 100 switches, you repeat that 100 times. If you make a typo on one switch, that switch behaves differently, and you might not catch the mistake until something breaks.
ACI policy-based automation eliminates this by using a central controller called the APIC (Application Policy Infrastructure Controller). The APIC is the brain of the ACI fabric. You log into the APIC’s graphical interface or use an API (Application Programming Interface—a way for software to talk to software) and define your policies there. You write the rule once. Then, the APIC automatically pushes that rule to every switch in the fabric that needs it. This is the core of 'policy-based automation': the policy drives the configuration, not the other way around.
The ACI fabric is made up of two types of switches: spine switches and leaf switches. Think of a leaf switch as the switch that connects to servers (the edge), and a spine switch as the switch that connects leaf switches together (the backbone). All leaf switches connect to all spine switches in a full mesh. When you define a policy on the APIC, the APIC tells every leaf and spine switch exactly what to do. The switches do not need to think or decide; they simply obey the policy.
Why does this exist? Before ACI, network engineers had to configure each switch by hand or use scripts that could break in unpredictable ways. As data centres grew to thousands of servers, this became impossible to manage. ACI was created to bring the same kind of automation that cloud providers use (like VMware vSphere or OpenStack) into the physical network. It replaces the old 'device-by-device' model with a 'fabric-wide' model where the whole network is treated as one big switch.
What does this replace? It replaces the traditional three-tier hierarchical network design (access, distribution, core) where VLANs (Virtual Local Area Networks) and ACLs (Access Control Lists) were manually configured on each device. In that old model, adding a new server meant updating every switch along the path. In ACI, you define an 'endpoint group' (EPG)—a logical grouping of servers that have similar security and connectivity needs—and a 'contract' (a rule allowing traffic between EPGs). For example, you put all web servers in one EPG, all database servers in another EPG, and define a contract that says 'web servers can talk to database servers on TCP port 3306'. The APIC then programs this rule into the fabric automatically.
Key components you need to know for the exam:
Tenant: A logical container for policies. You can have multiple tenants for different customers or departments.
VRF (Virtual Routing and Forwarding): A separate routing table within a tenant. Each VRF is like its own private network.
Bridge Domain (BD): A layer-2 forwarding context within a VRF. Think of it as a subnet.
Endpoint Group (EPG): A collection of endpoints (servers, virtual machines) that share the same policy requirements.
Contract: A policy that defines what traffic is allowed between EPGs. Contracts specify which ports and protocols are permitted.
Filter: A rule within a contract that matches specific traffic (e.g., TCP port 80).
When traffic arrives at a leaf switch from a server, the leaf switch identifies which EPG the server belongs to. It then checks the contract that applies to that EPG. If the traffic is allowed, it forwards it to the destination. If not, it drops it. This is called 'enforcing the policy at the leaf'. The spine switches only forward traffic between leaf switches and do not enforce policies themselves. This design makes the fabric scalable and predictable.
Automation comes into play when you need to change policies. Instead of logging into multiple switches, you update the policy on the APIC. The APIC automatically recalculates the necessary configurations and pushes them to every affected switch. This can happen in seconds. It also provides a single point of truth: every switch’s configuration is derived from the policies in the APIC, so there is no risk of configuration drift (where switches slowly become different from each other).
For the 350-601 exam, you must understand that policy-based automation is the heart of ACI. You will be asked about the relationship between EPGs, contracts, tenants, VRFs, and bridge domains. You may also see questions about how ACI automates the application of policies across the fabric. Remember: in ACI, you do not configure switches; you configure policies that switches enforce.
1. Define a Tenant
Create a logical container for your policy domain. This isolates the configurations for one customer, department, or application from others. The APIC uses this to scope all subsequent objects.
2. Create a VRF within the Tenant
Define a separate routing table within the tenant. Each VRF is its own isolated network. All EPGs within the same VRF can potentially communicate if contracts permit; EPGs in different VRFs never communicate.
3. Create a Bridge Domain
Set up a layer-2 forwarding context (like a subnet) within the VRF. Specify the IP subnet and gateway. This is where endpoints reside logically.
4. Create Endpoint Groups (EPGs)
Define logical groups of endpoints (servers or virtual machines). For example, 'Web-EPG' for all web servers. Each EPG is associated with a bridge domain and will enforce the same policy.
5. Define Contracts and Associate to EPGs
Create a contract that specifies allowed traffic (ports, protocols). Associate the contract to the EPGs by having one EPG 'provide' the contract (e.g., database) and another EPG 'consume' it (e.g., application). This permits traffic between them.
6. Deploy the Policy via the APIC
The APIC automatically calculates the necessary switch-level configurations (VLANs, ACLs, VXLAN mappings) and pushes them to all leaf and spine switches. The network is now configured to enforce your policy.
An IT professional working in a medium-sized enterprise data centre is tasked with deploying a new three-tier web application: a front-end web server tier, an application server tier, and a database tier. In a traditional network, this would require the engineer to log into the top-of-rack switch for the web servers, create a VLAN, assign an IP subnet, and write an ACL to allow HTTP (port 80) and HTTPS (port 443) traffic from the internet. Then they would log into the switch for the application servers, create another VLAN, assign a different subnet, and write ACLs permitting traffic from the web servers on specific ports (e.g., TCP 8080). Finally, they would configure the database switch with yet another VLAN and ACLs allowing traffic only from the application servers on port 3306. If any switch was misconfigured, the application would fail. This process could take hours and was prone to human error.
With ACI policy-based automation, the engineer does the following:
Opens the APIC web interface and creates a new tenant called 'AcmeApp'.
Within that tenant, creates three EPGs: 'Web-EPG', 'App-EPG', and 'DB-EPG'.
Defines a contract 'Web-to-App' that permits TCP port 8080 traffic between Web-EPG and App-EPG.
Defines a contract 'App-to-DB' that permits TCP port 3306 traffic between App-EPG and DB-EPG.
Associates each EPG with the appropriate physical ports on the leaf switches where the servers are plugged in.
Once these policies are saved, the APIC automatically calculates the required switch configurations and pushes them to all relevant leaf switches within the fabric. The engineer does not touch a single command-line interface on any switch. The whole process takes about 15 minutes, and the policy is enforced consistently. If later the engineer needs to add a new web server, they simply plug it into any leaf switch port and assign that port to the Web-EPG in the APIC. The APIC automatically applies the correct VLAN, subnet, and security policy to that port. No additional switch configuration is needed.
Another common task is migrating existing servers into the ACI fabric. The engineer might use a tool like Cisco ACI Migration Tool or Cisco ACI Multi-Site Orchestrator to analyse current VLANs and ACLs on the legacy network and convert them into ACI policy objects (EPGs and contracts). This eliminates the risk of missing a rule during migration.
Day-to-day operational tasks also become policy-based: monitoring traffic flows, identifying which contracts are being used, and troubleshooting connectivity issues. If a developer reports that the database tier is unreachable, the engineer can look at the contract 'App-to-DB' in the APIC and see exactly which ports are allowed. They can also check the 'operational' tab to see which endpoints are in each EPG and whether any denies are occurring. This ability to visualise the entire policy structure from a single dashboard is a direct benefit of policy-based automation.
For the 350-601 exam, you should also know that ACI integrates with tools like Ansible, Terraform, and Python scripts via the APIC REST API. This allows the IT professional to automate policy creation even further—for example, when a new application is deployed via a CI/CD pipeline, a script can call the APIC API to create the necessary EPGs and contracts automatically. This is the real-world pattern: policy-based automation reduces manual effort, eliminates configuration drift, and enables rapid application deployment.
The 350-601 exam tests your understanding of how ACI policy-based automation works, not just what it is. Almost every question about ACI will involve at least one of the following concepts: EPGs, Contracts, Tenants, VRFs, Bridge Domains, and the APIC. You must memorise the definitions and relationships between these objects.
Question types that appear:
Scenario-based questions: You are given a business requirement (e.g., 'The web servers must communicate with the application servers on TCP port 8443, and the application servers with the database servers on TCP port 3306. You must isolate the database servers from the web servers.') You must choose the correct policy model (EPGs and Contracts) from multiple choice options.
Drag-and-drop ordering: You may be asked to order the steps for creating a policy in ACI, such as 'Create Tenant, Create VRF, Create Bridge Domain, Create EPG, Create Contract, Associate Contract to EPG'.
True/false or multiple choice: Statements like 'In ACI, contracts are applied to the spine switches for enforcement' (false; enforcement happens at the leaf).
Key exam traps to watch:
Confusing EPGs with VLANs: EPGs are logical groups, not VLANs. While an EPG may map to a VLAN, they are not the same. A VLAN is a layer-2 concept; an EPG is a policy grouping. The exam loves to have incorrect options that say 'EPG is a VLAN'.
Thinking contracts are applied to endpoints: Contracts are applied to EPGs, not to individual servers.
Believing that spine switches enforce policies: Spine switches only forward traffic; leaf switches enforce all policies.
Mixing up the direction of contracts: A contract is always 'provided' by one EPG and 'consumed' by another. The provider EPG offers a service (like a database), and the consumer EPG requests access to it. The exam might word it as 'which EPG provides the contract?'
Concepts the exam loves to test:
The relationship between Tenant, VRF, Bridge Domain, and EPG. Know that a tenant contains VRFs, VRFs contain Bridge Domains, and Bridge Domains contain EPGs.
The rule of contracts: Without a contract, no traffic flows between EPGs (even within the same VRF). This is called 'default deny'.
The difference between 'intra-EPG' and 'inter-EPG' traffic: Intra-EPG traffic is allowed by default unless a special micro-segmentation policy is defined. Inter-EPG traffic requires a contract.
The purpose of 'subjects' and 'filters' inside a contract: A subject defines the direction (from consumer to provider or both), and a filter specifies the actual ports (e.g., TCP 80).
Exam memorisation list:
EPG: Logical grouping of endpoints (servers, VMs) with same policy needs.
Contract: Policy that defines allowed traffic between EPGs.
Tenant: Isolated policy domain (like a customer or department).
VRF: Private routing table within a tenant.
Bridge Domain: Layer-2 forwarding context (subnet) within a VRF.
APIC: Central controller that manages and pushes policies to all switches.
Leaf switch: Enforces policies on traffic.
Spine switch: Forwards traffic between leaf switches; does not enforce policies.
You should also be prepared for questions that mix ACI concepts with other 350-601 topics, like VXLAN (Virtual Extensible LAN) or EVPN (Ethernet VPN). ACI uses VXLAN as its overlay encapsulation, and policy-based automation programs the VXLAN tunnel endpoints. A question might ask: 'Which protocol is used as the overlay in ACI to enable policy-based automation?' Answer: VXLAN.
ACI policy-based automation means you define network rules once on the APIC, and it automatically pushes them to every leaf and spine switch in the fabric.
An EPG is a logical group of servers that share the same policy requirements; it is not a VLAN.
A contract is the only way to permit traffic between different EPGs; the default is 'deny all' for inter-EPG traffic.
Leaf switches enforce all policies; spine switches only forward traffic and do not inspect or filter.
The APIC is the central controller that stores, manages, and distributes all policies to the entire ACI fabric.
In ACI, tenants, VRFs, bridge domains, and EPGs form a hierarchy: a Tenant contains VRFs, which contain Bridge Domains, which contain EPGs.
These come up on the exam all the time. Here's how to tell them apart.
ACI Policy-Based Automation
Policies are defined centrally on the APIC and automatically pushed to all switches.
Consistent configuration across the entire fabric; no risk of human error or drift.
Adding a new server requires only assigning its port to an EPG in the APIC.
Traditional Switch-by-Switch Configuration
Commands must be typed individually on each switch via CLI or separate management tools.
High risk of configuration inconsistency between devices due to typos or missed steps.
Adding a new server requires configuring VLAN, ACL, and port settings on the specific switch manually.
EPG (Endpoint Group)
A logical grouping of endpoints that share the same policy (security, QoS, etc.).
Spans multiple switches; not limited to a single broadcast domain.
Policy enforcement is based on the EPG membership, not the VLAN number.
VLAN (Virtual Local Area Network)
A layer-2 broadcast domain that separates network traffic at the data link layer.
Confined to a single VLAN ID; limited to 4094 VLANs in standard Ethernet.
Traffic is segmented by VLAN ID, but security rules must be added separately (e.g., ACLs).
Leaf Switch in ACI
Connects directly to servers (endpoints).
Enforces all security policies (contracts) on traffic entering or leaving the leaf.
Learns endpoint MAC and IP addresses and reports them to the APIC.
Spine Switch in ACI
Connects only to leaf switches, not to servers.
Does not enforce any policies; only forwards traffic between leaf switches.
Does not learn endpoint details; acts as a fast forwarding backbone.
Mistake
ACI policy-based automation means you don't need to understand IP addresses or VLANs at all.
Correct
ACI handles a lot automatically, but you still need to understand IP addressing, subnets, and VLANs because you have to configure them in the bridge domain and EPG definitions. The APIC does not guess your network design.
Beginners hear 'automation' and assume zero configuration. But you still define the building blocks; the automation only distributes them.
Mistake
Once a policy is defined, it applies instantly to every switch in the entire fabric without any delay.
Correct
Policy deployment is very fast (usually under a minute), but it is not instantaneous. The APIC must compute the required device configurations and push them. During a large-scale change, there may be a brief delay.
Marketing material often says 'real-time' or 'instant', which beginners interpret as zero latency. Real networks always have some processing time.
Mistake
Contracts allow traffic by default; you only add contracts to restrict traffic.
Correct
Contracts allow traffic. The default state in ACI is 'deny all' for traffic between different EPGs. You must create a contract to permit anything. This is a key exam point.
People confuse 'firewall rules allow traffic unless blocked' with ACI's default deny model. The exam flips this to trick you.
Mistake
You can apply a contract to any individual server (endpoint) directly.
Correct
Contracts are applied to EPGs, not to individual endpoints. An endpoint belongs to an EPG, and the EPG's contracts define what that endpoint can reach.
Newcomers think of 'user-level' permissions where you click on a server and set rules. ACI groups servers logically—this abstraction is the whole point.
Mistake
Spine switches enforce the security policies because they are the backbone of the fabric.
Correct
Leaf switches enforce all security policies. Spines only forward traffic based on the forwarding tables provided by the APIC. They do not inspect or filter traffic.
In traditional hierarchical networks, the core (spine-equivalent) often does routing and filtering. Beginners assume the same role exists in ACI.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An EPG is a logical grouping of endpoints with the same policy, while a VLAN is a layer-2 broadcast domain. An EPG can map to one or more VLANs, but they are distinct concepts—EPGs define policy, VLANs define connectivity.
No. By default, traffic within the same EPG is allowed. Contracts are only required for traffic between different EPGs. This is called intra-EPG versus inter-EPG traffic.
If a leaf switch fails, the APIC detects the failure and can recompute policy distribution for the remaining switches. Endpoints connected to that failed switch lose connectivity until the switch is replaced. The fabric automatically reroutes traffic around the failure if paths are redundant.
No. ACI requires Cisco Nexus 9000 series switches specifically designed for the ACI mode. The policy model is proprietary to Cisco and will not work with other vendors.
Micro-segmentation is achieved using uSeg EPGs (micro-segmented endpoint groups). You can create policies that isolate individual endpoints even within the same EPG. This is done via contracts with special filters or using security groups.
The APIC is deployed as a cluster of three or more physical or virtual appliances. If one APIC fails, the others continue to manage the fabric. The cluster provides high availability and automatic failover.
You've finished ACI Policy-Based Automation. Continue through the 350-601 study guide to build a complete picture of the exam.
Done with this chapter?