F5-302 common mistakes
F5-302 · Understand the traps and how to avoid them.
Treating a virtual server's destination address and port as the only matching criterion, so a wildcard or network virtual server is expected to catch traffic that actually lands on a more specific listener.
Candidates memorize the idea of 'most specific match wins' but never work through how F5 builds the listener list and orders matches by address, then port, then protocol. When a test scenario has both 0.0.0.0:443 and 10.1.1.5:443, they pick the wildcard and get the wrong pool.
What to do instead
Draw the listener table for every scenario: enumerate each virtual server's address/port/protocol, mark which are exact versus wildcard, and state the precedence rule explicitly (exact address beats wildcard, exact port beats wildcard, protocol must match). Practice with three or four overlapping virtual servers until the ordering is automatic.
Assuming a pool member marked down by a monitor will still receive traffic as long as the pool has no other members, or that a single failed monitor takes the whole pool offline.
The interaction between pool-level availability, member state, and the 'action on service down' setting is easy to read but hard to reason about. Candidates conflate member availability with virtual-server availability and forget the fallback behavior configured on the pool.
What to do instead
Learn the state matrix: member up/down, pool available/degraded/offline, and the pool's action-on-service-down options (none, reboot, drop, reselect, failover). Walk through a two-member pool with one monitor failing and predict exactly where the connection goes before checking the answer.
Choosing a load-balancing method by name rather than by its actual algorithm, for example expecting least connections to account for member capacity or expecting observed-member to behave like round robin.
Most methods sound self-explanatory, so candidates skip the details: least connections counts connections but not weight by default, observed-member uses a performance score that decays, and predictive-member projects trends. The nuances only surface in questions with uneven member weights.
What to do instead
Build a one-line definition plus a worked example for each method (round robin, ratio, least connections, observed, predictive, fastest, least sessions, hash, priority). For each, note whether member weight changes the outcome and what happens when a member goes down mid-connection.
Configuring a client SSL profile and a server SSL profile but losing track of which side terminates encryption, then mispredicting whether the pool sees plaintext or ciphertext.
SSL offload, re-encryption, and passthrough all use the same profile objects, and the difference is purely where each profile is attached. Candidates memorize profile names without mapping them to the traffic flow.
What to do instead
For every SSL scenario, write the flow as client -> [client SSL profile] -> virtual server -> [server SSL profile] -> pool member, and mark where the bytes are encrypted. Then state the three modes (offload, re-encrypt, passthrough) in terms of which profiles exist.
Assuming a security policy or iRule will block a request just because it is attached somewhere in the configuration, without checking attachment point and evaluation order.
Security features can live on the virtual server, on a profile, or in an iRule, and they fire at different points in the request lifecycle. Candidates who only remember 'the policy exists' pick the wrong outcome when a later event overrides an earlier one.
What to do instead
Map each security control to its enforcement point (L4 before payload inspection, L7 after request headers are parsed, response-side after the server replies). For any 'will this be blocked' question, trace the event order and identify the first control that can act.
Treating an access policy as a simple allow/deny list and forgetting that session variables, per-request policy, and ending actions determine what the user actually receives.
APM flows are visual and branching, so candidates skim the diagram logic and assume a successful authentication means the resource is reachable. They miss that a branch can end in a deny or a redirect even after credentials succeed.
What to do instead
For each access policy, identify every ending action (allow, deny, redirect, and their session variable effects) and the conditions that reach them. Practice predicting the outcome for a user who passes authentication but fails an authorization or posture check.
Confusing GTM-wide availability with LTM virtual-server availability, so a wide IP is expected to return an answer even when every pool member behind it is down.
GTM health monitors, LTM monitors, and the dependency between them form a chain. Candidates learn each piece separately and then misjudge what happens when the LTM side fails but the GTM monitor still passes, or vice versa.
What to do instead
Draw the dependency chain: wide IP -> GTM pool -> GTM pool member (which points at an LTM virtual server) -> LTM pool -> LTM member. For each link, state which monitor governs it and what the client sees when that link fails.
Assuming DNS load balancing is deterministic, then being surprised when the same query returns different answers or when a cached answer outlives a topology change.
Load-balancing methods at the DNS layer (round robin, ratio, topology, global availability) plus TTL and resolver caching mean the client's view lags the configuration. Candidates reason about the server state, not the cached state.
What to do instead
For each GTM method, state the selection rule and then add the caching layer: what TTL is returned, who caches it, and how long a stale answer persists. Practice questions where a pool member goes down and you must say when clients stop receiving its address.
Reading a single log line or dashboard counter as proof of root cause, for example concluding a pool is broken because connection counts dropped, without checking whether requests were simply redirected or rejected earlier.
Analytics views aggregate at different layers, and a drop in one counter often reflects a change upstream rather than a fault. Candidates anchor on the first number they see and stop investigating.
What to do instead
Adopt a fixed triage order: virtual server stats, then pool and member stats, then profile or policy logs, then the client-side symptom. For each counter, write what an increase and a decrease could mean before drawing a conclusion.
Troubleshooting from the top down, changing pool members or restarting services before confirming that the client's packet even reaches the virtual server.
Symptom location and fault location differ: a timeout can originate at the client, the network path, the virtual server, the pool member, or the server itself. Candidates who start at the pool waste time on healthy components.
What to do instead
Use a layered checklist: does the client resolve and connect, does the virtual server show the connection, does a member get selected, does the member respond. Move one layer at a time and only change configuration after the failing layer is identified.