Free Practice Questions for F5 F5CAB1 Exam

A newly deployed BIG-IP Virtual Edition (VE) in VMware requires initial configuration of itsmanagement-ipaddress so it can be accessed over the network. F5 provides several valid mechanisms during initial console access:

A. Running the config utility

The config script is available on new BIG-IP installations and VE deployments.

It launches a guided text-based wizard allowing configuration of:

Management IP

Netmask

Default route

This is a standard and recommended method during first-time setup.

B. Using TMSH with create sys management-ip

Administrators can enter TMSH directly from the console and run:

create sys management-ip /

The management-ip object resides undersys, not under ltm or any other module.

This is the correct tmsh method for defining the management interface address.

Why the other options are incorrect:

C. create ltm management-ip

There isnosuch object under /ltm.

LTM handles traffic objects (virtual servers, pools), not system management interfaces.

D. Running the setup command

The setup command is used for general system configuration butdoes not configure the management-ip.

It is not the supported method for initial management IP assignment on VE deployments.

Therefore, the valid methods are running theconfigutility and using thesys management-ipcommand within TMSH.

For BIG-IP high-availability (HA) pairs, F5’s recommended upgrade workflow prioritizesservice continuity,predictable failover, andminimal downtime. The established best-practice sequence is:

Upgrade the standby unit first

Because the standby device is not passing traffic, upgrading and rebooting it does not impact production.

Boot the standby unit into the newly installed version

Once online, the administrator verifies basic health, device sync status, cluster communication, and module functionality.

Perform a controlled failover to the upgraded unit

Traffic shifts to the newly upgraded device, allowing validation of the configuration and operational behavior under real traffic loads.

Upgrade the second device (now standby)

The previously active device becomes standby after failover, allowing it to be safely upgraded and rebooted without interruption.

This phased approach ensures only one device is unavailable at a time, allowing continuous traffic flow throughout the upgrade process.

Why the Correct Answer is C

OptionCexactly matches F5’s documented production-safe upgrade method:

Upgrade thestandbynode first

Reboot into new image

Failover to upgraded device

Validate

Upgrade the remaining (now-standby) device

This procedure minimizes risk and traffic disruption.

Why the other options are incorrect:

A. Upgrade the active node first

Upgrading the active device requires removing it from service and failing over abruptly. This is not recommended and increases service disruption risk.

B. Resetting device trust

Resetting trust is unnecessary and can disrupt configuration sync, peer communication, and cluster operation. It is not part of any standard upgrade workflow.

D. Upgrading and rebooting both nodes simultaneously

This would causetotal outage, because both HA members would be unavailable at the same time.

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 adedicated, 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 allowlist (for HTTPS) and configuration options insshd(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.

Self-IPs include a security feature calledPort 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 donotexpose 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 isnot secure.

Exposes services that should remain restricted.

Therefore,Allow Mgmt / Allow Managementare the correct choices.

ThePort Lockdownfeature controls which services a Self-IP will respond to.

Setting a Self-IP toAllow Nonemeans:

The Self-IP will not acceptanytraffic except the very limited, hard-coded HA ports such asTCP 4353used for device trust and configuration sync.

All other HA ports, including those needed for network failover and other HA mechanisms,are blocked.

When essential HA services cannot communicate, each device assumes its peer is down.

This results in:

HA failover misbehavior

Both devices thinking the other is offline

Potentialactive-active condition, which is not intended and can cause traffic disruption

Thus,Allow Nonecan break HA functionality unless the Self-IP is not used for HA links.

The exhibit shows theCurrent Resource Allocationfor:

CPU

Disk

Memory

In particular, theMemory Allocationbar displays the modules that are currently provisioned.

Memory is the most reliable indicator because BIG-IP allocates memoryonlyto modules that are actively provisioned.

From the exhibit:

MGMT(Management) – always present

TMM(Traffic Management Microkernel) – indicatesLTM is provisioned

GTM– this label indicates that theDNS moduleis provisioned (GTM = Global Traffic Manager, now called DNS)

APM– explicitly shown, indicatingAccess Policy Manageris provisioned

Therefore, the provisioned modules are:

LTM(implied by TMM allocation)

DNS/GTM

APM

This matchesOption C: LTM, DNS, APM.

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

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/24and172.28.65.0/24—the administrator mustaddboth subnets to the existing list without removing current entries.

In tmsh, subnet entries must be specified innetwork/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 requiresnetwork/netmaskformat.

Option C:

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

The correct keyword must beallow.

Thus, onlyOption Acorrectly adds both permitted subnets in the proper tmsh format.

When a TMOS ISO file is transferred to/shared/images/, the BIG-IP automatically performs a validation step:

Checksum Verification

Before the image becomes visible in the GUI, the systemverifies the internal checksumembedded inside the ISO.

This ensures:

The file was fully transferred

The image is not corrupted

It matches the official F5 release signature

Only after passing this verification does the GUI display the ISO under “Available Images.”

Why the other options are incorrect:

A. Reboot into a new partition

No reboot occurs simply from uploading an image.

C. Copying into /var/local/images/

This directory isnotused for ISO storage.

All valid images remain in/shared/images/.

Thus, the correct system action ischecksum verification.

When installing a software upgrade with a HotFix on BIG-IP, the correct workflow requires:

Install the base TMOS imageon an unused boot volume

Install the corresponding HotFixonto that same boot volume

Activate the updated boot volumeto boot into the new software

This method ensures:

The existing active system (HD1.1) is untouched

The upgrade occurs in a new, clean volume (HD1.2)

The HotFix applies properly to the same base image

The administrator can revert to HD1.1 if issues occur

OptionCmatches the correct F5 upgrade sequence:

1. Install base image on HD1.2

2. Install HotFix on HD1.2

3. Activate HD1.2

Why the other options are incorrect:

A. Install HotFix before base image

HotFixes must be appliedafterthe base image; not valid.

B. Installing a HotFix on the active boot location (HD1.1)

Not recommended and does not use a clean new volume.

Also does not involve installing the base image.

D. Activating HD1.2 before installing anything

Cannot activate an empty or invalid boot volume.

Thus,Option Cis the correct sequence.