HPE7-A01 HPE Network Campus Access Professional Exam Topics and Questions

Planning is where most campus access projects succeed or fail before a single cable is run. At the professional level, the exam treats planning as an engineering discipline: you are expected to translate messy customer conversations into a design that can actually be built. Items here will expose gaps between what a customer says they need and what their existing environment can support, and that gap is where candidates lose marks.

– From customer requirements to a workable design

Identifying customer requirements means more than writing down what the customer asks for. You need to surface the constraints they did not mention: existing cabling grades, switch port density, PoE budgets, and the applications that will break if latency spikes. The exam tests whether you can read a requirements brief and spot what is missing or contradictory.

Interpreting an architect's high-level design then requires you to hold two things in your head simultaneously: what the design intends and what the current environment will actually allow. Candidates who treat the high-level design as a finished specification tend to miss the adjustment step. The exam rewards recognising where the architecture needs to bend to fit the site.

– Turning design intent into a buildable plan

Creating a low-level design is the point where abstract topology becomes specific configuration decisions. VLAN numbering, IP addressing, SSID parameters, RF channel plans, and uplink redundancy all need to be pinned down before implementation begins. The exam tests whether your low-level design choices are consistent with the requirements gathered earlier and the constraints surfaced by the environment analysis.

Preparing for implementation covers the pre-deployment checklist work: staging devices, confirming firmware versions, verifying that licensing is in order, and making sure the team knows the rollback plan. Items on this sub-topic often present a scenario where one preparation step was skipped, and you need to identify which omission caused the downstream problem. Methodical pre-work is the answer the exam is looking for, not heroic troubleshooting after the fact.

How Plan the Solution is tested

At 21% of the exam, this topic generates a meaningful share of items, and most of them are scenario-based. You will be given a customer environment with stated requirements and asked to pick the design decision that best fits both. The trap is that two or three options will look technically valid in isolation. Items reward the option that satisfies the requirement while respecting the environmental constraint, not the option that is simply correct in a textbook network.

A second pattern involves moving between design levels: you see a high-level diagram and must identify what the low-level plan should specify. Candidates lose marks here by jumping to configuration details before checking whether the architecture itself is appropriate for the stated requirements. The exam consistently rewards a methodical sequence: gather, analyse, interpret, design, prepare. Skipping a step in that sequence is usually what the wrong options do.

Configuration is the heaviest topic on the exam at 26%, and the weight is earned. Where planning asked you to make decisions, configuration asks you to execute them correctly across onboarding, provisioning, deployment, and validation in sequence. A mistake at any stage tends to compound: a misconfigured device that passes onboarding can break deployment two steps later, and the exam constructs scenarios that trace exactly that kind of cascade.

– Getting devices onto the network correctly

Device onboarding in an Aruba campus environment involves more than plugging in an AP or switch. Zero-touch provisioning, Aruba Central group assignments, and the trust chain between device certificate and management platform all come into play. The exam tests whether you understand the order of operations: what has to be true before a device can be claimed, and what breaks the claim process when it goes wrong.

Device provisioning then takes the onboarded device and applies the right configuration profile. The distinction between onboarding and provisioning matters here because the exam will present scenarios where a device is onboarded but misconfigured, or correctly provisioned but placed in the wrong group. Knowing which layer the problem sits in determines which fix is appropriate.

– Deploying and confirming the configuration

Deploying the solution covers pushing configuration to production, which in an Aruba Central-managed environment means understanding how templates, variables, and group hierarchies interact. A configuration that looks correct in a template can produce unexpected results when variable substitution is applied to a specific device. The exam rewards candidates who understand that deployment is not a single action but a chain of dependencies.

Validating the solution is the step candidates most often underweight in their preparation. Validation in the exam context means confirming that the deployed configuration produces the expected network behaviour, not just that the management platform reports no errors. Items on this sub-topic test whether you know which verification commands and dashboard views confirm actual traffic forwarding, authentication results, and RF behaviour, rather than just configuration syntax. A clean configuration screen and a working network are not the same thing.

How Configure the Solution is tested

The high weight here means you will see configuration items across a wide range of Aruba technologies: AOS-CX switching, AOS 10 APs, Aruba Central policies, and authentication frameworks including 802.1X and MAC-based. Items rarely test a single CLI command in isolation. Instead, they present a multi-step configuration scenario and ask you to identify the step that is missing, out of order, or inconsistent with the stated design.

The most common trap is selecting an option that is technically correct for a different deployment model. Aruba Central-managed and controller-managed configurations differ in meaningful ways, and the exam will not always flag which model applies: you are expected to read the scenario and infer it. Candidates lose marks by applying controller-era logic to a Central-managed scenario or vice versa. Items reward candidates who anchor their answer to the specific management model the scenario describes before evaluating any configuration option.

Once the network is live, the work shifts from building to sustaining. This topic covers the day-to-day and week-to-week tasks that keep a campus access environment healthy: watching the right metrics, updating firmware without breaking things, handling change requests, and keeping documentation accurate. At 15%, it is a smaller slice than configuration or troubleshooting, but the items are precise and candidates who treat operations as common sense tend to drop marks on the specifics.

– Visibility and keeping the environment current

Monitoring and reporting in an Aruba Central environment means knowing which dashboards and alert thresholds matter and which are noise. The exam tests whether you can identify the right data source for a given operational question: client health scores, RF utilisation trends, switch port statistics, and authentication failure rates each live in different parts of the platform. Items reward candidates who know where to look, not just that a problem exists.

Firmware updates carry more risk than they appear to on paper. The exam tests the correct update sequence for a mixed environment, the dependency between AOS version and Central feature availability, and the steps needed to validate that an update did not degrade service. A candidate who treats firmware updates as a one-click operation will miss the sequencing and rollback questions.

– Managing change and keeping records straight

Ongoing configuration changes in a production environment require change control discipline, and the exam reflects that. Items test whether you understand the impact of modifying a shared template versus a device-level override, and how a change in one part of the hierarchy propagates to devices downstream. The trap is selecting the change that achieves the immediate goal without recognising the side effect on other devices in the same group.

Maintaining documentation is tested in a practical rather than procedural way. Items present a scenario where documentation is out of date or incomplete and ask you to identify the operational risk that creates, or to determine what information a technician would need to resolve a specific situation. The exam rewards treating documentation as an operational tool, not an administrative formality. Accurate records of VLAN assignments, IP addressing, and RF plans directly affect how quickly the next incident gets resolved.

How Operate the Solution is tested

At 15%, this topic contributes a focused set of items, and they tend to be more platform-specific than the planning questions. Expect scenarios grounded in Aruba Central workflows: where a particular operational task is performed, what the platform shows when something is drifting out of compliance, and how to interpret a health or alert report correctly.

Firmware sequencing and template change impact are the two areas where candidates most often lose marks. Both require you to think one step ahead of the action being taken. Items reward candidates who identify the downstream consequence before committing to a course of action. The documentation sub-topic produces items that look deceptively straightforward: the question is not whether documentation matters but what specific piece of missing information creates the operational gap described in the scenario. Read the scenario carefully before dismissing a documentation item as obvious.

Troubleshooting carries 24% of the exam, making it the second-largest topic. The exam does not reward instinct here. It rewards a structured method applied consistently, and then the technical depth to execute each step of that method across physical, Layer 2, Layer 3, and application-layer problems. Candidates who jump straight to a fix without scoping the issue first will find that the scenario has been constructed to punish exactly that habit.

– Method first, then scope

The troubleshooting methodology sub-topic is not a soft opener. The exam tests whether you apply a defined process: establish symptoms, determine scope, identify likely causes, test hypotheses, and validate the fix. Items will present a scenario where a technician has already performed several steps and ask what should happen next. The answer depends entirely on where in the methodology the scenario sits, not on which fix sounds most plausible.

Determining issue scope means distinguishing between a problem affecting one client, one AP, one switch, one VLAN, or the entire site. The exam constructs scenarios where the scope is deliberately ambiguous from the first symptom described. Items reward the candidate who gathers scope-defining information before selecting a cause. Jumping to a single-device explanation when the evidence points to a shared infrastructure component is the most common wrong move here.

– Physical and data-link layer faults

Physical layer troubleshooting covers the parts of the problem that no amount of software configuration can fix: cable faults, SFP mismatches, PoE budget exhaustion, and RF interference that a spectrum analyser needs to characterise. The exam tests whether you know which tool or which platform view surfaces physical layer evidence, and whether you can read that evidence correctly.

Layer 2 troubleshooting in an Aruba campus environment involves spanning tree state, VLAN membership, trunk negotiation, and the interaction between AOS-CX and upstream devices. Items often present a connectivity symptom and require you to trace it to a specific Layer 2 misconfiguration. The trap is reaching for a Layer 3 explanation when the symptom is actually a VLAN or STP issue. The exam rewards methodical layer-by-layer elimination rather than pattern-matching to a familiar fault.

– Upper-layer faults and closing the loop

L2-L7 troubleshooting extends the scope to authentication failures, DHCP and DNS problems, firewall policy mismatches, and application-layer connectivity issues. In an Aruba environment this frequently means reading authentication logs in Aruba Central, correlating client association events with RADIUS responses, and distinguishing a policy denial from a credential failure. Items at this layer require you to interpret log output and select the cause that the evidence actually supports, not the cause that appears most often in similar scenarios.

Implementing and validating a resolution closes the troubleshooting loop. The exam tests whether the fix you select actually addresses the root cause identified during scoping, and whether you verify the outcome against the original symptom. A fix that resolves the immediate complaint without addressing the root cause is a trap option that appears in multiple items. Items reward candidates who confirm that the problem is gone and that the fix did not introduce a new fault.

How Troubleshoot the Solution is tested

The 24% weight means troubleshooting items will appear throughout your exam, not clustered at one point. Most are multi-step scenarios: a symptom is described, some diagnostic output is provided, and you must identify cause, next action, or correct fix. The diagnostic output is where the exam separates prepared candidates from unprepared ones. You need to be able to read Aruba Central client detail views, AOS-CX show command output, and RADIUS log entries and extract the relevant signal.

The methodology sub-topic produces items that penalise skipping steps. An option that goes straight to a fix will often be tempting because the fix is technically sound, but items reward the option that follows the correct sequence first. Scope determination is a second consistent source of lost marks: candidates who anchor too early on a single device miss items where the evidence points to shared infrastructure. Validate-after-fix items are also common, and they reward confirming behaviour, not just configuration.

Optimization sits at the end of the lifecycle and at the lightest weight on the exam, but the items here are not easy. They require you to compare a network's current behaviour against a measured baseline, apply WLAN and LAN best practices in context, and judge whether a change actually improved things. The exam treats optimization as a data-driven activity: opinions about what should work are not enough when the baseline tells a different story.

– Establishing a reference point

Performing an environment baseline is the step that gives every subsequent optimization decision its meaning. Without a baseline, you cannot tell whether a change improved performance or simply shifted the problem. The exam tests whether you know what a useful baseline captures: client throughput distributions, channel utilisation, retry rates, CRC error counts, uplink bandwidth consumption, and authentication success rates across time of day. A baseline that measures the wrong things is as misleading as no baseline at all.

The exam also tests the timing of baseline collection. A baseline taken during a low-traffic period will not represent peak-hour behaviour, and items will present scenarios where an optimization decision was made on a misleading baseline. Items reward candidates who recognise that the baseline must reflect the conditions under which the problem was reported.

– Applying best practices and confirming the outcome

WLAN best practices in an Aruba environment include channel width selection, transmit power management, band steering, minimum data rate configuration, and roaming parameters. The exam does not test these as a checklist. It presents a scenario where one parameter is misconfigured relative to the environment and asks which adjustment would produce a measurable improvement. Knowing the best practice value matters less than knowing why it is the best practice and what happens when it is wrong.

LAN best practices cover spanning tree optimisation, ECMP or LAG configuration for uplink bandwidth, QoS policy alignment with application requirements, and storm control thresholds. Again, the exam tests application in context rather than recall of standard values.

Comparing results to the baseline is the final confirmation step. Items test whether the post-change measurement was taken under conditions comparable to the baseline, and whether the improvement observed is in the metric that actually mattered to the original complaint. An improvement in the wrong metric is a trap that appears in optimization scenarios.

How Optimize the Solution is tested

At 14%, optimization produces fewer items than any other topic, but they tend to require careful reading. Most follow a before-and-after structure: a baseline measurement is described, a change is proposed or applied, and you must evaluate whether the outcome represents a genuine improvement or a misread of the data.

WLAN optimization items are the most technically detailed. They test parameter interactions: changing transmit power affects co-channel interference, and changing minimum data rates affects cell coverage edge behaviour. Items reward candidates who reason through the second-order effect of a change, not just the first. LAN optimization items are less frequent but test similar logic around uplink utilisation and QoS policy.

The baseline comparison sub-topic produces items where candidates lose marks by accepting a positive result at face value. The exam rewards scepticism: was the post-change measurement taken under comparable conditions, and does the improved metric actually address what the user reported? Treating optimization as confirmation rather than discovery is the mindset the exam tests for.