- Understanding the Legacy ACDX Content Areas
- Translating Customer Requirements Into Designs
- Wired and Wireless Campus Architecture
- RF Coverage and Capacity Planning
- High-Density WLAN Design
- Network Resilience
- Access-Security Requirements
- Branch Connectivity
- Design Documentation, BOMs, and Defending Tradeoffs
- Question Style and Case Study Format
- Mapping Content Areas to a Study Calendar
- ACDX vs. the Campus Access Architect Pathway
- Frequently Asked Questions
- ACDX content centers on translating stated customer requirements into defensible wired and wireless campus designs.
- Heavy emphasis falls on RF coverage/capacity math and high-density WLAN planning, not just device configuration.
- Design documentation, bills of materials, and tradeoff justification are treated as core skills, not paperwork afterthoughts.
- HPE's current catalog offers the separate Campus Access Architect track - don't confuse its blueprint with legacy ACDX content.
Understanding the Legacy ACDX Content Areas
The Aruba Certified Design Expert credential, issued through Hewlett Packard Enterprise / Aruba's certification program, was built around one central idea: a network designer's job is not to memorize CLI syntax, it's to turn a customer's business requirements into a network architecture that actually holds up under real-world constraints. That premise shapes every content area candidates historically studied for, and it's still the mental model worth using if you're approaching ACDX-style design questions today.
Because ACDX sits at the "expert" tier, the content areas are less about isolated facts and more about judgment calls - choosing between two valid designs, justifying a coverage model, or explaining why a particular resilience approach fits a specific building layout. This guide breaks the content into the eight areas that consistently show up in Aruba design-track material, and pairs each with the kind of thinking you need to practice. For a broader walkthrough of preparation strategy, see the ACDX Study Guide 2026.
Translating Customer Requirements Into Designs
Requirements-to-Design Translation
Every ACDX-style scenario begins with a narrative: a customer describes their building, their users, their pain points, and sometimes their budget. Your first job is extracting the actual technical requirements from that narrative before you touch a design decision.
- Separating stated requirements from unstated assumptions
- Identifying constraints that eliminate certain design options outright (budget caps, existing cabling, regulatory limits)
- Recognizing when a requirement conflicts with another (e.g., "minimize cost" vs. "support 99.99% uptime")
- Documenting assumptions explicitly so a reviewer can see your reasoning
This is the skill most candidates underestimate. It's tempting to jump straight to picking access points or switch models, but expert-level design questions reward candidates who can show their reasoning chain from "customer said X" to "therefore I designed Y." Practice writing out assumptions in plain language before sketching any topology.
Wired and Wireless Campus Architecture
Campus Architecture Fundamentals
This area covers how wired and wireless layers interact across a campus - core/aggregation/access hierarchies, uplink sizing, VLAN segmentation strategy, and where wireless controllers or gateways fit relative to the wired backbone.
- Matching topology choices to building size and floor count
- Justifying collapsed-core vs. multi-tier designs for a given campus
- Aligning wireless architecture decisions with existing wired infrastructure limitations
- Planning for future expansion without over-provisioning today
A common scenario pattern gives you a floor plan, a rough headcount, and a growth projection, then asks you to defend a topology choice against at least one alternative. The examiner (or in self-study, you) should be able to poke a hole in a weak justification - so practice building your case, not just your diagram.
RF Coverage and Capacity Planning
RF Coverage and Capacity
Coverage and capacity are treated as distinct problems in expert-level design work, and confusing them is one of the fastest ways to fail a scenario question. Coverage asks "can a device hear a signal here?" Capacity asks "can this AP serve every device that will actually connect here?"
- Estimating AP density from device counts, not just square footage
- Accounting for material types, ceiling height, and interference sources in coverage models
- Recognizing when a coverage-only design will fail under real capacity load
- Balancing channel planning against co-channel interference in dense deployments
Key Takeaway
When a scenario gives you both a square-footage figure and a device-per-user ratio, expect the question to test whether you design for capacity, coverage, or both - don't default to whichever number appears first.
High-Density WLAN Design
High-Density Wireless Environments
Auditoriums, stadiums, trading floors, and lecture halls each push wireless design past standard office assumptions. This content area asks you to adjust standard planning rules for environments where user density per AP is far above typical campus norms.
- Reducing cell size intentionally to raise AP density in packed spaces
- Choosing antenna types suited to high-density seating or open-floor layouts
- Managing client load balancing and band steering in saturated environments
- Anticipating device mix (laptops, phones, IoT) and its effect on airtime consumption
High-density scenarios often include a stated event type (conference, sporting event, classroom) as a clue about expected device behavior. Reading that clue correctly is part of the skill being tested - treat it the same way you'd treat a constraint in the requirements section above.
Network Resilience
Resilience and Redundancy
Resilience questions test whether your design survives a single point of failure - a downed link, a failed switch, a controller outage - without violating the customer's stated uptime expectations.
- Identifying single points of failure in a proposed topology
- Choosing redundancy mechanisms appropriate to the criticality level stated in the scenario
- Balancing resilience investment against budget constraints from the requirements section
- Explaining failover behavior in plain terms a non-technical stakeholder could follow
Resilience is rarely tested in isolation - it's layered onto an architecture question you've already answered. Expect scenarios where you have to revisit an earlier design decision once a new resilience requirement is introduced.
Access-Security Requirements
Access Security
This area covers how users, devices, and guests are authenticated and authorized onto the network, and how that policy layer is reflected in the physical and logical design.
- Matching authentication methods to device and user categories described in the scenario
- Designing role-based access control that maps to organizational structure
- Segmenting guest, IoT, and corporate traffic appropriately
- Accounting for compliance or regulatory constraints mentioned in the customer narrative
Security requirements frequently interact with the branch connectivity and resilience areas below - a single scenario may ask you to secure access at a branch site while also justifying the WAN link resilience that supports it.
Branch Connectivity
Branch and Remote-Site Design
Branch scenarios shrink the scale but raise the constraint density - smaller budgets, limited on-site IT support, and dependency on WAN links back to a central site or cloud-managed controller.
- Sizing branch designs appropriately for limited user counts and simplified support models
- Planning WAN link redundancy for sites with no local IT staff
- Extending centralized policy and management to distributed locations
- Justifying centralized vs. local control decisions for a given branch profile
Design Documentation, BOMs, and Defending Tradeoffs
Documentation and Tradeoff Defense
Expert-level design work isn't finished until it's communicated. This content area tests whether you can produce a bill of materials that matches your design decisions and defend the tradeoffs you made against a plausible alternative.
- Building a BOM that traces directly back to stated requirements and constraints
- Writing design documentation a customer or implementation team could actually follow
- Articulating why a rejected alternative was rejected, not just what was chosen
- Anticipating follow-up questions a stakeholder would raise about cost or complexity
This is where a lot of otherwise strong candidates lose points - a technically sound design with a sloppy or unjustified BOM reads as incomplete. Practicing this skill is covered in more depth in the ACDX Cheat Sheet 2026, which condenses the documentation checklist into a quick-reference format.
Question Style and Case Study Format
Rather than short factual recall questions, expert-level Aruba design material leans on extended case studies: a scenario states explicit requirements, constraints, and assumptions, sometimes with a diagram, and asks you to evaluate or produce a design against stated evaluation criteria. This format rewards candidates who can hold multiple constraints in mind simultaneously rather than optimizing for a single variable.
| Question Element | What It's Testing |
|---|---|
| Stated requirement | Whether you correctly identify what the customer actually needs |
| Stated constraint | Whether your design respects real-world limits (budget, cabling, staffing) |
| Stated assumption | Whether you notice gaps and document your own reasonable assumptions |
| Evaluation criteria | Whether your final design and BOM can be justified against a defined standard |
If you want a sense of how demanding this format feels in practice, the How Hard Is the ACDX Exam? breakdown walks through where candidates typically underestimate the workload.
Mapping Content Areas to a Study Calendar
A generic study calendar won't help much here, but a calendar built around the content areas above will. The idea isn't rigid time-blocking - it's sequencing so that foundational areas (requirements translation, architecture) are solid before you layer on the more math-heavy or scenario-dense areas (RF capacity, high-density WLAN, resilience).
Requirements Translation and Campus Architecture
- Practice extracting requirements/constraints from written scenarios
- Rehearse justifying topology choices against alternatives
RF Coverage, Capacity, and High-Density WLAN
- Work through AP density estimation exercises
- Contrast coverage-only vs. capacity-driven designs on the same floor plan
Resilience and Access Security
- Identify single points of failure in prior week's designs
- Layer role-based access policy onto existing architectures
Branch Connectivity, Documentation, and Full Case Studies
- Complete end-to-end scenarios covering branch design
- Produce full BOMs and written tradeoff justifications
This sequencing also mirrors how content areas compound on each other in real case studies - resilience decisions in week 3 will often force you to revisit architecture choices from week 1, which is intentional and worth practicing rather than avoiding.
ACDX vs. the Campus Access Architect Pathway
It's worth being precise here: HPE's current campus training catalog offers Designing HPE Aruba Networking Campus Access Solutions and Designing Advanced HPE Networking Campus Access Architect Solutions. The latter course prepares learners for the HPE Aruba Networking Certified Expert - Campus Access Architect credential - a distinct, present-day credential, not a rebranded ACDX. If you're mapping your own learning path forward from ACDX-style design fundamentals, that course catalog is the relevant onward step, but it should be evaluated on its own terms rather than treated as interchangeable with legacy ACDX content.
| Aspect | Legacy ACDX Focus | Campus Access Architect Pathway |
|---|---|---|
| Positioning | Historical Aruba design-expert credential and study material | Current HPE Aruba Networking Certified Expert track |
| Core Skill | Translating requirements into campus wired/wireless designs | Advanced campus access architecture per current HPE course design |
| Where to Learn It | Legacy design case studies and practice scenarios | Designing Advanced HPE Networking Campus Access Architect Solutions |
For candidates trying to understand eligibility and how these paths relate, the ACDX Requirements 2026 page walks through prerequisites in more detail, and Is the ACDX Certification Worth It? covers how this legacy credential fits into a broader career strategy.
Key Takeaway
Don't let course marketing blur the line - Campus Access Architect is a separate, current HPE credential with its own dedicated course, not a continuation labeled as ACDX.
To actually build fluency across these content areas, working through structured scenario practice on the main ACDX practice test platform is more useful than passive reading - you get repeated exposure to the requirements-constraints-assumptions format described above. Pair that with timed case-study drills from the practice test hub so the reasoning becomes automatic rather than something you have to reconstruct under pressure.
Frequently Asked Questions
Legacy ACDX design content spans eight practical areas: requirements translation, wired/wireless architecture, RF coverage and capacity, high-density WLAN planning, resilience, access security, branch connectivity, and documentation/BOM defense.
No. Campus Access Architect is a distinct, current HPE Aruba Networking Certified Expert credential with its own dedicated course. ACDX refers specifically to the legacy Aruba Certified Design Expert identity.
Design judgment. Scenarios present explicit requirements, constraints, and assumptions, then ask you to justify a design and its bill of materials rather than recall isolated facts.
RF coverage and capacity planning, along with documentation and BOM justification, are the areas where technically sound designs most often lose points due to weak reasoning or unclear tradeoff explanations.
Start with requirements translation and campus architecture fundamentals, then progress through the study calendar above before attempting full end-to-end case studies.