diff --git a/docs/concepts/configuration/pod-priority-preemption.md b/docs/concepts/configuration/pod-priority-preemption.md
index 1a85f4593b..01c1c764ed 100644
--- a/docs/concepts/configuration/pod-priority-preemption.md
+++ b/docs/concepts/configuration/pod-priority-preemption.md
@@ -220,14 +220,15 @@ can be scheduled on N. P might become feasible on N only if a Pod on another
 Node is preempted. Here's an example:
 
 * Pod P is being considered for Node N.
-* Pod Q is running on another Node in the same zone as Node N.
-* Pod P has anti-affinity with Pod Q.
-* There are no other cases of anti-affinity between Pod P and other Pods in the zone.
-* In order to schedule Pod P on Node N, Pod Q should be preempted, but scheduler
+* Pod Q is running on another Node in the same Zone as Node N.
+* Pod P has Zone-wide anti-affinity with Pod Q
+(`topologyKey: failure-domain.beta.kubernetes.io/zone`).
+* There are no other cases of anti-affinity between Pod P and other Pods in the Zone.
+* In order to schedule Pod P on Node N, Pod Q can be preempted, but scheduler
 does not perform cross-node preemption. So, Pod P will be deemed unschedulable
 on Node N.
 
-If Pod Q were removed from its Node, the anti-affinity violation would be gone,
+If Pod Q were removed from its Node, the Pod anti-affinity violation would be gone,
 and Pod P could possibly be scheduled on Node N.
 
 We may consider adding cross Node preemption in future versions if we find an