I85PREP
⌘ K
F5 201 TMOS study materials
F5 201 TMOS study resources

F5 201 TMOS practice questions

One question at a time. Build your F5 201 TMOS understanding.

First 50 of 190 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1BIG-IP LTM listeners, persistence and TLS boundaries

In the supplied ordinary monitored-pool BIG-IP model, an enabled standard virtual server is Available with a green indicator, and the configured availability rule is satisfied by at least one monitored member. Which description fits that stated observation?

  1. At least one pool member is monitor-up and the virtual server is accepting traffic Correct answer.
  2. No monitor is configured on the pool
  3. The virtual server is administratively disabled
  4. The unit is in Forced Offline

Explanation

Under the supplied ordinary monitored-pool model, the configured availability rule is met and the virtual server is enabled for relevant traffic. This does not prove every member or end-to-end application transaction succeeds. Other icons and administrative states must be interpreted using their actual release and configuration, not a universal color mnemonic.

Question 2BIG-IP LTM listeners, persistence and TLS boundaries

In BIG-IP status indicators, what does a BLUE circle next to a pool member indicate?

  1. Member is up and passing traffic
  2. Member status is Unknown - either no monitor is assigned or no monitor result has been returned yet Correct answer.
  3. Member is administratively offline
  4. Member has failed monitors and is marked down

Explanation

Blue indicates Unknown - either no health monitor is associated with the member (or the parent pool/node), or the monitor has not yet returned a result. Green is Available, red is Offline (monitor failed), yellow indicates that some but not all monitors are reporting, and black indicates Disabled.

Question 3BIG-IP LTM listeners, persistence and TLS boundaries

A virtual server is shown with Availability: Available but State: Disabled (Available - Disabled). What is the practical effect on traffic?

  1. The VS accepts new connections normally
  2. Existing connections persist but new connections are not accepted on this VS Correct answer.
  3. All connections are dropped immediately
  4. Monitors continue but configuration is locked

Explanation

Available - Disabled means the virtual server is healthy (pool members up) but has been administratively disabled. Existing connections continue to be processed until they close, but no new connections are accepted. This is the recommended state to bleed off traffic before maintenance. Forced Offline drops both new and existing connections.

Question 4BIG-IP LTM listeners, persistence and TLS boundaries

A client cannot reach a virtual server. tmsh show ltm virtual <name> shows Availability: Offline. What is the FIRST thing to check?

  1. Pool member health (monitor results) Correct answer.
  2. BIG-IP licensing
  3. NTP synchronization
  4. Management interface route

Explanation

Offline on a virtual server means all members of its default pool have failed their monitors, so the BIG-IP refuses new connections. Start by inspecting tmsh show ltm pool <pool> members to see which monitors are failing and why (timeouts, wrong send/receive string, server-side outage). Licensing, NTP, and the management route do not directly mark a virtual server Offline.

Question 5BIG-IP LTM listeners, persistence and TLS boundaries

Which of the following correctly describes the packet flow for a TCP client connecting to a standard virtual server with SNAT Automap?

  1. Client -> VIP, BIG-IP rewrites destination to a pool member and source to a self-IP, pool member responds to self-IP, BIG-IP rewrites back to client Correct answer.
  2. Client -> VIP, BIG-IP forwards untouched at L2 to pool member
  3. Client -> pool member directly; BIG-IP only logs
  4. Client -> VIP, BIG-IP NATs source to client real IP and destination to floating self-IP

Explanation

With SNAT Automap, BIG-IP DNATs the destination from the VIP to a selected pool member and SNATs the source to a self-IP on the egress VLAN. The pool member sees the self-IP as the client and replies to that self-IP. BIG-IP reverses both translations on return so the client sees its original VIP. Without SNAT, the pool member would reply to the original client IP, and the LTM must be the gateway.

Question 6BIG-IP LTM listeners, persistence and TLS boundaries

A virtual server is configured WITHOUT SNAT, pool members are on a different subnet, and the BIG-IP is not the pool members' default gateway. Symptom: clients see SYN sent, no ACK back. What is the cause?

  1. Asymmetric return: pool members reply directly to the client and TCP fails Correct answer.
  2. Pool members are administratively disabled
  3. Wrong service port on the VIP
  4. TLS handshake failure

Explanation

Without SNAT, the pool member sees the client's real IP as the source. If the BIG-IP is not its default gateway, the member sends the reply to its own next hop, bypassing the BIG-IP. The client receives a packet from the pool member's IP rather than the VIP and the TCP session fails. The fix is enable SNAT (Automap or pool) or make the BIG-IP the gateway.

Question 7BIG-IP LTM listeners, persistence and TLS boundaries

Which monitor type sends an ICMP Echo Request to a node and waits for an Echo Reply?

  1. ICMP Correct answer.
  2. Echo
  3. Gateway ICMP
  4. TCP

Explanation

The ICMP monitor sends an ICMP Echo Request (ping) and treats Echo Reply as success. F5 also ships a separate Gateway ICMP monitor specifically for default-route reachability checks. The Echo monitor is a different protocol (UDP/TCP echo service). TCP monitors complete a TCP handshake.

Question 8BIG-IP LTM listeners, persistence and TLS boundaries

You need a monitor that sends an HTTP GET / and verifies a specific status string in the response. Which monitor type should you use?

  1. TCP
  2. HTTP Correct answer.
  3. ICMP
  4. TCP Half-Open

Explanation

The HTTP monitor lets you set a Send String (e.g., GET / HTTP/1.0\r\n\r\n) and a Receive String to match in the response (e.g., HTTP/1.1 200 OK or a body keyword). TCP and TCP Half-Open only verify port reachability. ICMP cannot inspect application payloads.

Question 9BIG-IP LTM listeners, persistence and TLS boundaries

You need an HTTPS monitor that performs SSL handshake and HTTP-level health check. Which is the correct monitor type?

  1. TCP
  2. HTTP
  3. HTTPS Correct answer.
  4. External

Explanation

The HTTPS monitor wraps the HTTP send/receive logic inside an SSL/TLS connection on the configured port (typically 443). It validates that the pool member negotiates TLS and returns the expected HTTP response. Plain HTTP monitor would not negotiate TLS, and TCP would only verify the TCP port.

Question 10BIG-IP LTM listeners, persistence and TLS boundaries

You need a monitor that runs a custom shell script to check a complex back-end. Which monitor type supports this?

  1. External Correct answer.
  2. Inband
  3. HTTP with custom Receive Disable String
  4. FastL4

Explanation

External monitors execute a user-provided shell script (placed under /config/monitors) and use its exit code (0 = success) to mark a member up or down. They are the most flexible monitor type and are used when no built-in monitor matches the protocol. Inband monitors use real client traffic; FastL4 is a profile, not a monitor.

Question 11BIG-IP LTM listeners, persistence and TLS boundaries

Which persistence method ensures that a client returns to the same pool member by inserting an HTTP cookie containing the pool member's encoded identity?

  1. Source Address Affinity
  2. Cookie (Insert) Correct answer.
  3. SSL Session ID
  4. MSRDP

Explanation

Cookie persistence with the default Insert method has the BIG-IP add an HTTP cookie to responses containing the encoded pool-member ID. On follow-up requests the BIG-IP reads the cookie and steers the client to the same member. It requires an HTTP profile and only works for HTTP/HTTPS traffic. Source-affinity uses client IP. SSL Session ID uses TLS session. MSRDP keys on the RDP routing token.

Question 12BIG-IP LTM listeners, persistence and TLS boundaries

Which persistence method is appropriate for Microsoft Remote Desktop Services (Terminal Services) load balancing?

  1. Cookie persistence
  2. Source Address Affinity persistence
  3. MSRDP persistence Correct answer.
  4. Universal persistence

Explanation

MSRDP persistence keys on the routing token issued by the RD Connection Broker, ensuring that a reconnecting RDP client returns to the same backend session host. Cookie persistence requires HTTP. Source Address Affinity breaks if multiple clients share an IP. Universal persistence can implement custom keys but MSRDP is the purpose-built option.

Question 13BIG-IP LTM listeners, persistence and TLS boundaries

Which profile type is required on a virtual server to make iRule HTTP_REQUEST events fire?

  1. FastL4
  2. HTTP Correct answer.
  3. Stream
  4. OneConnect

Explanation

HTTP_REQUEST and other HTTP_* iRule events are emitted by the HTTP profile after it parses the client request line and headers. Without an HTTP profile, the BIG-IP does not parse Layer 7 and those events never fire. FastL4 explicitly bypasses L7 inspection. Stream is for content rewriting. OneConnect is for backend connection pooling.

Question 14BIG-IP LTM listeners, persistence and TLS boundaries

Which iRule event is the EARLIEST chance to inspect a TCP connection before any L7 parsing has occurred?

  1. HTTP_REQUEST
  2. CLIENT_ACCEPTED Correct answer.
  3. SERVER_CONNECTED
  4. CLIENTSSL_HANDSHAKE

Explanation

CLIENT_ACCEPTED fires immediately after the BIG-IP completes the TCP three-way handshake with the client, before any TLS or HTTP parsing. It is used to inspect or set L4 attributes such as source IP, source port, or to short-circuit a connection. HTTP_REQUEST requires an HTTP profile. SERVER_CONNECTED fires only after the BIG-IP has connected to a pool member.

Question 15BIG-IP LTM listeners, persistence and TLS boundaries

Which BIG-IP profile reduces back-end TCP connection load by multiplexing many client HTTP requests onto a smaller number of persistent connections to pool members?

  1. FastHTTP
  2. OneConnect Correct answer.
  3. Stream
  4. FastL4

Explanation

OneConnect maintains a pool of idle TCP connections to pool members and reuses them for new client HTTP requests, which dramatically reduces per-request connection overhead on origin servers. It requires HTTP. FastHTTP is a different profile that combines TCP and HTTP into a streamlined profile for high-volume HTTP. Stream rewrites payloads. FastL4 forwards at L4.

Question 16BIG-IP LTM listeners, persistence and TLS boundaries

Which profile is purpose-built for high-throughput, low-latency Layer 4 forwarding with optional hardware acceleration?

  1. TCP
  2. HTTP
  3. FastL4 Correct answer.
  4. FastHTTP

Explanation

FastL4 is the L4 forwarding profile that benefits from hardware ePVA acceleration on supported BIG-IP platforms. It does not parse HTTP and is used on Performance (Layer 4) virtual servers. FastHTTP is a streamlined L7 HTTP profile, not L4. TCP and HTTP are standard L4/L7 profiles without the L4-acceleration feature set.

Question 17BIG-IP LTM listeners, persistence and TLS boundaries

Which iRule command sends the connection to a specific pool, overriding the default pool of the virtual server?

  1. pool <pool_name> Correct answer.
  2. node <ip> <port>
  3. HTTP::pool
  4. LB::reselect

Explanation

The pool <name> command directs the current connection to the named pool, overriding the virtual server's default pool. It is commonly used inside HTTP_REQUEST to route based on URI/host. The node command sends to a specific node:port, bypassing pools entirely. LB::reselect retries selection within the current pool. HTTP::pool is not a valid iRule command.

Question 18BIG-IP LTM listeners, persistence and TLS boundaries

Which iRule event fires after the BIG-IP successfully selects a pool member for the connection?

  1. LB_SELECTED Correct answer.
  2. CLIENT_ACCEPTED
  3. HTTP_REQUEST
  4. CLIENTSSL_HANDSHAKE

Explanation

LB_SELECTED fires immediately after the load-balancing decision picks a pool member. It is useful for logging the chosen member or overriding selection with a different member via 'pool' or 'node'. CLIENT_ACCEPTED fires earlier on TCP accept. HTTP_REQUEST fires after L7 parsing. CLIENTSSL_HANDSHAKE fires after TLS.

Question 19BIG-IP LTM listeners, persistence and TLS boundaries

What does the iRule event CLIENTSSL_HANDSHAKE indicate?

  1. A failed TLS handshake
  2. A successful TLS handshake completed between the client and the BIG-IP Correct answer.
  3. An HTTP redirect
  4. A TCP RST was sent

Explanation

CLIENTSSL_HANDSHAKE fires after the BIG-IP successfully completes the TLS handshake with the client. It is used to inspect chosen ciphers, peer certificates, and to log SSL parameters. CLIENTSSL_HANDSHAKE_FAILED is the failure event.

Question 20BIG-IP LTM listeners, persistence and TLS boundaries

Which iRule command issues a Layer 7 redirect to the client?

  1. HTTP::redirect <url> Correct answer.
  2. HTTP::respond 301
  3. HTTP::header insert
  4. HTTP::uri

Explanation

HTTP::redirect <url> sends a 302 redirect to the client with the specified Location header. HTTP::respond can also send a custom response (including 301), but HTTP::redirect is the documented direct-redirect command. HTTP::header insert and HTTP::uri modify rather than redirect.

Question 21BIG-IP LTM listeners, persistence and TLS boundaries

You suspect the BIG-IP is not receiving traffic for a virtual server. After verifying physical link, what is the next BIG-IP-side check?

  1. Verify the destination IP matches a configured virtual address with a listening virtual server, and ARP/MAC for that virtual address Correct answer.
  2. Reboot the device
  3. Reinstall the license
  4. Re-create all monitors

Explanation

After link verification, confirm the virtual address is configured with the expected mask, the virtual server is listening on the right destination IP/port/protocol, and the BIG-IP is ARPing for that address (Virtual Address ARP setting enabled). Reboots/relicensing/recreating monitors do not address the basic ARP/listen path.

Question 22BIG-IP LTM listeners, persistence and TLS boundaries

Which iRule snippet correctly logs the client IP and selected pool member after load-balancing?

  1. when LB_SELECTED { log local0. "[IP::client_addr] -> [LB::server addr]" } Correct answer.
  2. when CLIENT_ACCEPTED { puts [IP::client_addr] }
  3. when HTTP_REQUEST { print [IP::client_addr] }
  4. when SERVER_CONNECTED { echo "connected" }

Explanation

In LB_SELECTED, the LB::server command exposes the chosen pool member; combined with IP::client_addr and log local0., this writes a structured entry to /var/log/ltm. puts/print/echo are not iRule logging primitives. CLIENT_ACCEPTED fires before LB selection, so [LB::server addr] would be unavailable.

Question 23BIG-IP TMOS operation, configuration and recovery evidence

Which tmsh command initiates a manual configuration sync to the rest of the device group?

  1. tmsh save /sys config
  2. tmsh run /cm config-sync to-group <group> Correct answer.
  3. tmsh run /sys ucs save
  4. tmsh modify /sys global-settings

Explanation

The listed config-sync to-group command initiates eligible configuration synchronization for the named device group in the specified tmsh model. It is different from a local save or archive. Validate actual group state and source configuration; synchronization does not universally include every runtime session, external dependency or application recovery requirement.

Question 24BIG-IP TMOS operation, configuration and recovery evidence

What is contained in a UCS (User Configuration Set) archive?

  1. Only the LTM virtual server objects
  2. System configuration, secret keys, certificates, and the license file Correct answer.
  3. Only the license file
  4. Operating system images

Explanation

A UCS archive includes the full system configuration (TMOS objects), system files such as /etc, certificates, private keys, and the device's license file. It is the standard backup for restoring a unit identical to the original or migrating to a like-licensed replacement. UCS does not include OS images.

Question 25BIG-IP TMOS operation, configuration and recovery evidence

Which tmsh command creates a UCS backup archive named today.ucs?

  1. tmsh save /sys ucs today Correct answer.
  2. tmsh save /sys config file today
  3. tmsh load /sys ucs today
  4. tmsh archive create today

Explanation

tmsh save /sys ucs today creates /var/local/ucs/today.ucs. To restore, use tmsh load /sys ucs today. save /sys config without 'ucs' creates an SCF, not a UCS. There is no 'archive create' subcommand.

Question 26BIG-IP TMOS operation, configuration and recovery evidence

What is an SCF (Single Configuration File) and how does it differ from a UCS?

  1. SCF is a binary disk image; UCS is a text file
  2. SCF is a portable text export of the configuration excluding system files and license; UCS is a binary archive that includes system files, secrets, and license Correct answer.
  3. SCF and UCS are interchangeable
  4. SCF includes only certificates

Explanation

An SCF is a human-readable text export of the TMOS configuration (saved with tmsh save /sys config file <name>) suitable for migration between dissimilar units, version control, or audits. It excludes system files, private keys, and the license. UCS is a binary archive that includes those.

Question 27BIG-IP TMOS operation, configuration and recovery evidence

On a typical BIG-IP appliance, what are HD1.1, HD1.2, etc.?

  1. Volume names referring to separate boot locations on disk that hold different software images Correct answer.
  2. Hardware diagnostic codes
  3. Hot-spare drive labels
  4. Backup partitions for UCS

Explanation

BIG-IP organises software installation into boot 'volumes' such as HD1.1, HD1.2, HD1.3 (or MD/SSD equivalents). Each holds an independent software image. tmsh show /sys software status lists volumes; an admin can install a new version into an unused volume and switch boot to it (tmsh modify /sys db boot.active.volume).

Question 28BIG-IP TMOS operation, configuration and recovery evidence

Which tmsh command installs a software image (or hotfix) into a target boot volume?

  1. tmsh install /sys software image <iso> Correct answer.
  2. tmsh save /sys software
  3. tmsh load /sys ucs
  4. tmsh restart /sys software

Explanation

tmsh install /sys software image <iso> volume <vol> [reboot] installs the image into the specified volume and optionally reboots. To install a hotfix, the equivalent is tmsh install /sys software hotfix <iso> volume <vol>. save and load are not used for software installation. There is no 'restart /sys software'.

Question 29BIG-IP TMOS operation, configuration and recovery evidence

After installing a new software image to volume HD1.2, how do you reboot from that new volume?

  1. tmsh reboot /sys volume HD1.2 (or set boot location and reboot) Correct answer.
  2. tmsh save /sys config and wait
  3. Manually press the front-panel reset
  4. Reinstall over HD1.1

Explanation

After installing into a target volume, you can boot from it with tmsh reboot /sys volume HD1.2 or set the active boot location and reboot. save /sys config persists configuration but does not change the boot volume. The front panel does not change boot location, and reinstalling overwrites images.

Question 30BIG-IP TMOS operation, configuration and recovery evidence

Which BIG-IP credential, applied to a system, unlocks the data-plane features the customer purchased?

  1. The license file (dossier-derived) - including base registration key and add-ons Correct answer.
  2. An SSH host key
  3. The qkview file
  4. DevCentral account

Explanation

BIG-IP licensing combines the base registration key with optional add-on modules. The unit generates a dossier (a hashed device fingerprint), which is exchanged with F5 (online or offline) to produce a license file. Without an active license, the data plane is restricted. SSH host keys, qkview files, and DevCentral accounts are not licensing artefacts.

Question 31BIG-IP TMOS operation, configuration and recovery evidence

On BIG-IP VE (Virtual Edition), what determines the throughput, modules, and CPU/RAM the VE will run with?

  1. The host hypervisor only
  2. The license tier and the deployed VM size Correct answer.
  3. The TMM kernel version
  4. The DNS profile

Explanation

BIG-IP VE behaviour is determined by the license tier (LTM Standalone, Better, Best, or specific Tx Gbps SKUs) AND the VM resources allocated (vCPU/RAM). The license caps throughput and feature set; the VM size constrains CPU/memory available to TMM. Hypervisor influences performance but not feature licensing.

Question 32BIG-IP TMOS operation, configuration and recovery evidence

You added a new VLAN through the GUI. Which step is required for the change to be persisted across reboots?

  1. Reboot the device
  2. Save the configuration (Save Configuration / tmsh save sys config) Correct answer.
  3. Restart TMM
  4. Run qkview

Explanation

On BIG-IP, GUI/tmsh changes are written to the running configuration but must be persisted to disk with Save Configuration (System > Archives) or tmsh save sys config to survive a reboot. Reboot does not persist; restarting TMM does not persist; qkview is a diagnostic.

Question 33BIG-IP TMOS operation, configuration and recovery evidence

In the BIG-IP GUI, where do you create or upload a UCS backup archive?

  1. System > Archives Correct answer.
  2. Local Traffic > Archives
  3. Network > Archives
  4. Security > Archives

Explanation

System > Archives is the GUI location for UCS archive create/upload/restore. The other paths are not the documented location.

Question 34BIG-IP TMOS operation, configuration and recovery evidence

What is the function of NTP on a BIG-IP, and why is it especially important in HA pairs?

  1. NTP is optional and only affects log timestamps
  2. NTP keeps clocks synchronized across the device group; without it, certificate trust, config sync, and event correlation can fail Correct answer.
  3. NTP serves time to clients
  4. NTP enables HTTP profile compression

Explanation

BIG-IP relies on synchronized time across the device group for certificate validation (HA mesh certs), config-sync timestamps, log correlation, and SSL session caches. Drift between peers can cause authentication and sync failures. NTP is therefore strongly recommended on all members.

Question 35BIG-IP TMOS operation, configuration and recovery evidence

Which feature lets BIG-IP forward SNMP traps to a central network management station for hardware and system events?

  1. SNMP trap destinations Correct answer.
  2. syslog only
  3. Web console alerts
  4. DNS resolvers

Explanation

BIG-IP supports SNMPv1/v2c/v3 trap destinations configured under sys snmp traps. The device generates traps for hardware faults, software events, and threshold breaches. Syslog is a parallel mechanism for free-text logs. Web alerts require a UI session. DNS resolvers are unrelated.

Question 36BIG-IP TMOS operation, configuration and recovery evidence

Which file path stores the running BIG-IP LTM configuration on disk?

  1. /etc/passwd
  2. /config/bigip.conf Correct answer.
  3. /var/log/ltm
  4. /usr/sbin/tmsh

Explanation

/config/bigip.conf is the primary stored LTM configuration file, written when you save sys config. /config/bigip_base.conf stores network/system-level config. /etc/passwd is OS user data. /var/log/ltm is logs. /usr/sbin/tmsh is the binary.

Question 37BIG-IP TMOS operation, configuration and recovery evidence

How are passwords stored in the BIG-IP configuration files for objects such as monitors and SNMP communities?

  1. In plain text
  2. Encrypted with master key (visible as $M$ ciphertext) by default Correct answer.
  3. Hashed only
  4. Removed from config

Explanation

Sensitive values such as monitor send/receive strings, SNMP communities, and key passphrases are stored encrypted in bigip.conf using the device's master key (visible as $M$... ciphertext). The master key is stored in /config/bigip.conf-encrypted regions. Plaintext storage would be a security failure.

Question 38BIG-IP TMOS operation, configuration and recovery evidence

You issue tmsh save /sys config and the command warns that the save will overwrite a partner's configuration. Which condition is most likely the cause?

  1. The device group is in 'Changes Pending' on the local device and the wrong member is being saved as canonical Correct answer.
  2. Disk full
  3. Wrong NTP
  4. Bad license

Explanation

In a sync-failover device group, save sys config alone does not synchronize - it persists the running config locally. Warnings about overwriting a partner's config occur with sync operations when the wrong direction would overwrite peer changes. Disk full, NTP, and licensing produce different errors.

Question 39BIG-IP TMOS operation, configuration and recovery evidence

You change the IP of a self-IP and the GUI says the change saved. The change persists across reboots only after which action?

  1. Run save sys config Correct answer.
  2. Reboot
  3. Restart sshd
  4. Run qkview

Explanation

Net configuration changes such as self-IP edits are written to running config but require save sys config (or System > Archives > Save Configuration) to be persisted to bigip_base.conf. Reboot without save loses the change.

Question 40BIG-IP TMOS operation, configuration and recovery evidence

Which command provides DNS resolver settings used by the BIG-IP system itself for management-plane lookups?

  1. tmsh list /sys dns Correct answer.
  2. tmsh list /ltm pool
  3. tmsh show /net interface
  4. tmsh show /sys hardware

Explanation

tmsh list /sys dns shows the system DNS resolver configuration (name servers, search domain). list /ltm pool is a load-balancing pool. show /net interface and show /sys hardware are unrelated.

Question 41BIG-IP TMOS operation, configuration and recovery evidence

You need to confirm the active boot volume after an upgrade. Which command shows installed software with active and boot status?

  1. tmsh show /sys software status Correct answer.
  2. tmsh show /sys version
  3. tmsh list /sys global-settings
  4. tmsh show /ltm pool

Explanation

tmsh show /sys software status lists every volume's installed image, its product/version/build, and which is the active boot volume. show /sys version shows only the running version. list /sys global-settings shows non-software settings. show /ltm pool is unrelated.

Question 42BIG-IP TMOS operation, configuration and recovery evidence

What is required to apply add-on modules (such as ASM, AFM, APM) to a BIG-IP after the base license is in place?

  1. Re-activate the license with the add-on key included; modules become available after provisioning Correct answer.
  2. Reinstall the OS
  3. Replace hardware
  4. Enable jumbo frames

Explanation

After purchasing add-ons, reactivate the license so the add-on entitlements are present. Then provision the modules under System > Resource Provisioning (or tmsh modify /sys provision). The new module becomes available after provisioning, often requiring a reboot or service restart depending on the module.

Question 43BIG-IP TMOS operation, configuration and recovery evidence

Which provisioning level setting allows a module to be installed but with minimal CPU/memory footprint?

  1. Dedicated
  2. Nominal
  3. Minimum Correct answer.
  4. None

Explanation

BIG-IP module provisioning levels are None, Minimum, Nominal, and Dedicated. Minimum installs with the smallest footprint suitable for occasional use. Nominal is balanced; Dedicated reserves the most CPU/memory and may disable other modules. None means unprovisioned.

Question 44BIG-IP TMOS operation, configuration and recovery evidence

Which tmsh command shuts down or reboots the BIG-IP cleanly?

  1. tmsh reboot or tmsh halt Correct answer.
  2. tmsh kill -9 1
  3. tmsh remove /sys ucs *
  4. tmsh clear /sys connection

Explanation

tmsh reboot performs a clean reboot. tmsh halt powers off the appliance. kill -9 1 would attempt to kill init - unsupported and dangerous. remove /sys ucs * deletes archives. clear /sys connection only flushes connections.

Question 45BIG-IP TMOS operation, configuration and recovery evidence

Which tmsh command shows the current overall device state and HA failover state (Active/Standby/Forced Offline)?

  1. tmsh show /cm failover-status Correct answer.
  2. tmsh show /sys version
  3. tmsh list /cm device
  4. tmsh show /sys ucs

Explanation

tmsh show /cm failover-status reports the active/standby state of the device for each traffic group, including 'Active', 'Standby', or 'Forced Offline'. show /sys version reports software version. list /cm device shows device-group membership configuration. show /sys ucs lists UCS archives.

Question 46BIG-IP TMOS operation, configuration and recovery evidence

In a sync-failover device group, which config-sync state means the local device's configuration matches the active configuration of the group?

  1. In Sync Correct answer.
  2. Awaiting Initial Sync
  3. Disconnected
  4. Changes Pending

Explanation

In Sync means the local device's configuration matches the group's active configuration. Awaiting Initial Sync occurs after first joining a group. Disconnected means peers cannot communicate. Changes Pending means local edits have not yet been pushed.

Question 47BIG-IP TMOS operation, configuration and recovery evidence

Which BIG-IP HA failover method uses a dedicated serial cable between two devices?

  1. Hardware-based (serial cable) failover Correct answer.
  2. Network-based unicast failover
  3. Multicast network failover
  4. Auto Last Hop

Explanation

Hardware-based failover uses a dedicated serial cable between two BIG-IP appliances and provides instantaneous, link-level detection of peer state. Network-based failover (unicast or multicast) uses heartbeat packets over an IP network. Auto Last Hop is a routing feature unrelated to failover.

Question 48BIG-IP TMOS operation, configuration and recovery evidence

Which HA failover transport sends regular keepalives to specific peer IP addresses, suitable in environments where multicast is blocked?

  1. Hardware (serial)
  2. Network failover Unicast Correct answer.
  3. Network failover Multicast
  4. Out-of-band SSH

Explanation

Network failover Unicast sends keepalives directly to configured peer IPs (typically the HA self-IPs). It is the recommended choice in datacenters where multicast is filtered. Multicast failover requires multicast support on the HA VLAN. Hardware uses a serial cable. SSH is not used for HA failover.

Question 49BIG-IP TMOS operation, configuration and recovery evidence

Which device group type performs configuration sync between members but does NOT provide automatic failover of traffic groups?

  1. Sync-Failover
  2. Sync-Only Correct answer.
  3. Sync-Failover with Auto Sync
  4. Heartbeat group

Explanation

Sync-Only device groups push configuration between members but do not exchange failover heartbeats or own traffic groups. They are useful when you want consistent config (for example shared partitions) without coupled failover. Sync-Failover groups both sync configuration and own traffic groups for failover. 'Heartbeat group' is not a real type.

Question 50BIG-IP TMOS operation, configuration and recovery evidence

Which command shows the BIG-IP system uptime, software version, build, and chassis details?

  1. tmsh show /sys version Correct answer.
  2. tmsh show /sys hardware
  3. tmsh show /sys ucs
  4. tmsh show /sys ntp

Explanation

tmsh show /sys version reports product, version, build, edition, and uptime. show /sys hardware lists hardware components. show /sys ucs lists archives. show /sys ntp shows NTP state.