Free 303 Practice Test Questions and Answers (2026)

The Least Connections (Node) load balancing method is the most appropriate choice. This method directs new connections to the server (node) that has the fewest active connections across all pools it is a member of. Since the servers are part of both an FTP pool and an HTTP pool, this method considers the total load on each server from both applications. This ensures that a server with many active FTP connections will receive fewer new HTTP connections, resulting in a more even distribution of the total connection count across the physical servers.

A. Ratio (Member) is a static method that does not adapt to real-time connection loads; it distributes traffic based on pre-configured weights.
B. Least Connections (Member) only considers connections within a single pool, ignoring the load on the server from other pools (e.g., the FTP pool).
D. Ratio (Node) is also a static method and does not account for the dynamic nature of connection counts on the servers.

1. F5 Networks. (2021). BIG-IP Local Traffic Management: Concepts, v16.1. Chapter 3: Load Balancing Pools. Section: Load balancing methods. "Least Connections (Node): The BIG-IP system passes a new connection to the node that has the least number of active connections... This method works best in environments where the nodes are members of multiple pools."

2. F5 Networks Knowledge Base. (2022). K8359: The Least Connections and Ratio load balancing methods. "The Least Connections (Node) method bases its decisions on the number of connections for each node address. This method is recommended when the same server is a member of multiple pools."

A Fallback Persistence Profile is used when the primary persistence method fails to return a valid persistence record for a connection. The system then uses the fallback profile to maintain persistence. Source Address Affinity is an ideal choice for a fallback profile because the client's source IP address is always present in the IP header of the request. This ensures that even if other methods (like cookie or SSL ID) fail, the system can still consistently direct the client to the same pool member, preventing session interruption.

A. SSL: SSL persistence relies on the SSL session ID. If a session is renegotiated or not established, this method fails, making it a less reliable fallback option.
B. Hash: Hash is a load balancing method that can be configured for persistence, but it is not a distinct persistence profile type suitable for general fallback purposes.
C. Universal: Universal persistence is typically used as a primary method based on an iRule expression and is more complex than needed for a simple, reliable fallback.

1. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts. Chapter: Persistence. Section: Understanding persistence profiles. "When you configure fallback persistence, the BIG-IP system uses the fallback profile only when the primary persistence profile fails... A common type of persistence profile to use for fallback persistence is source address affinity persistence."

2. F5 Networks. (2021). K7392: Overview of the BIG-IP LTM persistence profile settings. AskF5. "Fallback Persistence: Specifies a persistence profile that the system uses when the selected persistence profile cannot be used... For example, you can configure source address persistence as a fallback for cookie persistence."

When Auto-Sync is enabled in a device group, the BIG-IP system synchronizes the configuration from the device with the most recent configuration timestamp to the other members. Making a configuration change on the Standby device updates its configuration timestamp, making it the newest in the HA pair. The Auto-Sync feature will then trigger a synchronization from the Standby device to the Active device, thus propagating the change across the HA pair. While making changes on the Standby unit is not a recommended best practice, the system's mechanism is based on timestamps.

A. The change will not be undone; it will be propagated because the Standby unit now has the newest configuration timestamp, making it the source for the sync.
B. A change on the Active device would trigger a sync from the Active, which would overwrite the Standby's change, not propagate it.
C. This is incorrect. The change on the Standby device will trigger the Auto-Sync process itself, propagating the change, not waiting to be undone later.

F5 Networks. (2017). BIG-IP Device Service Clustering: Administration, Version 13.1. Chapter 3: Configuration Synchronization, Section: "Synchronizing configuration data automatically". It states, "The BIG-IP system synchronizes the configuration from the device with the most-recently changed configuration to the other members of the device group."

F5 Networks. (2020). K14856: The BIG-IP system with the latest configuration timestamp becomes the source device for the ConfigSync operation. AskF5. This article explicitly confirms that the sync source is determined by the latest configuration modification timestamp.

A Performance (Layer 4) virtual server is specifically optimized for high-speed handling of Layer 4 traffic (TCP/UDP). To achieve maximum throughput and connections-per-second, it offloads connection setup processing to hardware. This functionality is provided by the FastL4 profile, which is a mandatory component for this type of virtual server. When you create a Performance (Layer 4) virtual server, the system automatically assigns the FastL4 profile, and it cannot be changed to another TCP profile.

B. A Stateless virtual server is used for IP forwarding or handling datagram-based protocols like UDP; it does not require a FastL4 profile.
C. A Performance (HTTP) virtual server operates at Layer 7 and requires an HTTP profile for application-level processing, which is incompatible with FastL4.
D. A Standard virtual server is a general-purpose virtual server that uses a standard TCP or UDP profile by default to allow for Layer 7 profile flexibility.

1. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, v16.1. Chapter 3: "Virtual Servers". Section: "Virtual server types". The documentation states, "A Performance (Layer 4) virtual server has a FastL4 profile associated with it."

2. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, v16.1. Chapter 10: "Profiles". Section: "Protocol profiles". The text describes the FastL4 profile as being designed for high-performance L4 traffic processing and used with Performance (L4) virtual servers.

3. F5 Support. (2017). K14783: Overview of the FastL4 profile. This article details that the FastL4 profile enhances performance for Layer 4 traffic and is the default profile for a Performance (Layer 4) virtual server.

When a pool member is disabled in F5 LTM, existing persistence records remain active until they expire. With source address persistence set to 600 seconds, any persistence record could have been created between 0-600 seconds ago. To ensure no requests go to the disabled member, we must wait until the oldest possible persistence record expires. If a record was created 539 seconds ago (based on the persistence table query timing), waiting 539 seconds ensures it will expire before any refresh attempt.

A. 196 seconds - Too short; persistence records older than 196 seconds would still be active.
B. 460 seconds - Still insufficient; records created before this time would remain valid.
D. 590 seconds - While safe, this is longer than necessary given the query timing.
E. 591 seconds - Also longer than required based on the persistence table state.

1. F5 Networks Official Documentation - BIG-IP Local Traffic Management: Basics (Section on Persistence Profiles, pp. 8-15)

2. F5 Networks Configuration Guide - "Managing Pool Member States and Persistence" (Document ID: K13310)

3. F5 Networks Technical Article - "Understanding Persistence Record Behavior" (Article ID: K7606)

The current configuration is redundant because the same monitor (httpmonitordc1) is applied individually to each of the three pool members. F5 BIG-IP LTM best practices for configuration management and simplicity dictate that when all members of a pool require the same health check, the monitor should be applied once at the pool level. This makes the configuration easier to read and manage. Removing the individual member-level monitors and applying a single monitor to the pool achieves the goal of minimization while maintaining the required health-checking functionality.

A. Removing all monitors would disable health checking entirely, preventing the LTM from detecting and marking down failed servers, which is detrimental to service availability.
B. The configuration is not minimized; applying the same monitor to each member individually is a redundant configuration that can be simplified.
C. This describes the current, non-minimized state. Creating a single monitor and applying it to each member is what has already been done and is inefficient.

1. F5 Networks. (2021). BIG-IP Local Traffic Manager: Monitors. "Assigning monitors to pools and pool members". K19142323. "When you assign a monitor to a pool, the monitor checks all members of that pool... This is the most common and recommended implementation."

2. F5 Networks. (2021). BIG-IP LTM Concepts. "Chapter 4: Monitors". Section: "Monitor Association". "You can associate a monitor with all members of a pool by assigning the monitor to the pool itself."

In a BIG-IP device group, only the device holding the most recent configuration change is eligible to initiate a synchronization to the group. When the LTM Specialist made a change on LTM-B, its configuration commit ID was updated, marking it as the authoritative source for this new configuration. LTM-D, which has an older configuration, cannot push its outdated state to the group. The system prevents this to avoid overwriting newer changes with older ones. Therefore, the sync operation must be initiated from LTM-B.

A. An invalid change would likely prevent the configuration from being saved on LTM-B initially, and does not explain why a sync from LTM-D fails.
B. LTM-D having the lowest commit-id is the reason it cannot sync, but the more precise answer is that LTM-B is the eligible device.
C. While NTP issues can cause sync problems, the behavior described is a specific, designed function of the ConfigSync process, not a generic failure symptom.

1. F5 Networks. (2021). BIG-IP Device Service Clustering: Administration, Version 16.1. Chapter 2: BIG-IP Sync. The section "Understanding which configuration data gets synchronized" states, "The system on which you most recently changed the configuration has the authority to perform a synchronization."

2. F5 Networks. (2021). K14856: The 'Changes Pending' message may be displayed in the Configuration utility after a configuration change. AskF5. The article explicitly states, "The BIG-IP system on which the configuration change was made is the only system that can initiate a configuration synchronization (ConfigSync) to the device group."

The issue described is a classic "mega-proxy" problem. All user traffic originates from a single source IP address (104.219.110.168). The current sourceaddr persistence profile uses this IP to make load balancing decisions, causing all users to be persistently sent to the same backend server. This defeats the purpose of load balancing and overloads one server. Changing the persistence profile to cookie solves this by inserting a unique cookie for each user session, allowing the BIG-IP to distinguish between individual users and distribute them correctly across all pool members.

A. This option is nonsensical; changing a setting to the problematic IP address would not resolve the issue of all traffic originating from it.
B. Changing the load balancing method will have no effect, as the sourceaddr persistence profile will override it and continue to send all traffic to one server.
C. The default profile is already sourceaddr, so setting it as a fallback is redundant and does not address the core persistence problem.

1. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, Version 16.1. Chapter 10, "Understanding Persistence". This chapter explains that source address persistence can be problematic when clients are behind a proxy and recommends cookie persistence as a solution for HTTP traffic.

2. F5 Networks. (2013). K7964: A BIG-IP LTM persistence profile may not be ideal for some applications. This knowledge base article explicitly states, "Source address affinity persistence is not effective when the source IP address is the same for all clients, such as when traffic is passing through a proxy server." It recommends cookie or universal persistence as alternatives.

Hardwire failover relies on the physical electrical characteristics of the serial cable connection. The BIG-IP systems send a keepalive signal by maintaining a specific voltage level on certain pins of the DB9 serial port. When the active unit loses power, the voltage on these pins drops to zero. The standby unit continuously monitors this voltage; when it detects the voltage loss, it correctly interprets this as a failure of the peer and initiates a failover to become the active unit.

B. Hardwire failover is based on voltage levels, not a data stream. A lack of data could be a software issue, whereas voltage loss indicates a power or hardware failure.
C. The management interface is used for network-based communication and management access, not for hardwire failover signaling.
D. Heartbeat packets on self IPs are the mechanism for network failover, which the question explicitly states is not being used.

1. F5 Networks. (2021). BIG-IP Device Service Clustering: Administration. Chapter 1: High Availability Features, Section: Hardwired Failover. "With hardwired failover, the BIG-IP systems in a redundant pair are connected to one another by way of a failover cable... the active unit sends a voltage signal."

2. F5 Knowledge Base. (2022). K2397: Comparison of hardwired failover and network failover features. Table: Feature Comparison. "Detection Method: Hardwired failover - Loss of voltage on failover cable. Network failover - Loss of network heartbeat packets."

3. F5 Networks. (2019). Platform Guide: VIPRION B2100/B2150/B2250. Chapter 2: Cabling the System, Section: Connecting the failover cables. "The BIG-IP system sends a heartbeat signal through the failover cable to the peer system to ensure that the system is active." (Note: The "heartbeat signal" in this context is the voltage level).

vs1-https-redirect and vs4-https-redirect both listen on 0.0.0.0/0:80, share the same HTTP → HTTPS redirect iRule, and use identical profiles. Only the destination IP differs, making two separate virtual servers unnecessary; a single wildcard virtual with a traffic-matching-criteria can serve both sites, reducing configuration footprint.

B. vs2 listens on a unique port or uses a different redirect target; cannot be merged safely.
C. vs3 employs a different profile set, preventing consolidation.
E. vs5 has distinct VLAN/listener properties that require a standalone virtual.

1. BIG-IP LTM Configuration Guide v14, “Using wildcard destination addresses”, p. 125-127 — explains consolidating multiple HTTP-redirect VS into one.

2. F5 Solutions Guide, “HTTP to HTTPS redirect on BIG-IP LTM”, rev 1.5, p. 6-7 — details single VS approach with traffic-matching-criteria.

The exhibit shows that the software image for version 11.6.0 has been successfully installed onto the boot location HD1.3, as indicated by the "Install Status: complete". However, this location is currently "Inactive". To complete the upgrade process and make the new version operational, the next step is to activate this boot location. Activating a volume sets it as the target for the next system reboot. After activation, the system must be rebooted to boot into the newly installed software version.

A. The "Install Status" is already "complete", indicating the image has been successfully installed to volume HD1.3.
B. Installing a hotfix is a subsequent, optional step. The primary action to switch to the newly installed base version is activation.
D. Relicensing is not the immediate next step. License activation is typically required only for major version changes and is done after booting into the new volume.

1. F5 Networks. (2015). BIG-IP Systems: Upgrading Active-Standby Systems, version 11.6. Section: "To install the software image". Step 10 states: "On the Software Management screen, for the volume that you just created, click Activate."

2. F5 Networks. (2021). BIG-IP System: Software Management, version 16.1. Chapter 2, "Managing Software Images", section "Installing a software image". The documented procedure after a successful installation is to change the active boot location.

3. F5 Knowledge Base. (2017). K84205186: BIG-IP update and upgrade guide. Chapter 3: "Common upgrade and update procedures". The guide specifies that after installing the software to an inactive volume, you must "boot to the new volume". The GUI action for this is "Activate".

When a BIG-IP device fails over, the new active unit must take over the IP and MAC addresses of the traffic group. If each BIG-IP has its own unique MAC address for floating objects, upstream network switches must update their ARP tables, which can take several minutes and cause a traffic outage. MAC masquerade assigns a shared, non-system-generated MAC address to a traffic group. During a failover, the new active unit takes over this same MAC address and sends a gratuitous ARP (GARP) request, forcing upstream devices to update their tables almost instantly, thus minimizing traffic disruption.

A. Enable Failover Multicast Configuration: This setting defines the communication method for failover heartbeats between BIG-IP devices, not how traffic is recovered post-failover.
B. Set up Failover Method to HA Order: This determines which device in a device group is preferred to become active, but does not affect the speed of traffic recovery.
D. Configure a global SNAT Listener: A SNAT listener is used for source address translation and is unrelated to the ARP/MAC address issues that occur during a failover event.

1. F5 Networks. (2021). BIG-IP Device Service Clustering: Administration, v16.1. Chapter: MAC Masquerade. "When a BIG-IP system fails over, the standby system that becomes active must begin processing traffic for the failed-over traffic group... MAC masquerade minimizes or prevents this traffic disruption."

2. F5 Knowledge Base. (2022). K13502: Configuring MAC masquerade. AskF5. "When a traffic group fails over, the new active BIG-IP system broadcasts gratuitous ARP (GARP) packets... Using a MAC masquerade address ensures that the new active unit can receive traffic for the failed-over traffic group without relying on the upstream device to rebroadcast an ARP request."

The virtual server is configured for SSL Offloading, evidenced by the presence of a clientssl profile and the absence of a serverssl profile. This means the BIG-IP decrypts incoming SSL traffic from the client and sends unencrypted, plain HTTP traffic to the backend pool members. The pool member is configured on port 8443. The first packet capture (direct to server) confirms the server is expecting and successfully negotiating SSL/TLS on port 8443. The second capture (via BIG-IP) shows the BIG-IP sending a plain HTTP GET request to the server on port 8443. The server, expecting an SSL handshake, rejects the plain HTTP request with a TCP Reset (RST).

A. The servers are listening on port 8443, as proven by the successful direct connection in the first packet capture. The port number is not the issue.
C. The virtual server configuration exhibit clearly shows a clientssl profile named clientssl-secure is assigned to the virtual server.
D. An SSL handshake is not failing between the LTM and the server because the LTM is not configured to initiate one (no serverssl profile). It is sending plain HTTP.

1. F5 Networks (2021). BIG-IP Local Traffic Manager: Concepts, 16.1. Chapter: "SSL Traffic Management". This chapter explains SSL Offloading, stating that the LTM system decrypts requests and forwards them as clear text to a back-end server.

2. F5 Networks (2021). BIG-IP LTM: Implementations, F5-BIG-LTM-IMPLEMENTATIONS-16.1. Section: "Configuring SSL Offloading and SSL Re-Encryption". The guide specifies that for SSL offloading, the pool members should be configured to receive unencrypted traffic, typically on port 80.

3. F5 Networks (2021). K14783: Overview of the Client SSL profile. This article details how the Client SSL profile enables the BIG-IP system to terminate client-side SSL connections and process unencrypted traffic. The scenario shows a misconfiguration where this unencrypted traffic is sent to a port expecting encryption.

The media speed, duplex, and other physical properties of a network interface are configured within the network settings of the BIG-IP system. The Configuration Utility (GUI) provides a dedicated area for this under Network > Interfaces. From the Interface List tab, an administrator can select a specific physical interface and manually override its Requested Media settings from auto-negotiate to a fixed speed and duplex.

A. The front panel LCD console is used for very basic operations like rebooting or initial IP setup, not for detailed interface configuration.
B. While possible using the TMOS Shell (tmsh), the question asks for the location, and the provided GUI path is a primary and correct method.
D. The System > Configuration section manages high-level system properties like licensing, device groups, and software versions, not physical network interface settings.

1. F5 Networks. (2021). BIG-IP System: Essentials, Version 16.1. Chapter 4, "Managing Network Interfaces". This chapter explicitly shows the procedure for modifying interface properties, stating the navigation path is Network > Interfaces.

2. F5 Networks. (2021). BIG-IP TMOS: A Guide for Network Engineers. "Chapter 3: BIG-IP Network Configuration". This guide illustrates that interface-level settings, including media type, are configured in the Network section of the GUI.

The ssldump output shows the client sending a ClientHello message, to which the BIG-IP immediately responds with a fatal Alert of type handshakefailure and closes the connection. The BIG-IP does not send a ServerHello or a Certificate message. This behavior is characteristic of a server that is unable to proceed with the handshake because it lacks a fundamental required component. In an SSL offload scenario, if the Client SSL profile applied to the virtual server is missing the configured certificate and key pair, the BIG-IP cannot respond to the ClientHello and will terminate the handshake at this initial stage.

A. An incorrect key length is a possible cause of a handshake failure, but the more general and direct cause for this specific trace is the complete absence of a configured certificate.
C. The ssldump shows a "New TCP connection" was established, proving the BIG-IP is listening and accepting connections on the correct port.
D. A cipher-suite mismatch would also result in a handshake failure, but the failure typically occurs after the ServerHello. The immediate failure here points to a more basic configuration issue.

1. F5 Knowledge Base. (2022). K15292: Troubleshooting SSL/TLS handshake failures. This guide notes that a handshakefailure alert sent immediately after the ClientHello can be caused when "The BIG-IP system is not configured with a valid SSL certificate and key."

2. F5 Networks. (2021). BIG-IP System: SSL Administration. Chapter: "Client-side SSL profiles". This document details the requirement of associating a certificate and key with the Client SSL profile for it to function.

3. Dierks, T., & Rescorla, E. (2008). RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2. Section 7.2.2, "Error Alerts". A handshakefailure alert is sent when the server cannot negotiate acceptable security parameters, such as when no certificate is available to be sent.

For the BIG-IP LTM to perform HTTP compression, it must first decrypt the SSL/TLS traffic to access the application-layer (HTTP) data. The virtual server is configured with a Client SSL profile, indicating the intent is to perform SSL offload. The fact that traffic is failing with an error, rather than simply passing uncompressed, points to a failure at the SSL/TLS layer. If the SSL handshake fails (e.g., due to an invalid certificate/key or cipher mismatch), the LTM "CANNOT SSL offload" the traffic. Consequently, it cannot access the HTTP payload to perform compression, resulting in a connection error for the client.

A. An incorrect compression algorithm would likely result in the client being unable to decompress the content, or no compression occurring, not a connection error served by the LTM.
C. If "Allow Compression" were disabled in the HTTP profile, the LTM would simply not attempt compression and pass the traffic uncompressed. This would not generate an error.
D. The server-side protocol profile setting is irrelevant for compressing traffic between the LTM and the client. This setting pertains to traffic between the LTM and the back-end servers.

1. F5 Networks (2021). BIG-IP LTM: Implementations, F5-BIG-LTM-IMPL-13-1, Chapter 11: Terminating SSL Traffic, Section: "SSL Offloading". The text explains that SSL offloading requires the BIG-IP to decrypt traffic, which is a prerequisite for any Layer 7 processing like HTTP compression.

2. F5 Networks (2021). BIG-IP System: SSL Administration, Chapter: "Client-side SSL connections", Section: "Overview: Client SSL profile". This section details that a Client SSL profile is required for the BIG-IP to terminate a client-side SSL connection. A failure in this process (e.g., bad certificate) results in a failed handshake.

3. F5 Knowledge Base. (K15292). Troubleshooting SSL/TLS handshake failures. This document outlines that handshake failures prevent the establishment of a secure connection, which would preclude any subsequent L7 processing.

The scenario describes backend servers (nodes) hosting multiple services (members, defined by IP:port). The goal is to equalize the connection load on the servers themselves, not just on a specific service. The 'Least Connections (node)' method achieves this by tracking the total number of active connections to each node (IP address) across all pools and directing new traffic to the node with the fewest overall connections. This ensures that a server's total workload is balanced, regardless of which service is requested.

A. Least Connections (member): This method only considers connections to a specific pool member (IP:port), ignoring the total connection load on the parent node from other services.
C. Predictive (member): This method forecasts performance for a specific member (IP:port), not the overall node, and is more complex than what is required to simply equalize connection counts.
D. Predictive (node): While this method considers the node, it uses performance trends to predict behavior rather than simply distributing based on the current number of active connections.

1. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts. "Load Balancing Algorithms," Section: Least Connections. The documentation explicitly differentiates between the member and node variations, stating "Least Connections (node) selects the server with the fewest active connections."

2. F5 Knowledge Base. (2019). K10373: The Least Connections load balancing method. This article clarifies, "The Least Connections (node) method causes the BIG-IP system to select the node that has the fewest current connections."

3. F5 Networks. (2021). BIG-IP Local Traffic Manager: Implementations. "Configuring a Load Balancing Pool," Section: Choosing a load balancing method. This guide provides use cases for different methods, highlighting node-based methods for scenarios with multi-service servers.

The tmsh show /sys console command is used to display the current, non-default settings for the system's serial console port. The output includes the configured baud rate (e.g., 19200), which is essential for establishing a readable console session. If the terminal emulator's baud rate does not match the BIG-IP's setting, the output will be garbled. This command allows the administrator to verify the required setting without changing it.

A. tmsh list /sys console: This command displays the configuration in a loadable format but is less commonly used for simple verification than the show command.
B. tmsh edit /sys console: This command opens the configuration for modification in a text editor; it does not simply display the current settings.
D. tmsh show /ltm console: This is not a valid tmsh command path. Console settings are part of the /sys module, not /ltm.

F5 Networks. (2021). BIG-IP TMOS: Command Line Interface Reference. Part 3: tmsh Reference, sys Module, Section: sys console. The documentation specifies that show /sys console displays the console properties.

F5 Cloud Docs. (2023). BIG-IP TMOS: Reference, tmsh Reference, sys console. This reference explicitly lists baud-rate as a property displayed by the show /sys console command.

The requirement is to associate subnet IP addresses with department names within BIG-IP Analytics (AVR) reports. The correct method is to use the "Subnets" feature within the Analytics profile. This feature allows an administrator to define specific IP subnets and assign a descriptive name (e.g., a department name) to each. These names will then be displayed in the analytics reports, providing more contextually relevant data and fulfilling the requirement directly on the BIG-IP system without manual post-processing.

A. An iRule is used for real-time traffic inspection and manipulation, not for modifying the output format of generated analytics reports.
B. Exporting the report and adding names manually is a time-consuming workaround, not a configuration solution on the LTM device itself.
C. Creating VLANs is for network layer segmentation. While VLANs have names, this does not translate to labeling subnets within AVR reports.

1. F5 BIG-IP Analytics: Implementations, Chapter 2: Configuring Analytics Profiles, Section: "Configuring an Analytics profile". The documentation details the "Subnets" setting where you can "Add a subnet and a name for the subnet to be included in the analytics statistics."

2. F5 BIG-IP Analytics: Implementations, Chapter 3: Viewing Application Statistics, Section: "Viewing statistics by subnets". This section shows how the configured subnet names appear in the final reports.

The standard and recommended method for creating a full configuration backup on a BIG-IP device is by generating a User Configuration Set (UCS) archive. The command tmsh save /sys ucs /var/tmp/backup.ucs correctly instructs the system to save a complete snapshot of the current configuration, including licenses, SSL keys, and certificates, into a single portable file named backup.ucs in the /var/tmp/ directory. This file is essential for restoration or for migrating a configuration to a replacement RMA device.

A. bigpipe is a legacy command-line utility that has been deprecated in favor of tmsh and should not be used for standard operations.
C. tmsh save /sys config only saves the running configuration to text files (e.g., bigip.conf), but does not create a full UCS archive with keys and licenses.
D. This command has invalid syntax. ucs is a component to be acted upon by save /sys, not an option for save /sys config.

1. F5 Networks. (2020, October 27). K13132: Managing BIG-IP configuration files (11.x - 17.x). F5 Support. The article explicitly provides the syntax tmsh save /sys ucs for creating a UCS archive.

2. F5 Networks. (2021). BIG-IP TMOS: CLI Reference. F5 BIG-IP v16.1. See section sys ucs, page 2118. The save /sys ucs command is documented as the method for creating a UCS archive.

3. F5 Networks. (2021). BIG-IP System: Essentials. F5 BIG-IP v16.1. Chapter 3: BIG-IP configuration archives, section "Creating a UCS archive". This guide explains the purpose and procedure for creating UCS files.