ACE Professional common mistakes
ACE Professional · Understand the traps and how to avoid them.
Treating a transit gateway or peering connection as a single flat broadcast domain and applying one route table to every attachment, instead of designing separate route tables per segment and associating or propagating attachments explicitly.
Candidates carry over on-premises VLAN thinking where a routed core is implicitly reachable from everywhere, and they assume connectivity is automatic once an attachment exists rather than being the product of association and propagation decisions.
What to do instead
For every scenario, draw the attachment-to-route-table mapping before answering: state which attachments are associated with which table, which are propagated, and where blackholing occurs. Practise predicting reachability by walking the longest-prefix match through each table rather than assuming a shared table.
Assuming overlapping address space between two connected networks will simply route, rather than recognizing that overlapping CIDRs require NAT, a private connectivity intermediary, or re-addressing.
Lab environments rarely use overlapping ranges, so candidates never see the failure and default to 'add a route and it works' reasoning.
What to do instead
Memorize the overlap decision tree: if CIDRs overlap, plain routing and peering cannot work; choose address translation at the boundary, a brokered private connection, or renumbering. When a question mentions two private ranges in the same RFC1918 block, check for overlap before evaluating any routing answer.
Confusing the control plane of a routing protocol with its data plane, answering that a session being up means traffic is flowing, and missing that a route was learned but not installed or not preferred.
The exam phrases questions around session state and adjacency, which are visible and reassuring, while the actual failure is usually in route selection, administrative distance, or filtering.
What to do instead
For any routing question, separate three checks: is the adjacency or session established, was the prefix received and accepted by policy, and was it installed and selected in the forwarding table. Answer only after identifying which of the three is failing, and practise reading a routing table to spot a rejected or less-preferred path.
Mixing redistribution boundaries without controlling metrics or route tags, producing feedback loops and suboptimal paths, and then answering that redistribution alone solves reachability between two routing domains.
Redistribution is taught as a one-line fix, so candidates underestimate the need for mutual redistribution safeguards such as tags, filters, and seed metrics.
What to do instead
Whenever redistribution appears, require three elements in the answer: a seed or default metric, a filter or tag to prevent re-entry, and a stated preference between the two domains. Rehearse a two-point mutual redistribution design and be able to explain how a tag prevents a route from being re-learned.
Designing a campus workspace for a single user group with uniform policy, ignoring device-type segmentation, onboarding of unmanaged endpoints, and the difference between wired and wireless policy enforcement points.
Candidates focus on the authentication mechanism (certificate versus credentials) and skip the policy architecture, so they propose one SSID or one VLAN for everything and then cannot explain guest or IoT isolation.
What to do instead
For each campus scenario, produce a matrix of user or device class against access method against policy enforcement point, and state where segmentation is applied (SSID-to-VLAN mapping, group-based policy, or fabric edge). Ensure guest, contractor, IoT, and corporate classes each have a named path and an enforcement location.
Assuming a wireless client's roaming behaviour is controlled by the infrastructure, and answering that an access point decides when a client roams, rather than recognizing that the client device makes the roaming decision.
Controller and fabric documentation emphasizes infrastructure coordination, which leads candidates to overstate infrastructure control over the client.
What to do instead
State explicitly that the client initiates roaming and the infrastructure assists through better signal, faster key caching, and consistent policy across access points. When a question asks why a client sticks to a distant access point, consider client aggressiveness settings and sticky-client mitigation rather than assuming a configuration error on the controller.
Selecting a telemetry method by name rather than by what it can actually answer, for example choosing streaming telemetry for a historical trend question or flow records for a per-interface counter question.
Vendors market several telemetry mechanisms together, and candidates memorize labels without mapping each to its data model, granularity, and retention characteristics.
What to do instead
Build a comparison table with columns for data type (counters, flows, events, configuration), push versus pull, granularity, and typical retention, then answer by matching the question's required data type to the mechanism. If a question asks for correlation across time, prefer a method that retains history over one that only streams live state.
Treating assurance or analytics dashboards as ground truth and skipping validation of the underlying data source, sampling rate, and clock synchronization before drawing a conclusion.
Dashboards present confident-looking scores, so candidates accept a poor health score or a latency spike at face value instead of asking whether the measurement is complete or time-aligned.
What to do instead
Before concluding from any observability output, verify three things: the collection coverage (are all relevant devices exporting), the sampling or aggregation interval, and time synchronization across sources. In scenario questions, prefer answers that confirm data completeness before remediation over answers that immediately change configuration.
Planning a cloud network only for the happy path and omitting egress design, inspection insertion, and failure-domain behaviour, then selecting an answer that provides connectivity but no defined path for outbound or inspected traffic.
Candidates equate connectivity with correctness and do not habitually ask where traffic leaves the environment, where it is inspected, and what happens when an availability zone or appliance fails.
What to do instead
For every cloud networking design question, force four statements: inbound path, outbound path, inspection point, and behaviour under loss of one component. Reject any option that cannot name where traffic exits and where policy is enforced, and prefer designs with a symmetric return path.
Memorizing command output formats and configuration syntax instead of the decision criteria, so when a question presents an unfamiliar platform or a renamed feature the candidate cannot transfer the concept.
Hands-on practice tends to be platform-specific, and candidates rehearse keystrokes rather than the underlying model, which the exam deliberately abstracts.
What to do instead
Convert each lab exercise into a one-line principle: what problem the feature solves, what it requires, and how failure appears. Test yourself by describing the design in platform-neutral terms first, then mapping it to a specific implementation, so unfamiliar terminology does not block recognition of the concept.