Aruba Campus Access Professional common mistakes
Aruba Campus Access Professional · Understand the traps and how to avoid them.
Designing a campus topology that collapses core and access layers into one pair of switches without justifying why, then failing scenario questions that ask where a given function (routing boundary, policy enforcement, spanning-tree root) should live.
Candidates memorize 'three-tier vs two-tier' definitions but never practice mapping real constraints (port count, PoE budget, uplink oversubscription, redundancy) onto a layer choice, so they default to the simplest diagram.
What to do instead
For each design prompt, write down the requirements first (redundancy level, routing boundary, broadcast domain size, power budget), then justify each layer decision against a requirement. Practice producing a two-tier collapsed-core design and a three-tier design for the same requirement set and state explicitly which requirement drove the difference.
Assuming a redundant design is resilient without verifying that the redundant paths are actually forwarding and that failure of one link or one core switch leaves the expected convergence path.
Redundancy is treated as a checkbox on a diagram rather than a testable property; candidates do not habitually trace the post-failure forwarding path.
What to do instead
For every redundant design answer, redraw the topology with one link or device removed and confirm the remaining path carries the required traffic and that no single blocking point isolates an access block. Make this a mandatory second pass on design questions.
Configuring VSX or stacking and leaving the spanning-tree root, LACP hash, and inter-switch link expectations at defaults, producing asymmetric or suboptimal forwarding that the question is specifically probing.
Candidates know the commands to bring up the pair but not the operational prerequisites (root placement, ISL capacity, keepalive path, MAD handling) that make the pair behave as designed.
What to do instead
Build a checklist for any redundant-pair configuration: root bridge placement, ISL/LAG capacity relative to uplink count, keepalive/management path independence, and split-detection behavior. Apply the checklist to lab scenarios and to every configuration question.
Mixing routed and switched segments incorrectly at the distribution layer, for example placing an SVI on the wrong device or letting a VLAN span farther than the design intends, so traffic takes an unintended path.
Candidates focus on making connectivity work rather than on where the Layer 3 boundary is supposed to be, and do not verify which device owns each gateway.
What to do instead
Before answering, annotate the diagram with the gateway owner for every VLAN and confirm each VLAN's Layer 2 extent matches the design. Re-derive the forwarding path hop by hop from access port to destination and check it against the intended boundary.
Treating role-based access control as a single global setting instead of reasoning about where the enforcement point sits (controller, switch, or gateway) and what happens to traffic that never reaches that point.
Candidates learn role assignment commands but not the enforcement architecture, so they miss questions about traffic that bypasses the enforcement device or about consistent policy across wired and wireless.
What to do instead
Map each policy requirement to the enforcement point that can actually see the traffic, and identify traffic paths that avoid it. Practice describing how the same role policy is applied to a wireless client, a wired client, and a client on a different VLAN.
Configuring 802.1X or MAC authentication and declaring success without checking the failure path: what happens to a client that fails authentication, where it lands, and whether that fallback is intended.
Candidates test only the happy path (valid credentials, correct role) and never exercise reject, timeout, or unreachable RADIUS server conditions.
What to do instead
For every NAC configuration, define and verify the outcomes for accept, reject, timeout, and server-unreachable, including the assigned VLAN or role in each case. Include the critical-role or fallback behavior explicitly in your answer.
Planning RF coverage by access point count or by nominal datasheet range instead of by required signal, client density, and channel reuse, leading to designs that pass on paper but fail capacity questions.
Candidates conflate coverage with capacity and do not separate the two when sizing an AP layout.
What to do instead
For each wireless design prompt, state the target RSSI/SNR, the assumed client mix and density per area, and the channel plan, then check that both coverage and capacity constraints are satisfied. If a question hinges on density, size by clients per AP rather than by area.
Answering roaming and mobility questions by naming a roaming standard without checking that the underlying prerequisites (consistent security, matching VLAN or tunneled architecture, controller reachability) are met.
Candidates memorize roaming terminology but do not connect it to the L2/L3 design and security configuration that make fast, seamless roaming possible.
What to do instead
For any roaming scenario, verify in order: same or reachable mobility domain, consistent security context, and the Layer 2 or tunnel path that preserves the client's session. State which prerequisite would break roaming if removed.
Diagnosing a reported connectivity problem by starting from the client and working outward without first establishing the scope (one client, one AP, one VLAN, or one building) and the timeline (what changed).
Candidates jump to a favorite command or feature instead of narrowing the fault domain, so they pick plausible-sounding but non-discriminating troubleshooting steps.
What to do instead
Structure every troubleshooting answer as scope, then layer: confirm whether the fault is client-specific, port-specific, VLAN-specific, or device-wide, then test the lowest layer that distinguishes those cases. Prefer the single test that splits the remaining hypotheses in half.
Choosing a monitoring or logging action that would confirm a hypothesis but not actually isolate it, for example suggesting 'check the logs' without naming the specific event, counter, or interface statistic that would differ between the candidate causes.
Candidates know monitoring tools exist but have not practiced translating a hypothesis into a discriminating observable.
What to do instead
For each troubleshooting question, write the two most likely causes and then name one specific observable (a counter, a log event type, an interface state, a client state transition) whose value differs between them. If you cannot name that observable, the action is not yet a diagnostic step.