Does Selecting Prevent Failback Keep App1 on Server2?
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have a failover cluster named Cluster1 that hosts an application named App1. The General tab in App1 Properties is shown in the General exhibit. (Click the General tab.) The Failover tab in App1 Properties is shown in the Failover exhibit. (Click the Failover tab.) Server1 shuts down unexpectedly. You need to ensure that when you start Server1, App1 continues to run on Server2. Solution: From the Failover settings, you select Prevent failback. Does this meet the goal? - 
- 
Community Votes
50% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The exam is testing whether you understand failback behavior: 'Prevent failback' is the direct setting that stops a clustered application from moving back to a recovered node, even if no preferred owner is explicitly listed.
In this AZ-801 failover cluster scenario, setting 'Prevent failback' keeps App1 on Server2 after Server1 restarts. The community is split, but the official answer is Yes because preventing failback stops the application from returning to Server1.
Choosing B because 'no preferred owner is selected' and assuming the failback setting is irrelevant. In reality, selecting 'Prevent failback' explicitly guarantees the app remains on Server2, so it satisfies the goal.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Selecting 'Prevent failback' in the Failover tab configures the clustered role to stay on its current owner after another node comes back online. When Server1 shuts down and App1 fails over to Server2, 'Prevent failback' stops the cluster from moving App1 back to Server1 after Server1 restarts, which directly matches the requirement.Why the Other Options Are Wrong
Option B ('No') is incorrect because the question asks whether this solution meets the goal, not whether it is the only possible solution. Even if no preferred owner is selected and the cluster would not automatically fail back, selecting 'Prevent failback' still ensures that App1 remains on Server2. The setting does not create any behavior that would move App1 away from Server2.Community Comment Notes
Comment [1] suggests that without a preferred owner the setting makes no difference, but that observation does not make the solution invalid. Comments [3] and [4] correctly support answer A, recognizing that preventing failback is the appropriate way to keep the application on Server2. The key is to read the goal as 'keep App1 on Server2,' which is exactly what this option accomplishes.Official Reference
Exam Strategy
When answering 'Does this meet the goal?' questions, focus on whether the proposed action directly produces the stated outcome, not on whether it is necessary. If the setting prevents failback, it keeps the role on the current node, so answer Yes; avoid overthinking preferred-owner prerequisites.