500-470 Cisco Enterprise Networks SDA, SDWAN and ISE Exam for System Engineers Exam Topics and Questions

SD-Access Discovery is where the exam tests whether you understand the sales-engineering front end of a Cisco SDA engagement. This is not a deep technical configuration topic. The weight is modest, but candidates who dismiss it lose marks on scenario questions that hinge on why a customer would start an SDA conversation in the first place. Get the framing right here and the design topics that follow will make more sense.

– What SD-Access is and why it matters to buyers

The exam expects you to articulate Software Defined Access in terms a customer conversation would use, not in terms of VXLAN tunnels and LISP control planes. That means knowing the architectural intent: policy-driven segmentation, identity-based access, and the role of Cisco DNA Center as the management and automation layer over the campus fabric. Trends worth knowing include the shift away from VLAN-based segmentation toward group-based policy, and the pressure on enterprise IT teams to support more device types without expanding their operational overhead. The benefits the exam tests are the ones that show up in buying decisions: reduced time to contain a breach, consistent policy across wired and wireless, and simplified operations. Candidates who treat this as background reading and skip the detail tend to miss scenario questions that ask which capability addresses a stated customer pain.

– Discovery as a sales-engineering motion

The discovery sub-topic is framed around use cases, buying triggers, and the insights a system engineer surfaces during a customer engagement. The exam tests whether you can map a customer situation to the right SDA value proposition. Buying triggers are specific: a failed audit, a flat network with lateral movement risk, an upcoming campus refresh, or a mandate to segment IoT devices. Knowing which trigger aligns with which SDA capability is what separates a correct answer from a plausible-sounding distractor. The discovery motion also connects to the 4D engagement model that reappears later in the SD-WAN section, so building a clean mental model here pays dividends. Focus on the logic of the discovery conversation: what question surfaces the pain, what capability addresses it, and what outcome the customer cares about.

How 1.0 SD-Access Discovery is tested

At 6%, this topic contributes a small but real share of your score, and the items are almost entirely scenario-based. You will be placed in a customer conversation and asked to identify the right framing, the right capability to highlight, or the right buying trigger at play. Items reward candidates who can connect a described customer situation to a specific SDA benefit, not candidates who can define terms in isolation. The trap here is over-rotating on technical detail. A candidate who knows LISP and VXLAN inside-out but cannot articulate why a customer with an IoT segmentation problem should care about group-based policy will still miss these marks. Distractors are often technically accurate statements about SDA that simply do not address the customer scenario in the stem. Read the scenario carefully, identify what the customer's stated pain is, and choose the option that speaks to that pain directly.

Where Discovery tests your ability to frame the conversation, Design tests whether you can actually spec a solution. At 12%, this is one of the heavier topics in the exam, and it covers the decisions a system engineer has to make before a single device is configured. The questions reach across campus fabric architecture, DNA Center's role in that fabric, branch connectivity, migration from a traditional network, and data centre policy integration. Weak candidates know the components; strong ones know the tradeoffs.

– DNA Center and the campus fabric

The exam expects you to know where DNA Center sits in the SDA architecture and what it controls. DNA Center is the policy and automation plane: it translates group-based policy into fabric configuration and provides the assurance data that feeds back into operations. The campus fabric itself is built on an underlay and overlay model, with the underlay providing routed connectivity and the overlay carrying segmented traffic via VXLAN. High-level design considerations include underlay routing protocol choice, fabric edge and border node placement, and the separation of the control plane from the data plane. Items in this area ask you to match a design requirement to the right architectural component. The trap is conflating the roles: DNA Center does not forward traffic, and the fabric nodes do not hold policy intent. Getting that boundary right is what the exam rewards.

– Branch and migration design

Branch design under SDA is a distinct consideration from campus fabric design, and the exam treats them separately. A branch connected to an SDA campus fabric needs to maintain consistent group-based policy across the WAN link, which introduces dependencies on SD-WAN that the later topics cover in depth. For now, the exam focuses on the high-level architectural decision: how does a remote site participate in the fabric's policy model without running a full fabric locally. Migration is the other pressure point. Most customers are not building greenfield. The exam tests whether you understand the phased approach: what can coexist with a traditional network during transition, what must be cut over cleanly, and what the integration points are between legacy VLANs and the new group-based model. Candidates who have only studied the target-state architecture miss migration questions consistently.

– Data centre policy integration

SDA does not stop at the campus edge, and the exam expects you to know how group-based policy extends into the data centre. The key integration point is between SDA's scalable group tags and Cisco ACI or traditional DC switching. Policy consistency means a user's group membership, established at the campus edge, follows their traffic into the data centre without requiring a re-authentication or a separate policy definition. High-level DC integration design questions focus on where the border node sits, how group tags are preserved across the fabric boundary, and what happens when DC infrastructure does not natively understand SDA group policy. These are scenario questions, not definition questions. The distractor options usually describe technically valid configurations that solve the wrong problem, so reading the scenario constraint carefully is the skill being tested.

How 2.0 SD-Access Design is tested

At 12%, this topic will account for a meaningful portion of your exam, and the items are consistently applied-knowledge scenarios rather than recall questions. You will be given a customer environment with specific constraints, such as an existing routed underlay, a branch with limited hardware, or a DC running ACI, and asked to identify the design approach that fits. Items reward candidates who understand why a design decision is made, not just what the decision is. The most common place candidates drop marks is on migration questions: they know the end-state architecture but cannot reason about the transition. A second trap is treating DNA Center as a data-plane device. Several distractors are built around that misunderstanding. On branch and DC integration questions, pay attention to the scope of the scenario: a question about policy consistency at the DC border has a different answer than one about branch fabric participation, even if the technology terms overlap. Work through design scenarios under timed conditions to build the reasoning speed this topic demands.

After two topics focused on framing and designing an SDA solution, this topic shifts to demonstrating it. At 8%, the exam is testing a specific system-engineering skill: knowing how to show Cisco DNA Center Assurance in a way that maps back to the customer's stated concerns. This is narrower than it looks. The entire topic rests on one sub-topic, Assurance, and the exam rewards candidates who understand what Assurance actually shows a customer and why that matters at the point of a demonstration.

How 3.0 SDA Demonstration is tested

With a single sub-topic, items here are tightly scoped to DNA Center Assurance and its role in a customer demonstration. The exam does not ask you to click through a GUI or recall menu paths. It asks you to reason about what Assurance data is relevant to a given customer pain and how you would use it to advance a sales or validation conversation. Items reward candidates who can connect an Assurance capability, such as client health scoring, network health trending, or issue correlation, to a specific customer scenario. The trap is answering from a generic product-knowledge perspective rather than from the demonstration context. A statement about what Assurance can do is not the same as knowing which Assurance view resolves a customer's stated concern in a live demonstration. Candidates who have seen the platform tend to over-rely on UI memory; candidates who have only read about it tend to answer too abstractly. The strongest preparation combines knowing the capability with understanding the demonstration narrative it supports.

Defend is the exam's test of whether you can hold the SDA position under pressure. The questions here simulate the late stages of a customer engagement: competitive challenges, objections about product fit, concerns about roadmap, and the practical question of what to actually propose. This topic is broader than its 8% weight suggests because it touches seven distinct sub-topics, each representing a different kind of challenge a system engineer has to navigate.

– Competitive positioning and closing

The competitive sub-topic tests your ability to reason about where SDA wins and where it faces genuine challenges, without requiring you to disparage competitors by name. The exam rewards answers that are grounded in architectural differentiation: what SDA's group-based policy model, fabric underlay/overlay separation, and DNA Center automation layer offer that alternative approaches do not. Closing questions are scenario-based and focus on recognising the right moment and the right argument to advance the deal. Candidates who treat closing as a sales skill rather than a technical skill miss the point: the exam tests whether the system engineer can resolve the customer's last technical objection, not whether they can apply a sales methodology.

– Product, caveats, and roadmap

Product questions test whether you know what is in scope for SDA and what is not. Caveats are the honest constraints: hardware requirements, software version dependencies, scale limits, and integration boundaries that a system engineer must disclose during a customer engagement. The exam rewards candour: knowing a caveat and knowing how to address it is a stronger answer than pretending the constraint does not exist. Roadmap questions are about direction, not dates. The exam does not ask you to recall specific release timelines, but it does test whether you understand the strategic direction of the platform and can use that to address a customer concern about long-term investment. Candidates who over-promise on roadmap or under-disclose on caveats are penalised in the scenario options.

– What to sell and team exercises

The 'what to sell' sub-topic is about portfolio fit: given a customer's environment, budget, and pain points, which SDA components and SKUs make sense to lead with. This is a system-engineering judgment question, not a product catalogue question. Team exercises represent a different kind of scenario: multi-role situations where the system engineer's input is one part of a broader team motion. The exam tests whether you understand your role in that motion and how your technical positioning connects to the account team's broader strategy. These questions often have distractors that describe the right technical action taken at the wrong stage of the engagement, so sequencing matters as much as content.

How 4.0 SDA Defend is tested

Seven sub-topics at 8% means the exam samples across this topic rather than going deep on any one area. Items are scenario-based and typically place you in a specific moment of a customer engagement: a competitor has been named, a caveat has been raised, or the customer is asking what to buy. Items reward candidates who can match the right response to the specific stage and context of the engagement. The most common trap is selecting an answer that is technically accurate but contextually wrong: describing a product capability when the scenario calls for a competitive differentiator, or addressing a roadmap concern with a product feature that already exists. A second trap appears in caveat questions, where distractors often minimise or omit a real constraint. The exam consistently rewards the answer that acknowledges the constraint and provides a path forward, not the answer that avoids it. Working through team-exercise scenarios under timed conditions is the best preparation for the sequencing judgments this topic demands.

The SD-WAN section of the exam begins here, and the shift from SD-Access is deliberate. You are moving from campus policy to WAN transformation, and the discovery motion has its own logic. At 8%, this topic tests whether you can enter an SD-WAN customer conversation with the right framing: the right questions, the right triggers to listen for, and the right understanding of what the 4D engagement model is asking you to do at this stage.

– The 4D model and on-demand training

The 4D model structures the Cisco selling and engagement motion across Discover, Design, Demonstrate, and Defend. The exam tests whether you understand what the Discover phase is for and what a system engineer's role is within it. The 4D On-Demand Training sub-topic is less about content delivery and more about knowing that a structured enablement path exists and what it prepares a system engineer to do. The 4D Engagement sub-topic is about execution: how the Discover phase conversation is structured, what questions are asked, and what outputs the system engineer is expected to produce before moving to Design. Candidates who conflate the Discover and Design phases, or who treat the 4D model as background context rather than an examinable framework, lose marks on questions that hinge on phase boundaries.

– Customer discovery: triggers, trends, and capabilities

SD-WAN buying triggers are distinct from SDA triggers, and the exam expects you to know the difference. Common WAN triggers include application performance degradation over MPLS, rising circuit costs, the need to support direct internet access at branches, and the operational burden of managing a large number of WAN edge devices. Trends worth knowing include the shift from private WAN to hybrid WAN architectures, the growth of cloud-hosted applications driving branch internet breakout, and the increasing use of application-aware routing policies. The key capabilities the exam tests are those that map directly to these triggers: transport independence, application-aware routing, centralised policy management, and zero-touch provisioning for branch onboarding. A candidate who can match a described customer environment to the right capability, and explain why, is in a strong position on this topic.

How 5.0 SD-WAN: Discover is tested

At 8%, this topic parallels the SDA Discovery topic in weight but differs in content and context. Items are scenario-based and test your ability to read a customer environment and identify the SD-WAN buying trigger at play. The 4D model is examinable as a framework: questions may ask what a system engineer should do during the Discover phase, what outputs that phase produces, or how it connects to the next phase. Items reward candidates who understand the phase logic, not just the product capabilities. The most common trap is answering from a design perspective when the scenario is still in discovery. A distractor will often describe a technically correct SD-WAN configuration decision, but that is a Design-phase answer, not a Discover-phase answer. A second trap is treating SD-WAN trends as interchangeable with SDA trends. They overlap in places, but the WAN context has its own specific pressures. Read the scenario to confirm which domain and which phase the question is operating in before selecting your answer.

SD-WAN Design carries the same 12% weight as SDA Design, and the exam treats both with the same expectation: you need to reason through architectural decisions, not just recall component names. This topic covers the four pillars of WAN reinvention (security, connectivity, application services, and operations) plus solution architecture, high-level design considerations, and a video-based design use case. The breadth is real, and the questions test whether you can hold the whole picture together under a time constraint.

– High-level design and solution architecture

High-level design considerations for SD-WAN include transport selection, overlay topology, controller placement, and the boundary between the SD-WAN fabric and the broader network. Solution architecture questions test whether you can map a customer's environment to the right SD-WAN deployment model: single-region versus multi-region, on-premises controller versus cloud-hosted, and hub-and-spoke versus full-mesh overlay. The exam does not ask you to configure these components; it asks you to justify the choice. Candidates who know the components but cannot explain the decision criteria behind them will find the scenario options difficult to separate. The strongest preparation is to practice reasoning from a customer constraint to an architectural decision, rather than memorising architecture diagrams.

– Reinventing WAN security and connectivity

WAN security reinvention under Cisco SD-WAN centres on embedding security policy into the fabric rather than backhauling traffic to a central firewall. The exam tests whether you understand the implications of that shift: where security policy is enforced, what happens to encrypted WAN traffic inspection, and how segmentation is maintained across transport types. Connectivity reinvention covers transport independence and the ability to use MPLS, broadband, and LTE simultaneously under a single policy framework. Application-aware routing is the mechanism that makes this work: the fabric monitors path quality per application and shifts traffic based on policy thresholds. Items in this area ask you to identify the right connectivity design for a given branch profile, or to explain what happens to application traffic when a primary transport degrades. Read the transport and application constraints in the scenario carefully before answering.

– Application services, operations, and design use cases

Application services reinvention covers the SD-WAN fabric's ability to apply quality-of-service policies, direct cloud application traffic optimally, and support cloud security integration. The exam tests whether you understand which application service capability addresses a given customer pain, not whether you can configure it. Operations reinvention is about the management plane: centralised policy deployment, telemetry-driven visibility, and the reduction of per-device manual intervention. The video design use case sub-topic is specifically about applying SD-WAN design principles to a video-heavy traffic profile, which introduces specific QoS and bandwidth management considerations. Candidates who treat application services and operations as generic WAN management topics miss the SD-WAN-specific angles the exam is testing. Each reinvention pillar has a specific architectural answer; knowing which pillar a scenario question is targeting is the first step to selecting the right option.

How 6.0 SD-WAN: Design is tested

At 12%, this is the final high-weight topic, and the items are the most architecturally demanding in the exam. Scenarios describe a customer WAN environment with specific constraints (transport mix, application profile, security requirements, operational capacity) and ask you to identify the design decision that fits. Items reward candidates who can reason across multiple constraints simultaneously. The most common trap is optimising for one constraint while violating another: choosing a connectivity design that solves the transport problem but breaks the security model, for example. A second trap appears in operations and application services questions, where distractors often describe capabilities that exist in the platform but do not address the specific operational pain in the scenario. The video use case sub-topic is a focused area where candidates who have not thought through QoS design for high-bandwidth, latency-sensitive traffic will find the options difficult to separate. Work through multi-constraint design scenarios under exam conditions to build the reasoning pattern this topic rewards.

SD-WAN Design established what to build; Demonstration tests whether you can show it working and close the engagement. At 12%, this is one of the exam's highest-weighted topics, and its seven sub-topics span the full late-stage system-engineering motion: live capability demonstration, product and licensing knowledge, honest disclosure of caveats, portfolio positioning, team coordination, and partner-facing closing. The breadth reflects what a real demonstration engagement demands, and the exam samples across all of it.

– Demonstrating capability and knowing the products

Demonstration questions test whether you know which capability to show for a given customer concern and how to frame what the customer is seeing. The exam does not ask you to recall GUI paths. It asks you to match a demonstration element to a customer pain: if a customer is concerned about application performance visibility, you need to know which SD-WAN capability surfaces that data and why it is the right thing to demonstrate at that moment. Product knowledge at this stage goes deeper than the design phase. You need to know which hardware and software SKUs are relevant to a given deployment profile, and you need to know why one product fits a scenario better than another. Candidates who know the platform in general but cannot distinguish between product options in a specific customer context will find the distractor options difficult to separate.

– Licensing, caveats, and what to sell

Licensing questions are scenario-based: given a customer's use case and scale, which licensing tier or model applies. The exam rewards knowing the boundaries between licensing options, not memorising SKU numbers. Caveats are the constraints a system engineer must surface during a demonstration: scale limits, feature dependencies, integration prerequisites, and anything that could create a post-sale surprise. Items in this area consistently reward the answer that acknowledges the caveat and pairs it with a path forward. Minimising or omitting a real constraint is penalised. 'What to sell' questions build on the design-phase portfolio logic but apply it at the point of commitment: given everything the customer has seen and said, which components and entry points make the most sense to lead with. These are judgment questions, and the distractors often describe technically valid options that do not fit the customer's stated constraints.

– Team exercises and partner closing

Team exercise scenarios test your understanding of the system engineer's role within a broader account team motion during the demonstration phase. The exam places you in a multi-role situation and asks what the system engineer should contribute, escalate, or defer. Sequencing is the skill being tested: a technically correct action taken at the wrong point in the team motion is a wrong answer. The SD-WAN Closing-Partner sub-topic introduces the partner dimension. Closing with a partner involves aligning on the technical close, confirming the partner's role in the proposed solution, and ensuring the partner can carry the technical conversation forward independently. Items here reward candidates who understand the distinction between closing with a direct customer and closing through a partner, and who can identify what changes in the system engineer's demonstration and positioning when a partner is in the room.

How 7.0 SD-WAN: Demonstration is tested

At 12%, this topic matches the design topics in weight but demands a different kind of reasoning. Design questions ask you to justify an architectural decision; demonstration questions ask you to execute the right action at the right moment in a customer engagement. Scenarios will place you in a specific point of a demonstration or closing conversation and ask what the system engineer does next. Items reward candidates who read the engagement stage accurately before selecting a response. The most common trap is answering from a design mindset: describing an architectural decision when the scenario is asking about demonstration framing or closing logic. A second trap appears in caveat and licensing questions, where distractors often describe accurate product facts that are irrelevant to the customer's scenario. On partner-closing questions, candidates who apply the direct-customer closing logic without accounting for the partner's role will consistently select the wrong option. Work through the full range of sub-topics rather than concentrating on capability demonstration alone, because the exam distributes its items across all seven areas.

The exam now moves into its third technology domain, and the shift requires a reset. ISE is not an extension of SD-WAN or SDA; it is Cisco's identity and access control platform, and it brings its own buying triggers, its own customer pain points, and its own discovery logic. At 6%, this topic is the lightest in the ISE section, but it sets the framing that the heavier ISE design and demonstration topics depend on. Candidates who skip it and jump straight to ISE features tend to miss the scenario context that makes the later questions answerable.

How 8.0 ISE: Discover is tested

Three sub-topics at 6% means the exam is testing breadth of framing rather than depth of technical knowledge. Items here are scenario-based and ask you to identify the right ISE value proposition for a described customer situation, or to recognise the buying trigger that opens an ISE conversation. The introduction to ISE sub-topic is not tested as a definition exercise; it is tested through scenarios where you need to know what ISE does at a system level to distinguish it from other Cisco security products. Trends, challenges, and benefits are examinable in the same way the SDA and SD-WAN discovery topics tested them: by mapping a described customer pressure to the right ISE capability. Buying triggers for ISE are specific, including compliance mandates, uncontrolled guest access, BYOD proliferation, and the inability to see what is on the network. Items reward candidates who can match the trigger to the capability, not candidates who can define ISE in general terms. The trap is defaulting to generic network security language when the scenario is asking for an ISE-specific answer.

ISE Design is the most technically demanding topic in the ISE section and one of the broadest in the entire exam. At 11%, it covers solution architecture, ISE fundamentals, and five named features: Access Control, Profiling, Guest Access, BYOD, and TrustSec. Each feature has its own design logic, and the exam expects you to reason across all of them. Knowing what each feature does is the starting point; knowing which design decision fits a given customer environment is what the items actually test.

– Architecture, fundamentals, and high-level design

ISE solution architecture questions focus on deployment models, node types, and the placement of policy services in a distributed environment. The exam tests whether you understand the roles of different ISE personas (Administration, Policy Services, Monitoring) and how they are distributed across a deployment to meet scale and redundancy requirements. Fundamentals cover the authentication and authorisation framework: how ISE processes a request, what attributes it evaluates, and how policy sets map to outcomes. High-level design considerations bring these elements together in a customer scenario: given a specified environment size, device mix, and redundancy requirement, what does the right ISE architecture look like. Candidates who know the components individually but cannot reason about their interaction in a specific deployment will find the scenario options difficult to distinguish. The architectural boundary between what ISE handles natively and what it delegates to integrated systems is a consistent area of exam focus.

– Access Control and Profiling

Access Control is the core ISE function: authenticating a device or user and authorising the appropriate level of network access based on policy. The exam tests the design decisions behind access control, including the choice between 802.1X, MAB, and web authentication for different device types, and the conditions under which each method is appropriate. Profiling is ISE's ability to identify what a device is before a user credential is involved. The exam expects you to know how ISE collects profiling data, which probes are relevant in different network environments, and how profiling feeds into access policy decisions. Items in this area reward candidates who understand the dependency: access control policy is only as accurate as the profiling data behind it. A design question about profiling will often describe a network environment and ask which probe configuration produces reliable device classification in that context. Generic answers about profiling capability will not separate the options.

– Guest Access and BYOD

Guest Access design covers the workflows, portal types, and sponsorship models that ISE supports for visitors and contractors. The exam tests the design decision, not the configuration: given a customer's guest access requirement (self-registration, sponsored access, or social login), which ISE guest model fits and what are the policy implications. BYOD design is more complex because it involves device onboarding, certificate provisioning, and the ongoing management of personally owned devices that are granted network access. The exam expects you to understand the BYOD onboarding flow, the role of ISE's My Devices portal, and the design considerations around certificate lifecycle and device compliance. A common trap in both areas is selecting a portal or workflow that works technically but does not match the customer's stated operational model. The scenario will usually specify whether the organisation has a helpdesk sponsorship process or requires fully self-service onboarding, and the answer depends on that constraint.

– TrustSec

TrustSec is ISE's group-based policy enforcement mechanism, and it connects directly to the SDA group policy model covered earlier in the exam. The design questions here focus on how TrustSec assigns security group tags, how those tags are propagated across the network, and how policy is enforced at the point of egress. The exam tests whether you understand the relationship between ISE as the policy authority and the network infrastructure as the enforcement point. Candidates who have studied SDA will recognise the scalable group tag concept, but TrustSec design has its own considerations: inline tagging versus SXP propagation, the role of the TrustSec matrix, and the design implications of mixed environments where not all switches support inline tagging. Items in this area reward candidates who can identify the right propagation mechanism for a described network environment. The distinction between inline and SXP-based tag propagation is the most commonly tested design decision in this sub-topic.

How 9.0 ISE: Design is tested

At 11%, this topic generates a substantial share of your score, and the items are consistently scenario-driven. You will be given a customer environment with a specific device mix, access requirement, or policy goal and asked to identify the ISE design decision that fits. Items reward candidates who can reason from a customer constraint to a specific ISE capability or configuration approach. The exam does not ask you to configure ISE; it asks you to justify design choices. The most common place candidates lose marks is on feature interaction questions: scenarios where the right answer depends on understanding how profiling feeds access control, or how TrustSec tag assignment connects to SDA policy. A second trap appears in BYOD and Guest questions, where distractors describe portal or workflow options that are technically valid but do not match the operational model specified in the scenario. On TrustSec questions, candidates who have not thought through the inline versus SXP distinction will find two options that both sound correct. Covering all eight sub-topics in your preparation is necessary; the exam does not concentrate its items on the more prominent features.

ISE Demonstration covers the point in a customer engagement where you move from describing ISE's design to showing it and defending the investment. At 6%, the topic is tightly scoped to four sub-topics: the demonstration and proof-of-value motion, product and licensing specifics, caveats, and roadmap across ISE, TrustSec, and SDA Policy. The roadmap sub-topic is the element that distinguishes this demonstration topic from its SDA and SD-WAN equivalents, because it asks you to connect three related technologies in a forward-looking conversation.

How 10.0 ISE: Demonstration is tested

Items here follow the same demonstration-phase logic as the SDA and SD-WAN demonstration topics, but with ISE-specific content and the added dimension of a multi-technology roadmap. Demonstration and proof-of-value questions ask which ISE capability to surface for a given customer concern, and what a proof-of-value engagement is designed to establish. The exam rewards candidates who understand the difference between a product demonstration and a proof of value: one shows what the platform can do, the other validates that it solves the customer's specific problem. Product and licensing questions test the boundaries between ISE deployment options and licensing tiers in a scenario context. Caveat questions follow the same pattern as earlier topics: items reward the answer that discloses the constraint and addresses it, not the answer that avoids it. Roadmap questions are the most distinctive element. The exam tests whether you can use the ISE, TrustSec, and SDA Policy roadmap direction to address a customer's concern about long-term investment, without over-committing to specific release timelines. Candidates who treat roadmap as a feature list rather than a strategic narrative will select distractors that are too specific or too vague.

The exam closes on ISE Defend, and the final topic carries real weight at 11%. Two sub-topics might suggest a narrow scope, but competitive positioning and portfolio selection for ISE each carry enough depth to generate a significant share of scenario questions. After ten topics of framing, designing, demonstrating, and defending across three technology domains, this is where the exam tests whether you can hold the ISE position against a direct challenge and make the right call on what to propose.

How 11.0 ISE: Defend is tested

At 11% with two sub-topics, the exam goes deeper on each area than the sub-topic count suggests. Competitive questions place you in a scenario where ISE is being compared to an alternative, and ask you to identify the differentiating argument that fits the customer's stated concern. Items reward architectural differentiation grounded in ISE's specific capabilities: its integration with the broader Cisco security and network portfolio, its policy model, and its scale. Generic security platform arguments are penalised because the distractors are written to catch candidates who answer at the wrong level of specificity. 'What to sell' questions build on the ISE Design knowledge from topic 9 but apply it at the point of commitment. Given a customer's environment, compliance requirement, and operational capacity, which ISE components and entry points make sense to lead with. The trap here is recommending a full-featured deployment when the scenario describes a customer who needs a phased or constrained starting point. Items reward the answer that matches the customer's actual situation, not the answer that describes the most technically complete ISE deployment. Candidates who have worked through the full exam will have the SDA and TrustSec context to reason about ISE's portfolio position accurately.