Free F5 F5CAB1 Practice Exam with Questions & Answers

The screenshot shown is from the User Administration section of the BIG-IP GUI.

This section controls:

Root and Admin passwords

SSH Access

SSH IP Allow settings

However, it does not contain any controls for restricting access to the WebUI (TMUI) .

BIG-IP does not provide TMUI access restrictions from this part of the GUI.

Access to the web-based Configuration Utility is controlled by the httpd allow list , configured through TMSH:

tmsh modify /sys httpd allow { < IP/subnet > }

This setting is not displayed in the User Administration panel, and in many BIG-IP versions, the httpd allow list is only configurable from the CLI , not the GUI.

Therefore, the administrator cannot find the setting in the screen shown because:

TMUI access restriction is not located in this GUI section

It must be configured using tmsh under /sys httpd allow

This is why Option A is correct.

The BIG-IP has two distinct planes:

Management-plane → handled entirely by the management interface (MGMT)

Data-plane (TMM) → handles Self IPs, VLAN interfaces, and traffic processing

To capture traffic on the management interface, only the management-side NICs may be used:

mgmt → Logical name for the management interface

eth0 → Physical Linux interface mapped to the management port on most BIG-IP platforms

Both of these correctly capture inbound/outbound WebUI (HTTPS/443) traffic on the management port.

Why the correct answers are A and B

A. tcpdump -i eth0 -n port 443

On BIG-IP appliances and VMs, the management port maps to eth0 at the Linux OS level.

Capturing on eth0 correctly shows HTTPS traffic to the WebUI.

B. tcpdump -i mgmt -n port 443

mgmt is the BIG-IP alias for the management interface.

This is the preferred and most explicit capture interface for management-plane packet captures.

Why the other options are incorrect:

C. tcpdump -i 0.0

Interface 0.0 is the TMM switch interface used for data-plane packet captures.

It does NOT capture management-plane traffic.

D. tcpdump -i tun0

Used for tunnel interfaces (IPsec, VXLAN, etc.)

Not related to management access.

E. tcpdump -i management

There is no interface named management on BIG-IP.

The correct names are mgmt or eth0.

To understand:

Which modules are licensed

Which modules are provisioned

The resource requirements (CPU / RAM) of each module

The administrator uses:

System » Resource Provisioning

This page displays:

All modules present in the license

Whether they are enabled or disabled

Required memory to activate each module

CPU and disk allocation information

Provisioning level options (None / Minimal / Nominal / Dedicated)

This is the exact location where BIG-IP administrators evaluate module capacity before enabling or purchasing licensing upgrades.

Why the other options are incorrect:

A. Configuration » OVSDB

Used for network virtualization integrations, not licenses or modules.

B. Software Management

Used for software image installation, not licensing.

C. Configuration » Device

Displays hostname, failover settings, device properties — not module resource requirements.

Thus, module licensing and memory requirement data are found under Resource Provisioning .

Self-IPs include a security feature called Port Lockdown , which restricts which services respond on that Self-IP.

By default, Self-IPs block management access (SSH and HTTPS/TMUI), meaning an administrator cannot manage the device through in-band Self-IPs unless explicitly allowed.

Allow Mgmt / Allow Management

These settings enable only the management services required for administrative access, specifically:

SSH (22)

HTTPS/TMUI (443)

These options allow secure administration without opening unnecessary ports.

Why these are correct:

They provide only the essential access for management.

They follow F5 security best practices when using in-band admin access.

They do not expose all services, reducing the attack surface.

Why the other options are incorrect:

A. Allow Default

This allows only a minimal set of system-required ports (e.g., failover, config sync), not SSH or HTTPS.

Administrator access would still fail.

B. Allow All

Opens all ports on the Self-IP, which is not secure .

Exposes services that should remain restricted.

Therefore, Allow Mgmt / Allow Management are the correct choices.

Self-IPs implement a security feature known as Port Lockdown , which limits which services are reachable on a Self-IP.

However, certain services required for BIG-IP device-to-device communication bypass Port Lockdown to ensure cluster and HA functionality.

TCP 4353

TCP port 4353 is used by Device Service Clustering (DSC) for:

Device trust establishment

Configuration synchronization

Failover communication

Because BIG-IP devices must always be able to communicate for HA functions to remain operational, port 4353 is exempt from Port Lockdown rules .

Why the other options are incorrect

A. TCP 443

Not required for device trust or synchronization.

HTTPS access is fully controlled by Port Lockdown.

C. UDP 53

DNS traffic is not required for synchronization and has no exemption under Port Lockdown.

BIG-IP controls access to the web-based Configuration Utility (TMUI) through the /sys httpd allow list. This parameter specifies which client IPs or subnets may initiate HTTP/HTTPS connections to the management interface.

To restrict TMUI access to only the 10.0.0.0/24 subnet:

The correct method is to modify the HTTPD allow list so that it contains only this subnet.

This requires replacing the entire current list with the new subnet using:

modify /sys httpd allow replace-all-with {10.0.0.0/24}

This ensures that only clients within 10.0.0.0/24 can reach the Configuration Utility.

Why the other options are incorrect:

Options A and C create network ACL objects under /net acl, which apply to data-plane traffic, not management-plane TMUI access. TMUI access is not controlled by LTM ACLs but by the HTTPD allow directive.

Option B is incorrect syntax and references /ltm httpd, which is not the proper object; the correct hierarchy is /sys httpd.

Thus, only modifying the /sys httpd allow list achieves the required restriction.

When a TMOS image (.iso file) is uploaded into the /shared/images/ directory, the BIG-IP performs an internal validation step before the ISO appears in the GUI.

1. The system verifies the internal checksum

BIG-IP automatically reads the embedded checksum inside the ISO file

Verifies integrity of the uploaded image

Confirms the file is not corrupted or incomplete

Ensures the image is a valid F5 TMOS software image

Only after this checksum verification succeeds does the image appear under:

System → Software Management → Image List

Why the other options are incorrect:

A. The system performs a reboot into a new partition

Uploading an ISO file never triggers a reboot.

C. The system copies the image to /var/local/images/

All valid TMOS images remain in /shared/images/ .

No copying occurs.

When installing a HotFix on a BIG-IP device, F5 best practices require:

Installing the base TMOS image on a new, unused boot volume (HD1.2)

This ensures the upgrade happens on a clean volume.

The existing active boot location remains untouched for rollback.

Installing the HotFix onto the SAME new boot volume (HD1.2)

HotFixes must be applied on top of a base version.

They cannot be installed on an empty volume.

They must match the base image version.

Activating the new boot volume (HD1.2)

The system reboots into the updated software stack.

Activation happens after base + HotFix installation is complete.

This sequence is exactly shown in Option C :

Install base Image in HD1.2

Install HotFix in HD1.2

Activate HD1.2

Why the other options are incorrect:

A. Install HotFix before base image

Impossible.

HotFix requires an installed base version first.

B. Installing HotFix on HD1.1 (active boot volume)

Not recommended.

Upgrading in-place removes rollback safety.

HotFix cannot be applied cleanly without applying base image first.

D. Activate HD1.2 before installing anything

You cannot activate an empty boot volume.

Activation only occurs after the base + HotFix software is installed.

Comprehensive and Detailed Explanation From BIG-IP Administration — Install, Initial Configuration, and Upgrade:

When provisioning modules on a BIG-IP system, F5 provides specific resource allocation settings that define how system resources — CPU, memory, and disk — are distributed to each licensed module. The two valid and officially recognised allocation settings are Nominal and Dedicated .

Nominal instructs the system to allocate a moderate, balanced share of resources to the module. It allows the module to function effectively while sharing system resources with other provisioned modules. This is the most commonly used setting in multi-module deployments.

Dedicated allocates the maximum available system resources exclusively to a single module. When this setting is applied, it is typically the only module provisioned, as it consumes resources at a level that prevents other modules from operating concurrently in a meaningful capacity.

Option A — Maximum is not a valid BIG-IP provisioning allocation level; it does not appear in the official provisioning interface or documentation as a selectable resource tier.

Option C — Limited similarly does not exist as a defined resource allocation setting within BIG-IP module provisioning. It may superficially resemble valid terminology but has no standing in the official provisioning framework.

Administrators access these settings via System » Resource Provisioning in the Configuration Utility, where each licensed module displays its available allocation options.

Reference Topics: Module Resource Provisioning, Nominal vs. Dedicated Allocation, System Resource Management — BIG-IP Administration Study Guide.

BIG-IP systems require all ISO images (base TMOS images and HotFix images) to be stored in a specific directory used for software installation:

/shared/images/

This directory:

Is the only supported location from which the BIG-IP software installation system validates and installs ISO files

Is accessible by both the GUI and TMSH installers

Has adequate storage space allocated specifically for images

Is part of the shared partition that persists across reboots

When transferring images via SCP, the administrator must copy them directly into /shared/images/ so that:

The GUI (System → Software Management → Available Images) can detect the image

TMSH install software image commands can reference it

Other directories such as /local/images/ or /var/images/ are not valid storage paths for software images.