Aruba Campus Access Architect (HPE7-A11) common mistakes
Aruba Campus Access Architect (HPE7-A11) · Understand the traps and how to avoid them.
Designing an Aruba wireless network by picking AP models and mounting locations first, then choosing the controller/gateway architecture and licensing afterward.
Candidates come from a hardware-installation mindset where the AP is the design unit; the exam treats the architecture (gateway vs controller vs controller-less, mobility conductor, scale limits, licensing model) as the design decision that constrains everything else, so a bottom-up answer omits the capacity and licensing reasoning the scenario is testing.
What to do instead
Practice writing a one-page design order of operations: requirements and client density, then architecture and scale limits (device and client counts per gateway/conductor), then licensing, then AP selection and RF plan. Answer scenario questions by walking that order explicitly.
Treating VLANs as the segmentation boundary and answering design questions with VLAN-per-department only, without mapping roles to a policy-enforcement point (role-based access, tunneled vs local switching, policy enforcement firewall).
VLAN-based segmentation is the familiar on-premises mental model; the exam scenarios usually add IoT, guest, and contractor traffic where role-based policy and centralized enforcement are the expected answer, so VLAN-only responses miss the security intent being tested.
What to do instead
For every segmentation scenario, state the role definitions, where policy is enforced (gateway/firewall role, tunnel vs local), and how traffic between roles is inspected. Practice translating a stated business requirement into a role plus enforcement point, not into a VLAN number.
Assuming a single underlay or a single spanning-tree topology will carry all traffic types, and answering redundancy questions with 'add a second link' without specifying active/active vs active/standby behavior and failure convergence.
Candidates memorize redundancy features by name but not their failure semantics; exams probe what actually happens on link or node failure (traffic re-path, reconvergence, client impact), and vague answers reveal the gap.
What to do instead
Build a failure-mode table for each redundancy mechanism you study: what fails, what detects it, what re-paths, expected outage window, and effect on wireless clients. Answer by naming the detection and reconvergence path, not just the feature.
Answering monitoring and automation questions with generic 'use the dashboard' or 'script it' responses instead of naming the telemetry source, the collection method, and the action taken on an alert.
Candidates know the management tool exists but not the data flow (what is collected where, how it is exported, what triggers an action), so they cannot distinguish between monitoring, alerting, and automated remediation in scenario questions.
What to do instead
For each management tool in scope, write three lines: what data it collects, how it is exported or integrated, and one concrete automated action. Practice scenarios by stating the telemetry source and the closed-loop action.
Planning a migration as a cutover date rather than as a sequence of coexistence states, and failing to describe how old and new infrastructure interoperate during the transition.
Candidates study the target design and the source design separately; exam scenarios ask about the middle period (mixed authentication, duplicate SSIDs, roaming across old and new, temporary routing), which is where most real failures and most exam distractors live.
What to do instead
For each migration topic, sketch at least two intermediate states and name the interop mechanism (shared AAA, shared DHCP/DNS, common SSID with matching security, routing between old and new). Answer migration questions by describing the transition state, not just the endpoint.
Selecting security controls by product name (e.g., 'enable 802.1X') without specifying the identity source, the EAP method, the role assignment outcome, and the fallback behavior for non-supplicant devices.
Product-name answers feel complete but the exam scores the configuration logic and the edge cases; IoT and headless devices are the standard trap, and candidates who never designed a fallback path default to weakening the whole policy.
What to do instead
For every authentication answer, state: identity store, EAP method, role/ VLAN assignment, and the documented path for devices that cannot do 802.1X (MPSK, device profiling, or a restricted role). Include the failure behavior when the RADIUS server is unreachable.
Sizing wireless capacity from coverage (one AP per area) and ignoring client density, airtime, band steering, and high-density design factors when answering design questions.
Coverage-based design is the entry-level habit; the architect exam includes auditoriums, warehouses, and IoT-dense floors where capacity and airtime, not signal, drive AP count, and candidates under-provision or over-provision without justifying either.
What to do instead
Practice capacity calculations: clients per AP by application type, channel width and band plan, and the resulting AP count, then reconcile with coverage. In answers, state the binding constraint (capacity or coverage) explicitly.
Describing high availability only in terms of hardware redundancy and omitting stateful failover of client sessions, authentication state, and IP mobility during a controller or gateway failure.
Candidates equate HA with dual power supplies and stacked switches; wireless and gateway HA questions hinge on whether client sessions and roaming state survive, which requires understanding state synchronization and where the client's anchor is.
What to do instead
For each HA design, answer three questions: what state is synchronized, where the client's session anchor lives, and what the client experiences during failover (re-auth, DHCP renewal, dropped sessions). Practice stating the client-visible outcome, not just the redundancy mode.
Answering troubleshooting scenarios by listing show commands instead of forming a hypothesis, isolating the layer, and naming the evidence that would confirm or eliminate it.
Command recall is easy to study and feels productive; the exam presents symptoms and expects a diagnostic sequence, so command lists without a decision path fail to distinguish between plausible causes.
What to do instead
Practice a fixed troubleshooting script: define the symptom scope (one client, one AP, one VLAN, all), pick the layer to test first, name the specific evidence, and state the next branch for each outcome. Write answers as a decision tree, not a command dump.
Treating integration with external systems (AAA, DHCP/DNS, firewall, NAC, cloud management) as a checkbox and not stating the protocols, the failure domain, and what happens when the external system is unavailable.
Integration questions look like product-compatibility questions, but they test dependency analysis; candidates who never mapped the dependency graph cannot answer what breaks and how the design degrades when a shared service fails.
What to do instead
Draw a dependency map for each design: every external service, the protocol used, whether it is in the data path or control path, and the designed degraded mode (local survivability, cached credentials, secondary server). Answer integration questions by naming the dependency and its failure behavior.