The Leader node has *no* special role to play in a cluster while the cluster nodes are all up and running, or Leader node is not special in any way with respect to replication/syncing of data while the nodes are up and running. Therefore, the LEADER node may not be the ACTIVE node in an A/P cluster, you can check the VIP owner (ACTIVE node) by checking it in the Cluster > Status page.
All that the Leader tag on the cluster status page indicates is that after the last cluster partition repair (cluster split/rejoin) that node sent its state to the joining nodes. That’s it. After that initial synchronization is done, the leader node is just like any other node. While the cluster is up and running, state updates continue and are replicated across the cluster in a symmetric manner – the leader does not play any special role.
The leader is elected based on a very involved algorithm and some heuristics which strives to make sure that the “best qualified” node sends its state to the joining node. The goal is to retain the node that is most likely to have the most recent system state as the leader.
The sync rank is used as a tie breaker if we cannot tell which node is better via any other means. So, it is quite likely than in some scenario the node with the lower sync rank be the leader. There is usually no need to change the default value for sync rank from zero (0). If you always makes configuration changes from a given node, it may help in some rare corner cases to assign that node a higher sync rank. In an A/P cluster configuration, it will be better to simply sign in using the VIP, in which case there is no point in changing the sync ranks.