Free HPE6-A90 practice test: 30 questions with answers

Device groups in Central hold the configuration that is pushed to the devices assigned to them, so one change at group level applies to every member. Sites organize devices by location for monitoring and do not carry the shared configuration. Local CLI edits and manual copies drift out of step over time, and a TFTP fetch at reboot is not how Central manages its devices.

Groups carry the configuration that Central pushes to devices, and sites are used to organize devices by physical location for monitoring. Swapping those roles, treating the two as the same container, or requiring one device per site are all incorrect.

The client list filtered by time shows which clients were affected and when the drop began, which is the right first step when the access points look healthy. Firmware inventory and license reports do not show client-level quality over time, and the configuration editor changes settings rather than monitoring them.

Alerts let the team learn about a problem, such as a device going offline, without watching the dashboards all day. Faster refresh is a display setting, alerts do not replace device logging, and they do not add approval steps to logins.

Role-based access in Central lets an account view health and monitoring data while configuration rights stay withheld. A shared administrator login, or full rights backed only by a reminder, lets the technician change settings, and local switch accounts sit outside the Central permission model.

Activate links a device to the Central account, and the device then receives its group configuration from Central, so little local setup is needed. Typing the full configuration on site, loading an emailed file or relying on SNMP polling are not how Central onboards devices.

A device is assigned to a single group, and that group's configuration is what the device receives, while sites organize devices for location-based monitoring. Renaming a site does not rewrite device settings, and groups are logical containers that do not need to follow the building floor plan.

Trends show patterns over time, so the team can tell a recurring issue from a one-off event and plan capacity. Trend graphs do not lock configuration, do not notify anyone on their own and do not change firmware.

A device that is offline in Central while still forwarding locally usually has a problem reaching the cloud service, so checking the route and outbound HTTPS is the relevant test. Recreating VLAN 1, disabling spanning tree and renaming the switch do not address connectivity to the cloud service.

Group configuration is pushed to every device assigned to the group, so the change does not have to be repeated per device. Limiting the update to one site, permanently excluding offline devices and requiring factory resets are all incorrect.

A trunk carries multiple VLANs with 802.1Q tags, which is what a switch-to-switch link needs here. An access port carries only one untagged VLAN, so the access options would drop VLANs or merge them, and mirror mode does not carry traffic between the switches.

VSX makes the pair look like one logical switch to the downstream device, which allows a LAG to span both members. The other options describe a spanning tree blockage, a routing-only exchange and an active-standby address scheme, none of which is how VSX presents the pair.

The ISL keeps the two VSX peers in sync, which is what lets them act as one switch. The other options describe an internet uplink, a bypass path for client traffic and a management-only role, none of which is the purpose of the ISL.

MAC Authentication Bypass admits a device that has no supplicant based on its MAC address, and it can be limited to the printers as a documented exception. Disabling authentication everywhere, installing a supplicant the printers cannot run or trusting a native VLAN removes or defeats the control the company requires.

Interface state history and error counters for the affected port show when the link changed and what kind of errors it sees, which points toward cabling, speed or duplex faults. Wireless roaming data, the PoE budget and license expiry dates do not describe that port's link.

When the PoE budget is exhausted, the switch cuts power to some ports, and access points restarting after a new load appears is a typical sign. A hostname mismatch, uplink spanning tree settings and radio channels do not cause a switch to withdraw power from its ports.

BPDU guard on an edge port disables that port when it receives spanning tree BPDUs, which an edge port should never see. Jumbo frames, static MAC entries and port mirroring do not stop spanning tree frames from reaching the core.

A LAG bundles several physical links into one logical link, adding bandwidth and keeping the connection up when a member fails. Giving each member its own VLAN or encrypting traffic are not functions of link aggregation.

Traffic between VLANs must be routed, so the user's port must be in the expected VLAN and the user's subnet needs a working gateway or SVI. A mirror destination port and the spanning tree state of the user's port do not explain loss of inter-VLAN reachability by themselves.

DHCP snooping drops DHCP server replies that arrive on untrusted ports, which stops a rogue server from handing out addresses. Jumbo frames, port mirroring and static routes do not stop an unauthorized DHCP server from answering clients.

AOS-10 moves management and configuration into Central, which removes the need for an on-premises Mobility Master. The other options describe local-only gateway management, a design with no gateways, and a Mobility Master that forwards client traffic, none of which matches AOS-10.

Tunnel forwarding carries client data from the access point to a gateway, where traffic can be inspected and policy applied centrally. Bridge and local-only forwarding keep traffic off the central gateway, and management-only forwarding would not carry client data at all.

Gateways are where tunneled client traffic ends and where centralized firewall and role-based policy are applied. Storing monitoring history, injecting PoE and issuing licenses are not the gateway's role in AOS-10.

A gateway cluster lets the surviving member take over client sessions, which limits the impact of a single gateway failure. Doubling radios, removing Central's need for status data and splitting SSIDs across gateways are not benefits of clustering.

Central is the cloud-based management plane for AOS-10, handling configuration, monitoring and firmware for access points and gateways. It is not a data-forwarding path or an on-site appliance, and WLANs are defined centrally rather than on each access point.

An access point showing online in Central does not prove the data path works, so the tunnel to the gateway and reachability of DHCP for the client VLAN come first. A naming pattern, a passphrase change and a band restriction do not explain a missing IP address on a working tunnel, and a bad passphrase would block association instead.

Central provides the cloud-based management for AOS-10, and the forwarding mode is chosen per WLAN between tunnel and bridge. AOS-10 does not need an on-premises Mobility Master, and it still uses SSIDs for wireless service.

A WLAN is the wireless service that clients see as an SSID, together with the security and forwarding settings that apply to it. The other options describe a wired management VLAN, a license and a dashboard, none of which defines a wireless service.

Bridge forwarding lets client traffic leave onto the local wired network at the access point, avoiding the tunnel to the data center. Tunnel forwarding adds the detour the branch wants to avoid, Central is a management platform rather than a data path, and mirror forwarding does not deliver traffic to the internet at all.

A role groups users so that the policy applied after authentication, such as firewall rules and access, matches what that group should be allowed to do. Floor plan locations, radio power settings and device license keys are separate concepts.