Aruba Associate common mistakes
Aruba Associate · Understand the traps and how to avoid them.
Treating 2.4 GHz and 5 GHz channels as one interchangeable pool, so the candidate assigns channel 6 in 2.4 GHz and channel 6 or 11 in 5 GHz as if they were the same numbering, or picks channel 3 or 9 for 2.4 GHz because 'it is between the non-overlapping ones'.
The two bands use different channel numbering and spacing: 2.4 GHz has 20 MHz-wide channels spaced 5 MHz apart, giving only three non-overlapping 1/6/11 in North America, while 5 GHz channels are 20 MHz with 20 MHz spacing and largely non-overlapping by design. Candidates memorize '1, 6, 11' and then apply it everywhere, or assume any channel number is valid in both bands.
What to do instead
Build a one-page band comparison table from memory: 2.4 GHz 1-13 (region-dependent), 20 MHz spacing requirement, only 1/6/11 non-overlapping; 5 GHz UNII-1/2/2e/3 ranges with DFS channels in UNII-2 and UNII-2e. For every channel-planning question, first ask 'which band', then apply the band-specific rule. Practice identifying whether a stated channel is legal in a given regulatory domain.
Assuming higher transmit power or more APs always improves coverage, and choosing 'increase AP power to maximum' as the fix for coverage holes or roaming problems.
More AP power increases the cell size but also raises the noise floor and can create sticky clients and co-channel interference; roaming depends on the client hearing multiple APs at comparable levels, so an overpowered AP makes clients cling to it. Candidates conflate 'stronger signal' with 'better WLAN'.
What to do instead
Learn the design principle that AP power and client power should be balanced so adjacent cells overlap at roughly -65 to -70 dBm and clients see multiple APs. When a question mentions sticky clients or failed roaming, look for answers that reduce power, enable band steering or 802.11k/v, or add APs at lower power rather than crank up the existing ones.
Mixing up which Aruba platform does what, e.g., describing Aruba Central as an on-premises controller, calling ClearPass a wireless controller, or claiming Mobility Controllers require a separate AirWave license to manage APs.
The portfolio has overlapping-sounding names (Central, ClearPass, AirWave, Mobility Controller, Mobility Master, gateways) and candidates learn them as a list of acronyms rather than as roles: cloud management, NAC/policy, legacy monitoring, on-prem control plane, and management/standby node. Questions test role assignment, not acronym recall.
What to do instead
Make a role matrix with columns: what it is, where it runs (cloud/on-prem/appliance/virtual), what problem it solves, and what it does NOT do. Anchor each product to one sentence, e.g., 'Central = cloud management and monitoring of Aruba devices', 'ClearPass = policy and NAC', 'Mobility Master = hierarchical management and configuration for controllers'. Re-derive the answer from the role, not the name.
Confusing the control plane and data plane roles of a Mobility Master versus a Mobility Controller, or assuming an AP terminates its data tunnel on the Mobility Master.
Aruba's hierarchical architecture separates management/configuration (Mobility Master) from the actual client traffic forwarding (Mobility Controller), and candidates who learned flat controller architectures assume every named device handles user traffic. The terminology 'master' invites the wrong intuition.
What to do instead
Draw the hierarchy once: Mobility Master at the top for configuration and licensing, Mobility Controllers below it terminating AP tunnels and forwarding client traffic, APs at the edge. Then answer architecture questions by asking 'is this a configuration/management action or a forwarding action?' Management actions go to the Master; data path questions go to the controller.
Treating all Aruba APs as identical, e.g., assuming every AP can run in Instant mode, that all APs have the same radio count or Wi-Fi generation, or that an AP model number alone tells you whether it is controller-managed or Instant.
The AP lineup spans many generations and families with different radio configurations, uplink speeds, and operating modes; candidates study one AP datasheet and generalize. Exam items often hinge on a capability (dual-radio vs tri-radio, Wi-Fi 6 vs 6E, whether an AP can be a conductor) rather than the model name.
What to do instead
Learn APs by capability class rather than memorizing every SKU: number of radios and bands, Wi-Fi generation, maximum PHY rate, uplink type, and supported operating modes (controller-managed, Instant, cloud-managed). When a question names an unfamiliar AP, answer from the stated capability in the stem rather than guessing from the model number.
Assuming an AP will always find a controller automatically and that 'it just works', so the candidate picks 'no configuration needed' for AP onboarding scenarios instead of identifying DHCP option 43/60, DNS discovery, or the Aruba Activate/centralized provisioning step.
AP discovery is a multi-path process (static controller IP, DHCP options, DNS, broadcast on local subnet) and the exam tests which mechanism applies in a given network. Candidates who only labbed a flat network never see the discovery failure and assume zero-touch is unconditional.
What to do instead
Memorize the discovery order and the role of DHCP option 43 (controller IP list) and option 60 (vendor class identifier), plus DNS-based discovery. For any 'AP shows up but never joins' question, walk the path: does it get an IP, does it learn a controller address, can it reach that address on UDP 8200/443, is the AP allowed by the controller's whitelist/approval policy.
Confusing authentication with authorization, e.g., answering that 802.1X alone determines which VLAN or role a guest gets, or assuming a PSK network provides per-user accountability.
Security questions blend 802.1X, MAC authentication, captive portal, roles, and firewall policies into one flow. Candidates learn '802.1X = secure' and stop there, missing that Aruba assigns a user role after authentication and that role enforcement (VLAN, ACL, bandwidth contract) is a separate step in the AAA profile.
What to do instead
Separate the flow into three stages: identity (who are you: 802.1X, MAC auth, captive portal, PSK), authorization (what role/policy applies: derived from server attributes or configured rules), and enforcement (role-based VLAN and ACLs applied at the controller or gateway). For each scenario, state which stage the question is asking about before choosing an answer.
Designing guest access without a clear path from the unauthenticated state to the guest role, e.g., putting the guest SSID on the corporate VLAN 'for simplicity' or forgetting that the captive portal and the pre-authentication role must permit DHCP and DNS.
Guest networks need a pre-auth role that allows DHCP/DNS and redirects HTTP to the portal, then a post-auth guest role with restricted access. Candidates focus on the portal page and skip the role transition, so they miss why guests cannot get an IP or why the portal never loads.
What to do instead
Draw the guest state machine: associate -> pre-auth role (DHCP, DNS, portal redirect) -> captive portal login or self-registration -> post-auth guest role (internet-only ACL, bandwidth contract, isolation). Check every guest troubleshooting question against this sequence and look for the missing pre-auth allowance or the missing role mapping.
Reading a monitoring output literally without interpreting counters, e.g., treating a high retry count as a hardware fault, or diagnosing a client issue from signal strength alone while ignoring SNR, channel utilization, and retry/error rates.
Candidates memorize where to find data (client table, AP table, RF dashboard) but not how to read it together. A single metric rarely proves a cause; the exam expects correlation of client SNR, retry rate, channel utilization, and airtime.
What to do instead
Practice a fixed triage order: is the client associated (association/auth failures), is the RF good (SNR, retries, PHY rate), is the channel congested (utilization, interference), is the path good (ping/gateway reachability), is policy blocking it (role/ACL). For each dashboard metric, write one sentence on what a bad value implies and what it does not.
Assuming Aruba Central configuration and monitoring are the same thing, or that a device managed in Central behaves identically to an on-premises controller with local configuration, so the candidate picks an on-prem CLI fix for a cloud-managed group.
Central uses groups, sites, and configuration templates pushed from the cloud, and monitoring is separate from configuration; candidates who learned CLI-first workflows apply them to cloud-managed devices where the config source of truth is the group, not the device.
What to do instead
For every Central question, first classify it as configuration (group/template/scope), monitoring (dashboards, alerts, audit trail), or device onboarding (Activate, subscription assignment). Then ask whether the device is in a group with a template or in a template-less group, because that determines whether a local change survives the next sync.