Aruba ACMA common mistakes
Aruba ACMA · Understand the traps and how to avoid them.
Treating the Mobility Master/Mobility Conductor as the device that forwards client traffic, or sizing throughput and licensing against it instead of the managed Mobility Controllers.
Study material shows the hierarchy diagram and the words 'controller' and 'master' together, so candidates merge the two planes into one box and never separate management from data forwarding.
What to do instead
Draw the planes explicitly: the conductor holds configuration, firmware, and global licensing and pushes it to managed controllers/APs; the managed controller (or the AP itself in bridge mode) forwards user traffic. For every design question, state which plane the component sits in before choosing an answer.
Assuming every Aruba access point needs a hardware controller, and therefore ruling out Instant AP or Central-managed options on scenario questions about small sites or branch deployments.
Controller-based ArubaOS deployment is the first architecture candidates learn, and the virtual controller election among Instant APs is easy to forget because no dedicated appliance appears in the topology.
What to do instead
Memorise the three deployment models: controller-based ArubaOS, Instant AP with an elected virtual controller (optionally managed by Central or AirWave, and optionally tunnelled to a gateway), and cloud-managed AOS 10/Central. For each, be able to name what happens if the virtual controller AP fails: a new conductor is elected from the remaining cluster members.
Reusing 2.4 GHz co-channel logic in 5 GHz, for example planning only three 'non-overlapping' channels or assuming every 5 GHz channel listed by a scanner is usable at full power in every country.
The 1/6/11 rule is drilled so heavily that candidates apply it universally, and they overlook that 5 GHz channels come in UNII blocks where parts of the band are subject to DFS/TPC and some are restricted by regulatory domain.
What to do instead
Learn the 5 GHz channel numbering as UNII blocks (36-48, 52-64, 100-144, 149-165 in the common US plan), note which blocks require DFS and radar detection, and remember channel width is created by bonding adjacent 20 MHz channels. Always confirm the regulatory domain before declaring a channel or width legal.
Mixing up the 802.11 amendment letters with security certifications, such as assuming 802.11ax implies WPA3 or that 802.11i is a roaming standard rather than the basis for WPA2/RSNA.
Amendment numbers are memorised as a list without being tied to a function, and vendors market Wi-Fi 6 and WPA3 together so often that the two blur into one feature.
What to do instead
Build a two-column table and be able to state each from memory: 802.11k neighbour reports, 802.11v BSS transition management, 802.11r fast BSS transition, 802.11w protected management frames, 802.11i robust security (WPA2), 802.11ax high-efficiency. Note that security and roaming standards are independent of the PHY amendment in use.
Creating an SSID profile and a virtual AP profile and then assuming the WLAN is live, without checking that the virtual AP is bound to the correct AP group or AP name and that its referenced AAA and SSID profiles resolve.
The configuration model is a web of references, and the GUI happily saves a profile that is not attached to anything, so the WLAN appears configured but never beacons.
What to do instead
Before validating any WLAN change, trace the chain out loud: virtual AP profile → SSID profile (name, encryption, VLAN) → AAA profile (initial role, 802.1X, server group) → AP group binding. Confirm the virtual AP is actually assigned to the target AP group or ap-name rather than left unassigned, and save the configuration so it persists across reload.
Assuming VLAN assignment happens in the AAA profile, or forgetting that the client VLAN must be trunked on the AP uplink and allowed on the upstream switch port.
Client VLAN can be set in more than one place (virtual AP/SSID profile, or dynamically returned by the authentication server), and lab setups usually use a single untagged VLAN, so trunking problems never surface during practice.
What to do instead
Know both paths: a static VLAN configured with the virtual AP, and a server-derived VLAN returned in the RADIUS attributes, which overrides the static value. Then verify the transport: the AP uplink must carry every client VLAN as tagged, matched by the switch port configuration, before any client can obtain an address.
Treating authentication and encryption as the same setting, so a question asking how a client is identified is answered with the cipher suite, or a WPA3-Personal question is answered as if it still used a shared passphrase exchange.
In the GUI a single drop-down often selects an entire security mode, which hides the fact that the identity proof and the over-the-air protection are separate decisions.
What to do instead
Separate the two questions every time: who proves identity (open, PSK/SAE, 802.1X/EAP) and how frames are protected (CCMP/AES, GCMP, or SAE's simultaneous authentication of equals). WPA3-Personal replaces the PSK handshake with SAE; WPA3-Enterprise can additionally require 192-bit mode. State both layers in your answer.
Building a guest captive portal design without verifying that unauthenticated clients can reach the portal itself, or assuming the post-authentication role is the same as the initial role.
The login page depends on the client being blocked from most destinations but permitted to a few, and candidates picture the portal as internal to the controller rather than as a destination that must be reachable before login.
What to do instead
Walk the flow as three states: initial/pre-authentication role, captive portal redirect plus the walled garden/allowlist entries needed for the portal host and DNS, then the post-authentication role derived from the authentication result. Check that the allowlist covers every host and port the page loads, and test the redirect from a client with no cached credentials.
Troubleshooting sticky clients by raising AP transmit power, and expecting the infrastructure to force a client to move to a better AP.
Signal strength is intuitive and easy to change, whereas the roaming decision belongs to the client and is influenced by the AP only through suggestions, so the fix feels productive while making the mismatch worse.
What to do instead
Reduce the coverage overlap problem from the AP side with balanced, lower power and denser AP placement rather than turning power up. Use client-match/band-steering features and 802.11k/v assistance to encourage movement, and remember that roaming across a VLAN boundary adds a mobility/anchor requirement that a same-VLAN roam does not. Verify with client-table output showing the actual roam events.
Starting diagnosis from RF or running a configuration change first, without establishing how far the client got in the connection sequence, and without distinguishing which AP table or client command actually answers the question.
Symptom words like 'cannot connect' are ambiguous, and the command family is large, so candidates jump to the single command they remember instead of ordering the layers.
What to do instead
Work the sequence and name a check for each step: beacon/association, 802.11 authentication and key exchange, 802.1X/EAP or PSK, DHCP address, then role and firewall policy. Use the AP database versus active AP listing to confirm the AP is up and heartbeating, client-table output for association state, and session/role output for forwarding policy. Change one variable at a time.