Aruba ACDA common mistakes
Aruba ACDA · Understand the traps and how to avoid them.
Designing the wireless RF plan from the AP datasheet's maximum data rate and default transmit power, treating coverage as a single AP-to-client distance, instead of computing a bidirectional link budget and planning for uplink (client-to-AP) as the limiting direction.
Candidates carry over consumer or vendor-marketing intuitions that 'more APs at max power = better', and forget that client radios are weaker and that co-channel interference degrades capacity even where RSSI looks fine.
What to do instead
For every coverage question, state the assumed client transmit power and antenna gain, compute the uplink RSSI at the cell edge, and set AP power so that the target edge SNR/RSSI is met with minimal co-channel overlap; justify AP count by capacity (client count x per-client throughput) as well as coverage.
Choosing channel width and band plan by preference (e.g., 'use 80 MHz everywhere for speed') without reconciling it against the available non-overlapping channel count and the resulting co-channel interference (CCI) in a dense floor plan.
Candidates optimize a single metric (peak throughput) and skip the arithmetic that shows 80 MHz in 5 GHz yields too few channels for the AP density, producing CCI that collapses aggregate capacity.
What to do instead
Show the channel-count math: number of usable channels at the chosen width vs. number of APs per RF neighborhood; default to 20/40 MHz in high-density areas, reserve 80 MHz for low-density or high-throughput zones, and document the reuse pattern.
Treating WLAN design as complete once the RF plan is done, omitting the wired underlay: PoE budget, uplink oversubscription, and switch port capacity to the APs and to the distribution layer.
Candidates compartmentalize domains and forget that AP power class (e.g., Wi-Fi 6/6E APs needing higher PoE) and per-AP uplink bandwidth determine whether the wireless design is even deployable.
What to do instead
For each AP, verify PoE class vs. switch port capability and total switch PoE budget, and size AP uplinks and closet-to-distribution links against expected peak wireless throughput with an explicit oversubscription ratio.
Producing a flat, single-VLAN design or one that ignores the user/device role model, then bolting on ACLs later, rather than deriving VLANs and roles from the security and segmentation requirements first.
Candidates default to 'one subnet per floor' habits and treat segmentation as a configuration afterthought, which conflicts with the role-based access model the design must support.
What to do instead
Start from an entity/role inventory (employees, guests, IoT, voice, management), map each to a VLAN and role, then design the L2/L3 boundaries, DHCP scope sizing, and inter-role policy enforcement point (firewall vs. role-based ACLs) before drawing the topology.
Sizing DHCP scopes and subnets from the count of currently known devices instead of from peak concurrent leases plus growth and guest churn, and ignoring lease time effects on pool exhaustion.
Candidates use headcount as the device count and forget BYOD multiples, IoT, and that short lease times recycle addresses but transiently inflate pool pressure during churn events.
What to do instead
Size pools as (users x devices-per-user) + IoT + guest peak, add a documented growth headroom, and align lease time with the expected dwell/churn; state the assumption explicitly in the design.
Designing WAN/branch connectivity without stating the traffic-flow and availability requirements (which flows are local vs. centralized, what SLA/RTO the branch needs), then picking a single transport and calling it resilient.
Candidates jump to a technology (MPLS vs. broadband vs. LTE/5G) before establishing the requirement, and equate 'two links' with resilience without checking diverse paths, power, or failover behavior.
What to do instead
Write the flow matrix (local breakout vs. backhauled), required availability and failover time, then select transports and a routing/failover mechanism (e.g., policy-based forwarding, dynamic routing) that satisfies it; verify path diversity and branch power/UPS assumptions.
Designing branch or campus security as a perimeter-only model, leaving inter-VLAN and guest-to-internal traffic unfiltered, and treating 'the firewall is at HQ' as sufficient for local branch traffic.
Candidates inherit a castle-and-moat mental model and miss that local breakout at a branch or flat internal routing bypasses the central enforcement point entirely.
What to do instead
Place enforcement where traffic actually crosses trust boundaries: define intra-campus role-to-role policy, branch-local firewall/UTM for breakout traffic, and state which flows are inspected centrally vs. locally.
Proposing network management and monitoring as a list of features ('we will use SNMP and syslog') without specifying what is measured, thresholds/alerting, retention, and how the data feeds capacity or fault response.
Candidates treat monitoring as a checkbox rather than a design element, so they cannot answer questions about how the design detects or diagnoses a failure.
What to do instead
For each layer, name the telemetry (interface/utilization, RF metrics, client experience, device health), the collection method and interval, the alert thresholds, and the operational response; tie RF and capacity telemetry back to the design assumptions.
Presenting a design as a final diagram without recording the requirements, assumptions, constraints, and rejected alternatives that produced it, so the reasoning cannot be defended when a scenario changes.
Candidates optimize for 'the right picture' and skip the methodology artifacts the exam rewards: traceability from requirement to design decision.
What to do instead
Structure every design answer as requirements -> assumptions/constraints -> options considered -> decision with justification -> validation plan; explicitly flag assumptions that, if wrong, would change the design.
Ignoring the management-plane and out-of-band design: no dedicated management VLAN/network, management reachability dependent on the same links being designed, and no plan for device onboarding, firmware, or configuration backup.
Candidates focus on data-plane forwarding and forget that the design must remain manageable during outages and at scale, and that management traffic itself needs segmentation and security.
What to do instead
Include a dedicated management network/VLAN with defined access paths and role restrictions, confirm management reachability survives data-plane failures where required, and specify onboarding, image management, and config backup as part of the design.