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

The exhibit shows the node 10.1.20.11 is available (green circle), indicating it is reachable via ICMP. However, the pool member 10.1.20.11:80 is marked down (red diamond). This signifies that the service-specific health check on port 80 is failing. The httpmonitor is configured to expect a Receive String of "UP" in the server's response. The failure means the application on the server is not returning a response containing "UP", causing the monitor to mark the pool member as unavailable for traffic.

A. The node health monitor is responding successfully, as indicated by the green circle next to the node address in the user interface.

C. HTTP 1.1 is a standard and valid protocol for web application health monitors; its use is not the cause of the failure.

D. The BIG-IP device can reach the node, as confirmed by the "Available (Enabled)" status of the node itself. The issue is with the application service.

1. BIG-IP Local Traffic Management: Monitors, "About Monitors," Section: "Monitor status." This guide explains the different status icons (green circle for up, red diamond for down).

2. BIG-IP Local Traffic Management: Monitors, "HTTP," Section: "Receive String." This section describes how the Receive String is used to validate the health of the application response.

3. F5 Knowledge Base, K13397: "Overview of BIG-IP health monitoring," F5 Networks, Inc. Explains the distinction between node-level (ICMP) and service-level (pool member) monitoring.

The log messages indicate the BIG-IP system's Traffic Management Microkernel (TMM) has exceeded its high-water memory threshold, triggering the "Aggressive mode" of the connection sweeper. This is a protective mechanism to reclaim memory under heavy load. The second log line, "1 Connections killed," explicitly confirms that the system has started terminating (reaping) existing connections to free up memory resources. This action is a direct result of the TMM memory exhaustion.

B. The log explicitly states "1 Connections killed," not that all connections are dropped. The sweeper selectively reaps connections, typically starting with the oldest and idlest ones.

D. The log message specifies "(global memory)," which refers to TMM memory, not the host's swap memory. While related, they are distinct memory pools with different triggers.

- F5 Networks. (2021). BIG-IP TMM and system memory limits. AskF5 article K15740. "When TMM memory usage exceeds the high-water mark (85 percent by default), the system invokes the aggressive sweeper to reap connections."

- F5 Networks. (2021). The BIG-IP system may log the 'Aggressive mode sweeper' message. AskF5 article K15475. "This message indicates that the BIG-IP system is experiencing high TMM memory utilization... the system begins to terminate connections to reclaim memory."

- F5 Networks. (2017). BIG-IP LTM Concepts. Chapter: Memory Management. "The aggressive sweeper is activated when memory utilization reaches the high-water mark... it begins to drop connections."

The Configuration Utility provides detailed, per-object statistics for Local Traffic Manager (LTM) components. To view CPU utilization specifically for an individual virtual server, the administrator must navigate to the statistics section for that object type. The correct path is Statistics > Module Statistics > Local Traffic > Virtual Servers. This screen displays a list of all configured virtual servers and provides detailed performance metrics for each one, including connections, throughput, and CPU cycles consumed.

A. The Virtual Addresses screen shows statistics for the IP address itself, which may be shared by multiple virtual servers, not for a specific virtual server.

B. The Traffic Summary screen provides a high-level, aggregated overview of system traffic, not granular, per-object statistics like CPU usage for a single virtual server.

C. The Process CPU Utilization screen shows CPU usage by system daemons and processes (e.g., tmm, mcpd), not by LTM configuration objects like virtual servers.

1. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, Chapter 14: Monitoring BIG-IP LTM Traffic. This chapter describes the various statistical screens available in the Configuration Utility. The "Viewing statistics for virtual servers" section details the path Statistics > Module Statistics > Local Traffic > Virtual Servers for accessing performance data.

2. F5 Networks. (2021). BIG-IP System: Monitoring and Reporting Guide, Chapter 2: Viewing Statistical Data. The guide explains how to access different types of statistics, confirming that LTM object statistics are found under Module Statistics > Local Traffic.

The failover is governed by the HA order (D, B, C, A) and the 'Auto Fallback' setting. When BIGIP-B reboots, the traffic group fails over to the next available device in the order, BIGIP-C. Because 'Auto Fallback' is enabled, the system will always attempt to make the most-preferred available device active. BIGIP-D is ineligible as it is forced to standby. When BIGIP-B comes back online, it is more preferred than the currently active BIGIP-C. Therefore, Auto Fallback triggers a failover, and BIGIP-B becomes the active device.

A. BIGIP-A: This is the least preferred device and would only be active if all others in the HA order were unavailable.

B. BIGIP-D: This device cannot become active because it has been manually forced to a standby state.

D. BIGIP-C: While BIGIP-C becomes active temporarily when BIGIP-B reboots, it yields to the more-preferred BIGIP-B upon its return due to Auto Fallback.

1. F5 Networks. (2021). BIG-IP Device Service Clustering: Administration. Chapter 3: "Traffic Groups", Section: "Understanding failover". Retrieved from support.f5.com.

2. F5 Networks. (2021). BIG-IP TMOS: Implementations. Chapter 2: "High Availability", Section: "Configuring an HA Order failover". Retrieved from support.f5.com.

A gatewayicmp health monitor works by sending ICMP Echo Request packets (pings) to the monitored node and waiting for an ICMP Echo Reply. If the server is online but the monitor marks it as down, it means the server is not responding to these specific ICMP requests from the BIG-IP's self IP address. A common cause for this behavior, especially when it affects a single server while others in the same subnet are fine, is a host-based firewall (e.g., Windows Firewall, Linux iptables/firewalld) on that specific server that is configured to block incoming ICMP traffic.

A. The admin user is logged on the server. A user's login session has no bearing on the server's kernel-level network stack responding to ICMP requests.

B. The latest patches have not been installed on the server. While unpatched systems can have unpredictable behavior, it is not a direct or common cause for blocking ICMP.

D. The HTTP service is not started on the server. The monitor is ICMP-based, not HTTP-based. The status of the HTTP service is irrelevant to this monitor's operation.

F5 Networks. (2021). BIG-IP LTM: Monitors - ICMP and Gateway ICMP Monitors. F5 BIG-IP Documentation. This document describes the function of the gatewayicmp monitor, which sends an ICMP echo request to a pool member.

F5 Networks. (2017). Troubleshooting LTM Health Monitors (11.x). F5 University Courseware. Module on troubleshooting monitor failures identifies network and host-based firewalls as a primary reason for ICMP monitor failures. (Reference to general principle in F5 training).

To limit the number of new connections per second to a Virtual Server, the administrator must configure the "Connection Rate Limit" setting. This feature, located in the virtual server's properties, specifically throttles the rate at which new connections are accepted, preventing the virtual server and backend resources from being overwhelmed during traffic surges. It is measured in connections per second.

A. A OneConnect profile optimizes server-side connections by reusing them for multiple client requests, but it does not limit the rate of new incoming client connections.

B. An HTTP Compression profile reduces the size of HTTP payloads to save bandwidth; it has no effect on connection rates.

C. A connection limit sets the maximum number of total concurrent connections allowed, not the rate of new connections per second.

F5 Networks (2021). BIG-IP Local Traffic Manager: Concepts - Chapter 3: Virtual Servers. In the section "Virtual Server settings," the "Connection Rate Limit" property is defined as "the number of connections per second allowed for a virtual server."

F5 Networks. (n.d.). K15434: Overview of the BIG-IP virtual server Connection Rate Limit and Connection Limit settings. AskF5. This support article explicitly differentiates between Connection Limit (total concurrent) and Connection Rate Limit (new connections per second).

The SNMP trap bigipExternalLinkChange indicates a status change for a physical network interface on the BIG-IP device. The identifier "Link: 1.0" refers to the physical port labeled 1.0. The correct location within the BIG-IP Configuration Utility to view the live status (e.g., UP, DOWN, DISABLED) of all physical network interfaces is the Interface List page, which is found under the Network menu. This screen provides a comprehensive list of all ports and their current operational state.

A. System > Platform: This page displays general hardware status like fans, power supplies, and temperature, not the status of individual network ports.

B. Network > Trunks > Trunk List: This shows the status of link aggregation groups (trunks), not individual physical interfaces unless they are members of a trunk.

C. Statistics > Performance > System: This provides performance graphs for system-level resources like CPU and memory, not the link status of a network interface.

- F5 Networks. (2021). BIG-IP TMOS: Routing Administration. Chapter: "Managing Network Interfaces". This chapter details the use of the Network > Interfaces page to view and configure physical interfaces, including their status.

- F5 Networks. (2019). BIG-IP Systems: Enterprise Management with SNMP. Appendix A: "F5-BIGIP-SYSTEM-MIB objects". The documentation for the sysExtLink object confirms that it relates to the status of external network links (interfaces). The GUI location to verify this is Network > Interfaces.

The BIG-IP system uses the audit log to record messages generated by configuration changes. Any modification made to the system's configuration through the Traffic Management Shell (tmsh), the configuration utility (GUI), or iControl REST is logged to the /var/log/audit file. This log includes details such as the user who made the change, their source IP address, the configuration object that was modified, and the action taken (e.g., create, modify, delete).

A. /var/log/messages: This file contains general system messages from the kernel and various system daemons, but not specific configuration change audit trails.

C. /var/log/user.log: This log file contains user-level messages and is not the primary location for system-wide configuration audit events.

D. /var/log/secure: This file logs authentication-related messages, such as successful and failed login attempts, but not the configuration changes made after logging in.

1. F5 Networks. (2023). Overview of BIG-IP logging. BIG-IP TMOS: Operations Guide, 17.1.x. F5 Cloud Docs. (Section: "Standard system log files," which explicitly states /var/log/audit is for "auditing traffic.")

2. F5 Networks. (2022). K16197: Reviewing BIG-IP log files. F5 Support (AskF5), K16197. (This article provides a table of common log files and their purposes, identifying /var/log/audit for "BIG-IP audit logging.")

3. F5 Networks. (2023). Auditing BIG-IP system user activity. BIG-IP TMOS: Implementations, 17.1.x. F5 Cloud Docs. (This document details the audit logging feature and its output to /var/log/audit.)

The exhibit shows the virtual server application_vs with a status indicating it is offline but enabled. In

BIG-IP terminology, this status means the virtual server itself is administratively enabled, but it is

unable to pass traffic because no usable pool members are available.

Two common and documented causes for this condition are:

Pool member(s) administratively disabled (Option A):

When all pool members are administratively disabled, BIG-IP removes them from load-balancing

decisions. Even though the virtual server remains enabled, it has no available pool members to send

traffic to, resulting in an offline status.

Node(s) administratively disabled (Option C):

Pool members inherit the status of their parent nodes. If a node is administratively disabled, all

associated pool members are also marked unavailable. This condition causes the virtual server to

show as offline, even though the virtual server configuration itself is correct.

The other options are incorrect:

Forced offline pool members (Option B) result in a different operational intent and are explicitly set

for maintenance scenarios.

Virtual server administratively disabled (Option D) would show the virtual server as disabled, not

enabled/offline.

This behavior is consistent with BIG-IP traffic management logic and is commonly verified by

reviewing pool and node availability states when diagnosing virtual server availability issues.

When a BIG-IP device fails over, the new active unit must announce its ownership of floating IP addresses to the network. This is typically done via Gratuitous ARP (GARP). However, some network devices may be slow to process these updates, causing a delay in traffic restoration. MAC masquerade solves this by assigning a shared, non-floating MAC address to a traffic group. During a failover, the MAC address associated with the floating IPs does not change, eliminating the need for upstream devices to update their ARP caches. This results in a much faster and more seamless failover with minimal traffic disruption.

A. Enable Failover Multicast Configuration: This setting defines the IP address for HA communication between BIG-IP units; it does not affect how external network devices see the active unit.

B. Set up Failover Method to HA Order: This determines which device becomes active based on a pre-defined list, but it does not speed up the network convergence post-failover.

D. Configure a global SNAT Listener: A SNAT listener is used for source address translation and is unrelated to high-availability failover mechanisms or network convergence speed.

1. F5 Networks. (2021). BIG-IP Device Service Clustering: Administration. Chapter 3: High Availability Configuration, Section: "Configuring MAC masquerade". "You can configure a MAC masquerade address on a traffic group to minimize ARP communications and broadcasts... This feature is useful for preventing a loss of traffic when a device fails over."

2. F5 Networks. (2021). BIG-IP LTM: Implementations. Chapter 11: Configuring High Availability, Section: "Understanding MAC masquerade". "When a device fails over, the new active device begins using the masquerade MAC address immediately. This prevents the BIG-IP system from having to send out gratuitous ARP (GARP) messages to update the ARP tables of the hosts on the external network."