HPE7-A07 Aruba Certified Campus Access Mobility Expert Written Exam Topics and Questions

At 4% of the exam, Network Stack is the smallest domain, but do not treat it as a throwaway. The single sub-topic demands that you move from observation to diagnosis: given a real customer symptom, you must work through the stack systematically and land on a solution. That means your mental model of how layers interact has to be sharp enough to isolate a fault without guessing. Where candidates lose marks here is in jumping to a fix before fully characterising the problem.

How Network Stack is tested

Items in this domain present a described customer fault and ask you to identify the cause or select the appropriate remediation step. Because the sub-topic is explicitly scenario-driven, you will not see abstract theory questions. The examiner expects you to apply stack knowledge to a specific set of symptoms, which means you need to be comfortable reading a scenario, narrowing the fault to a layer, and choosing the action that addresses that layer without breaking anything above or below it.

The trap is selecting a fix that would work in isolation but conflicts with the broader network state described in the scenario. Items reward the candidate who reads all the given constraints before committing to an answer. A second common loss point is confusing a symptom at one layer with a root cause at another. Candidates who treat this as a pure recall topic and stop at naming the layer rather than prescribing the fix tend to miss these items.

Moving up from individual stack faults, Connectivity asks you to operate at the design and deployment level across the whole campus network. At 9%, it covers a wide surface: translating customer requirements into configurations, applying advanced networking architectures, spotting weaknesses in a proposed design, and troubleshooting device deployment end to end. The breadth is the difficulty. You need to hold the design intent and the operational reality in mind at the same time, because the exam tests both in the same item.

– From requirements to configuration

Developing configurations from customer requirements is where candidates who know the technology still lose marks, because the question is never just 'what does this feature do' but 'what does this customer actually need, and which configuration delivers exactly that.' You must read the requirement carefully for constraints: scale, existing infrastructure, vendor interoperability, and any stated limitations. An option that configures the right feature in the wrong mode, or that solves the stated problem while violating an unstated constraint in the scenario, will be wrong even if it looks technically sound. Practice translating plain-language requirements into specific Aruba configuration choices, and pay attention to what the requirement does not say as much as what it does.

– Architecture, design gaps, and device deployment

Applying advanced networking architectures means you are expected to know when a particular topology or technology is the appropriate choice for a given campus environment, not just how to configure it once chosen. Identifying problem areas in a design requires a different mental posture: you are auditing someone else's work and looking for the decision that will cause a failure under load, during failover, or at scale.

Device deployment troubleshooting ties the two together. A device that fails to come up cleanly often points back to an architectural mismatch or a design gap, so the exam expects you to trace the fault from the symptom back to the design decision that caused it. Candidates who treat deployment troubleshooting as purely operational, without considering the design layer, tend to select fixes that treat the symptom rather than the cause.

How Connectivity is tested

Expect scenario-based items that embed a customer requirement or a network diagram and then ask you to evaluate configuration options or identify the flaw in a proposed design. The weight of 9% means you will see enough items that a pattern of misses here has a measurable impact on your score.

Items reward candidates who read the scenario constraints before evaluating the options. The most common trap is selecting a technically valid configuration that does not match the specific requirement stated in the scenario. A second trap appears in design-fault items: the flaw is often in an architectural assumption rather than a configuration detail, so candidates who focus only on syntax-level errors miss it. Deployment troubleshooting items reward working backwards from the observed symptom to the decision point that produced it, rather than applying a generic checklist.

After the broad design territory of Connectivity, this domain narrows to a specific engineering discipline: keeping the network up when something fails. At 6%, it carries a single sub-topic, but that sub-topic spans design, troubleshooting, and remediation across resiliency mechanisms, redundancy schemes, and fault-tolerance technologies. The challenge is that these three concepts overlap in the Aruba campus context, and the exam expects you to distinguish which mechanism is appropriate for a given failure mode rather than treating them as interchangeable.

How Network Resiliency and virtualization is tested

Items in this domain present a failure scenario or a design requirement and ask you to select the mechanism that provides the stated level of continuity, or to identify why an existing design fails to recover correctly. Because the sub-topic explicitly covers design and troubleshooting together, you will see both forward-looking items (choose the right redundancy scheme for this requirement) and backward-looking ones (given this observed failure, identify what is misconfigured).

The trap in design items is selecting a mechanism that provides redundancy in principle but does not match the failure mode described. For example, a solution that handles device failure may not handle link failure in the same topology. Items reward the candidate who maps the specific failure mode to the specific mechanism rather than picking the most familiar option.

In troubleshooting items, the loss point is usually misreading the symptom: a network that is slow rather than down suggests a partial failure that a full-redundancy mechanism alone will not fix. Read the failure description precisely before evaluating options.

Switching accounts for 10% of the exam and sits at the operational core of the campus access layer. The single sub-topic is dense: it spans Layer 2 and Layer 3 switching, broadcast domain design, and the interconnection technologies that tie the access, distribution, and core tiers together. At the expert level, implementation knowledge is table stakes. The exam is really testing whether you can troubleshoot a misbehaving switched environment and then remediate it correctly, without introducing a new fault in the process.

How Switching is tested

Items present a Layer 2 or Layer 3 switching fault, a design scenario, or a remediation choice and ask you to identify the cause or select the correct fix. The 10% weight means this domain contributes a meaningful share of your score, and the combined implementation-troubleshoot-remediate framing means items can start from any point in that cycle.

Broadcast domain questions frequently trip candidates who can configure VLANs correctly but have not thought carefully about what happens at the boundary between Layer 2 and Layer 3 domains under specific traffic conditions. Interconnection technology items reward knowing not just the protocol but the operational state you should expect to see when it is working correctly, because the scenario will describe a state and ask what it means.

The most common loss point is remediation: candidates identify the fault accurately but select a fix that resolves it in isolation while creating a secondary problem elsewhere in the switched topology. Items reward fixes that account for the full topology, not just the failing segment.

WLAN is the dominant domain of this exam at 25%, and the three sub-topics cover the full arc from RF physics through customer-facing configuration to Layer 2 broadcast domain behaviour. If you have been building Aruba wireless networks day-to-day, some of this will feel familiar, but the expert-level framing means the exam expects you to design and troubleshoot, not just configure. A weakness in any of the three sub-areas will show up clearly in your score given the weight this domain carries.

– RF attributes and wireless functions

RF troubleshooting at the expert level means moving past 'the signal is weak' to identifying why: channel utilisation, co-channel interference, non-Wi-Fi interference sources, power settings, antenna patterns, and the interaction between client capabilities and AP configuration. You are expected to read a described RF environment, identify what is causing the symptom, and select the design or configuration change that addresses the root cause.

The trap here is confusing correlation with causation. A high retry rate and a low RSSI can have several different root causes, and the exam will present scenarios where the obvious fix addresses the symptom without resolving the underlying condition. Items reward candidates who work from the RF data to the cause rather than from the symptom to the nearest familiar fix.

– Configuration from customer requirements

Building a WLAN configuration from customer requirements is where the RF knowledge has to translate into Aruba-specific settings. The sub-topic covers the full configuration stack: SSID parameters, radio profiles, band steering, client match, ARM settings, and the policies that govern how clients associate and roam.

At the expert level, the exam will give you a requirement that has more than one plausible configuration path and ask you to choose the one that satisfies all the stated constraints. Requirements around client density, roaming behaviour, or legacy device support each impose constraints that narrow the valid options. Candidates who know the features individually but have not practised mapping multi-constraint requirements to a single configuration tend to select options that satisfy the most prominent requirement while violating a secondary one.

– Layer 2 broadcast domains and interconnection

The third sub-topic brings switching concepts into the wireless domain: how broadcast domains are defined and enforced across an Aruba wireless infrastructure, and how the WLAN interconnects with the wired network at Layer 2. This includes tunnel modes, VLAN assignment, and the behaviour of broadcast and multicast traffic across the wireless edge.

This sub-topic catches candidates who treat wireless and wired as separate disciplines. The exam presents scenarios where the fault crosses the boundary: a client associates successfully but cannot reach a resource, and the cause is in the Layer 2 interconnection rather than in the RF or the SSID configuration. Items reward candidates who can trace a client's traffic path from the air interface through the AP, across the tunnel or trunk, and into the wired infrastructure, and identify where that path breaks.

How WLAN is tested

At 25%, WLAN items will appear throughout the exam and span all three sub-topics. Expect a mix of RF scenario analysis, configuration selection from requirements, and Layer 2 fault diagnosis. Some items will combine sub-topics: an RF symptom that turns out to have a Layer 2 cause, or a configuration requirement that has RF implications.

Items reward candidates who resist the first plausible explanation. The exam is written at the expert level, which means distractors are technically defensible. The RF sub-topic in particular rewards methodical fault isolation over pattern-matching to familiar symptoms.

The most consistent loss point across all three sub-topics is incomplete reading of the scenario. A scenario that specifies client type, density, and roaming requirement is giving you constraints that eliminate options; candidates who skim those details and focus only on the fault symptom select options that are partially correct. Given the 25% weight, disciplined scenario reading here has a larger effect on your total score than in any other domain.

Routing sits at 9% and follows naturally from the switching and wireless domains: once traffic leaves the Layer 2 boundary, routing decisions determine where it goes. The single sub-topic covers both design and troubleshooting of routing topologies and functions, which in the Aruba campus context means understanding how routing integrates with the access and distribution layers rather than treating it as a standalone discipline. Expert-level items here test whether you can design for a requirement and then diagnose when that design fails in operation.

How Routing is tested

Items present routing topology scenarios or operational faults and ask you to evaluate a design decision or identify the cause of a routing failure. Because the sub-topic combines design and troubleshooting, you will see both types in roughly equal measure.

Design items reward selecting the routing approach that satisfies the stated topology constraints, not just the one that is technically valid in isolation. A common trap is selecting a routing protocol or redistribution approach that works in a simple topology but breaks under the specific scale or redundancy requirement given in the scenario.

Troubleshooting items reward working from the observed routing behaviour, such as a missing route or an unexpected path, to the configuration or topology decision that produced it. Candidates who jump to reconfiguring the routing protocol without verifying the underlying topology state tend to select fixes that do not hold. Read the topology description carefully; the fault is usually in the interaction between the routing design and the physical or logical topology, not in the protocol configuration alone.

Security carries 11% and covers three distinct sub-topics that each demand a different kind of thinking. Designing and troubleshooting security concepts in a customer network is broad; troubleshooting EAP-TLS on a wireless SSID is specific and certificate-focused; building and troubleshooting Group-Based Policy is an Aruba-specific capability that requires knowing both the policy model and the failure modes. Together they span policy design, protocol-level diagnostics, and platform-specific implementation.

– Security design and customer network concepts

At the expert level, security design questions ask you to select the approach that satisfies a customer's stated security requirement within the constraints of their existing network. That means understanding which security mechanisms are appropriate for which threat models, and where a chosen mechanism creates operational complexity or interoperability risk.

Troubleshooting items in this sub-topic present a network where a security control is either failing to enforce correctly or is blocking traffic it should permit. Items reward candidates who can distinguish a policy misconfiguration from a protocol failure, and who understand the order in which security controls are evaluated in the Aruba campus architecture. Candidates who approach these items by checking configuration syntax first, rather than verifying the policy logic, tend to miss the fault.

– EAP-TLS troubleshooting and Group-Based Policy

EAP-TLS troubleshooting is certificate-chain work. The exam will give you a described failure during SSID authentication and ask you to identify which element of the certificate infrastructure is at fault: the client certificate, the CA trust relationship, the RADIUS server configuration, or the AP or controller behaviour. Items reward tracing the authentication exchange step by step rather than guessing at the most common failure point.

Group-Based Policy (GBP) items test both the policy construction and its operational behaviour. Building GBP correctly means understanding the tag model and the enforcement points; troubleshooting it means knowing what to check when traffic that should be permitted is dropped or traffic that should be blocked gets through. The two failure directions look different in the data, and the exam expects you to tell them apart from a described symptom.

How Security is tested

At 11%, Security items appear with enough frequency that weaknesses in any one of the three sub-topics will affect your score. Items span design selection, protocol-level fault isolation, and platform-specific policy troubleshooting.

The EAP-TLS sub-topic is the one most likely to produce a loss if you have only theoretical certificate knowledge. Items reward step-by-step authentication tracing; candidates who know what EAP-TLS does but have not worked through failure scenarios tend to select the most common failure point rather than the one the scenario actually describes.

GBP items reward knowing the enforcement model precisely. A policy that looks correct in configuration can still fail if the enforcement point is wrong or the tag assignment is not happening as expected. Items are written to distinguish these cases, so reading the full scenario before evaluating options is essential. Security design items reward fitting the mechanism to the stated threat model rather than selecting the strongest available control.

Authentication and Authorization accounts for 10% and is where the security policy meets the network infrastructure in practice. The two sub-topics are tightly linked: AAA configuration design and troubleshooting, and ClearPass integration analysis. Getting AAA right in design is necessary but not sufficient; the exam also tests whether you can read a ClearPass integration and identify what is wrong with it. Candidates who have deployed ClearPass in production will have an advantage here, but only if they have also thought carefully about failure modes.

– AAA design and troubleshooting

Designing AAA configurations from requirements means selecting the right combination of authentication methods, authorization sources, and accounting targets for a stated customer scenario. At the expert level, the requirement will include constraints: device types, user populations, fallback behaviour, and integration with existing infrastructure. Items reward configurations that satisfy all the stated constraints, not just the primary authentication requirement.

Troubleshooting AAA means working through the authentication flow to find where it breaks. A client that fails to authenticate could be failing at the supplicant, the authenticator, the RADIUS exchange, or the policy evaluation. Items reward narrowing the fault to the right point in the flow rather than replacing components until something works. Candidates who skip straight to the RADIUS server when the fault is actually at the authenticator tend to select incorrect remediation steps.

– ClearPass integration

ClearPass integration items ask you to read a described integration, understand what it is supposed to do, and identify either a design problem or an operational fault. This sub-topic is not about knowing ClearPass features in the abstract; it is about understanding how ClearPass interacts with the Aruba campus infrastructure and where that interaction can fail.

Analysis items reward understanding the data flow: how a client request reaches ClearPass, how ClearPass evaluates it against policy, and how the result is returned to the network device. A fault in any of those three stages produces a different symptom, and the exam expects you to match the symptom to the stage. Candidates who treat ClearPass as a black box and focus only on the network-side configuration tend to miss faults that originate in the ClearPass policy or the trust relationship between ClearPass and the network device.

How Authentication/Authorization is tested

At 10%, this domain generates enough items that a gap in either sub-topic matters. AAA items span design selection and fault isolation; ClearPass items focus on integration analysis and operational diagnosis.

The most common loss point in AAA troubleshooting items is selecting a fix at the wrong layer of the authentication stack. Items are constructed so that the symptom is consistent with multiple failure points, and the scenario details are what distinguish the correct layer. Read the described client behaviour and the described network state together before evaluating options.

ClearPass integration items reward candidates who understand the trust and data-flow model rather than those who have memorised configuration screens. Items will describe an integration state and ask what it means for client authentication behaviour. The trap is selecting an explanation that is plausible for ClearPass in general but does not match the specific integration described in the scenario.

The previous domains each embed troubleshooting within a specific technology area. This domain makes troubleshooting itself the subject. At 10%, it tests advanced fault isolation and remediation across the campus network as a whole, which means you may face a scenario that crosses technology boundaries: a fault that starts in routing, surfaces in wireless, and is confirmed through an authentication log. The skill being tested is method, not just knowledge of any single technology.

How Troubleshooting is tested

Items present multi-layer or multi-technology campus faults and ask you to select the next diagnostic step, identify the root cause, or choose the remediation action. The distinguishing feature of this domain is that the fault description will often be ambiguous enough to point at more than one technology area, and narrowing it down is part of the task.

Items reward a structured approach: establishing what is known, identifying what that rules out, and selecting the diagnostic action that most efficiently narrows the remaining candidates. Candidates who pick the most familiar technology as the likely cause and work from there tend to select diagnostic steps that confirm their assumption rather than test it.

Remediation items carry a specific trap: the fix that resolves the described symptom fastest is not always the one that addresses the root cause and maintains network stability. Items reward fixes that are durable under the full network state described, not just fixes that would work in a simplified version of the scenario. Read every constraint in the scenario before selecting a remediation action.

Performance Optimization closes the exam at 6%. Where the Troubleshooting domain focused on faults that break connectivity, this domain focuses on networks that work but do not work well enough. The single sub-topic covers analysis and remediation of performance issues, which in a campus access context means identifying the configuration, design, or environmental factor that is degrading throughput, increasing latency, or reducing capacity, and then choosing the fix that addresses it without introducing a new constraint.

How Performance Optimization is tested

Items present a campus network or segment with a described performance symptom and ask you to identify the cause or select the remediation. The key distinction from troubleshooting items in other domains is that the network is functional: clients are connected, services are reachable, but something is measurably degraded.

Items reward candidates who can read performance data or a described symptom and map it to the correct layer and mechanism. A throughput problem in a wireless environment has different causes than a throughput problem on a wired uplink, and the scenario will give you enough detail to tell them apart if you read it carefully.

The most common loss point is selecting a remediation that improves the described metric in isolation but creates a new constraint elsewhere, such as adjusting a QoS policy that helps one traffic class at the expense of another. Items reward fixes that account for the full traffic profile described in the scenario. Candidates who focus only on the degraded metric and ignore the rest of the described environment tend to select options that are partially correct.