Important F5 Networks F5CAB3 Exam Questions

Answer: C

Explanation:

Standard DNS queries use UDP. Configuring the Virtual Server for TCP causes DNS traffic to fail.

Answer: C

Explanation:

A 400 Bad Request response from an HTTP/1.1 web server is a definitive indicator that the HTTP request sent by the health monitor is missing a required Host header. In HTTP/1.1, the Host header is mandatory per RFC 7230. Web servers --- particularly those hosting named virtual hosts such as www.f5.com --- will reject any HTTP/1.1 request that omits the Host header, returning a 400 error, which the BIG-IP monitor interprets as a failed health check, marking all members DOWN.

The correct Send string must include:

The GET request line with HTTP/1.1 protocol declaration

A \r\n (carriage return + line feed) after the request line

The Host: www.f5.com header to satisfy HTTP/1.1 requirements

A \r\n after the Host header

Connection: Close header to instruct the server to close the connection after responding

A final \r\n\r\n to properly terminate the HTTP request headers

Only option C satisfies all these requirements with the correct syntax and Host header inclusion.

Option D (the current configured string) omits the Host header entirely --- the root cause of the 400 error. Options A and B are structurally incomplete or syntactically malformed.

Answer: D

Explanation:

This question tests precise knowledge of both TMSH command syntax and BIG-IP object namespace hierarchy. Two critical distinctions must be correctly identified:

1. create vs. modify: Since the Trunk already exists and the administrator is adding interfaces to it, the correct verb is modify --- not create. Using create on an existing object would either throw an error or attempt to overwrite the object entirely, neither of which is the desired outcome.

2. /sys vs. /net namespace: Trunk objects in BIG-IP reside within the /net namespace, which encompasses network-layer constructs including Trunks, VLANs, Self IPs, and Routes. The /sys namespace is reserved for system-level objects such as management settings, software, and licensing --- it does not contain Trunk objects.

Therefore, the only syntactically and functionally correct command is:

tmsh modify /net trunk trunk_A interfaces add {1.3 1.4}

This command appends interfaces 1.3 and 1.4 to the existing trunk_A object without disrupting currently assigned interfaces, increasing aggregated bandwidth accordingly.

Options A and C use the incorrect /sys namespace, and options A and B incorrectly use the create verb for an existing object.

Answer: C

Explanation:

In F5 BIG-IP systems, an iApp is a template-driven framework used to deploy and manage application-specific configurations. When an iApp is deployed, the system creates a specialized folder or 'Application Service' container to hold all the resulting Local Traffic Manager (LTM) objects, such as virtual servers, pools, and profiles. This container is visually and programmatically identified by the .app extension in its path name.

The naming convention for these objects follows a specific hierarchical structure: //<iapp_name>.app/<object_name>. For example, if an administrator creates an iApp named 'testhttp' in the '/Common' partition, the virtual server created by that iApp would be identified in the configuration (TMSH) and the GUI as /Common/testhttp.app/testhttp. This structure allows the BIG-IP system to distinguish between manually created objects and those managed by the iApp's automation logic.

This identification is crucial because iApp-managed objects typically have Strict Updates enabled, which prevents administrators from making direct manual changes to the object settings outside of the iApp's reconfigure interface. Attempting to modify such an object directly will result in an error message stating that the application service must be updated using an application management interface. By recognizing the .app path and the repeated name within the structure, an administrator can immediately identify that the object belongs to an iApp and should be managed through the iApp's specific management screen rather than standard LTM configuration menus.

Answer: D

Explanation:

In F5 BIG-IP architecture, a Trunk is a logical aggregation of physical interfaces designed to increase bandwidth and provide link redundancy through 802.3ad Link Aggregation Control Protocol (LACP). When creating a Trunk object within the BIG-IP configuration, the administrator must assign physical Interfaces to it --- these are the underlying hardware ports (e.g., 1.1, 1.2, 1.3) that will be bundled together to form the aggregated logical link.

It is critical to understand the layered object hierarchy on the BIG-IP platform:

Interfaces assigned to Trunks

Trunks (or individual Interfaces) assigned to VLANs (as tagged or untagged members)

VLANs assigned Self IP addresses

Self IPs / Routes configured at the network layer above

VLANs are not added to a Trunk; rather, a Trunk is added as a member of a VLAN. IP addresses and network routes are configured independently at a higher abstraction layer and have no direct association with Trunk creation.

This layered design ensures proper separation of concerns across the data plane. Misunderstanding this hierarchy is a common configuration error that can result in traffic forwarding failures.