Free F5CAB3 Practice Test Questions and Answers (2026) Practice Questions

The VLAN Fail-safe feature is a high-availability mechanism that monitors a VLAN for network traffic. If no traffic is detected on a failsafe-enabled VLAN for a specified timeout period, the BIG-IP system assumes a network failure has occurred on that link and initiates a failover to its peer device. When a new VLAN is created and Fail-safe is enabled on it, but no devices are communicating on it yet, the failsafe timer will expire, triggering an unintended failover. To prevent this, the administrator should disable Fail-safe on the new VLAN until it is actively passing traffic.

A. Auto Last Hop is a routing feature that ensures return packets use the same MAC address they arrived from, unrelated to HA failover.

B. Source Check is a security feature on a VLAN to prevent IP spoofing and is not a failover trigger.

D. A Customer Tag is simply a user-defined metadata tag for a VLAN and has no impact on system operations or failover.

- F5 Networks. (2021). BIG-IP Device Service Clustering: Administration. BIG-IP 16.1. Chapter 5: High Availability Features. Section: Understanding Fail-safe. "VLAN failsafe is a feature where the BIG-IP system monitors for traffic on a specified VLAN. If the system detects a loss of traffic... it initiates a failover."

- F5 Support. (2022). K13297: Overview of VLAN failsafe (11.x - 17.x). AskF5. "If the BIG-IP system does not receive any packets on the VLAN for half of the configured VLAN failsafe timeout value, the system may initiate a failover."

- F5 Networks. (2021). BIG-IP TMOS: Routing Administration. BIG-IP 16.1. Chapter 1: VLANs and Trunks. Section: Configuring fail-safe for a VLAN. This section details the configuration and purpose of VLAN failsafe.

To handle encrypted traffic from users to the virtual server, a Client SSL profile is required. When multiple hostnames resolve to the same virtual server IP, the BIG-IP system must present the correct SSL certificate for the requested hostname. This is achieved using the Transport Layer Security (TLS) extension called Server Name Indication (SNI). Within the BIG-IP Client SSL profile, the "Server Name" setting is used to specify the hostname that corresponds to the certificate and key, enabling the system to serve the correct certificate based on the name provided by the client in the TLS handshake.

A. Client SSL, Client Name: "Client Name" is not a valid setting in a Client SSL profile for selecting a server certificate based on hostname.

B. Server SSL, Server Name: A Server SSL profile is used to re-encrypt traffic from the BIG-IP to the backend servers, not for the client-to-BIG-IP connection.

D. Server SSL, Client Name: This uses the incorrect profile type for the client-facing connection and an invalid setting for SNI.

- F5 Networks. (2021). BIG-IP LTM Local Traffic Manager: Implementations. Chapter 4: Implementing SSL/TLS, Section: Configuring the BIG-IP system to use SNI to secure traffic to multiple sites.

- F5 Knowledge Base. (2022). K13452: Configure a virtual server to serve multiple HTTPS sites using the TLS Server Name Indication feature. This article details the procedure, specifying the use of a Client SSL profile and configuring the "Server Name" field.

- F5 Networks. (2021). BIG-IP System: SSL Administration. Chapter: SSL Profiles, Section: Client SSL profiles, Subsection: Certificate and Key. This section describes the "Server Name" setting for SNI support.

The "Slow Ramp Time" setting on a pool is designed to prevent a newly available pool member (either one just added or one that has recovered from being down) from being overwhelmed. In a highly utilized pool, if Slow Ramp Time is 0 (the default), the load balancing method may immediately send a full share of traffic to the new member. This can overload the server's resources or application caches, causing failures. A non-zero value gradually increases the traffic sent to the new member over the specified time.

A. Availability Requirement: This setting determines when the entire pool is marked down; it does not affect how traffic is distributed to new members.

B. Allow SNAT: This is a setting on the virtual server, not the pool, and it controls source address translation.

C. Action On Service Down: This setting dictates how to handle existing connections when a member goes down, not how to treat a newly added member.

- F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, Version 16.1. Chapter 4: Pools, Section: Understanding slow ramp time. This section explains the feature's purpose.

- F5 Support. (2019). K7222: The Slow Ramp Time setting allows you to gradually ramp traffic to a pool member. F5 Knowledge Base. This article details the functionality and its importance in preventing service disruption.

To make a load-balancing decision based on the URI, the iRule must execute after the BIG-IP system has received the complete HTTP request from the client. The HTTPREQUEST event is triggered at this specific point in the traffic flow. Within this event, the iRule has access to all HTTP headers, including the host and the URI path, allowing it to parse the URI and direct the request to the appropriate pool or pool member using commands like pool or node .

A. The CLIENTACCEPTED event occurs when the TCP connection is established, before any HTTP data, including the URI, has been sent by the client.

B. The HTTPRESPONSE event occurs after the server has responded, which is too late to make a routing decision for the client's request.

D. The SERVERCONNECTED event triggers after a connection to a pool member is established, meaning the load-balancing decision has already been made.

1. F5 Networks. (n.d.). iRules 101 - #02 - Events. F5 DevCentral. Retrieved from https://community.f5.com/t5/technical-articles/irules-101-02-events/ta-p/278413. (See section on HTTPREQUEST).

2. F5 Networks. (n.d.). Mastering iRules: The F5 Synthesis of an HTTP Request. F5 DevCentral. Retrieved from https://community.f5.com/t5/technical-articles/mastering-irules-the-f5-synthesis-of-an-http-request/ta-p/280384. (This article details the event order and what data is available).

3. F5 Networks. (n.d.). HTTPREQUEST. F5 Cloud Docs iRules API. Retrieved from https://clouddocs.f5.com/api/irules/HTTPREQUEST.html.

The virtual server is configured to handle SSH traffic on port 22, which is a raw TCP protocol. The configuration incorrectly applies an HTTP profile (http). The BIG-IP system will attempt to parse the SSH protocol handshake as if it were HTTP traffic, which will fail and cause the connection to be reset. To resolve this, the HTTP profile, which is designed for Layer 7 HTTP traffic management, must be removed by setting it to 'None'. This allows the BIG-IP to process the traffic as generic TCP, which is appropriate for SSH.

A. Set Protocol to UDP: SSH is a TCP-based protocol; changing the virtual server's protocol to UDP would make it incompatible with SSH clients.

B. Set Source Address to 10.1.1.2: This would restrict access to a single source IP address and would not fix the underlying protocol mismatch issue.

C. Set Destination Address/Mask to 0.0.0.0/0: This would make the virtual server a wildcard forwarder, which is not the intent and does not solve the profile incompatibility.

F5 Networks. (2021). BIG-IP LTM Local Traffic Manager: Concepts, 16.1. "About virtual servers," Section: Profiles. The documentation explains that profiles add functionality for specific traffic types and that an incorrect profile type (like HTTP for non-HTTP traffic) can cause connections to fail.

F5 Knowledge Base. (2020). K14783: Overview of the HTTP profile. This article details the functions of the HTTP profile, which are specific to parsing and manipulating HTTP headers and content. Applying this to SSH, which lacks HTTP headers, will result in a protocol error.

The Source Address Affinity persistence profile, also known as sourceaddr, is the most suitable option for a fallback persistence profile. This method tracks sessions based on the client's source IP address. Since every IP packet contains a source IP, it provides a reliable, universal "catch-all" mechanism. If the primary persistence method (e.g., cookie or SSL) fails or is not applicable for a given connection, the BIG-IP system can revert to the source IP, ensuring the client's session is still maintained with the same pool member.

A. SSL persistence relies on the SSL Session ID, which is not always present or consistent, making it a poor choice for a universal fallback.

B. Hash persistence requires specific data within the request to create a hash, which may not be available, making it an unreliable fallback method.

C. Universal persistence is a highly customizable method based on iRules and is typically used as a primary, not a fallback, persistence method.

1. F5, Inc. (2021). BIG-IP Local Traffic Manager: Concepts, Version 16.1. "Managing persistence profiles," Chapter 13, "Persistence," Section: "Understanding persistence." The manual describes source address affinity as a simple and widely applicable method, making it a common choice for fallback.

2. F5, Inc. (2021). BIG-IP LTM Concepts Guide. "About fallback persistence." This section explicitly states, "A common profile to select for the fallback persistence profile is a source address affinity persistence profile."

Cookie persistence is the most appropriate method for HTTP traffic. The BIG-IP system inserts a cookie containing pool member information into the HTTP response. When the client makes a subsequent request, it includes this cookie, allowing the BIG-IP to read it and send the request to the same pool member. This method is highly reliable as it is not dependent on the client's source IP address, which can change due to network address translation (NAT) or proxy servers. It ensures session integrity for web applications by tracking the client's browser session directly.

A. Destination address persistence is used to direct traffic to the same pool member based on the destination IP, which is not suitable for typical load-balancing scenarios.

B. Hash persistence can be used, but it's less specific and reliable for HTTP than cookie persistence, especially when clients are behind a shared proxy.

C. SSL persistence uses the SSL/TLS session ID. It is only effective for the duration of a single SSL session and is not as robust as cookie persistence for HTTP applications.

1. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, Chapter 5: Persistence. F5 Cloud Docs. Retrieved from https://techdocs.f5.com/kb/en-us/products/big-ipltm/manuals/product/ltm-concepts-13-1-0/5.html. (See section: "Cookie persistence").

2. F5 Networks. (2021). K7786: Overview of BIG-IP LTM persistence profiles. F5 Support. Retrieved from https://support.f5.com/csp/article/K7786. (See section: "Cookie persistence").

The requirement is to monitor a specific web application's health on a node that hosts multiple applications. An HTTP monitor is an application-layer monitor that can be configured with a custom send string (e.g., GET /healthcheck.html HTTP/1.1\r\nHost: myapp.com\r\nConnection: Close\r\n\r\n) and a receive string (e.g., 200 OK). This verifies that the web server is not only listening on the port but is also able to process requests and return a valid response for that specific application. This ensures that only the pool member for the failed application is marked down.

A. UDP monitor: This is for UDP-based services, whereas web applications primarily use TCP.

B. ICMP + TCP monitor: This combination only verifies that the node is reachable (ICMP) and the port is open (TCP), not that the application itself is functioning correctly.

D. TCP monitor: This only confirms that a TCP handshake can be completed, which does not guarantee the web application is healthy or serving correct content.

- F5, Inc. (2021). BIG-IP Local Traffic Manager: Monitors, Chapter 3: HTTP Monitors. F5 Networks. The manual states, "An HTTP monitor checks the status of a web page... You can also specify a receive string that the monitor must find in the server's response." This demonstrates its ability to perform application-specific checks.

- F5 Knowledge Center. (2022). K2167: Constructing HTTP requests for use with the HTTP or HTTPS application health monitor. AskF5. This guide provides detailed instructions on creating custom send strings to validate specific application responses, confirming the suitability for this scenario.

The question states that SNAT Automap is configured, which means the backend servers see the BIG-IP's IP address as the source of the connection, not the original client's IP. For HTTP/S applications, the standard method to pass the original client IP to the backend is by inserting it into an HTTP header. The X-Forwarded-For (XFF) header is the de facto standard for this purpose. This functionality is enabled within the HTTP profile that is applied to the virtual server.

A. Performance (HTTP) Virtual Server: This is a fast, optimized virtual server type, but it does not inherently solve the client IP visibility issue when SNAT is used.

C. HTTP Transparent profile: There is no standard profile with this name. True network transparency requires disabling SNAT, which contradicts the question's premise.

D. SNAT pool using client IP: A SNAT pool is a list of BIG-IP-owned IP addresses to be used for translation; it cannot be configured to use the dynamic client IP.

- F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, Version 16.1. Chapter 10: HTTP Profiles, Section: Configuring the HTTP profile. This section describes the "Insert X-Forwarded-For" option.

- F5 Support. (2022). K4816: Using the X-Forwarded-For HTTP header to preserve the original client IP address for traffic translated by a SNAT. F5 Knowledge Base. This article provides a comprehensive guide on the topic.

The pool contains members representing four distinct services: FTP (21), SSH (22), HTTP (80), and HTTPS (443). To accurately determine the health of a server providing all these services, a health monitor should be configured for each service. The "Availability Requirement" setting of "All" ensures that the BIG-IP system marks a node as available only if all associated health monitors report success. This prevents traffic from being sent to a server that may have one or more critical services down, thereby ensuring the most accurate availability status for the entire application stack on that server.

B. HTTP, HTTPS, FTP, and ICMP...: ICMP only checks for network-level reachability (a ping response) and does not verify if the actual application services are running.

C. ...Availability Requirement of at least one health monitor: This setting would mark a server as available even if only one of its four services is running, which is not an accurate reflection of its overall health.

F5 Networks. (2021). BIG-IP LTM Local Traffic Manager: Monitors. "Monitoring Pool Member and Node Availability," Section: Using the All and At Least settings. The documentation states, "When you set the Availability Requirement to All, you ensure that the system can mark a node as up only when all of the monitors associated with that node return a status of up."

F5 Knowledge Base. (2019). K12531: Overview of BIG-IP health monitoring. This article explains that multiple monitors can be applied to a pool and the Availability Requirement setting dictates the logic for marking the resource up or down.