А теперь немного моего ИМХО по этому поводу.
Существует несколько нюансов при выполнении этой задачи.

1) Никогда нельзя быть твердо уверенным что обновление сервера, с уставновленными из репозитория пакетами пройдет без сучка и задоринки, поэтому нельзя быть уверенным, что если мы запустим ансибл по 100 серверам у нас вообще все это выживет. Бывали случаи когда какие-то пакеты конфликтовали, и новый дистр не поднимался успешно. Ну и наконец где ваша уверенность что софт, установленный из репозитория текущего дистрибутива есть в новом??? Таким образом 2,3 варианты ответов отметаем сразу.

2) как сказано в условиях задачи "одинаково настроенные". На самом деле нет. Это в идеальном мире можно условно "расклонировать" 100 раз службу и получить одинаковый результат. По факту всегда найдется какой-то "любимый" некоторым сисадмином сервер, на который тот ходит руками. Не важно зачем - логи читать или статус софта запрашивать. А еще бывает иногда необходимость выкатить условно-релизную версию софта на сервер, чтобы убедиться, что релиз не положит весь поток продового трафика. И вот уже у нас вроде бы 100 одинаковых серверов, а вот уже и нет, даже если потом все сервера приводятся к одинаковой версии софта.

3) самое важное - это как раз необходимость изучить, какую же вообще выполняют задачу эти 100 серверов.
3.1) У нас 100 серверов-воркеров. на сервере крутится служба, которая ходит в очередь и выполняет задание. При простое одного такого воркера вообще никто не заплачет. Можно выдергивать и обновлять.
3.2) У нас кластер на 100 машин. Например куб. или эластик. Опа, а вот тут уже начинаются первые вопросы. Если мы обновим дистрибутив, сможет ли вообще наше приложение существовать в новом окружении? не посыпется по зависямостям? ничего лишнего не снесется? Все ли нужные пакеты запинены? не приведет ли новое ядро к тому что будет падать в корку приложение? Что вообще произойдет с подами куба если мы выведем ноду из обслуживания? А вдруг у нас настроено афинити и приложение жестко привязано к этой ноде и когда мы ее положим оно нигде не поднимется? С базами тоже интересно, нужно знать, достаточно ли у нас реплик, что шардинг разнесен правильно. В случае с тем же эластиком, например пишется такой плейбук, который дожидается пока не поднимется предыдущий сервер, прежде чем обновлять следующий.

Поэтому такие задачи требуют глубокого изучения, построения сценариев обновления, написания автоматизации, а возможно подъема различных стендов, на которых все это будет обкатываться. А уж какой командой мы обновлять будем сервер и ядро - это никому не интересно.. 😃