F5 Networks BIG-IP Administration Install, Initial Configuration, and Upgrade F5CAB1 Exam Questions

Answer : A

Access to the BIG-IP Configuration Utility (TMUI) is controlled through the /sys httpd allow list.

This list defines which IP addresses or subnets are allowed to connect to the management web interface.

To allow two new subnets---172.28.31.0/24 and 172.28.65.0/24---the administrator must add both subnets to the existing list without removing current entries.

In tmsh, subnet entries must be specified in network/netmask format, for example:

172.28.31.0/255.255.255.0

The correct tmsh command to append these networks is:

modify /sys httpd allow add { 172.28.31.0/255.255.255.0 172.28.65.0/255.255.255.0 }

Why the other options are incorrect:

Option B:

IPs are listed without masks, which is invalid for subnet-based access control.

The system requires network/netmask format.

Option C:

The command uses permit instead of allow, which is not a valid attribute of /sys httpd.

The correct keyword must be allow.

Thus, only Option A correctly adds both permitted subnets in the proper tmsh format.

Answer : B

To identify which boot volume is currently active on a BIG-IP system, the correct command is:

tmsh show sys software status

This command displays:

All installed boot volumes (HD1.1, HD1.2, HD1.3, etc.)

The BIG-IP software version installed on each volume

The Active field, indicating which volume the system is currently booted from

The installation status (''complete'', ''in-progress'', ''allowed'')

This is the standard and authoritative way to determine the active boot location.

Why the other options are incorrect:

A . tmsh show sys version

Displays OS version, build, and date.

Does not show boot locations or which volume is active.

C . tmsh list sys software update

Shows software update configurations, not boot volume status.

Does not display which volume is active.

Answer : C

Provisioning settings define which modules are enabled and how system resources are allocated to them.

These provisioning declarations are stored in:

/config/bigip.conf

This file contains:

Full module provisioning statements

TMSH-equivalent provisioning configurations such as:

sys provision ltm { level nominal }

sys provision asm { level nominal }

It is the primary system configuration file that stores all active provisioning details.

Why the other answers are incorrect

A . /config/bigip.license

Shows licensed modules, not provisioned modules.

B . /config/bigip_base.conf

Stores base networking (VLANs, Self-IPs, routes), not provisioning.

D . config.ucs

A backup archive, not a live configuration file.

Thus, the correct file to review active module provisioning is /config/bigip.conf.

Answer : A

Provisioning defines how BIG-IP allocates system resources to modules. The provisioning levels include:

Dedicated -- allocates all CPU, memory, and disk resources to a single module

Nominal -- standard resource allocation balanced with other modules

Minimal -- lowest level, used for basic utility needs

None -- module disabled

Comprehensive / Maximal -- not valid TMOS provisioning levels

Why ''Dedicated'' is correct

When a BIG-IP device is intended to run only ASM (Web Application Firewall), the recommended way to maximize performance is to provision the module at Dedicated level.

With ASM: Dedicated:

ASM receives the entire hardware capacity

No other modules can or should be provisioned

This is explicitly recommended when a device is used solely as a WAF platform

Why other options are incorrect

B . Comprehensive / C. Maximal

These are not valid provisioning modes in BIG-IP.

TMOS supports: Nominal, Minimal, Large (module-specific), and Dedicated.

D . Nominal

Shares resources with other modules

Does not provide full system performance

Not suitable when exclusive resource allocation is required

Thus, Dedicated is the correct provisioning choice.

Answer : B, D

Comprehensive and Detailed Explanation (Paraphrased from F5 BIG-IP Administration Install, Initial Configuration, and Upgrade concepts)

When performing a TMOS upgrade, F5 recommends validating the target software version to ensure that the release does not contain defects that may impact system behavior. The upgrade preparation process includes checking for known issues, validating compatibility, and reviewing advisory information for the intended version. Two primary F5 tools serve this purpose:

B . F5 iHealth

iHealth is a cloud-based diagnostic and analysis platform used to evaluate the operational state of a BIG-IP system.

Administrators upload a QKView file to iHealth to receive an automated assessment of the system. As part of upgrade planning, iHealth provides:

Upgrade advisories, identifying potential risks such as deprecated features, module compatibility concerns, or changes in behavior between TMOS versions.

Checks against known defects, allowing administrators to determine whether the target TMOS version contains issues relevant to their deployment.

This aligns with F5's recommended upgrade workflow, where iHealth is used before upgrading to confirm system readiness and detect software-level concerns.

D . F5 Bug Tracker

The Bug Tracker is F5's dedicated interface for reviewing software defects across TMOS releases.

It enables administrators to:

Search for known bugs by TMOS version, module, severity, or defect ID.

Review the status of defects (open, resolved, fixed in later releases).

Identify whether high-impact or security-related issues are associated with the target upgrade version.

F5 documentation emphasizes reviewing known defects prior to installation of new software images, making the Bug Tracker a critical resource for upgrade validation.

Why the other options are not correct

A . F5 End User Diagnostics (EUD)

EUD is used exclusively for hardware diagnostics (ports, memory, fans). It does not provide software-related issue verification and is not used for upgrade planning.

C . F5 University

This is a training platform, not an operational tool. It does not provide defect listings or upgrade-specific warnings.

E . F5 Downloads

Although it provides access to software images and release notes, it is not a tool for identifying known bugs. Release notes summarize general fixes and features, but systematic bug verification requires iHealth or the Bug Tracker.

Answer : A, D

Securing the BIG-IP management interface is a fundamental administrative responsibility. F5 best practices emphasize restricting who can reach the management port and ensuring that only authorized systems are allowed access.

A . Limiting management access to trusted network segments

F5 recommends placing the management interface on a dedicated, isolated, and secured management network or VLAN, rather than exposing it to production or untrusted networks.

This reduces the attack surface by ensuring only trusted segments have visibility to administrative interfaces.

D . Restricting management access by IP or subnet

F5 BIG-IP uses the /sys httpd allow list (for HTTPS) and configuration options in sshd (for SSH) to control which IP addresses or subnets can access the device.

By specifying only known administrative IPs or ranges, unauthorized users cannot reach the login services.

Why the other options are incorrect

B . Blocking all management HTTPS/SSH ports

This would prevent any administrative access and is not a viable security practice.

C . Using Self-IP addresses for administrative access

F5 explicitly warns against using Self-IPs for management access unless strictly necessary.

Self-IPs are exposed to the data plane and should not be used as the primary administrative interface.

Answer : C

The HTTPD allow list controls which IP addresses or subnets may access the Configuration Utility (TMUI) on the BIG-IP system. The Administrator already has two subnets allowed and needs to add a single host IP to the existing list.

The object /sys httpd allow supports actions such as add, delete, and replace-all-with.

Because the goal is to add one more entry without removing the existing permitted subnets, the correct command is:

modify /sys httpd allow add { 172.28.32.22 }

This appends the new host to the existing list while preserving the previously configured networks.

Why the other options are incorrect:

Option A (replace-all-with) would overwrite the entire allow list, removing existing permitted subnets---unacceptable.

Option B (delete) would remove the existing networks and not add the required host.

Therefore, the correct administrative action is to add the jump host's IP.