Aruba Architect Expert (Written) common mistakes
Aruba Architect Expert (Written) · Understand the traps and how to avoid them.
Answering design-scenario questions by naming a single product or feature instead of stating the requirement-to-design mapping (business driver, constraints, chosen architecture, validation criteria).
Candidates study feature lists and CLI, so they pattern-match the technology keyword in the stem and stop there; the expert-level stems reward the reasoning chain, not the noun.
What to do instead
Before answering, write the driver, the binding constraint, and the trade-off in one line each; then pick the option that reflects that full chain rather than the most familiar product name.
Treating the design methodology as a fixed sequence of phases and ignoring the iteration and validation loops (requirements re-validation, pilot/validation before rollout, design sign-off gates).
Linear memorization of phase names feels sufficient, but scenario questions ask what to do when a requirement changes mid-design or validation fails.
What to do instead
Practice describing what artifact each phase produces and what triggers a return to an earlier phase; answer with the loop, not just the next phase name.
Sizing campus wireless from client count or AP count alone, without deriving device density, per-client throughput and airtime budget, and then checking the resulting channel plan and power settings.
RF math is tedious and candidates default to a rule-of-thumb AP-per-area figure that ignores high-density, voice, or location-services requirements embedded in the stem.
What to do instead
For each campus WLAN stem, compute required throughput per client, multiply by clients per AP, check airtime and channel reuse, then confirm the design still meets coverage and roaming constraints.
Choosing a campus or branch topology and control-plane model (collapsed core vs. spine-leaf, centralized vs. distributed gateway, controller-based vs. controller-less) without tying it to the stated scale, failure-domain, and operational-skill constraints.
Candidates pick the model they know best; the exam instead tests whether the chosen model survives the stated failure scenario and the customer's operational capability.
What to do instead
For each topology question, list the failure domain and the operations team's skill level from the stem, then eliminate any model that violates either before comparing the rest.
Designing data center and WAN/edge solutions without explicitly addressing oversubscription ratios, east-west vs. north-south traffic, and edge redundancy/failover behavior.
Candidates focus on protocol selection (EVPN, VXLAN, routing) and skip the capacity and failure math that the scenario questions actually probe.
What to do instead
For every DC/WAN stem, state the expected traffic pattern, the acceptable oversubscription at each tier, and the failover path with its post-failure capacity; choose the design that satisfies all three.
Treating segmentation as VLANs only, and failing to map role-based policy consistently across wired, wireless, and WAN enforcement points (including how identity and device posture feed the policy).
VLAN-centric thinking is deeply ingrained and candidates miss that the exam asks about end-to-end policy consistency and the identity source that drives it.
What to do instead
For each segmentation stem, trace one user role from authentication through policy enforcement on every access type, and verify the same role gets the same policy everywhere.
Answering security-architecture questions with a single control (e.g., 802.1X alone) when the scenario requires defense in depth: authentication, posture, encryption, monitoring, and incident response as a layered set.
Candidates equate 'secure design' with the most prominent feature in the domain and forget the complementary controls the scenario implicitly requires.
What to do instead
For each security stem, list the threat in the scenario, then map at least one preventive, one detective, and one responsive control; pick the option that covers all three layers.
Confusing automation, orchestration, and assurance APIs, and writing answers that call the wrong interface or assume idempotency and error handling that the described workflow does not provide.
Candidates memorize API names without understanding which layer owns state, so they misassign responsibility between the controller, the orchestrator, and the monitoring system.
What to do instead
For each automation stem, identify who owns desired state, who reconciles drift, and who reports compliance; then match the API to that role and include failure/retry behavior in the answer.
Designing monitoring and analytics around dashboards and alerts only, without defining the baseline, the KPI thresholds, the data retention, and the action each alert triggers.
Candidates treat assurance as a visualization problem and miss that the exam tests closed-loop operations: detect, diagnose, act, and verify.
What to do instead
For each assurance stem, specify the baseline source, the threshold and its justification, the owner and action for each alert, and how the fix will be verified.
Planning migrations and lifecycle transitions as a cutover event, ignoring coexistence, rollback criteria, licensing/support transitions, and the operational runbook for the transition period.
Candidates focus on the target state and skip the transition state, which is where the scenario questions concentrate risk.
What to do instead
For each migration stem, describe the coexistence period, the rollback trigger and procedure, the licensing/support change, and the success criteria for each stage before selecting an answer.