FlashArray-Storage-Professional Exam Questions & Answers

Policy-Driven Automation: Pure Protect //DRaaS (Disaster Recovery as a Service) is built on a declarative policy engine. When you define a business policy (Protection Group or similar policy-based management), the system's primary goal is to bring the environment into compliance with the 'Desired State' defined by that policy.

Retention Enforcement: When the retention period is reduced (e.g., from 7 days down to 3 days), the Purity/Pure Protect engine identifies that any existing snapshots or backups older than the new 3-day threshold are now 'out of policy.'

Immediate Reclamation: Unlike some legacy backup systems that only apply new retention settings to future backups, Pure Storage's policy-driven architecture typically triggers an immediate cleanup of the now-obsolete data to reclaim space on the target. This ensures the environment matches the modified policy requirements immediately upon the policy update.

SafeMode Considerations: If SafeMode is enabled on the target, these 'erased' backups will actually move into the 'Destroyed' (but not yet eradicated) bucket for the duration of the SafeMode timer, providing a safety net against accidental policy changes or malicious deletions. However, from the perspective of the active DR policy, they are removed.

ActiveCluster Scalability Limits: Pure Storage FlashArrays have specific scalability limits regarding the number of 'Active' or 'Stretched' pods allowed per array or ActiveCluster pair. While these limits can vary slightly based on the Purity//FA version and the specific hardware model (e.g., //X, //XL, or //m), a common architectural limit in many Purity versions is up to 12 stretched pods.

The Scenario Analysis: In this case, the environment already has 12 stretched pods successfully replicating. When the administrator attempts to stretch a 13th pod, the operation fails because the array has hit the maximum concurrent stretched pod count supported by the Purity operating environment for that configuration.

Stretched vs. Unstretched: A pod exists locally (unstretched) without consuming an ActiveCluster pod 'slot' in the same way. The failure specifically occurs during the 'stretch' operation, which is the point where the synchronous replication relationship and mediator monitoring are established.

Resolution: To resolve this, the administrator would either need to:

Unstretch or Eradicate an existing pod that is no longer needed to free up a slot.

Check the specific Purity Release Notes for the hardware model to see if a firmware upgrade increases the maximum pod limit (some newer versions support more, but 12 is the classic threshold often tested in professional certifications).

Logical vs. Physical Reclamation: When an administrator 'Eradicates' a volume, the FlashArray immediately removes the logical reference to that data. However, the physical blocks are not 'wiped' instantly. Instead, those blocks are marked as 'eligible for reclamation' by Purity's background Garbage Collection (GC) process.

Workload Prioritization: Purity is designed to prioritize Host I/O (production performance) over background system tasks. If the array is under an extremely high workload (high Load Meter percentage), Purity will automatically throttle the Garbage Collection process to ensure the application latency remains as low as possible.

The 'Reclamation Lag': If the incoming write rate from the hosts (new data being written) exceeds the speed at which the throttled GC process can reclaim space from the eradicated volume, the 'Used Space' metric will continue to trend upward. This is a common scenario when arrays are pushed to their performance or capacity limits simultaneously.

Why Option A is incorrect: The 24-hour safeguard applies to Destroyed volumes (the 'Pending Eradication' bucket). Once an administrator manually clicks Eradicate, that safeguard is bypassed, and the space should logically be freed. If the space is still not reflecting as 'Free,' it is a back-end processing delay, not a timer delay.

Why Option C is incorrect: In the Purity Operating Environment, the array does not require the host to 'unmount' or 'disconnect' before it can reclaim space. Once the volume is destroyed and eradicated on the array side, those blocks are gone from the array's perspective, regardless of the host's state (though the host will likely experience I/O errors).

ActiveCluster Connectivity Models: In an ActiveCluster environment, hosts can connect to the arrays using either a Uniform or Non-Uniform access model. In a Uniform model, the host has active paths to both FlashArrays in the cluster.

The Failover Scenario: When the replication network between the two arrays fails (a 'split-brain' scenario), the Mediator decides which array keeps the pod online (the winner) and which array takes it offline (the loser) to ensure data consistency.

Analyzing the Symptoms:

The pod failed over, meaning one array is now the exclusive servicer for that pod.

Most volumes in that pod stayed online for the host. This proves that the host is correctly registered in Purity (ruling out Option C) and that the general ActiveCluster/Pod logic is functioning.

Only one specific volume lost connectivity.

The Root Cause (Zoning/Access): If a single volume loses connectivity while others do not, it indicates a pathing issue specific to that volume's visibility. In an ActiveCluster failover, if the 'winning' array does not have a physical path to the host for that specific volume (due to missing FC Zoning or Ethernet VLAN tagging on the switches), the host will lose access once the 'losing' array drops its paths.

Why Option A is unlikely: If 'Uniform access' (the ability to see both arrays) was the issue, it would typically affect all volumes in the pod equally during a failover, not just a single outlier. The fact that the rest of the volumes remained available suggests the host is configured for uniform access, but the specific network plumbing (zoning) for that one volume's path to the surviving array is missing.

!

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.