F5-303 common mistakes
F5-303 · Understand the traps and how to avoid them.
Treating profiles as independent toggles and forgetting that the client-side TCP, HTTP, and SSL profiles are inherited from the parent virtual server when a child virtual server does not define its own.
Candidates memorise the list of profile types but never learn the inheritance and precedence rules, so they assume a profile set on the parent automatically applies on the child or, conversely, that the child must always redefine everything.
What to do instead
Learn the rule that a child virtual server inherits the parent's profiles unless it explicitly overrides them, and that a profile attached to the virtual server takes precedence over the same profile type attached at a lower level. Practise by tracing which HTTP profile is actually in effect for a child virtual server after an override, and note that some settings such as SNAT and pool selection follow different inheritance behaviour than profiles.
Confusing the roles of a pool, a pool member, a node, and a virtual server when reading a configuration or predicting where traffic goes.
The object model is hierarchical and the GUI hides the node layer, so candidates conflate a node (an IP address) with a pool member (an IP address plus a port) and then misread monitor associations and health status.
What to do instead
Draw the hierarchy explicitly: virtual server points to a pool, pool contains pool members, each pool member references a node. Remember that a node monitor marks the whole address down while a member monitor marks only that address-port pair down, and that a node marked down by a node monitor takes all its members out of service. Build a small configuration in a lab and inspect it to confirm which object owns which monitor.
Assuming a load-balancing method distributes connections evenly rather than by the metric it actually uses, for example expecting round robin behaviour from least connections or predicting priority-group behaviour incorrectly.
Method names sound intuitive, and candidates rarely test how each method behaves when members have different capacities, when a member is marked down, or when priority groups are configured.
What to do instead
Learn what each method actually measures: round robin cycles through available members, least connections picks the member with the fewest current connections, observed member uses a composite score, and ratio methods weight by configured ratio. Priority groups restrict traffic to the highest-priority group that has an available member. Verify behaviour in a lab by marking a member down and observing which member receives the next connection.
Diagnosing a failed TLS handshake by changing cipher strings at random instead of checking whether the client and server share a common protocol version, cipher, and certificate chain.
Cipher configuration is dense and candidates skip the fundamentals of how the ClientHello and ServerHello negotiate, so they cannot tell a protocol mismatch from a cipher mismatch from an untrusted chain.
What to do instead
Work through the handshake in order: negotiated TLS version, then cipher suite compatibility, then certificate validity including intermediate chain, then SNI-based selection if multiple client SSL profiles exist. Use the profile's cipher and protocol settings plus client-side test tools to confirm which step fails before changing configuration, and remember that a client SSL profile terminates TLS on the BIG-IP while a server SSL profile re-encrypts to the pool.
Treating a negative security policy as a permissive default and being surprised that a request the policy does not explicitly allow is blocked, or conversely assuming the default policy blocks everything.
Candidates learn that policies can be positive or negative but do not internalise that a negative security policy blocks by default and requires explicit allow entries, while a positive policy allows by default and requires explicit block entries.
What to do instead
State the default action for each policy type before answering: negative security policy denies by default, positive security policy allows by default. Then check whether the specific attack signature, URL, parameter, or method in the scenario is explicitly permitted or denied and whether the enforcement mode is blocking or transparent. Confirm by reading the policy's default action and the matched entity's action rather than guessing.
Blaming the WAF for a blocked request without checking whether the request was flagged by a signature, a violation, or a learning suggestion, and without checking the enforcement mode.
All blocking appears the same from the client side, and candidates jump to disabling the policy instead of reading the request's violation details and the enforcement mode that determined the outcome.
What to do instead
Check the enforcement mode first: transparent mode logs without blocking, blocking mode enforces. Then identify which entity fired, whether it was a signature, a parameter violation, a URL violation, or a disallowed method or file type, and whether the request was staged. Only after identifying the specific violation should you consider a policy exception or a signature disabled, and prefer a targeted exception over disabling the policy.
Using an iControl REST call with the wrong authentication method, wrong Content-Type, or the wrong collection versus resource URL and then concluding the API is broken.
Candidates memorise endpoint fragments but not the request envelope, so they send form-encoded bodies, omit the JSON content type, or POST to a collection URL when they meant to modify an existing object.
What to do instead
Standardise the request pattern: authenticate to the token endpoint and use the returned token in the header, send Content-Type application/json, use GET on a collection to list and on a specific resource to read, use POST to a collection to create, and use PUT or PATCH on a specific resource to modify. Verify the exact URL by reading the object's selfLink in a GET response rather than constructing it from memory.
Writing an automation script that hard-codes object names and ordering and then fails on a second run because objects already exist or dependencies are created out of order.
Candidates focus on getting one successful run and do not consider idempotency or dependency order, which is exactly what breaks in repeated or partial deployments.
What to do instead
Design for repeatability: check whether an object exists before creating it, use PUT or PATCH to converge existing objects, and create dependencies in order, for example nodes and monitors before pool members, pools before virtual servers, and profiles before the virtual servers that reference them. Test by running the automation twice against the same target and confirming the second run makes no unintended changes.
Reading a single monitor status and concluding a pool member is healthy or unhealthy without checking which monitors are assigned and whether the monitor is a node monitor or a pool member monitor.
The status display aggregates results, and candidates do not trace which monitor produced the down state, so they troubleshoot the wrong layer or the wrong object.
What to do instead
Trace the monitor chain: identify every monitor assigned to the pool member and to its node, check each monitor's interval, timeout, and send and receive strings, and determine which one is failing. Remember that a node monitor failure takes the whole node down regardless of member-level monitors. Confirm with a direct probe from the BIG-IP to the member's address and port using the monitor's expected exchange.
Treating a persistence issue as a load-balancing issue and changing the load-balancing method when the real problem is a persistence profile that does not match the application's session mechanism.
Both problems look like users landing on the wrong server, and candidates rarely check whether the persistence profile is source-address based while clients sit behind a NAT or proxy, or cookie-based while the application rewrites cookies.
What to do instead
Check the persistence profile before touching the load-balancing method: confirm the persistence type matches how the application tracks sessions, confirm the persistence entry has not timed out, and check whether a source-address persistence profile is collapsing many clients behind one proxy address onto a single member. Test by observing persistence entries and their expiry, and consider cookie persistence or an iRule-based persistence key when the client address is not a reliable identifier.