Enterprise architecture for Cisco 350-401 ENCOR: Concepts, Scenarios, and Study Priorities

 

Enterprise architecture questions are rarely solved by naming the most advanced platform. They are solved by matching a design to requirements, failure domains, operational constraints, policy boundaries, and verification needs. That is exactly how Cisco frames the Architecture domain in the current 350-401 ENCOR v1.2 blueprint.

Architecture represents 15% of the ENCOR exam. The current scope covers high-level 2-tier, 3-tier, fabric, and cloud design; high availability including redundancy, FHRP, and SSO; Catalyst SD-WAN control/data-plane concepts and trade-offs; SD-Access and coexistence with traditional campus networks; and interpretation of QoS configurations. Older wireless-design objectives from v1.1 are not part of the v1.2 blueprint.

That breadth is a clue about the expected level. A candidate on the CCNP Enterprise path should be able to explain why a design changes failure blast radius, convergence, policy placement, operational complexity, or application behavior. Memorizing that a fabric has an underlay and overlay is not enough if you cannot reason about what fails when one layer is healthy and the other is not.

Architecture also sets the boundaries for later domains. Security policy, assurance data, virtualization, and automation all depend on where forwarding and control decisions occur. Use the ENCOR security guide as a cross-check: if you cannot identify where identity, segmentation, management access, and encryption should be enforced in the design, the architecture model is incomplete.

Start with requirements before topology

A design begins with constraints and outcomes.

How many users and sites must the network support? How quickly is growth expected? Which applications are sensitive to latency, loss, or jitter? How much downtime is acceptable? Which parts of the environment require segmentation? How centralized should policy be? What operational skills does the team have? How much complexity can the organization sustain?

Those questions determine whether a design that looks elegant on paper is actually appropriate.

A two-tier campus can be highly effective when the scale and operational requirements do not justify an additional core layer. A three-tier design can provide clearer modularity and scale in larger environments. A fabric can centralize policy and simplify certain forms of segmentation and mobility, but it also introduces controllers, overlays, and operational dependencies that the team must understand.

The ENCOR mindset is not “three-tier is better than two-tier.” It is “which architecture best meets the stated requirements and what trade-offs follow?”

Understand the two-tier campus

In a two-tier campus, the access layer connects endpoints while a collapsed core/distribution layer provides aggregation, routing, policy, and connectivity toward other parts of the network.

The design can reduce device count and simplify operations. It works well in many small and medium environments where a dedicated core would add cost and complexity without sufficient benefit.

Study the failure domains. What happens if one distribution device fails? How are uplinks designed? Where does first-hop redundancy exist? Are access switches dual-homed? Does the design use Layer 2 or routed access patterns? Which control-plane protocols reconverge after failure?

Draw the topology and annotate what each device is responsible for. Then change a requirement. If the campus doubles in size or must connect many distribution blocks, does a dedicated core become useful?

This is how to turn a diagram into architectural reasoning.

Understand the three-tier campus

The classic three-tier model separates access, distribution, and core.

Access connects users and devices. Distribution aggregates access, defines boundaries, performs routing and policy, and provides redundancy. Core provides fast, resilient connectivity between distribution blocks and other major network areas.

The value of the core is not simply “another layer.” It creates a stable transit function that can improve modularity as the network grows.

A good study exercise is to compare failure and change impact. If a distribution block undergoes maintenance, can the core continue connecting other areas? If a new building is added, where is the new block attached? Which policies stay at distribution instead of being pushed into the core?

ENCOR architecture questions become easier when you think of modularity as limiting the blast radius of change and failure.

High availability is a system property

Redundancy is not the same as availability.

Two devices can exist and still share a single power source, uplink, control dependency, or misconfiguration. High availability requires you to identify the failure being protected against and confirm that the redundant element actually provides an independent path or function.

The v1.2 blueprint includes techniques such as redundancy, FHRP, and stateful switchover concepts.

For first-hop redundancy, focus on the user experience. Endpoints keep a stable default-gateway address while the active forwarding role can move between devices. Understand priorities, preemption concepts where relevant, and what happens when a device or path fails.

For system-level redundancy, ask what state needs to survive a failure. Route information, forwarding state, controller reachability, policy, and sessions can all influence convergence.

A strong answer identifies the failure domain and the recovery mechanism rather than simply choosing “add redundancy.”

Separate control plane and data plane

Modern enterprise architecture becomes easier when you consistently distinguish control from forwarding.

The data plane moves packets. The control plane establishes the information used to decide where packets go. Management systems can add another layer by providing configuration, policy, telemetry, and orchestration.

In SD-WAN, centralized components can distribute policy and control information while branch or edge devices continue forwarding traffic. In SD-Access, fabric control and policy components help determine how endpoints are identified, segmented, and connected across the underlay.

This separation allows centralized intent without requiring every packet to pass through a controller.

When studying any software-defined architecture, ask four questions: Who makes policy? Who learns state? Who programs or influences forwarding? Which device actually forwards the packet?

Those questions prevent controllers from becoming a memorized list.

Catalyst SD-WAN: understand the architecture story

Catalyst SD-WAN is designed to provide policy-driven WAN connectivity across diverse transports.

At a high level, the architecture separates control and orchestration functions from distributed forwarding at the edge. This allows centralized policy, route and reachability exchange, segmentation, telemetry, and application-aware path decisions while branch devices forward user traffic.

For exam preparation, focus on the role of the main components rather than memorizing every software release name. Know how secure control connections are established conceptually, how routes or policies are distributed, how multiple transports can be used, and why application-aware routing can improve use of WAN paths.

Then study limitations and operational considerations. Centralization can improve consistency, but controller availability, certificate trust, underlay reachability, policy design, and operational skills still matter.

A useful scenario is a company with MPLS and broadband links that wants centralized policy and better application path selection. Explain why SD-WAN may fit and which new dependencies it introduces.

SD-Access: policy and segmentation across the campus

SD-Access applies fabric concepts to the enterprise campus.

The architecture uses an underlay for IP reachability and an overlay for endpoint connectivity and segmentation. Control-plane mechanisms track endpoint identity and location, while policy systems can support scalable segmentation.

Do not study SD-Access only as component names. Understand the problems it is trying to solve: consistent segmentation, mobility, centralized policy, and simplified operations at scale.

A traditional campus often binds policy closely to VLANs, subnets, and device-by-device configuration. A fabric approach can separate logical policy from some of those physical constraints.

The trade-off is additional architectural machinery. Controllers, fabric roles, underlay health, mapping, and policy systems must all operate correctly.

If an endpoint can reach some destinations but not others, ask whether the problem is underlay reachability, overlay mapping, policy, or border connectivity. That layered reasoning is more useful than memorizing architecture slides.

Traditional campus and SD-Access can coexist

Real enterprises rarely replace an entire network at once.

The v1.2 blueprint explicitly expects candidates to understand traditional campus interoperability with SD-Access. That means you should be able to reason about boundaries between fabric and non-fabric portions of the environment.

Study where traffic enters or leaves the fabric, how routing and segmentation information may cross those boundaries, and why migration design matters.

A useful scenario is a campus that converts one building to fabric while other buildings remain traditional. Users still need shared services. The design must preserve reachability and security while avoiding policy inconsistency.

This is a recurring enterprise architecture theme: new and old systems need a controlled transition path.

Cloud is an architectural location and operating model

“Cloud” in an enterprise architecture diagram can mean many things: SaaS applications, IaaS workloads, cloud-native services, security services, or management platforms.

Avoid treating cloud as simply “the internet.”

Ask how sites reach cloud workloads, where security inspection occurs, how identity and segmentation are maintained, whether traffic should backhaul through a data center, and how resilience is designed across providers or regions where appropriate.

SD-WAN can be relevant because branch users often need efficient access to distributed applications. Direct internet access may improve performance but changes security and visibility requirements.

A good architecture explanation connects cloud adoption to routing, security, observability, and operations rather than adding a cloud icon to the diagram.

QoS is architecture when application behavior matters

QoS is included in the Architecture domain because application requirements influence network design.

Start with traffic characteristics. Real-time voice and video are sensitive to delay and jitter. Transactional applications may be sensitive to latency. Bulk transfers may consume bandwidth but tolerate delay.

QoS creates differentiated treatment through classification, marking, queuing, policing, shaping, and related mechanisms.

For ENCOR, practice interpreting policy rather than only defining terms. Given a policy, identify which class a packet enters, what marking occurs, and what treatment applies under congestion.

Architecture questions may also ask whether the network has enough capacity and whether QoS is being used appropriately. QoS cannot create bandwidth; it decides how limited resources are treated.

The best study approach is to connect policy configuration to an application requirement.

Architecture scenario: growing campus

A company has one building with a collapsed core and is expanding to four large buildings. The current design uses Layer 2 uplinks and has increasingly large failure domains.

Do not jump immediately to one vendor design. Identify the requirements: scale, resilience, change isolation, policy consistency, and operational capability.

A more modular architecture may introduce routed boundaries and a dedicated core, or the organization may evaluate a fabric approach if segmentation and mobility requirements justify it.

Compare options. Traditional modular design may be operationally familiar. Fabric may simplify some policy tasks but require new control components and skills.

The correct exam reasoning is to choose based on stated constraints, not architectural fashion.

Architecture scenario: branch WAN transformation

An organization has hundreds of branches using a mix of MPLS, broadband, and cellular backup. Application use is shifting toward SaaS and cloud services.

The existing network backhauls most traffic to a central data center, creating latency and inefficient use of links.

An SD-WAN design can centralize policy, use multiple transports, and make application-aware path decisions. But the architecture must also address security for direct internet access, controller availability, branch onboarding, segmentation, and monitoring.

A strong answer identifies both benefits and new dependencies.

This is why “SD-WAN is cheaper” is too simplistic. Cost can be a benefit, but architecture is driven by policy, application performance, resiliency, operations, and security as well.

Architecture scenario: segmentation requirement

A university campus needs students, faculty, facilities devices, research systems, and guests separated by policy. Users move between buildings frequently.

Traditional VLAN/subnet segmentation can work, but at larger scale it may create operational complexity when policy and location are tightly coupled.

A fabric-based approach can create more identity- or group-oriented segmentation and support mobility. The design still requires healthy underlay reachability and controlled connections to shared services and external networks.

On the exam, identify whether the problem is primarily segmentation, mobility, or simple network isolation. Not every environment requires fabric.

The architecture should be proportional to the requirement.

Compare architecture trade-offs explicitly

Build a comparison table during study.

Two-tier: lower complexity, fewer devices, suitable for moderate scale; may become less modular as the environment grows.

Three-tier: stronger modularity and scale; more devices and design considerations.

Traditional campus: familiar operation and broad skills; policy can become device- and location-dependent.

SD-Access: centralized policy and fabric segmentation; adds controller, overlay, and migration complexity.

Traditional WAN: direct control and familiar routing; policy consistency across many sites can be operationally expensive.

SD-WAN: centralized policy and multi-transport use; introduces controller/orchestration and secure onboarding dependencies.

Do not memorize “pros and cons” as universal truths. Tie each one to a scenario.

Study Architecture with drawings

Architecture is one domain where drawing is especially effective.

Sketch the design from memory. Label control plane, data plane, policy, redundancy, and boundary roles. Then explain one packet path.

For SD-WAN, draw branch edges, transports, and control components. For SD-Access, draw underlay, fabric roles, and external connectivity. For campus, draw access/distribution/core or collapsed core.

If the drawing becomes a collection of unexplained boxes, you need more understanding.

After each drawing, add one failure and explain what should happen.

This active method is more useful than rereading polished diagrams.

Use verification even in design study

Architecture sounds conceptual, but operational evidence matters.

For high availability, what state proves the active/standby relationship? For QoS, what counters prove classification? For SD-WAN, what health and path information would an operator inspect? For SD-Access, what evidence confirms underlay reachability, endpoint mapping, or policy?

You do not need every command for every controller. You do need the mindset that architecture ultimately produces observable network behavior.

This connection between design and verification also prepares you for the practical preparation guide.

Common architecture mistakes

One mistake is choosing the most advanced design regardless of requirement.

Another is equating redundancy with high availability without identifying shared failure points.

A third is confusing control-plane centralization with centralized packet forwarding.

A fourth is memorizing SD-WAN or SD-Access component names without understanding packet and policy flow.

A fifth is ignoring operations. A design that the team cannot monitor, secure, and change safely may not deliver its theoretical benefits.

A sixth is reading QoS configuration without connecting it to application behavior.

Correct those mistakes by constantly asking “what problem is being solved?” and “what evidence shows the architecture is working?”

Build an Architecture study checklist

Your checklist should include: two-tier and three-tier principles; fabric and cloud concepts; redundancy and FHRP; SD-WAN control/data-plane behavior and trade-offs; SD-Access underlay/overlay and traditional interoperability; QoS interpretation.

For each item, write one scenario and one failure.

Then explain the architecture aloud without notes.

If you can explain the requirement, mechanism, trade-off, failure behavior, and verification path, you are studying at a professional level.

Architecture judgment at exam depth

Enterprise architecture for ENCOR is not about choosing a favorite design. It is about understanding how requirements become topology, policy, redundancy, and operational dependencies.

Keep the current v1.2 scope in view. Build from requirements. Separate control from forwarding. Treat high availability as a failure-domain problem. Connect SD-WAN and SD-Access to the problems they solve. Read QoS as application treatment.

Use Cisco certifications for supporting context, but practice making and defending design decisions yourself.

The strongest Architecture candidate can look at an unfamiliar enterprise scenario and build a reasoned design story from first principles.

High availability scenario: redundancy without independent paths

A campus has two distribution switches, but both depend on the same upstream firewall and power distribution unit. The design team calls the campus highly available because every access switch is dual-homed.

This is a useful ENCOR scenario because it exposes the difference between component redundancy and end-to-end resilience.

Map the user path to critical services. Identify each point where both “redundant” paths converge. Those shared dependencies are potential single points of failure. The correct improvement may involve redundant upstream security, diverse physical paths, independent power, or a different routing design depending on the requirement.

FHRP protects the default-gateway function. It does not protect every upstream dependency. Stateful switchover can preserve control or forwarding state on a platform, but it also does not create a second WAN circuit.

Architecture questions often become straightforward when you ask, “Which exact failure is this mechanism designed to survive?”

Understand FHRP as an endpoint-facing abstraction

Hosts normally need one default gateway. Redundant routers create a challenge because endpoints should not need to change configuration when one gateway device fails.

First-hop redundancy protocols solve that problem by presenting a virtual gateway identity while physical devices coordinate forwarding responsibility.

From an architecture perspective, the interesting questions are not only protocol names. Consider gateway placement, Layer 2 boundaries, tracking of upstream health, convergence expectations, and whether the redundancy exists at the right failure domain.

A design can have a perfectly functioning virtual gateway while upstream connectivity from the active device is impaired. Tracking can help the role follow actual service health where appropriate.

In exam scenarios, do not stop at “there are two routers.” Ask whether the endpoints retain gateway service through the stated failure.

SD-WAN scenario: control is healthy, application path is not

Imagine branch edges remain registered with the SD-WAN control system and management views show devices as reachable. Users still report that a critical application is performing poorly.

The control plane being healthy does not prove every data path is healthy.

Investigate transport quality, application-aware routing policy, path preference, QoS, loss, latency, and any local or cloud security path. Determine whether the policy is choosing a path that is technically up but operationally poor.

This scenario reinforces an architectural rule: control-plane state, data-plane state, and application experience are related but distinct.

A candidate who understands that separation is less likely to choose a controller-focused answer when the evidence points to forwarding or performance.

SD-Access scenario: underlay versus overlay failure

A fabric edge can reach the border device at the IP underlay, but a group of endpoints cannot reach a shared service.

Because underlay reachability works, the next questions should involve overlay state, endpoint mapping, segmentation policy, or border connectivity rather than ordinary IP transport.

Now reverse the scenario. Multiple fabric roles lose reachability to one another. Overlay symptoms appear everywhere. The underlay becomes a stronger suspect because it is the transport on which the overlay depends.

This is why architecture study should include dependency graphs. Underlay supports overlay; mapping supports endpoint reachability; policy controls permitted communication; border functions connect fabric to external networks.

When a scenario names several components, identify the dependency that must be true first.

Migration architecture: avoid the big-bang assumption

Organizations often move gradually from traditional networking to software-defined architectures.

A realistic migration may begin with visibility and controller onboarding, then introduce centralized policy, selected fabric areas, or branch conversions in stages. Existing routing, segmentation, and operational processes continue during transition.

A good migration design defines coexistence, rollback, testing, training, and success measures.

For ENCOR, you do not need a product deployment playbook. You should recognize that interoperability with traditional networks matters and that migration creates temporary architectural boundaries.

A strong answer prefers staged validation when risk is significant. It also preserves monitoring and security across both old and new portions of the environment.

The architecture is not complete until operations can support it.

Cloud connectivity scenario: direct internet access versus backhaul

A branch accesses mostly SaaS applications but sends all traffic through a central data center for security inspection. Users complain about latency.

Direct internet access could improve application path efficiency, but the decision changes security and visibility.

Ask what controls currently exist at the data center. If the branch exits locally, where will DNS security, firewall inspection, web policy, identity, logging, and threat controls operate? Does the SD-WAN or cloud-security design provide equivalent or improved protection?

The architectural answer is not “local breakout is faster.” It is “local breakout can reduce unnecessary path length if security and policy are redesigned appropriately.”

This is a classic trade-off scenario: performance, security, operations, and cost must be evaluated together.

QoS scenario: priority is not unlimited bandwidth

A WAN carries voice, interactive business traffic, backups, and software distribution. During congestion, users complain about call quality.

A QoS policy can classify voice and provide priority treatment, but the priority queue should be designed carefully. Unlimited priority traffic can starve other classes. Marking also needs to be trusted or enforced at appropriate boundaries.

Study the full chain: classify, mark, queue, police or shape where needed, apply the policy in the correct direction, and verify counters.

Then ask what happens when the link is simply too small for the total required load. QoS can manage contention; it cannot create capacity.

ENCOR architecture reasoning should therefore combine policy with capacity planning.

Architecture verification plan

Even before implementation, define how the design will be validated.

For a campus, verify failover, routing convergence, gateway resilience, segmentation, and application reachability. For SD-WAN, verify transport loss behavior, path selection, policy distribution, branch onboarding, and application performance. For SD-Access, verify underlay reachability, endpoint registration, segmentation, and external connectivity.

For QoS, generate representative traffic and inspect class counters and performance under congestion.

For high availability, fail the component the design claims to survive. Do not simply inspect that two devices exist.

A design becomes credible when there is a practical way to prove that requirements are met.

Turn architecture requirements into acceptance criteria

“Network should be resilient” is not an acceptance criterion.

A better statement might specify that loss of one distribution device must not interrupt critical application access beyond an agreed convergence window. “Support segmentation” becomes a test that specified user groups can reach only authorized services. “Improve SaaS performance” becomes a measurable latency or path target.

Exam questions may not ask you to write acceptance criteria, but the habit improves reasoning. It forces vague benefits to become observable.

When two architectures both seem plausible, the acceptance criteria often reveal which one fits better.

Compare operational complexity as a real constraint

A technically elegant architecture can fail operationally if the team cannot support it.

Controller-based networking, automation, overlays, model-driven APIs, and centralized policy can reduce repetitive device configuration while increasing the importance of software, certificates, APIs, telemetry, and platform skills.

Traditional networking may be familiar but can become difficult to operate consistently at large scale.

Neither model is universally simpler. Complexity moves.

A good architect asks where the organization wants complexity to live and whether people, process, and tooling can support it. ENCOR candidates should be able to discuss that trade-off without treating “software-defined” as automatically easier.

Security belongs in architecture

Architecture and Security are separate blueprint domains, but real designs combine them.

Segmentation boundaries, management access, encryption, trust zones, firewall placement, identity, and telemetry should be considered during design rather than added afterward.

For SD-WAN, secure control connections and branch security matter. For campus, device administration and segmentation matter. For cloud connectivity, local breakout changes inspection and logging. For fabric, identity-based policy can change how segmentation is expressed.

When an architecture question includes a security requirement, do not treat it as a separate afterthought. Determine where enforcement belongs in the packet path and control model.

The dedicated ENCOR security guide is a useful companion once the architecture is clear.

Build a one-hour architecture lab without devices

Architecture can be practiced with paper and a timer.

Choose a fictional company: headquarters, three branches, one cloud application, a small data center, voice, guests, and regulated users.

Spend ten minutes gathering requirements. Spend fifteen drawing a traditional design. Spend fifteen drawing a software-defined alternative. Spend ten comparing failure domains and security. Spend ten defining verification tests.

Then change one requirement: acquisition adds 100 branches, or users become mostly remote, or a new regulation requires stronger segmentation.

Redesign only what the changed requirement justifies.

This exercise develops architecture judgment faster than memorizing polished reference diagrams.

Exam-question method for Architecture

When an architecture question appears, identify the requirement first.

Next, identify whether the decision is about scale, resilience, segmentation, performance, policy, operations, or connectivity.

Then eliminate answers that solve a different problem. A QoS change does not solve a single point of failure. FHRP does not solve WAN path diversity. SD-WAN does not automatically replace endpoint security. Fabric segmentation does not fix a broken underlay.

Finally, choose the option whose mechanism directly addresses the stated requirement with acceptable trade-offs.

This process helps because many distractors are real technologies used in the wrong context.

Final study priorities for Architecture

Know the current v1.2 scope precisely. Be able to compare two-tier, three-tier, fabric, and cloud-oriented designs. Understand redundancy, FHRP, and high-availability thinking. Explain Catalyst SD-WAN control and data planes, benefits, and limitations. Explain SD-Access control/data-plane ideas and traditional interoperability. Interpret QoS configurations.

Do not spend current ENCOR architecture study time on removed v1.1 wireless objectives.

For every topic, maintain one business requirement, one diagram, one failure scenario, and one verification method.

That small set of artifacts is enough to turn Architecture from a memory exercise into design reasoning.

Use an architecture review sequence: requirement, boundary, failure, evidence

Start with the requirement in business and application language. What must communicate, what must remain isolated, what latency or availability matters, and what operational constraints exist? Next, draw boundaries: sites, failure domains, routing domains, policy zones, management domains, and places where traffic changes encapsulation or trust.

Then ask how the design fails. A redundant pair of devices is not high availability if both depend on one upstream path, one power source, one control service, or one configuration error. An SD-WAN fabric can have healthy control connections while an application path violates policy. An SD-Access underlay can forward correctly while overlay reachability or identity policy fails.

Finally, decide what evidence proves each requirement. Architecture is not finished at the drawing. Define what you would observe after a link failure, policy update, gateway switchover, or QoS congestion event. That forces the design to become operationally testable.

Distinguish abstraction from dependency

Modern architectures reduce configuration complexity by introducing abstraction. FHRP gives endpoints a stable default gateway even when the active device changes. SD-WAN separates centralized intent and control relationships from individual WAN forwarding decisions. SD-Access creates an overlay where identity and segmentation can be expressed without making every policy depend directly on physical topology.

Abstraction is useful, but it does not remove dependencies. A virtual gateway still depends on physical paths. An overlay still depends on an underlay. Centralized policy still depends on authentication, reachability, certificates, controllers, and consistent telemetry. ENCOR scenarios often become easier when you identify which abstraction is failing and which underlying dependency could cause the symptom.

Migration case: traditional campus to fabric

Suppose a campus cannot be replaced in one maintenance window. Some buildings remain traditional VLAN/routed-access designs while a new area adopts SD-Access. The design question is not whether one architecture is “better” in isolation. It is how endpoints, routing, policy, operations, and troubleshooting will work during coexistence.

Define migration boundaries and success criteria. Which users or devices move first? How will traditional networks interoperate with the fabric? Where is policy translated or enforced? What happens to monitoring and support workflows? What rollback is possible if onboarding fails? A staged migration can reduce blast radius but creates temporary operational complexity; the project must account for that cost.

Treat QoS as an architecture promise under congestion

QoS does not manufacture bandwidth. It defines how traffic is classified, marked, queued, shaped, policed, or prioritized when resources are constrained. Architecture questions therefore should connect QoS to application requirements and trust boundaries. Where are markings accepted? Where are they rewritten? Which traffic deserves protection, and what happens to everything else?

A design that gives a priority queue without controlling admission can still fail. A policy configured on the wrong interface or direction can be operationally irrelevant. Study QoS by tracing behavior across the path rather than memorizing class-map and policy-map names.