New (2026) Download free F5CAB5 PDF for F5 Practice Tests
100% Free F5CAB5 Files For passing the exam Quickly
NEW QUESTION # 29
A BIG-IP Administrator notices that one of the servers that runs an application isNOTreceiving any traffic.
The BIG-IP Administrator examines the configuration status of the application and observes the displayed monitor configuration and affected pool member status.
What is the possible cause of this issue? (Choose one answer)
- A. The application isNOTresponding with the expected Receive String.
- B. The BIG-IP device isNOTable to reach the pool.
- C. The node health monitor isNOTresponding.
- D. HTTP 1.1 isNOTappropriate for monitoring purposes.
Answer: C
Explanation:
The key clue in the exhibit is the pool member's availability showing"Offline (Enabled) - Parent down". In BIG-IP terminology, a pool member inherits the status of itsparent node. If thenodeis marked down (for example, by a node-level monitor or a default "node is down" condition), thenall pool members using that node IPwill also be marked down and will not receive any traffic, even if the application service on the member port might be healthy.
While the HTTPS monitor configuration (send/receive strings) is displayed, the statusspecificallyindicates anode (parent) failure, not a service-level failure. If the problem were the application not matching the receive string, you would typically see the member down due to themember's monitorfailing (and the status would reflect monitor failure details), rather than "parent down." Option D is too broad; BIG-IP can generally reach the subnet (other servers work), and this symptom points to a specific node condition. Option C is incorrect because HTTP/1.1 is commonly used for monitoring and is valid when properly formatted (especially with a Host header). Therefore, the most likely cause is that thenode health monitor is not responding, causing the node-and consequently the member-to be marked down.
NEW QUESTION # 30
Pool /Common/testpool member /Common/10.120.0.5:8090 monitor status down.
[ /Common/http: up, /Common/http2: down; last error: ] [ was up for
lhr:0min:43sec ]
Why is this pool member being marked down?
- A. The pool member is currently only serving HTTP2 traffic.
- B. The pool member is currently only serving TCP traffic.
- C. The pool member is currently only serving UDP traffic.
- D. The pool member is currently only serving HTTP traffic.
Answer: D
Explanation:
This log entry indicates that multiple monitors are assigned to the pool member, and the member is failing one of them.
Understanding Monitor Logic: By default, if multiple monitors are assigned to a pool or pool member without a "Minimum To Up" (Availability Requirement) setting, the system requires all monitors to pass for the member to be marked "Up".
Analyzing the Log: The log clearly states: [ /Common/http: up, /Common/http2: down; ... ]. This means the standard HTTP monitor is successful, indicating the member is serving HTTP traffic, but the http2 monitor has failed.
Conclusion: Since the http monitor is "up" but the member as a whole is "down," we can conclude the member is successfully responding to standard HTTP requests but not HTTP2 requests.
Therefore, the member is currently only serving standard HTTP traffic.
NEW QUESTION # 31
A BIG-IP Administrator uses backend servers to host multiple services per server. There are multiple virtual servers and pools defined, referencing the same backend servers. Which load balancing algorithm is most appropriate to have an equal number of connections on each backend server?17
- A. Least Connections (node)
- B. Least Connections (member)
- C. Predictive (member)
- D. Predictive (node)
Answer: A
Explanation:
When load balancing is not working as 23expected and connections appear skewed across physical hardware, the administrator must distinguish between "member"24 and "node" level balancing. A "member" refers to a specific IP and Port combination (e.g., 10.1.1.1:80), whereas a "node" refers to the underlying IP address (10.1.1.1) regardless of the port25. If a single server hosts multiple services (Web, FTP, API) across different pools, using "Least Connections (member)" would only balance connections within each individual pool26.
This could lead to a scenario where one server is overwhelmed because it is winning the "least connections" count in three different pools simultaneously. By selecting "Least Connections (node)," the BIG-IP tracks the total number of concurrent connections to the physical IP address across all pools it belongs to27. This ensures that the administrator can maintain an equal distribution of work across the hardware, preventing performance degradation on backend servers that host multiple application services.
NEW QUESTION # 32
Which command displays current connections?
- A. show sys failover
- B. show sys connection
- C. show sys memory
- D. show net vlan
Answer: B
Explanation:
This shows active connections handled by the system.
NEW QUESTION # 33
In the BIG-IP Configuration Utility, a user requests a single screen view to determine the status of all Virtual Servers and associated pool members, as well as any iRules in use. Where should the BIG-IP Administrator instruct the user to find this view?32
- A. Local Traffic > Monitors
- B. Local Traffic > Network Map
- C. Statistics
- D. Local Traffic > Virtual Servers
Answer: B
Explanation:
Comprehensive and Detailed Explanation From BIG-IP A41dministration Support and Troubleshooting documents:To confirm functionality across a complex environment, the "Network Map" is the most efficient troubleshooting tool in the Configuration Utility43. It provides a hierarchical, visual representation of the traffic management objects44. A single glance allows the administrator to see the status of a Virtual Server (Green/Red/Yellow), the status of its associated pool, the health of individual pool members, and which iRules are currently attached45. This view is superior to the standard "Virtual Server List" for troubleshooting because it maps the dependencies between objects46. For example, if a Virtual Server is "Red," the Network Map will show if that status is inherited from a failed pool or a specific monitor failing on a pool member.
Reviewing these basic stats in the Network Map helps the administrator quickly isolate whether a failure is at the service level (Virtual Server), the logic level (iRule), or the hardware level (Pool Member).
NEW QUESTION # 34
A BIG-IP Administrator needs to view the CPU utilization of a particular Virtual Server. Which section of the Configuration Utility should the administrator use for this purpose?
- A. Statistics > Analytics > Process CPU Utilization
- B. S70tatistics > Module Statistics >71 Local Traffic > Virtual Addresses
- C. Statistics > Module Statistics > Local Traffic > Virtual Servers
- D. Statistics > Module Statistics > Traffic Summary
Answer: C
Explanation:
Monitoring granular resource utilization is essential when troubleshooting performance degradation for specific applications. While global system stats show overall hardware health, they do not pinpoint which virtual server is overconsuming resources during traffic spikes. To identify the specific application causing a high CPU load, the administrator should navigate to Statistics > Module Statistics > Local Traffic > Virtual Servers7474. This section provides detailed metrics for each virtual server, including CPU cycles used for traffic processing and iRule execution75. Identifying a "top-talker" or a problematic virtual server allows the administrator to take targeted action, such as optimizing an inefficient iRule, adjusting compression levels, or offloading the virtual server to a different device group76. This targeted troubleshooting ensures that one high-demand virtual server does not negatively impact the performance of other services running on the same BIG-IP hardware, maintaining overall system stability and resource availability
NEW QUESTION # 35
A BIG-IP Administrator configured a virtual server with a pool of 3 members and selected the Round Robin load balancing method to evenly distribute traffic across the pool members. During initial testing, the virtual server failed to respond to http requests.
Plaintext
ltm virtual http.vs {
destination 10.10.1.100:http
ip-protocol tcp
mask 255.255.255.255
pool http.pool
profiles {
tcp{}
}
serverssl-use-sni disabled
source 0.0.0.0/0
translate-address enabled
translate-port enabled
}
ltm pool http_pool {
members {
10.10.1.101:http {
address 10.10.1.101
session monitor-enabled
state checking
}
10.10.1.102:http {
address 10.10.1.102
session monitor-enabled
state checking
}
}
monitor tcp
}
What configuration change on the BIG-IP will resolve this issue?
- A. Add SNAT Auto Map
- B. Add http profile
- C. Add http monitor
Answer: A
Explanation:
The issue described is a classic case of asymmetric routing in a "one-arm" or same-subnet topology.
Symptom Analysis: The Virtual Server (10.10.1.100) and the pool members (10.10.1.101 and 10.10.1.102) are on the same subnet.
The Problem: When a client sends a request to the VIP, the BIG-IP translates the destination IP but keeps the client's original source IP. The server receives the packet and sees a source IP from a different subnet. Instead of sending the response back to the BIG-IP, the server sends it directly to its default gateway. The client receives a response from the server's IP, which it doesn't recognize, causing the connection to fail.
The Solution: Enabling SNAT Auto Map ensures the BIG-IP changes the source IP of the packet to its own self-IP. This forces the pool member to send the response back to the BIG-IP, which then translates it correctly and sends it to the client.
Incorrect Options: Adding an HTTP profile (Option B) or an HTTP monitor (Option C) would enhance the configuration but would not fix the underlying Layer 3 routing issue causing the traffic drop.
NEW QUESTION # 36
A BIG-IP Administrator needs to collect HTTP status code and HTTP method for traffic flowing through a virtual server. Which default profile provides this information?
- A. Request Adapt
- B. Analytics
- C. Statistics
- D. HTTP
Answer: B
Explanation:
To gather granular Layer 7 data such as specific HTTP methods (GET, POST, etc.) and HTTP status codes (200, 404, 500), the BIG-IP system utilizes the Analytics (AVR) profile.
* Analytics Profile (Application Visibility and Reporting): While a standard HTTP profile tracks basic byte counts and requests, the Analytics profile is designed specifically to capture, analyze, and display detailed application performance metrics.
* Metrics Captured: When attached to a virtual server, it records URL-level statistics, response codes, page load times, and client-side metrics.
* Why not others? * HTTP Profile (Option A): This profile handles the parsing of HTTP traffic but does not provide a built-in reporting dashboard for status code distribution.
* Statistics Profile (Option C): This is a legacy profile used for custom user-defined counters and does not automatically categorize HTTP methods or status codes.
* Request Adapt (Option D): This is used for integrating with ICAP servers (like virus scanners) and does not perform traffic reporting.
NEW QUESTION # 37
In an F5 BIG-IP system, a pool is configured with a health monitor and the "ManualResume" feature is Enabled. If a poolmember is marked Offline(Red) due to a health monitor failure, what will be the status of the member once the health monitor successfully passes again?
- A. Offline (Enabled)
- B. Offline (Disabled)
- C. Available (Enabled)
- D. Available (Disabled)
Answer: B
Explanation:
The "Manual Resume" feature is a safety mechanism used when a pool is not working as expected due to flapping services or unstable backend applications. Normally, when a health monitor fails, the pool member is marked "Offline" (Red), and when the monitor passes, it automatically returns to "Available" (Green). However, if "Manual Resume" is enabled, the BIG-IP will not automatically put the member back into rotation after a failure. Even if the health check begins to pass again, the member remains in an "Offline (Disabled)" state. This requires an administrator to manually intervene and re-enable the member. This is a common point of confusion when troubleshooting; a member may show passing health checks but still not receive traffic because it is waiting for a manual administrative "resume" command. This feature is intended to prevent "unhealthy" servers from receiving traffic until an engineer has confirmed the root cause of the initial failure was resolved.
NEW QUESTION # 38
A BIG-IP Administrator makes a configuration change to a Virtual Server on the Standby device of an HA pair. The HA pair is currently configured with Auto-Sync Enabled. What effect will the change have on the HA pair configuration?
- A. The change will take effect when Auto-Sync propagates the config to the HA pair.
- B. The change will be undone when Auto-Sync propagates the config to the HA pair.
- C. The change will be propagated next time a configuration change is made on the Active device.
- D. The change will be undone next time a configuration change is made on the Active device.
Answer: A
Explanation:
Understanding High Availability (HA) synchronization behavior is critical for maintaining a stable environment. In a device group where "Auto-Sync" is enabled, the BIG-IP system monitors the management plane for any configuration updates across all members. While best practices often suggest making changes on the "Active" device, TMOS allows changes on any device within the group. When a change is made on the "Standby" device, the system detects a configuration mismatch and, because Auto-Sync is enabled, it automatically pushes those changes to the other devices in the sync group, including the current Active member. To troubleshoot if this is working correctly, the administrator should review the "Sync Status" stats in the Configuration Utility. If the changes do not propagate, it suggests a breakdown in the HA trust relationship or network connectivity issues on the failover VLAN. Proper interpretation of this scenario confirms that the HA functionality is operating correctly, ensuring that both devices have a consistent set of virtual servers and pools, which is vital for seamless failover.
NEW QUESTION # 39
Which log file is most commonly used to troubleshoot LTM-related issues in F5 BIG-IP?
- A. /var/log/audit
- B. /var/log/secure
- C. /var/log/boot.log
- D. /var/log/ltm
Answer: D
Explanation:
This log contains Local Traffic Manager (LTM) events, such as pool member status and traffic issues.
NEW QUESTION # 40
Where should the BIG-IP Administrator go in the GUI to verify the status of pool members of a pool?
- A. Local Traffic --> Nodes
- B. Local Traffic --> Pools --> <pool_in_question> --> Members
- C. Local Traffic --> Virtual Servers --> Statistics
- D. Local Traffic --> Pools
Answer: B
Explanation:
To verify the specific health and availability status of individual members within a specific pool, the administrator must navigate to the Members tab of that specific pool.
Navigation Path: The correct path is Local Traffic > Pools > Pool List, then clicking on the name of the <pool_in_question>, and finally selecting the Members tab. This screen provides a granular view of each member's IP address, port, and their current status (indicated by the colored icons:
Green, Red, Yellow, or Blue).
Why Option A is correct: While you can see a general status summary on the Pool List page (Option B), that page only shows the status of the pool as a whole. To troubleshoot why a pool is not working or to see which specific member is down, you must drill down into the Members tab.
NEW QUESTION # 41
A BIG-IP Administrator makes a configuration change to the BIG-IP device. Which file logs the message regarding the configuration change?
- A. /var/log/messages
- B. /var/log/user.log
- C. /var/log/secure
- D. /var/log/audit
Answer: D
Explanation:
The BIG-IP system uses the audit log to track administrative actions and configuration changes.
Audit Logging Functionality: When a user modifies the configuration via the Configuration Utility (GUI), the Traffic Management Shell (tmsh), or iControl, the system records the event in the audit log. This includes the name of the user who made the change, the timestamp, and the specific command or object that was modified.
Log Location: The audit log is stored at /var/log/audit.
Evaluation of Other Options:
/var/log/messages (Option A) contains general system and kernel messages but is not the primary source for configuration change details.
/var/log/secure (Option B) primarily logs authentication and authorization attempts (logins and logouts).
/var/log/user.log (Option D) is a generic Linux log file for user-level applications and does not track BIG-IP LTM configuration changes.
NEW QUESTION # 42
Refer to the exhibit. A user with IP address 192.168.162.70 is unable to connect to an HTTP application. What is a possible cause within the Virtual Server configuration?
- A. The Destination Address is configured as 192.168.162.80
- B. The Virtual Server is configured as a Standard Type
- C. The Service Port is configured as 0 *All Ports
- D. The Source Address is configured as 10.128.10.0/24
Answer: D
Explanation:
The failure to connect is caused by a restrictive Source Address filter configured on the Virtual Server.
Source Address Filtering: In the BIG-IP system, the Source Address field on a Virtual Server acts as an implicit Access Control List (ACL). Only traffic originating from a client IP address that matches the specified network range will be accepted and processed by the Virtual Server.
Analyzing the Exhibit: The provided configuration for vs_http shows the Source Address is set to
10.128.10.0/24. This means the Virtual Server will only accept connections from the subnet ranging from 10.128.10.1 to 10.128.10.254.
Identifying the Conflict: The user trying to connect has the IP address 192.168.162.70. Since
192.168.162.70 does not fall within the allowed 10.128.10.0/24 range, the BIG-IP system will not match this traffic to the Virtual Server, effectively blocking the connection attempt.
NEW QUESTION # 43
Due to a change in application requirements, a BIG-IP Administrator needs to modify the configuration of a Virtual Server to include a Fallback Persistence Profile. Which persistence profile type should the BIG-IP Administrator use for this purpose?
- A. Universal
- B. Source Address Affinity
- C. SSL
- D. Hash
Answer: B
Explanation:
Persistence is critical for ensuring that a client's session remains with the same pool member throughout its duration. If primary persistence (like Cookie Persistence) fails--for instance, because the client has disabled cookies--load balancing will not work as expected, and the session may be broken. A "Fallback Persistence Profile" provides a backup method. The most common and reliable fallback method is "Source Address Affinity". This method tracks the client's IP address in the BIG-IP's persistence table and ensures that any subsequent requests from that IP are routed to the same pool member, even if the primary persistence token is missing.
Troubleshooting session drops often involves checking if a fallback method is configured to handle scenarios where the primary method is unsupported by the client's browser or environment. Without a fallback, the BIG-IP would revert to standard load balancing, potentially sending the client to a different server that lacks their session data.
NEW QUESTION # 44
A BIG-IP Administrator is informed that traffic on Interface 1.1 is expected to increase over the maximum bandwidth capacity on the link. There is a single VLAN on the Interface. What should the BIG-IP Administrator do to increase the total available bandwidth?
- A. Set the media speed of Interface 1.1 manually
- B. Increase the MTU on the VLAN using Interface 1.1
- C. Assign two Interfaces to the VLAN
- D. Create a trunk object with two Interfaces
Answer: D
Explanation:
When a physical network link (like Interface 1.1) reaches its maximum capacity, it creates a bottleneck that negatively impacts network-level performance. To overcome the physical limits of a single interface, BIG-IP administrators use "Trunking," which is the F5 term for Link Aggregation (often implemented via LACP). A trunk object bundles multiple physical interfaces into a single logical link. By creating a trunk with two or more interfaces, the BIG-IP can spread the traffic load across all members of the trunk, effectively doubling or tripling the available bandwidth for the associated VLANs. Beyond performance, troubleshooting redundancy often leads to the use of trunks; if one cable in a trunk fails, the others continue to carry traffic, preventing a complete outage. This is a superior solution to simply increasing MTU (which requires end-to-end support) or manually setting media speeds. In a high-availability environment, configuring trunks is a foundational troubleshooting and optimization step to ensure that traffic spikes do not result in packet loss due to link saturation.
NEW QUESTION # 45
A BIG-IP Administrator receives reports from users that SSL connections to the BIG-IP device are failing. Upon checking the log files, the administrator notices: SSL transaction (TPS) rate limit reached. stats show a maximum of 1200 client-side SSL TPS and 800 server-side SSL TPS. What is the minimum SSL license limit required to handle this peak?
- A. 0
- B. 1
- C. 2
- D. 3
Answer: A
Explanation:
Troubleshooting failed SSL handshakes involves interpreting the resource limits defined by the system's license8888. The log message SSL transaction (TPS) rate limit reached indicates the BIG-IP is dropping SSL connections because it has exceeded its licensed "Transactions Per Second" capacity. When analyzing stats to determine the correct license level, the administrator must focus on "Client-side" SSL TPS. This represents the initial encrypted handshakes between users and the BIG-IP virtual servers91. In this scenario, the peak client-side demand is 1200 TPS. While the 800 server-side transactions represent re-encryption toward the backend, F5's primary SSL TPS license limits typically apply to the client-facing side of the traffic flow. Therefore, to resolve the intermittent connectivity issues and ensure the virtual server works reliably during peaks, the license must be upgraded to at least 1200 TPS949596969696. 9798Confirming this peak via statistics and comparing it to the current license is a standard troubleshooting step for SSL performance issues.
NEW QUESTION # 46
Some users who connect to a busy Virtual Server have connections reset by the BIG-IP system. Pool member resources are NOT a factor in this behavior. What is a possible cause for this behavior?
- A. The Connection Limit is set too low.
- B. The server SSL Profile has NOT been reconfigured.
- C. The Connection Rate Limit is set too high
- D. The Rewrite Profile has NOT been configured.
Answer: A
Explanation:
When troubleshooting intermittent connection resets on a "busy" Virtual Server, the administrator must examine the configured thresholds62. A "Connection Limit" is a hard cap on the number of concurrent connections a Virtual Server or pool member can handle63. If this limit is set too low, the BIG-IP will reset any new connection attempts once the threshold is reached64. The key indicator in this scenario is that the problem only affects "some users" and happens when the server is "busy," suggesting that the system is hitting a capacity ceiling rather than suffering from a persistent configuration error65. Unlike a missing SSL profile, which would likely cause all connections to fail, or a "Connection Rate Limit," which throttles how fast connections arrive, a "Connection Limit" focuses on the total volume66. Identifying this as the cause requires reviewing the Virtual Server's statistics to see if the "Current Connections" count is consistently peaking at the configured limit value.
NEW QUESTION # 47
Refer to the exhibit.
A BIG-IP Administrator needs to deploy an application on the BIG-IP system to performSSL offload and re- encrypt the traffic to pool members. During testing, users are unable to connect to the application.
What must the BIG-IP Administrator do to resolve the issue? (Choose one answer)
- A. Remove the configured SSL Profile (Client)
- B. Configure Protocol Profile (Server) as splitsession-default-tcp
- C. Configure an SSL Profile (Server)
- D. Enable Forward Proxy in the SSL Profile (Client)
Answer: C
Explanation:
To successfully performSSL offload and re-encryptionon a BIG-IP system, the virtual server must be configured withboth a Client SSL profile and a Server SSL profile. The Client SSL profile enables BIG-IP to decrypt inbound HTTPS traffic from clients, while the Server SSL profile is required tore-encrypt traffic before forwarding it to the pool members.
From the exhibit, the virtual server has aClient SSL profile configured, which allows BIG-IP to accept HTTPS connections from clients. However, there isno Server SSL profile attached, meaning BIG-IP attempts to sendunencrypted HTTP trafficto pool members listening on HTTPS (port 443). This protocol mismatch causes the server-side SSL handshake to fail, resulting in users being unable to connect to the application.
This behavior is well documented in BIG-IP SSL troubleshooting guides: when backend servers expect HTTPS, a Server SSL profile is mandatory to establish a secure connection from BIG-IP to the pool members.
The other options are incorrect:
* Removing the Client SSL profile (Option A) would break client-side HTTPS.
* The server-side TCP profile (Option B) is unrelated to SSL encryption.
* Forward Proxy (Option C) is only used for outbound SSL inspection scenarios.
Therefore, configuring anSSL Profile (Server)is the correct and required solution.
NEW QUESTION # 48
Without decrypting, what portion of an HTTPS session is visible with a packet capture? (Choose one answer)
- A. HTTP Request Headers
- B. HTTP Response Headers
- C. Cookies
- D. Source IP Address
Answer: D
Explanation:
In an HTTPS session, the application-layer payload--including HTTP request headers, response headers, cookies, and body content--is encrypted using SSL/TLS. Without decrypting the traffic (for example, without SSL offloading on BIG-IP or access to the private keys), a packet capture cannot reveal any HTTP-level details.
However, network-layer and transport-layer information remains visible, even when encryption is used. This includes source and destination IP addresses, source and destination ports, TCP flags, sequence numbers, and TLS handshake metadata. Therefore, thesource IP address (Option B) is visible in a packet capture of HTTPS traffic without decryption.
NEW QUESTION # 49
......
F5 F5CAB5 Exam Syllabus Topics:
| Topic | Details |
|---|---|
| Topic 1 |
|
| Topic 2 |
|
| Topic 3 |
|
F5CAB5 Premium Exam Engine - Download Free PDF Questions: https://www.free4torrent.com/F5CAB5-braindumps-torrent.html
F5CAB5 Dumps Questions Study Exam Guide : https://drive.google.com/open?id=1Qo-HoXJmZKejmZc-bJsPYp5CIsU5-H_T