F5-304 common mistakes
F5-304 · Understand the traps and how to avoid them.
Treating a standard virtual server and a forwarding (IP) virtual server as interchangeable when planning how traffic reaches a pool, then being unable to explain why a wildcard destination or a non-HTTP protocol works on one design and not the other.
Candidates memorize that both types exist but never internalize that a standard virtual server matches on destination address and port and terminates/load-balances at L4-L7, whereas a forwarding virtual server passes packets through without NAT or pool selection unless configured otherwise. Exam items probe the consequence (source address preservation, return path, pool requirement) rather than the definition.
What to do instead
Build a comparison table with rows for listener match, default pool requirement, source address visibility to the server, and typical use case (HTTP app vs. routed/non-TCP traffic). For each row, write one sentence on what breaks if you choose the wrong type, then re-derive the table from memory before practicing questions.
Assuming a profile applied at the virtual server level always overrides the same profile type set on the pool or inherited from the parent, without checking which profile type follows which precedence rule.
Most profiles are virtual-server scoped and a pool-level profile of the same type can take effect for server-side traffic, but candidates generalize one rule to all profile types (SSL, HTTP, TCP, persistence) and mis-answer items about which setting actually wins. The mental shortcut 'most specific wins' is not universally true across profile families.
What to do instead
Learn the precedence model per profile family rather than as a single rule: identify which profiles are client-side, which are server-side, and which are inherited from a parent virtual server. For each family, state in one line where the effective setting comes from, and verify with a lab where a conflicting profile is set at two levels.
Confusing load-balancing methods that look similar on paper, such as least connections versus observed-member versus predictive-member, and picking an answer based only on the method name.
The names suggest a single behavior, but the actual algorithms differ in whether they use current connection counts, a dynamic ratio derived from observed performance, or a trend projection. Candidates who never worked through a numeric example cannot distinguish them under exam phrasing.
What to do instead
Work three small numeric scenarios by hand (three pool members with different connection counts and response times) and compute the next member chosen by least connections, observed-member, and predictive-member. Write the distinguishing input for each in one sentence and keep that sheet for review.
Designing a persistence strategy that pins a client to a member but forgetting the fallback behavior when the persisted member goes down, then answering as if the client is simply dropped or always re-balanced.
Persistence and health monitoring are studied as separate chapters, so candidates do not connect them. Exam items describe a member failure and ask what happens to an established persistence record; without knowing whether the persistence entry is honored, ignored, or remapped, the answer is a guess.
What to do instead
For each persistence type you study (source address, cookie, SSL session ID), write what happens in three cases: member healthy, member marked down, and persistence entry expired. Confirm the behavior in a lab by disabling a member mid-session and observing the client's next request.
Treating an iRule event as if it runs at every point in the connection and expecting a command valid in one event to work in another, or expecting a variable set in one event to be visible in a later event without storing it.
iRules are event-driven and each event exposes a different command set and a different scope for local variables. Candidates who read iRules as linear scripts mis-predict which event fires for a given traffic condition and where a value must be persisted.
What to do instead
Draw the request/response timeline (CLIENT_ACCEPTED, HTTP_REQUEST, LB_SELECTED, HTTP_RESPONSE, CLIENT_CLOSED) and annotate which commands and variables are legal at each point. Rewrite one small iRule so state is carried in a table or a profile-persisted variable, and note why the local-variable version fails.
Assuming a client certificate is validated simply because the Client SSL profile requests one, without accounting for the setting that controls whether the certificate is actually required and verified against a trust anchor.
The profile has separate controls for requesting a certificate, requiring it, and validating it against a CA bundle. Candidates collapse these into one concept and answer items about mutual TLS as if any request implies enforcement.
What to do instead
Map the Client SSL profile settings one by one: certificate request behavior, requirement, and the trust chain used for verification. State in one sentence what happens to a client presenting no certificate versus an untrusted certificate under each combination, and test both in a lab.
Mixing up the order in which access policy items execute and assuming an ending or a branch is reached regardless of the preceding item's outcome, so the predicted result of a multi-step policy is wrong.
Access policies are visual flows with branching, and candidates memorize individual agent types without tracing the path. Exam items give a scenario (successful authentication, failed authorization, group mismatch) and ask which ending is reached, which requires following the flow rather than recalling definitions.
What to do instead
Take one multi-item policy (logon, AD query, group check, decision) and trace four client scenarios end to end on paper, naming the exact ending for each. Then change one branch condition and re-trace to see how the ending shifts.
Answering a troubleshooting item by naming the first plausible cause instead of the diagnostic that would discriminate between causes, such as jumping to 'pool member is down' when the monitor is passing but the service is not listening.
Candidates study features forward (what a monitor does) but not backward (what evidence rules a cause out). Exam items reward choosing the check that separates two hypotheses, and a plausible-but-unverified cause looks attractive under time pressure.
What to do instead
For each common symptom (connection reset, 502-style error, intermittent timeout, one member receiving no traffic), list three candidate causes and the single command or log that distinguishes them. Practice stating 'I would check X because it separates A from B' before selecting an answer.
Reading a monitor's status as equivalent to application health, so a green pool member is assumed to be serving correct responses when the monitor only proves a shallow check succeeded.
Default monitors often test only a TCP handshake or a simple HTTP status. Candidates who do not distinguish L4 reachability from application-level correctness mis-diagnose scenarios where the app returns errors but the monitor stays green.
What to do instead
Categorize the monitors you use by depth (TCP connect, HTTP status, content match, custom script) and write what each one would miss. Then design a send/receive string that would catch a specific failure (for example, a login page returning an error body) and explain why the default would not.
Assuming a configuration change is active immediately after it is saved, without accounting for sync between devices in a device group or for the difference between saved and running state.
In multi-device deployments, a change made on one unit is not automatically present on its peers, and candidates who study single-device behavior answer items about HA pairs as if the change propagates instantly.
What to do instead
Write the sequence for a config change in a device group: make change, review pending changes, sync to peers, verify on the peer. For each step, name the failure symptom if it is skipped, and confirm the sync state display in a lab with two units.