{"id":3662,"date":"2026-10-08T11:50:13","date_gmt":"2026-10-08T11:50:13","guid":{"rendered":"https:\/\/www.examtopics.info\/blog\/cisco-350-601-aci-policy-model\/"},"modified":"2026-10-08T11:50:13","modified_gmt":"2026-10-08T11:50:13","slug":"cisco-350-601-aci-policy-model","status":"publish","type":"post","link":"https:\/\/www.examtopics.info\/blog\/cisco-350-601-aci-policy-model\/","title":{"rendered":"Cisco 350-601: ACI Policy Model"},"content":{"rendered":"

Cisco 350-601: ACI Policy Model<\/h2>\n

Cisco Application Centric Infrastructure (ACI) manages the data center through an object-based policy model. Instead of configuring every forwarding decision as an isolated interface command, administrators describe tenants, network contexts, endpoint groups, application relationships, and contracts in APIC. The fabric then translates that desired policy into device-level behavior. Understanding those relationships is more important than memorizing the APIC menu structure because the same model appears in troubleshooting, APIs, and design discussions.<\/p>\n

The current 350-601 DCCOR<\/a> v1.1 exam covers core Cisco data-center technologies, while 300-620 DCACI<\/a> v1.1 goes deeper into ACI implementation and management. A useful ACI mental model starts with isolation and forwarding, then adds application grouping and policy between those groups.<\/p>\n

See the policy model as a hierarchy of managed objects<\/h3>\n

APIC represents ACI configuration in a management information tree. Objects have parent-child relationships, attributes, and distinguished names that identify their location in the tree. The GUI, API, and automation tools ultimately manipulate this same object model. That is why learning the hierarchy pays off beyond one configuration method.<\/p>\n

A tenant sits high in the policy structure and can contain VRFs, bridge domains, subnets, application profiles, endpoint groups, contracts, filters, and external connectivity objects. Objects inherit context through their relationships, so a troubleshooting question often becomes \u201cwhich object owns this policy and which objects reference it?\u201d rather than \u201cwhich switch has the command?\u201d<\/p>\n

The Cisco ACI and software-defined networking<\/a> is fundamentally controller-driven. APIC maintains policy intent and programs the fabric nodes. Engineers still need to understand forwarding behavior, but they investigate that behavior through the model that generated it.<\/p>\n

Use tenants to define policy ownership and administrative scope<\/h3>\n

A tenant is a logical container for application policy. It provides a boundary for organizing objects and can represent a business unit, customer, environment, or another administrative grouping. Cisco documentation describes a tenant as a policy isolation construct rather than a private network by itself. The actual Layer 3 isolation comes from VRFs inside or associated with the tenant.<\/p>\n

Tenant design should reflect operational ownership. If two application teams require completely separate lifecycle and policy control, separate tenants may make sense. If the separation is only network routing, different VRFs within a shared administrative tenant may be enough. Excessive tenant fragmentation can make shared services and troubleshooting more complicated, while overly broad tenants can blur responsibility.<\/p>\n

Shared resources require deliberate design. ACI can let tenants consume common services, but cross-tenant relationships should be documented because the resulting access is less obvious than policy contained entirely inside one tenant. The object model allows sharing; governance decides whether it should occur.<\/p>\n

Use VRFs to create Layer 3 forwarding domains<\/h3>\n

A VRF, called a context or private network in parts of the ACI interface, provides an independent Layer 3 routing domain. Endpoints in different VRFs do not automatically share routing tables. This gives architects a strong isolation primitive for tenants, application zones, environments, or security boundaries.<\/p>\n

Multiple bridge domains can associate with the same VRF. That relationship matters because the bridge domain controls Layer 2 and subnet behavior while the VRF supplies the Layer 3 context in which those subnets route. When an endpoint cannot reach a destination, confirm that both source and destination are in the expected VRF before focusing on contracts.<\/p>\n

VRF design also affects external connectivity. L3Out policies connect ACI routing domains to external networks, and the external prefixes or endpoint groups must be associated with the correct VRF. A misplaced VRF association can make a policy look correct at the EPG level while routing still fails.<\/p>\n

Bridge domains connect Layer 2 behavior to the routing context<\/h3>\n

A bridge domain represents a Layer 2 forwarding domain and is associated with a VRF. It can contain subnets that provide default-gateway services for endpoints, and it carries policy controls for behaviors such as unicast routing, ARP flooding, unknown unicast handling, and other forwarding characteristics depending on the design.<\/p>\n

Do not treat a bridge domain as a direct synonym for a traditional VLAN. A VLAN encapsulation can map endpoint attachment into an EPG, while the bridge domain is an ACI policy object that defines forwarding behavior for one or more EPGs. Keeping those concepts separate prevents designs that simply recreate a traditional VLAN diagram inside APIC without understanding the policy model.<\/p>\n

The internal discussion of VLAN and VXLAN<\/a> provides useful context for why modern fabrics separate endpoint segmentation from the limitations of a single physical Layer 2 topology. ACI handles the fabric details, but the architect still needs to decide which endpoints share a bridge domain and where Layer 3 boundaries should exist.<\/p>\n

Application profiles organize endpoint groups around application intent<\/h3>\n

An application profile is a container for endpoint groups that belong to an application or policy design. It helps operators describe relationships in terms of application tiers instead of switch ports. A common example is separating web, application, and database endpoints into distinct EPGs so policy can express which tiers may communicate.<\/p>\n

The application profile itself does not create connectivity. Its value is organization and context. Endpoints become members of EPGs, EPGs link to bridge domains and attachment policies, and contracts determine permitted communication between groups. Troubleshooting should follow those relationships rather than stopping at the application-profile name.<\/p>\n

Use names that describe function rather than physical location. \u201cpayments-web\u201d communicates more intent than \u201cleaf101-vlan210.\u201d Physical attachment can change while the application role remains stable. Policy models are most useful when object names help humans understand why the object exists.<\/p>\n

Endpoint groups are the main policy subjects in application connectivity<\/h3>\n

An endpoint group (EPG) is a collection of endpoints that share common policy requirements. Endpoints can be classified through static ports, VLAN encapsulation, virtual machine manager integration, or other supported mechanisms. Once classified, the endpoint inherits the policy relationships of its EPG.<\/p>\n

EPG design should reflect policy, not merely address range. Two servers can be in the same subnet but require different security relationships; separate EPGs let policy distinguish them. Conversely, splitting endpoints into many EPGs without a real policy difference creates management overhead without adding meaningful control.<\/p>\n

Intra-EPG communication is generally permitted by default, while inter-EPG communication depends on policy such as contracts. That makes EPG boundaries an important security decision. If two workloads should be mutually restricted, placing them in the same EPG and expecting a normal inter-EPG contract to separate them is the wrong design assumption.<\/p>\n

Contracts define which EPGs may communicate<\/h3>\n

Contracts are the policy mechanism that controls communication between endpoint groups. A provider EPG offers a service and a consumer EPG uses it. The contract contains subjects that reference filters, and filters describe the traffic criteria such as protocols and ports. This produces an allow-list relationship based on application roles.<\/p>\n

Good contracts are specific enough to express the required service without becoming impossible to operate. A web tier may consume TCP 443 from an application service, while a database tier exposes only the database port to the application EPG. Broad \u201cpermit any\u201d contracts weaken the benefit of the model because they preserve object structure without meaningful policy.<\/p>\n

Provider and consumer direction matters. When a contract appears present but traffic is denied, confirm which EPG provides the service, which consumes it, and which direction the filter represents. Also inspect whether a taboo contract, preferred group, vzAny relationship, or other policy feature changes the normal contract logic in that design.<\/p>\n

Domains and attachment policies connect logical EPGs to real endpoints<\/h3>\n

ACI policy still needs a way to attach servers, hypervisors, firewalls, and other systems. Physical domains, VMM domains, VLAN pools, attachable access entity profiles, interface policy groups, and static path bindings form the access-policy chain that maps an endpoint to the intended EPG.<\/p>\n

This chain is a common troubleshooting area because a correct tenant policy cannot help an endpoint that never lands in the expected EPG. Check the physical interface, policy group, VLAN encapsulation, domain association, and endpoint-learning information. In virtualized environments, confirm that the VMM integration and port-group mapping are healthy.<\/p>\n

The Cisco data-center architecture<\/a> context is useful here: controller-based policy does not remove the importance of physical redundancy, correct cabling, MTU consistency, and interface state. The policy model sits on top of an infrastructure that still must forward packets correctly.<\/p>\n

Use L3Out and external EPGs to model connectivity beyond the fabric<\/h3>\n

L3Out policies connect an ACI VRF to external routed networks. They define the routing protocol or static connectivity, node and interface profiles, and external network objects that represent prefixes outside the fabric. Contracts then control which internal EPGs can communicate with those external destinations.<\/p>\n

External connectivity therefore spans several policy layers. Route exchange must succeed, the prefix must appear in the right routing context, the external EPG must classify the destination as intended, and a contract must allow the traffic. A failure in any layer can look like a simple reachability problem from the server.<\/p>\n

Troubleshoot from routing and classification outward. Confirm the VRF, route presence, next hop, L3Out status, external prefix match, and contract relation. This is faster than changing filters randomly when the real problem is that the destination route never entered the fabric.<\/p>\n

When communication fails, start with the endpoints: are they learned, in the expected EPG, and associated with the correct bridge domain and VRF? Then examine the contract relationship and filter. If the destination is external, continue into the L3Out. If the endpoint is missing, move down into access policies and attachment.<\/p>\n

APIC faults, health information, endpoint tables, contract relationships, and API objects provide evidence along that path. Avoid using health scores as a substitute for diagnosis; a score tells you that something is degraded, while the object relationships explain why traffic is or is not permitted.<\/p>\n

The strength of the ACI model is that the same hierarchy supports design, automation, and troubleshooting. Once engineers understand tenants, VRFs, bridge domains, application profiles, EPGs, contracts, access domains, and L3Outs as connected objects, the fabric becomes easier to reason about than a collection of isolated switch configurations. That object-based understanding is the foundation for both manual APIC operations and reliable ACI automation.<\/p>\n

ACI automation should operate on the same relationships. A script that creates an EPG without checking its bridge-domain, VRF, domain, and contract references can leave syntactically valid but unusable policy. Build higher-level automation that validates the dependency graph before creating or deleting objects. The APIC API makes bulk changes possible; it also makes a wrong assumption repeatable at large scale.<\/p>\n

Object deletion deserves special care because relationships can outlive the engineer’s mental model. Before removing a contract, bridge domain, or application object, discover which consumers or references depend on it. Use APIC’s dependency information and a planned change diff rather than deleting until an error disappears. A failed delete can be a useful signal that another policy object still relies on the item.<\/p>\n

Operational naming conventions become part of the architecture. Prefixes or structured names can encode environment and application ownership, but avoid names so long and mechanical that nobody can recognize them during an incident. Combine readable object names with external inventory that records owner, business service, change history, and lifecycle. APIC represents network policy; it should not be forced to hold every piece of organizational metadata.<\/p>\n","protected":false},"excerpt":{"rendered":"

Cisco 350-601: ACI Policy Model Cisco Application Centric Infrastructure (ACI) manages the data center through an object-based policy model. Instead of configuring every forwarding decision as an isolated interface command, administrators describe tenants, network contexts, endpoint groups, application relationships, and contracts in APIC. The fabric then translates that desired policy into device-level behavior. Understanding those […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,1],"tags":[],"class_list":["post-3662","post","type-post","status-publish","format-standard","hentry","category-networking","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3662","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/comments?post=3662"}],"version-history":[{"count":0,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3662\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/media?parent=3662"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/categories?post=3662"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/tags?post=3662"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}