• Home
• F5 Exams
• 201 - TMOS Administration

201 F5 Practice Test Questions and Exam Dumps

Question 1

What could be a valid reason for a pool to show an offline (red) status, assuming all possible monitor assignments are shown below?

A. No monitors are currently assigned to any pool, member or node.
B. The pool has a monitor assigned to it, and none of the pool members passed the test.
C. The pool has a monitor assigned to it, and only some of the pool's members passed the test.
D. A monitor is assigned to all nodes and all nodes have passed the test. The pool's members have no specific monitor assigned to them.

Correct Answer: B

Explanation:
In a load balancing environment such as with F5 BIG-IP or similar systems, the health and availability of a pool (which is a collection of pool members—typically nodes with specific services) is determined by the status of the monitors applied. Monitors are used to check the health of nodes, pool members, or even the pool itself. If the monitor fails, the associated object is marked as offline or degraded.

Let’s analyze each option:

A. No monitors are currently assigned to any pool, member or node.
If there are no monitors applied anywhere—neither to the pool, the pool members, nor the nodes—then the system doesn't have any health checks to rely on. In many systems like F5, if no monitors are assigned, the pool or members may be marked as unknown or possibly available depending on the system's default behavior. But they would not be marked offline (red) simply due to lack of monitoring. Thus, this doesn’t explain a red/offline status.

B. The pool has a monitor assigned to it, and none of the pool members passed the test.
This is the most accurate and direct explanation. If a monitor is directly assigned to the pool (as opposed to individual pool members), it applies its logic to the members within the pool. If none of the pool members pass the health check, the pool itself is marked offline. This is the classic case for a pool going red—meaning it has been actively evaluated and found to have no healthy resources. Therefore, this condition would result in a pool status of offline (red).

C. The pool has a monitor assigned to it, and only some of the pool's members passed the test.
In this scenario, while not all pool members are healthy, the presence of at least one passing member means the pool itself is not entirely down. Most systems will show the pool as partially available or degraded (often a yellow/orange status), but not offline (red). Therefore, this doesn’t fully justify a red/offline pool state.

D. A monitor is assigned to all nodes and all nodes have passed the test. The pool's members have no specific monitor assigned to them.
This scenario explains that nodes are being monitored and are all healthy, but there are no monitors on the pool members or the pool itself. In such a case, the pool's status may vary by system, but typically it would either inherit a status based on node health or be considered unknown. Again, this would not result in a red/offline state because there is no failed monitoring directly affecting the pool members. So this explanation does not align with a confirmed offline pool status.
The key to understanding this question is recognizing what a pool status of offline really means: the load balancer actively checked the health of the pool and found no valid, functioning resources. That would only be the case if health checks were applied and all failed. Option B directly states that a monitor is assigned to the pool and none of the members passed—which matches this condition precisely.

Thus, the correct answer is B.

Question 2

You are tasked with terminating client SSL traffic at the BIG-IP and ensuring client sessions persist to the same pool member using a cookie issued by the BIG-IP. Which four profiles should typically be included in the virtual server's configuration? (Choose four.)

A. TCP
B. HTTP
C. HTTPS
D. ClientSSL
E. ServerSSL
F. CookieBased Persistence

Correct Answer : A, B, D, F

Explanation:

When configuring a virtual server on an F5 BIG-IP device to terminate SSL traffic and persist client sessions using a cookie, you must apply a specific combination of profiles that address transport, decryption, application layer handling, and session persistence.

Option A, TCP, is essential because SSL (and thus HTTPS) traffic runs over the TCP protocol. This profile handles low-level transport functions like connection setup, retransmissions, and window scaling. Without it, the virtual server would be unable to manage the fundamental network transport of the incoming client connections.

Option B, HTTP, is needed for the BIG-IP to interpret and interact with the HTTP protocol at the application layer. Since the goal is to persist based on a cookie, and cookies exist in HTTP headers, the HTTP profile must be enabled. It also allows the BIG-IP to read, inspect, and modify HTTP traffic after it is decrypted.

Option D, ClientSSL, enables the BIG-IP to perform SSL termination by decrypting client SSL traffic. This profile defines the certificate and key used for decryption and controls SSL behavior, including cipher suites and SSL version negotiation. Without this profile, the BIG-IP cannot terminate SSL connections from clients.

Option F, CookieBased Persistence, ensures that once a client connects to a particular pool member, all subsequent connections from that same client are sent to the same pool member. This is achieved using a BIG-IP-generated cookie inserted into HTTP responses, which the client sends back on future requests. This behavior is critical in maintaining session continuity in load-balanced environments.

Now let’s consider why the remaining options are incorrect.

Option C, HTTPS, is not a valid profile in BIG-IP terminology. HTTPS refers to the protocol (HTTP over SSL), but BIG-IP requires separate profiles (ClientSSL for encryption and HTTP for application logic) to support HTTPS traffic. There is no actual "HTTPS" profile to select.

Option E, ServerSSL, is only required if you want the BIG-IP to re-encrypt traffic before sending it to backend servers. Since the question only states SSL termination at the BIG-IP and makes no mention of re-establishing SSL sessions with pool members, the ServerSSL profile is unnecessary here.

In summary, the four required profiles for this configuration are TCP (transport), HTTP (application layer), ClientSSL (SSL termination), and CookieBased Persistence (session persistence). Each plays a distinct and necessary role in successfully handling secure client traffic and maintaining consistent server-side routing.

Therefore, the correct answers are A, B, D, and F.

Question 3

A site needs to terminate client HTTPS traffic at the BIG-IP and forward that traffic unencrypted. Which two are profile types that must be associated with such a virtual server? (Choose two.)

A. TCP
B. HTTP
C. HTTPS
D. ClientSSL
E. ServerSSL

Correct answers: A, D

Explanation:

This question is focused on configuring a BIG-IP virtual server to terminate HTTPS traffic from the client (perform SSL decryption), and then forward the traffic in plaintext (HTTP) to backend servers. This configuration is typically used to offload SSL processing from backend servers and enable inspection or modification of the traffic before it is sent onward.

To understand the correct profile types, let’s break down what is required in this scenario.

Objective:

• Accept encrypted HTTPS traffic from clients

• Decrypt (terminate SSL) at the BIG-IP

• Forward unencrypted HTTP traffic to backend servers

Breakdown of Required Profiles:

A. TCP – Correct
A TCP profile is mandatory for any virtual server handling TCP-based traffic, including HTTP and HTTPS. It defines how the BIG-IP system manages TCP connections, such as timeouts, window scaling, and retransmissions. Without this profile, the virtual server cannot handle basic TCP communications. Therefore, a TCP profile is always required for HTTPS termination and HTTP forwarding.

B. HTTP – Optional/Incorrect in this context
An HTTP profile is used to enable advanced HTTP-specific features like compression, OneConnect, and header rewriting. While it may be useful if you want to inspect or manipulate HTTP traffic, it is not strictly required for terminating HTTPS and forwarding HTTP traffic. The core requirement in this scenario is SSL termination, not HTTP-level functionality. So although it could be used, it is not one of the essential two profiles.

C. HTTPS – Incorrect
There is no actual “HTTPS” profile type in BIG-IP. HTTPS is the protocol, but the BIG-IP uses SSL profiles (ClientSSL and ServerSSL) to manage encrypted traffic. Therefore, this option is incorrect because it refers to a protocol, not a valid profile.

D. ClientSSL – Correct
A ClientSSL profile is required to terminate inbound HTTPS traffic from the client. This profile tells the BIG-IP how to decrypt SSL traffic, what certificates to use, and what ciphers to support. Since the question clearly states that HTTPS termination must occur at the BIG-IP, this profile is mandatory. It performs the decryption of the client-side SSL session.

E. ServerSSL – Incorrect
The ServerSSL profile is used when the BIG-IP needs to re-encrypt traffic before forwarding it to the backend server. However, in this case, the question specifies that traffic must be forwarded unencrypted, so no ServerSSL profile is required or desired. Including a ServerSSL profile would cause the traffic to be re-encrypted, which contradicts the requirement.

The two essential profile types for a BIG-IP virtual server that terminates HTTPS traffic and forwards it as plaintext are:

• TCP profile (for handling the transport layer protocol)

• ClientSSL profile (for terminating SSL)

These enable the BIG-IP to accept encrypted connections, decrypt them for inspection or processing, and then forward the traffic unencrypted.

Correct answers: A, D

Question 4

Which of the following statements correctly describe characteristics of profiles in a load balancer system like F5? (Choose three.)

A. Default profiles cannot be created or deleted.
B. Custom profiles are always based on a parent profile.
C. A profile can be a child of one profile and a parent of another.
D. All changes to parent profiles are propagated to their child profiles.
E. While most virtual servers have at least one profile associated with them, it is not required.

Correct Answers: A, B, C

Explanation:
Profiles in systems like F5 BIG-IP are used to define specific behaviors and settings for different aspects of traffic management such as TCP handling, SSL offloading, HTTP manipulation, and more. Profiles are modular, reusable configurations that can be applied to virtual servers and other entities. Understanding how profiles work—including default and custom types, inheritance, and relationships—is essential for effective configuration and troubleshooting.

Let’s examine each of the given statements:

A. Default profiles cannot be created or deleted.
This statement is true. In systems like F5, default profiles are included with the system software and are intended to serve as templates or fallbacks. These profiles (e.g., tcp, http, clientssl) are system-provided and cannot be deleted or recreated by users. While you can clone or base a custom profile on a default one, you cannot alter or remove the original default profile. This immutability ensures that administrators always have a known starting point for creating custom configurations.

B. Custom profiles are always based on a parent profile.
This is also accurate. Any time a user creates a custom profile, it must be based on an existing profile—either a default or another custom profile. This parent-child structure allows for the inheritance of settings. If a setting in the child profile is not explicitly overridden, it inherits that value from the parent. This makes profile management more efficient and consistent across many virtual servers.

C. A profile can be a child of one profile and a parent of another.
This is a true characteristic. Custom profiles can act both as children (inheriting settings from a parent profile) and as parents to other custom profiles. This layering allows for a flexible hierarchy of profiles. For example, you might create a custom SSL profile based on the default clientssl profile, and then build environment-specific profiles on top of that (e.g., clientssl_prod, clientssl_dev), each inheriting from your custom base. This multi-level inheritance model helps streamline configuration.

D. All changes to parent profiles are propagated to their child profiles.
This statement is false. While child profiles inherit settings from their parents, only the inherited (non-overridden) settings are affected by changes in the parent profile. If a child profile has overridden a particular setting, then changes to the parent’s version of that setting will not affect the child. For example, if a child profile overrides the idle timeout setting, a change in the parent’s idle timeout will not be reflected in the child. So changes are not universally propagated, only selectively where inheritance is still in place.

E. While most virtual servers have at least one profile associated with them, it is not required.
This statement is incorrect. Profiles are essential for virtual server functionality. In fact, a basic set of profiles is usually required to define how the virtual server processes traffic. For example, a TCP virtual server will typically need a TCP profile, and an HTTP server needs an HTTP profile. Some profiles are automatically applied if not explicitly set, but a virtual server without any profiles would not function properly. Therefore, it is misleading to say that profiles are not required.

The three correct characteristics of profiles are:

• A (Default profiles cannot be created or deleted)

• B (Custom profiles are based on a parent)

• C (Profiles can act as both child and parent)

Therefore, the correct answers are A, B, C.

Question 5

Which cookie persistence method involves the least amount of configuration change on web servers to be implemented properly?

A. insert
B. rewrite
C. passive
D. session

Correct Answer : A

Explanation:

Cookie persistence is a method used by load balancers, like F5 BIG-IP, to ensure that a client’s requests are consistently directed to the same backend server for the duration of a session. This is especially important for applications that maintain session-specific data on a particular server. There are several cookie persistence methods available, each differing in terms of how they manage cookies and how much involvement is required from the web servers themselves.

The insert method requires the least amount of configuration change on web servers because it is entirely handled by the load balancer (BIG-IP). In this method, the BIG-IP device generates a new cookie—typically named something like BIGipServer<pool-name>—and inserts it into the HTTP response before it reaches the client. This inserted cookie contains encoded information that allows the BIG-IP to identify the correct pool member on future requests from that client.

Since the web server is not aware of this cookie and does not need to process or modify it in any way, there are no required changes to the web server's code or configuration. It continues to operate as usual, unaware that the persistence mechanism is happening entirely through the load balancer’s intervention.

The rewrite method, on the other hand, involves modifying an existing cookie that is already set by the web application. In this scenario, the BIG-IP intercepts the response and alters a designated cookie’s value to include persistence-related information. This technique often requires coordination with the application developers or changes to the cookie settings on the server, such as ensuring the correct cookie name and format are used, or avoiding conflicts with other uses of the same cookie.

The passive method monitors the application's own cookie (without modifying or injecting any cookie). It requires that the web server already sets a cookie that can be used for persistence. This approach involves some configuration on the server side to ensure the proper cookie is created and contains information that the BIG-IP can use to determine the appropriate server. So while it avoids changes to how cookies are transmitted, it depends on application-level setup.

The session method refers more generally to application-managed session handling, which may involve server-side session IDs and other mechanisms. In some contexts, it could require the use of a session database or sticky session configurations, which may involve significant server-side adjustments, depending on how the application is designed.

In summary, the insert method is the least intrusive because the BIG-IP handles everything independently—generating, injecting, and using the cookie for persistence—without requiring any changes or cooperation from the web server or application code. This makes it the most convenient method when minimal disruption to the existing environment is desired.

Therefore, the correct answer is A.

Question 6

Which statement is true concerning cookie persistence?

A. Cookie persistence allows persistence independent of IP addresses.
B. Cookie persistence allows persistence even if the data are encrypted from client to pool member.
C. Cookie persistence uses a cookie that stores the virtual server, pool name, and member IP address in clear text.
D. If a client's browser accepts cookies, cookie persistence will always cause a cookie to be written to the client's file system.

Correct answer: A

Explanation:

This question is focused on understanding how cookie persistence works on load balancers such as F5 BIG-IP devices. Cookie persistence, sometimes referred to as cookie-based session persistence, is a method used to ensure that a client is consistently directed to the same backend server during a session, based on a special cookie inserted into the client’s browser.

Let’s analyze each option in detail.

A. Cookie persistence allows persistence independent of IP addresses – Correct

This statement is true. Cookie persistence does not rely on the client's IP address to maintain session persistence. Instead, the BIG-IP inserts a cookie into the HTTP response, which is stored by the client's browser. On subsequent requests, the browser sends this cookie back, and the load balancer uses the cookie value to route the request to the same backend server. This approach allows clients behind NATs or proxy servers (which may change IPs) to still maintain a persistent connection to the same server.

This independence from IP addresses is one of the main advantages of cookie persistence over other persistence types like source address affinity.

B. Cookie persistence allows persistence even if the data are encrypted from client to pool member – Incorrect

This statement is false because cookie persistence requires visibility into HTTP headers, and for the BIG-IP to insert or read a cookie, the traffic must be decrypted at the BIG-IP. If the data is encrypted end-to-end (from the client all the way to the backend server), the BIG-IP cannot see or insert cookies into the HTTP stream. Therefore, cookie persistence will not function in a fully encrypted tunnel unless SSL is terminated at the BIG-IP.

C. Cookie persistence uses a cookie that stores the virtual server, pool name, and member IP address in clear text – Incorrect

This statement is partially misleading and therefore incorrect. In reality, F5’s default cookie persistence (called “insert mode”) stores only a coded version of the pool member’s IP and port in the cookie. It does not store the virtual server or pool name. Moreover, while it may be in clear text in default mode, you can configure the BIG-IP to encrypt or hash the cookie for security. So the claim that it always stores that specific data in clear text is inaccurate.

D. If a client's browser accepts cookies, cookie persistence will always cause a cookie to be written to the client's file system – Incorrect

This is not necessarily true. The cookie used for persistence is often a session cookie, which is stored in the client’s browser memory and deleted when the browser is closed. It is not always written to the file system like a persistent cookie (e.g., one with an expiration date). Whether or not it is written to disk depends on the configuration of the cookie itself, specifically the expiration settings.

Cookie persistence allows for maintaining client sessions without relying on the client’s IP address, which makes it particularly useful in environments where clients are behind NATs, proxies, or other IP-masking technologies. This makes option A the correct and most accurate description of how cookie persistence works in practice.

Correct answer: A

Question 7

If a virtual server is configured with a ServerSSL profile, what type of SSL certificates are required on the pool members?

A. No SSL certificates are required on the pool members.
B. The pool members’ SSL certificates must only exist.
C. The pool members’ SSL certificates must be issued from a certificate authority.
D. The pool members’ SSL certificates must be created within the company hosting the BIGIPs.

Correct Answer: C

Explanation:
To understand this question, it's important to first define what a ServerSSL profile is and how SSL/TLS communication works in a load balancing scenario involving SSL offloading or re-encryption.

A virtual server in an F5 BIG-IP (or similar appliance) can use ClientSSL and/or ServerSSL profiles. These profiles determine how SSL/TLS connections are established between the client, the BIG-IP system, and the backend servers (pool members). When a ServerSSL profile is applied to a virtual server, it means that the BIG-IP will re-encrypt the traffic and establish an SSL connection with the pool members on behalf of the client. This is commonly referred to as SSL bridging or SSL re-encryption.

For the ServerSSL profile to function properly, the pool members must present valid SSL certificates to the BIG-IP when it initiates SSL handshakes. Let’s analyze the choices in light of this:

A. No SSL certificates are required on the pool members.
This is incorrect. A ServerSSL profile means the BIG-IP expects to create an SSL connection with the pool members. That requires the pool members to present SSL certificates during the handshake. Without them, the SSL handshake would fail, resulting in an inability to establish the backend connection.

B. The pool members’ SSL certificates must only exist.
This is misleading. While the certificates must exist, existence alone is not sufficient. The BIG-IP (by default) will attempt to validate the certificate presented by the server (pool member) to ensure it’s legitimate and trusted. That means the certificate must meet certain conditions—like being issued by a recognized certificate authority (CA) or matching expected subject names.

C. The pool members’ SSL certificates must be issued from a certificate authority.
This is correct under standard ServerSSL behavior. By default, BIG-IP validates the pool members' certificates during the SSL handshake, and this validation includes checking whether the certificate is signed by a trusted CA. The ServerSSL profile includes settings to control whether the certificate must be verified, whether self-signed certs are allowed, and whether the certificate's common name or subject alternative name matches the expected host.

In enterprise environments, these certificates are typically CA-signed to ensure trust and security. Although it’s possible to disable certificate verification in the ServerSSL profile, that’s not the default and should not be assumed in a general question like this.

D. The pool members’ SSL certificates must be created within the company hosting the BIGIPs.
This is overly specific and unnecessary. Certificates can be issued from any trusted CA, whether public or internal, as long as the BIG-IP trusts that CA. It does not have to be generated within the same company that manages the BIG-IP. What matters is whether the certificates can be validated, not where they were generated.

To successfully perform SSL re-encryption using a ServerSSL profile, pool members must present valid SSL certificates. These certificates must typically be issued by a trusted certificate authority so that BIG-IP can validate them during the SSL handshake.

Question 8

When setting up a Virtual Server that uses an iRule with the HTTP_REQUEST event, which sequence correctly outlines the steps needed to create all required components?

A. create profiles, create the iRule, create required pools, create the Virtual Server
B. create the Virtual Server, create required pools, create the iRule, edit the Virtual Server
C. create a custom HTTP profile, create required pools, create the Virtual Server, create the iRule
D. create required pools, create a custom HTTP profile, create the iRule, create the Virtual Server

Correct Answer : D

Explanation:

In F5 BIG-IP configurations, setting up a virtual server with an iRule that references the HTTP_REQUEST event requires that certain foundational objects be in place before others. This ensures that the system can associate the iRule with the correct protocols, services, and server pools. The correct and logical order for creating all necessary components follows a bottom-up approach: establishing the supporting elements (like pools and profiles) before configuring the virtual server that ties everything together.

Step-by-step reasoning for the correct sequence:

1. Create required pools: This is the group of backend servers that will process traffic sent from the virtual server. Pools are essential to complete the virtual server configuration, as the virtual server must know where to send traffic. The pool(s) must exist before the virtual server can reference them.

2. Create a custom HTTP profile: Since the iRule uses the HTTP_REQUEST event, it depends on the virtual server supporting Layer 7 HTTP traffic. A custom HTTP profile (or the default one, in some cases) must be applied to the virtual server to ensure it can parse and manage HTTP-level information, which is required for the iRule to function. Creating a custom HTTP profile beforehand ensures you can fine-tune any required behavior (compression, headers, caching, etc.) for your application needs.

3. Create the iRule: Now that the system knows it will be handling HTTP traffic and which pool the traffic will go to, you can write and create the iRule. The iRule must reference existing event types like HTTP_REQUEST, and it may also reference pools or other BIG-IP objects. It's better to have those referenced objects created before defining the iRule, to avoid configuration errors.

4. Create the Virtual Server: The virtual server acts as the entry point for client traffic. When creating it, you must associate it with the previously defined pool, the HTTP profile, and the iRule. At this point, all the referenced objects exist, allowing for a smooth and complete configuration.

Now, let's explain why the other choices are incorrect:

• Option A suggests creating profiles and the iRule before the pools and virtual server. This order risks referencing non-existent objects in the iRule or virtual server configuration, which can lead to deployment errors.

• Option B starts by creating the Virtual Server first. This is problematic because a virtual server cannot be completed without referencing pools or profiles, which have not yet been created in this sequence.

• Option C puts the creation of the iRule after the virtual server, which doesn’t allow you to bind the iRule during virtual server setup. You would have to edit the virtual server afterward to attach the iRule, which adds unnecessary steps and risk of misconfiguration.

Only Option D follows the logical and dependency-aware progression: build the foundation first (pools, profiles), then add the rules (iRule), and finally assemble the virtual server with everything properly in place.

Therefore, the correct answer is D.