F5 F5CAB1 BIG-IP Administration Install, Initial Configuration, and Upgrade Exam Practice Test

When upgrading to a newer TMOS software version, BIG-IP validates whether the current license is permitted to run that version.

This is controlled by theService Check Datein the device’s license file.

If the Service Check Date is older than the minimum required for the target version:

The systemboots into the new volume,

Butfails to load the configuration,

And will instead present messages indicating that the configuration cannot be applied due to aninvalid or outdated license.

This is a well-known behavior:

An outdated license, not reactivated before upgrade, causes configuration load failure after reboot into the new software.

Why the other options are incorrect:

A. Performed on the standby unit

Upgrading a standby unit does not cause configuration load failure.

Standby-only upgrades are standard best practice.

C. Two reboots required

BIG-IP does not require two reboots during an upgrade.

One reboot into the new volume is sufficient.

D. DNS connectivity failure

DNS connectivity does not affect configuration loading.

DNS is only needed for automatic license activation, not for applying config at boot.

Thus, the configuration failed to load because thelicense was not reactivated before the upgrade, makingOption Bcorrect.

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.

Provisioning determines:

Which BIG-IP modules are enabled (LTM, ASM, APM, AFM, DNS, etc.)

Their provisioning levels (None, Minimal, Nominal, Dedicated)

Two accurate ways to view provisioning settings are:

A. GUI — System → Resource Provisioning → Module Allocation

This is the primary GUI screen showing:

All modules

Their provisioning level

System resource distribution impact

Administrators commonly use this page to confirm or change module provisioning.

D. TMSH — list /sys provision

This tmsh command displays each module and its provisioning level:

sys provision ltm { level nominal }

sys provision asm { level none }

This is the authoritative CLI method for checking module provisioning configurations.

Why the other options are incorrect:

B. show /sys provision

Showsruntimeinformation butnot the actual configuration levels.

list is the correct command for configuration details.

C. Statistics → Module Statistics

Shows performance statistics, NOT provisioning status.

Therefore, the correct responses areAandD.

Port Lockdown controls which ports and protocols aSelf IPwill respond to.

TheAllow Defaultsetting permits only a predefined set of BIG-IP internal and required service ports.

The Allow Default listincludes:

TCP 443→ HTTPS (Management/TMUI access via Self-IP)

TCP 4353 → CMI (device sync)

TCP/UDP ports related to HA communication

Other essential internal F5 ports

Why TCP 443 is correct:

It is one of the officially allowed ports underAllow Default.

It enables HTTPS/TMUI access through a Self IP.

Why the other options are incorrect:

A. TCP 80 (HTTP)

Not allowed under Allow Default

HTTP via Self-IP is blocked unless placed under Allow Custom

B. UDP 8443

Not an F5 default service

Not part of the Allow Default ports

BIG-IP provisioning determines how CPU, memory, and disk resources are allocated to each module. The goal is to provision only the modules required and at levels appropriate to their performance needs.

Requirements in the question

The device will be used for:

LTM(Local Traffic Manager) → load balancing

ASM(Application Security Manager) → WAF

No functions require:

APM (Access Policy Manager)

AFM (Advanced Firewall Manager)

Why Option C is correct

Provisioning bothLTMandASMatNominallevel provides:

Adequate performance for production load

Plentiful system resources while avoiding dedicating the entire system to a single module

Balanced allocation without starving memory or CPU

SettingAPM: NoneandAFM: Noneensures unused modules consume zero resources.

Why the other options are incorrect

A. Dedicated provisioning for both LTM and ASM

Two modules cannot both run in “Dedicated” mode.

Dedicated mode allocatesallresources to a single module — the second module cannot be dedicated simultaneously.

B. LTM and ASM both Dedicated

Same issue: only one module can be Dedicated at a time.

Also unnecessary for load balancing + WAF.

D. Setting APM and AFM to Minimal

Minimal still consumes memory and CPU.

Unused modules should be set toNone.

Therefore,Option Cis the best provisioning strategy.

The exhibit shows aSelf IPwith:

VLAN:Data

Port Lockdown:Allow None

Impact of “Allow None” on SNMP

When a Self IP is configured with:

Port Lockdown: Allow None

the BIG-IP blocksallservices and ports except a few hardcoded HA communication ports.

This means:

UDP/161 (SNMP)is blocked

UDP/162 (SNMP traps)is blocked

The SNMP server cannot poll or receive data from the BIG-IP through this Self IP

SNMP relies on access through the Self IP if out-of-band (mgmt interface) is not used.

Thus, the issue is directly caused byPort Lockdown = Allow None, which prevents SNMP communication.

Why the other options are incorrect:

B. Traffic Group must use a floating Traffic Group

SNMP polling doesnotrequire floating Self IPs.

Floating groups apply to HA failover IPs, not SNMP functionality.

C. VLAN/Tunnel must allow All VLANs

Self IPs are always bound to a VLAN; SNMP doesnotrequire All VLANs.

As long as the Self IP belongs to a reachable VLAN, SNMP can work.

D. Configuration is correct

It is not correct:Allow Noneblocks SNMP and is the problem.

When installing a BIG-IP software versionwith a HotFixon anew boot volume, F5 requires that both thebase TMOS imageand theHotFix imagebe installed together as part of the same installation workflow.

The correct process is:

Specify thebase TMOS ISO

Specify theHotFix ISOthat corresponds to that base version

Instruct the system tocreate a new boot volume

Install both images into that new volume

This is achieved with the following tmsh syntax:

tmsh install /sys software BIGIP-.iso hotfix Hotfix-BIGIP--ENG.iso create-volume HD1.2

This command:

Installs the base image first

Applies the HotFix on top of the base image

Creates and installs everything onHD1.2

Leaves the currently active volume untouched for rollback

Why the other options are incorrect

A. Installing only the hotfix

A HotFix cannot be installed by itself on a new volume. A base image must already be present.

C. Using create instead of install

The create keyword is not valid for software installation operations.

D. Using copy

The copy command does not install software images or hotfixes.

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:

Version-specific issue analysis, comparing the system’s configuration and hardware against F5’s internal catalog of published issues.

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 forknown bugs by TMOS version, module, severity, or defect ID.

Review thestatus 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 forhardware diagnostics(ports, memory, fans). It does not provide software-related issue verification and is not used for upgrade planning.

C. F5 University

This is atraining 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 isnot a tool for identifying known bugs. Release notes summarize general fixes and features, but systematic bug verification requires iHealth or the Bug Tracker.

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.

To understand:

Which modules arelicensed

Which modules areprovisioned

Theresource 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 underResource Provisioning.

The BIG-IP system has built-in licensing enforcement.

If an administrator provisions a module that the device isnot licensedto run, the system will still allow the provisioning action to occurinitially, but the system detects the mismatch and displays an alert.

What actually happens:

The GUI places awarning bannerin theupper-left cornerlabeled something similar to:“Provisioning Warning”

This appears immediately after provisioning a module that is not included in the active license.

The system remains in an “inconsistent state” until the module is disabled again or the license is updated.

This is the visual cue BIG-IP uses to indicate that a module was provisioned without valid licensing.

Why the other options are incorrect:

A. “A BIG-IP does not allow unlicensed modules to be provisioned.”

Not true. BIG-IPdoesallow provisioning, but warns afterward.

B. “A warning will appear when provisioning an unlicensed module.”

The warning doesnotappear during the provisioning step itself.

It appearsafter provisioning, in the main GUI, as a system banner.

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

Dedicated– allocatesallCPU, 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 runonly ASM(Web Application Firewall), the recommended way to maximize performance is to provision the module atDedicatedlevel.

WithASM: Dedicated:

ASM receives theentire 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 arenot valid provisioning modesin 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,Dedicatedis the correct provisioning choice.

TheService Check Datedetermines whether a particular software version is allowed to run under the device’s license.

When installing or upgrading TMOS, the installer checks theService Check Datestored in the BIG-IP license file.

If the license date isolderthan the minimum required for the target version, the software installation isblocked.

This check happensspecifically during a software install, not during routine device operations.

Editing virtual servers or system startup do not trigger this validation.

Thus, the enforcement happensduring software installation.