Aruba Network Security Associate common mistakes
Aruba Network Security Associate · Understand the traps and how to avoid them.
Treating 802.1X, captive-portal, and MAC authentication as interchangeable and picking one as a universal answer for 'how should this device get on the network', regardless of whether the endpoint can run a supplicant.
Candidates memorize the three methods as a list and then match on keywords in the question stem rather than on device capability, so printers and IoT devices get assigned 802.1X answers and managed laptops get MAC-auth answers.
What to do instead
Before answering, classify the endpoint: can it run an 802.1X supplicant with credentials or a certificate? If not, does it have a stable MAC and a registration workflow? Then map: managed endpoint with supplicant -> 802.1X; headless device with known MAC -> MAC authentication; guest or unmanaged user needing a browser -> captive portal. State the capability that drove the choice.
Confusing authentication with authorization: assuming that a successful 802.1X authentication by itself determines the VLAN or role the client lands in, and describing the RADIUS Accept as the end of the story.
The words 'authenticate' and 'authorize' are used loosely in study material, and Accept/Reject is the most visible RADIUS output, so candidates stop reading at the Access-Accept.
What to do instead
Trace the full chain explicitly: identity is proven at authentication (EAP exchange, credentials or certificate), then authorization data returned in the RADIUS response (role, VLAN, or policy attributes) drives enforcement, and the enforcement point applies the role. When a question asks 'what determines the client's access', the answer is the returned authorization attributes plus the local role/policy mapping, not the Accept alone.
Describing role-based access control as a static VLAN assignment only, and failing to distinguish a role that carries a policy (per-role ACLs, per-role bandwidth, per-role session behavior) from a role that merely maps to a subnet.
VLAN-per-role is the simplest mental model and is easy to picture, so candidates collapse all enforcement into VLAN membership and cannot answer questions about differentiated treatment of clients in the same VLAN.
What to do instead
For any RBAC question, name the enforcement layer separately from the addressing layer: a role can be applied to a client independent of its VLAN, and policy (permit/deny rules, QoS, captive-portal redirection, re-authentication timers) is attached to the role. Be able to say what happens when two clients share a VLAN but have different roles.
Mixing up EAP methods by their security properties, e.g. treating PEAP or EAP-TTLS as client-certificate methods, or assuming EAP-TLS works without a server certificate, or claiming EAP-TLS protects only the server side.
All EAP methods look like 'EAP-something' and the tunneled methods (PEAP, TTLS, FAST) do use certificates, but only for the server, which is the detail candidates drop.
What to do instead
Build a two-column table: server certificate required (all of PEAP, TTLS, FAST, TLS) versus client certificate required (EAP-TLS only). Also note which methods create a TLS tunnel for the inner method. Answer method questions by checking those two properties against the scenario rather than by name recognition.
Answering wireless security questions by naming the strongest cipher (e.g. 'use AES-CCMP') without addressing the authentication and key-management mode (WPA2-Personal PSK vs WPA2/WPA3-Enterprise 802.1X vs SAE), so the answer does not fix the actual weakness described.
Cipher suites are heavily emphasized in study material, so candidates reach for the encryption term when the scenario is really about shared-key exposure or lack of per-user identity.
What to do instead
Read the scenario for the weakness first: shared secret across many users -> move to Enterprise 802.1X with per-user credentials; offline dictionary attack on the handshake -> WPA3-SAE or strong unique PSKs; legacy TKIP/WEP -> upgrade to AES-CCMP/GCMP. Then state the cipher as a secondary improvement, not the primary fix.
Treating a RADIUS shared secret, a PSK, and a user password as the same kind of secret, and proposing to 'rotate the shared secret' or 'change the PSK' as a remedy for a compromised user credential (or vice versa).
All three are called 'secrets' or 'keys' in casual reading, and the exam often describes a leaked credential without naming which type, so candidates apply the rotation they remember best.
What to do instead
Identify the secret's scope before prescribing a fix: a RADIUS shared secret is per network-device-to-RADIUS-server pair; a PSK is per SSID and shared by all users of that SSID; a user password is per identity. A leaked user password is fixed by disabling/resetting that identity and investigating its use; a leaked PSK requires changing the SSID passphrase for everyone; a leaked RADIUS secret requires changing it on both the NAD and the server.
Confusing what a RADIUS server does with what a network access device (switch/controller/gateway) does, e.g. saying the RADIUS server assigns the client's VLAN directly or that the switch performs the EAP method negotiation with the client's credentials.
Both boxes appear in every 802.1X diagram and the flow arrows are easy to blur, so responsibilities get swapped when the question probes the boundary.
What to do instead
Fix the division of labor: the supplicant and the authenticator (NAD) exchange EAP; the NAD encapsulates EAP in RADIUS to the authentication server; the server evaluates credentials and returns Accept/Reject plus authorization attributes; the NAD enforces the resulting role/VLAN/policy. Any answer that has the RADIUS server directly configuring a port or VLAN on the switch is wrong unless it is describing returned attributes the NAD then applies.
Answering monitoring questions with 'enable logging' or 'check the logs' instead of specifying the telemetry source, the event, and the response action that would actually detect or contain the described incident.
Logging is treated as a single generic control, so candidates do not practice mapping a symptom (rogue AP, repeated auth failures, MAC spoofing, client deauth flood) to the specific signal and the specific first response.
What to do instead
For each incident type, rehearse a three-part answer: where the evidence lives (RADIUS auth logs, controller/AP event and WIDS logs, switch port and DHCP logs, syslog/SIEM correlation), what pattern indicates it (e.g. many rejects from one identity, an SSID seen with an unknown BSSID, a MAC appearing on two ports), and the first containment step (contain/blacklist the rogue, quarantine the port, disable the account, preserve logs before remediation).
Skipping the pre-deployment checks for wired/wireless security changes: proposing to enable 802.1X or WPA3-Enterprise on production without first confirming RADIUS reachability, server certificate trust on clients, supplicant configuration, and a fallback/monitor-mode period.
Configuration questions reward knowing the correct end-state settings, so candidates describe the final configuration and omit the transition steps that prevent an outage.
What to do instead
Whenever a question asks how to roll out an authentication or encryption change, include the readiness items: RADIUS server reachable and shared secret matching, server certificate issued by a CA the clients trust with the correct name, supplicants configured for the chosen EAP method, and a staged rollout (monitor/audit mode, then enforce, with a defined exception path for non-supplicant devices).
Misclassifying threats by layer or control type: labeling a deauthentication flood, evil twin, or MAC spoofing as an encryption problem, or answering a threat-landscape question with a preventive control when the scenario asks for detection (or vice versa).
Threat names are learned as vocabulary without the layer or the control category attached, so candidates match on the word 'wireless' or 'attack' and pick a plausible-sounding but mismatched control.
What to do instead
For each threat, state three things before choosing: the layer/mechanism (radio/association, authentication, network, host), whether the goal is prevention or detection, and the matching control (e.g. deauth flood -> WIDS detection and management-frame protection, not a stronger cipher; evil twin -> rogue AP detection and client certificate validation of the server, not a PSK change; MAC spoofing -> 802.1X identity plus port security/MAC notification, not WEP).