Important Pure Storage FlashArray-Storage-Professional Exam Questions

Answer: C

Explanation:

Command Purpose: The purehost monitor command is the primary tool in the Pure Storage CLI for observing real-time performance and connectivity health from the perspective of the hosts connected to the FlashArray.

The --balance Flag: When the --balance flag is added, the output shifts from general performance (IOPS, bandwidth, latency) to showing how I/O is distributed across the available paths (controllers and ports). This is critical for identifying 'unbalanced' loads, which usually point to misconfigured MPIO (Multi-Path I/O) on the host side (e.g., a host only using one controller's ports).

Interval vs. Repeat:

The --interval flag specifies the time in seconds between each sample. In option C, --interval 15 tells the array to refresh the data every 15 seconds.

The --repeat flag (seen in option A) is used to limit the total number of samples taken before the command exits. However, in standard troubleshooting, the administrator typically wants a consistent stream of data until manually stopped (Ctrl+C).

--resample (seen in option B) is not a valid flag for the purehost monitor command in Purity.

Best Practice: When troubleshooting multipathing, Pure Storage recommends monitoring the balance to ensure that the 'Relative I/O' percentage is roughly equal across all active paths. Large discrepancies often indicate that the host's MPIO policy is set to 'Failover Only' instead of the recommended 'Round Robin' or 'Least Queue Depth.'

Answer: A

Explanation:

Understanding Total Latency: In a FlashArray environment, total latency as seen by the host application is the sum of several components. Pure Storage breaks this down into Array Time and SAN Time to help administrators pinpoint where performance bottlenecks exist.

SAN Time Definition: SAN Time represents the latency introduced by the network infrastructure between the host (initiator) and the FlashArray (target). This includes the time spent traveling across Fibre Channel or Ethernet switches, cables, and host bus adapters (HBAs). It is calculated by taking the total round-trip time measured by the host and subtracting the time the FlashArray spent processing the I/O.

Metric Breakdown: * Array Time: The time the FlashArray takes to process the I/O once it hits the front-end ports (Option C describes internal array time).

SAN Time: The transit time for the request to reach the array and the response to return to the host (Option A).

Wait Time: In ActiveCluster environments, there is also 'Mirror Latency,' which is the time spent synchronizing data to a peer array (Option B).

Troubleshooting Value: If a user reports high latency but the FlashArray GUI shows very low Array Time, the administrator can look at the SAN Time metric. A high SAN Time indicates an issue with the fabric, such as a failing SFP, a congested switch port, or oversubscribed ISLs (Inter-Switch Links).

Answer: B

Explanation:

When an NFS client successfully mounts an export using the target's IP address, it proves that the fundamental network connectivity (routing, firewalls) and the storage protocol layer (NFS export policies, host access permissions) are functioning correctly.

However, if the exact same mount attempt fails when using the Fully Qualified Domain Name (FQDN) of the FlashArray file service, the issue lies entirely with name resolution. The Domain Name System (DNS) is responsible for translating human-readable FQDNs into the IP addresses required for network communication. If the client cannot reach the DNS server, or if the DNS server lacks the correct A or AAAA records for the FlashArray's file Virtual IP (VIP) addresses, the client won't be able to resolve the name to the IP, causing the mount command to fail.

Here is why the other options are incorrect:

Issue with the Active Directory (AD) controller (A): Active Directory is primarily used for directory services, user authentication, and authorization (such as mapping permissions for SMB or NFSv4). While AD environments usually include DNS, an 'AD controller issue' in the context of storage protocols usually points to permission denials, not host name resolution failures. Furthermore, since the mount works via IP, basic access is already validated.

Issue with the OpenLDAP (C): Similar to AD, OpenLDAP provides directory services for user mappings (UID/GID) and authentication. It does not perform FQDN-to-IP resolution.

Answer: B

Explanation:

For FlashArray File Services (FA File), user authentication and mapping depend on the storage protocol being used. In an NFS-only environment, remote user authentication (resolving UNIX UIDs and GIDs to actual usernames and managing access) is typically handled via LDAP or NIS.

To configure this integration in the Purity GUI, the storage administrator must navigate to Settings > Access > Directory Services. This specific section allows the FlashArray to connect to a centralized directory server (such as OpenLDAP or even Active Directory providing LDAP services) to pull the necessary UNIX user and group attributes required for NFS file permissions to function properly.

Here is why the other options are incorrect:

Settings > Access > Create Active Directory Account (A): This specific menu path is used strictly for configuring native Active Directory (AD) computer accounts and joining the domain to support the SMB (Server Message Block) protocol. Since the scenario explicitly states the company is an 'NFS only shop,' configuring an SMB AD account is not the correct step.

Settings > Access > File System (C): While you manage file-level exports and policies within the Purity file interface, the global configuration for remote user authentication and directory server integration lives under the dedicated Directory Services pane.

Answer: C

Explanation:

The ActiveCluster Mediator (whether it is the Pure1 Cloud Mediator or the On-Premises VM) is a lightweight tie-breaker that communicates continuously with the management interfaces of both FlashArrays. If it was previously online and suddenly reports as 'unreachable' from both arrays simultaneously, the issue is almost always caused by a network interruption or firewall rule change blocking the required communication ports between the arrays' management IP addresses and the Mediator VM.

If a network firewall is suddenly configured to drop or deny outbound TCP traffic (such as port 80/443 depending on the specific HTTP/HTTPS discovery and heartbeat configuration) from the FlashArrays to the ESXi-hosted Mediator, the arrays will fail to send their heartbeats, causing the mediator status to drop to 'unreachable.'

Here is why the other options are incorrect:

Fibre Channel (FC) zoning or network access has not been created properly for the host (A): The Mediator is completely independent of the front-end host storage fabric (Fibre Channel or iSCSI). Host zoning issues would prevent the ESXi server from seeing its volumes, but it would not cause the FlashArrays to lose management network connectivity to the Mediator.

The mediator does not reside within a Pure datastore (B): This is actually a strict best practice and requirement. Pure Storage explicitly states that the On-Premises Mediator VM must be deployed in a separate (third) failure domain. It should not reside on the ActiveCluster mirrored datastore, because a site-wide SAN failure would take the mediator offline exactly when it is needed most. Therefore, not residing on a Pure datastore is the correct setup, not a cause for an outage.