diff --git a/latest/ug/nodes/managed-node-update-behavior.adoc b/latest/ug/nodes/managed-node-update-behavior.adoc
index 01179d4f..d3ae24bc 100644
--- a/latest/ug/nodes/managed-node-update-behavior.adoc
+++ b/latest/ug/nodes/managed-node-update-behavior.adoc
@@ -85,9 +85,10 @@ The minimal strategy is useful in scenarios where you are constrained to resourc
 The _default_ update strategy has these steps:
 
 . It increases the quantity of nodes (desired count) in the Auto Scaling Group, causing the node group to create additional nodes.
+. It cordons all the old nodes of the node group as soon as a new node comes into 'Ready' state.
 . It randomly selects a node that needs to be upgraded, up to the maximum unavailable configured for the node group.
 . It drains the Pods from the node. If the Pods don't leave the node within 15 minutes and there's no force flag, the upgrade phase fails with a `PodEvictionFailure` error. For this scenario, you can apply the force flag with the `update-nodegroup-version` request to delete the Pods.
-. It cordons the node after every Pod is evicted and waits for 60 seconds. This is done so that the service controller doesn't send any new requests to this node and removes this node from its list of active nodes.
+. The cordoned and drained node waits for 60 seconds after the eviction of all the Pods from the node. This is done so that the service controller doesn't send any new requests to this node and removes this node from its list of active nodes.
 . It sends a termination request to the Auto Scaling Group for the cordoned node.
 . It repeats the previous upgrade steps until there are no nodes in the node group that are deployed with the earlier version of the launch template.