Сценарий развёртывания — бесплатный тест онлайн

Вопрос 1 из 30

Для блока «Сборка» сравнивают несколько внешне похожих решений. Что точнее всего характеризует работу показанного кода?

git pull
make build
cp app /srv/app/current/app

Файл становится исполняемым shell-кодом, а xtrace может раскрыть секреты; кроме того, копия секретов остаётся в каталоге релиза. Результат зависит от состояния рабочей копии, сети и инструментов сервера; текущая версия может быть перезаписана до завершения проверки. Контрольная сумма подтверждает байты артефакта, после чего он распаковывается в отдельный release-каталог. ERR trap не видит все контексты ошибок и может сработать после этапа, где откат уже опасен; состояния нужно фиксировать явно. Специализированный валидатор проверяет схему до активации и читает конфигурацию из защищённого постоянного места.

Вопрос 2 из 30

Для блока «Конфигурация» сравнивают несколько внешне похожих решений. Какое наблюдение выдерживает проверку по аргументам, потокам и коду завершения?

cp .env "$release/.env"
set -x
source "$release/.env"

Файл становится исполняемым shell-кодом, а xtrace может раскрыть секреты; кроме того, копия секретов остаётся в каталоге релиза. Результат зависит от состояния рабочей копии, сети и инструментов сервера; текущая версия может быть перезаписана до завершения проверки. На GNU-системах готовая ссылка атомарно переименовывается поверх current в пределах файловой системы. Текст VERSION не доказывает происхождение артефакта; идентификатор сборки и digest должны приходить из доверенного конвейера. Специализированный валидатор проверяет схему до активации и читает конфигурацию из защищённого постоянного места.

Вопрос 3 из 30

Для блока «Атомарная замена» сравнивают несколько внешне похожих решений. Что в этом коде произойдёт или останется верным при указанных условиях?

rm -f /srv/app/current
ln -s "$release" /srv/app/current

На GNU-системах готовая ссылка атомарно переименовывается поверх current в пределах файловой системы. Специализированный валидатор проверяет схему до активации и читает конфигурацию из защищённого постоянного места. Ссылка может вернуться, но уже выполненная миграция или отправленные сообщения останутся; частичный эффект не отменяется автоматически. Расширяющая совместимая миграция до переключения и отложенное удаление упрощают откат старого кода. Между командами current отсутствует, а при ошибке ln сервис остаётся без активной версии.

Вопрос 4 из 30

Для блока «Откат» сравнивают несколько внешне похожих решений. Как следует оценить этот вариант с учётом синтаксиса Bash и вызванных программ?

previous=$(readlink /srv/app/current)
activate "$new"
healthcheck || activate "$previous"

Расширяющая совместимая миграция до переключения и отложенное удаление упрощают откат старого кода. Фиксированная пауза не доказывает готовность и то слишком коротка, то зря замедляет развёртывание. Ссылка может вернуться, но уже выполненная миграция или отправленные сообщения останутся; частичный эффект не отменяется автоматически. Успешный 200 подтверждает ответ endpoint, но не обязательно подключение к базе, очередь, версию и критический пользовательский сценарий. Сравнение версии подтверждает, что трафик дошёл до нового процесса; отдельный readiness-тест должен проверить зависимости.

Вопрос 5 из 30

Для блока «Проверка и диагностика» сравнивают несколько внешне похожих решений. Код рассматривают на техническом ревью. Какой вывод подтверждается его фактическим поведением?

curl -fsS http://127.0.0.1:8080/health

Ссылка может вернуться, но уже выполненная миграция или отправленные сообщения останутся; частичный эффект не отменяется автоматически. Успешный 200 подтверждает ответ endpoint, но не обязательно подключение к базе, очередь, версию и критический пользовательский сценарий. Сравнение версии подтверждает, что трафик дошёл до нового процесса; отдельный readiness-тест должен проверить зависимости. ERR trap не видит все контексты ошибок и может сработать после этапа, где откат уже опасен; состояния нужно фиксировать явно. Расширяющая совместимая миграция до переключения и отложенное удаление упрощают откат старого кода.

Вопрос 6 из 30

Для блока «Безопасность и переносимость» сравнивают несколько внешне похожих решений. Что точнее всего характеризует работу показанного кода?

cat > /tmp/deploy.sudoers <<'EOF'
deploy ALL=(ALL) NOPASSWD: ALL
EOF

Сценарий готовит более узкое правило, но аргументы, aliases и возможность изменить unit-файл тоже нужно проверить до установки. Сценарий создаёт правило полного passwordless sudo; любая уязвимость или подмена команды в deploy-скрипте после установки такого правила даёт root-доступ. На GNU-системах готовая ссылка атомарно переименовывается поверх current в пределах файловой системы. ERR trap не видит все контексты ошибок и может сработать после этапа, где откат уже опасен; состояния нужно фиксировать явно. Расширяющая совместимая миграция до переключения и отложенное удаление упрощают откат старого кода.

Вопрос 7 из 30

В служебном сценарии найден следующий фрагмент по теме «Сборка». Какое утверждение верно именно для этого варианта?

sha256sum -c app.tar.gz.sha256 && tar -xzf app.tar.gz -C "$release"

Контрольная сумма подтверждает байты артефакта, после чего он распаковывается в отдельный release-каталог. Текст VERSION не доказывает происхождение артефакта; идентификатор сборки и digest должны приходить из доверенного конвейера. Проверка существования полей недостаточна: нулевые, ложные и неверные типы требуют явной схемы. На GNU-системах готовая ссылка атомарно переименовывается поверх current в пределах файловой системы. Специализированный валидатор проверяет схему до активации и читает конфигурацию из защищённого постоянного места.

Вопрос 8 из 30

В служебном сценарии найден следующий фрагмент по теме «Конфигурация». Что следует записать в заключении ревью этого фрагмента?

/opt/app/bin/check-config --file /etc/app/config.json

Контрольная сумма подтверждает байты артефакта, после чего он распаковывается в отдельный release-каталог. Если current — каталог или находится на другой файловой системе, семантика отличается; атомарность нужно подтвердить для конкретной структуры. Специализированный валидатор проверяет схему до активации и читает конфигурацию из защищённого постоянного места. Проверка существования полей недостаточна: нулевые, ложные и неверные типы требуют явной схемы. Ссылка может вернуться, но уже выполненная миграция или отправленные сообщения останутся; частичный эффект не отменяется автоматически.

Вопрос 9 из 30

В служебном сценарии найден следующий фрагмент по теме «Атомарная замена». Какой разбор не смешивает этот вариант с другими способами решения задачи?

ln -s "$release" /srv/app/current.new
mv -Tf /srv/app/current.new /srv/app/current

Фиксированная пауза не доказывает готовность и то слишком коротка, то зря замедляет развёртывание. Успешный 200 подтверждает ответ endpoint, но не обязательно подключение к базе, очередь, версию и критический пользовательский сценарий. Если current — каталог или находится на другой файловой системе, семантика отличается; атомарность нужно подтвердить для конкретной структуры. ERR trap не видит все контексты ошибок и может сработать после этапа, где откат уже опасен; состояния нужно фиксировать явно. На GNU-системах готовая ссылка атомарно переименовывается поверх current в пределах файловой системы.

Вопрос 10 из 30

В служебном сценарии найден следующий фрагмент по теме «Откат». Какое описание согласуется с фактическими аргументами и состоянием процессов?

migrate expand
activate new
# destructive migration later

Расширяющая совместимая миграция до переключения и отложенное удаление упрощают откат старого кода. Явные владелец, группа и режим создают предсказуемый каталог; setgid наследует группу для новых релизов. ERR trap не видит все контексты ошибок и может сработать после этапа, где откат уже опасен; состояния нужно фиксировать явно. Файл становится исполняемым shell-кодом, а xtrace может раскрыть секреты; кроме того, копия секретов остаётся в каталоге релиза. Сценарий создаёт правило полного passwordless sudo; любая уязвимость или подмена команды в deploy-скрипте после установки такого правила даёт root-доступ.

Вопрос 11 из 30

В служебном сценарии найден следующий фрагмент по теме «Проверка и диагностика». Какой технический вывод относится к показанному коду, а не к похожему решению?

curl -fsS /version | jq -e --arg v "$version" '.version==$v'

Сравнение версии подтверждает, что трафик дошёл до нового процесса; отдельный readiness-тест должен проверить зависимости. На GNU-системах готовая ссылка атомарно переименовывается поверх current в пределах файловой системы. Фиксированная пауза не доказывает готовность и то слишком коротка, то зря замедляет развёртывание. Если current — каталог или находится на другой файловой системе, семантика отличается; атомарность нужно подтвердить для конкретной структуры. ERR trap не видит все контексты ошибок и может сработать после этапа, где откат уже опасен; состояния нужно фиксировать явно.

Вопрос 12 из 30

В служебном сценарии найден следующий фрагмент по теме «Безопасность и переносимость». Какое утверждение верно именно для этого варианта?

cat > /tmp/deploy.sudoers <<'EOF'
deploy ALL=(root) NOPASSWD: /bin/systemctl restart app.service
EOF

Специализированный валидатор проверяет схему до активации и читает конфигурацию из защищённого постоянного места. Явные владелец, группа и режим создают предсказуемый каталог; setgid наследует группу для новых релизов. Если current — каталог или находится на другой файловой системе, семантика отличается; атомарность нужно подтвердить для конкретной структуры. Сценарий готовит более узкое правило, но аргументы, aliases и возможность изменить unit-файл тоже нужно проверить до установки. Файл становится исполняемым shell-кодом, а xtrace может раскрыть секреты; кроме того, копия секретов остаётся в каталоге релиза.

Вопрос 13 из 30

При проверке темы «Сборка» в тесте «Сценарий развёртывания» нужно оценить именно этот вариант. Что этот вариант меняет в поведении сценария на самом деле?

version=$(cat VERSION)

Если current — каталог или находится на другой файловой системе, семантика отличается; атомарность нужно подтвердить для конкретной структуры. Ссылка может вернуться, но уже выполненная миграция или отправленные сообщения останутся; частичный эффект не отменяется автоматически. Расширяющая совместимая миграция до переключения и отложенное удаление упрощают откат старого кода. Результат зависит от состояния рабочей копии, сети и инструментов сервера; текущая версия может быть перезаписана до завершения проверки. Текст VERSION не доказывает происхождение артефакта; идентификатор сборки и digest должны приходить из доверенного конвейера.

Вопрос 14 из 30

При проверке темы «Конфигурация» в тесте «Сценарий развёртывания» нужно оценить именно этот вариант. Какой вывод соответствует именно этой записи, а не общему совету по теме?

jq -e '.port and .database' config.json

Проверка существования полей недостаточна: нулевые, ложные и неверные типы требуют явной схемы. ERR trap не видит все контексты ошибок и может сработать после этапа, где откат уже опасен; состояния нужно фиксировать явно. Расширяющая совместимая миграция до переключения и отложенное удаление упрощают откат старого кода. Файл становится исполняемым shell-кодом, а xtrace может раскрыть секреты; кроме того, копия секретов остаётся в каталоге релиза. Фиксированная пауза не доказывает готовность и то слишком коротка, то зря замедляет развёртывание.

Вопрос 15 из 30

При проверке темы «Атомарная замена» в тесте «Сценарий развёртывания» нужно оценить именно этот вариант. Что можно уверенно сказать об этом решении после пошагового разбора?

mv "$release" /srv/app/current

Успешный 200 подтверждает ответ endpoint, но не обязательно подключение к базе, очередь, версию и критический пользовательский сценарий. Фиксированная пауза не доказывает готовность и то слишком коротка, то зря замедляет развёртывание. Между командами current отсутствует, а при ошибке ln сервис остаётся без активной версии. Если current — каталог или находится на другой файловой системе, семантика отличается; атомарность нужно подтвердить для конкретной структуры. Текст VERSION не доказывает происхождение артефакта; идентификатор сборки и digest должны приходить из доверенного конвейера.

Вопрос 16 из 30

При проверке темы «Откат» в тесте «Сценарий развёртывания» нужно оценить именно этот вариант. Какое утверждение относится к приведённому фрагменту без лишних допущений?

trap rollback ERR

Сценарий создаёт правило полного passwordless sudo; любая уязвимость или подмена команды в deploy-скрипте после установки такого правила даёт root-доступ. ERR trap не видит все контексты ошибок и может сработать после этапа, где откат уже опасен; состояния нужно фиксировать явно. Ссылка может вернуться, но уже выполненная миграция или отправленные сообщения останутся; частичный эффект не отменяется автоматически. Сценарий готовит более узкое правило, но аргументы, aliases и возможность изменить unit-файл тоже нужно проверить до установки. Специализированный валидатор проверяет схему до активации и читает конфигурацию из защищённого постоянного места.

Вопрос 17 из 30

При проверке темы «Проверка и диагностика» в тесте «Сценарий развёртывания» нужно оценить именно этот вариант. Какой вывод подтверждается правилами Bash и указанной последовательностью команд?

sleep 10
mark_success

Успешный 200 подтверждает ответ endpoint, но не обязательно подключение к базе, очередь, версию и критический пользовательский сценарий. Специализированный валидатор проверяет схему до активации и читает конфигурацию из защищённого постоянного места. Фиксированная пауза не доказывает готовность и то слишком коротка, то зря замедляет развёртывание. Текст VERSION не доказывает происхождение артефакта; идентификатор сборки и digest должны приходить из доверенного конвейера. Файл становится исполняемым shell-кодом, а xtrace может раскрыть секреты; кроме того, копия секретов остаётся в каталоге релиза.

Вопрос 18 из 30

При проверке темы «Безопасность и переносимость» в тесте «Сценарий развёртывания» нужно оценить именно этот вариант. Что этот вариант меняет в поведении сценария на самом деле?

install -d -o deploy -g app -m 2750 /srv/app/releases

Фиксированная пауза не доказывает готовность и то слишком коротка, то зря замедляет развёртывание. Явные владелец, группа и режим создают предсказуемый каталог; setgid наследует группу для новых релизов. Проверка существования полей недостаточна: нулевые, ложные и неверные типы требуют явной схемы. Если current — каталог или находится на другой файловой системе, семантика отличается; атомарность нужно подтвердить для конкретной структуры. Сценарий создаёт правило полного passwordless sudo; любая уязвимость или подмена команды в deploy-скрипте после установки такого правила даёт root-доступ.

Вопрос 19 из 30

В тесте «Сценарий развёртывания» разбирается тема «Сборка». Какой риск останется даже после корректной реализации основной конструкции?

Флаги mv -T, readlink -f и systemctl зависят от платформы; сценарий должен объявлять GNU/Linux-среду или иметь протестированные альтернативы. Воспроизводимая сборка упрощает аудит, но deploy всё равно обязан проверить подпись или digest и совместимость миграций. Результат зависит от состояния рабочей копии, сети и инструментов сервера; текущая версия может быть перезаписана до завершения проверки. Журнал deploy должен содержать release id, предыдущую версию, этап, оператора и статусы, но не секреты и не полный дамп окружения. Атомарное переключение файлов не делает атомарным состояние памяти, соединений и базы; службе нужен корректный reload или rolling-процесс.

Вопрос 20 из 30

В тесте «Сценарий развёртывания» разбирается тема «Конфигурация». Какое ограничение особенно важно учесть перед переносом решения в эксплуатацию?

Флаги mv -T, readlink -f и systemctl зависят от платформы; сценарий должен объявлять GNU/Linux-среду или иметь протестированные альтернативы. Изменение конфигурации и кода в одном развёртывании должно иметь совместимый порядок; новый код может стартовать на старой схеме во время поэтапного переключения. Файл становится исполняемым shell-кодом, а xtrace может раскрыть секреты; кроме того, копия секретов остаётся в каталоге релиза. Воспроизводимая сборка упрощает аудит, но deploy всё равно обязан проверить подпись или digest и совместимость миграций. План отката должен иметь крайний срок и критерий остановки: бесконечные переключения между двумя дефектными версиями усугубляют аварию.

Вопрос 21 из 30

В тесте «Сценарий развёртывания» разбирается тема «Атомарная замена». Какую оговорку стоит вынести в описание эксплуатационного контракта?

Флаги mv -T, readlink -f и systemctl зависят от платформы; сценарий должен объявлять GNU/Linux-среду или иметь протестированные альтернативы. Воспроизводимая сборка упрощает аудит, но deploy всё равно обязан проверить подпись или digest и совместимость миграций. План отката должен иметь крайний срок и критерий остановки: бесконечные переключения между двумя дефектными версиями усугубляют аварию. Атомарное переключение файлов не делает атомарным состояние памяти, соединений и базы; службе нужен корректный reload или rolling-процесс. Между командами current отсутствует, а при ошибке ln сервис остаётся без активной версии.

Вопрос 22 из 30

В тесте «Сценарий развёртывания» разбирается тема «Откат». Какое условие остаётся за пределами гарантии выбранного механизма?

План отката должен иметь крайний срок и критерий остановки: бесконечные переключения между двумя дефектными версиями усугубляют аварию. Флаги mv -T, readlink -f и systemctl зависят от платформы; сценарий должен объявлять GNU/Linux-среду или иметь протестированные альтернативы. Изменение конфигурации и кода в одном развёртывании должно иметь совместимый порядок; новый код может стартовать на старой схеме во время поэтапного переключения. Ссылка может вернуться, но уже выполненная миграция или отправленные сообщения останутся; частичный эффект не отменяется автоматически. Журнал deploy должен содержать release id, предыдущую версию, этап, оператора и статусы, но не секреты и не полный дамп окружения.

Вопрос 23 из 30

В тесте «Сценарий развёртывания» разбирается тема «Проверка и диагностика». Какое замечание точнее всего отделяет учебный пример от промышленного решения?

План отката должен иметь крайний срок и критерий остановки: бесконечные переключения между двумя дефектными версиями усугубляют аварию. Журнал deploy должен содержать release id, предыдущую версию, этап, оператора и статусы, но не секреты и не полный дамп окружения. Флаги mv -T, readlink -f и systemctl зависят от платформы; сценарий должен объявлять GNU/Linux-среду или иметь протестированные альтернативы. Воспроизводимая сборка упрощает аудит, но deploy всё равно обязан проверить подпись или digest и совместимость миграций. Успешный 200 подтверждает ответ endpoint, но не обязательно подключение к базе, очередь, версию и критический пользовательский сценарий.

Вопрос 24 из 30

В тесте «Сценарий развёртывания» разбирается тема «Безопасность и переносимость». Какой риск останется даже после корректной реализации основной конструкции?

Воспроизводимая сборка упрощает аудит, но deploy всё равно обязан проверить подпись или digest и совместимость миграций. Флаги mv -T, readlink -f и systemctl зависят от платформы; сценарий должен объявлять GNU/Linux-среду или иметь протестированные альтернативы. Атомарное переключение файлов не делает атомарным состояние памяти, соединений и базы; службе нужен корректный reload или rolling-процесс. План отката должен иметь крайний срок и критерий остановки: бесконечные переключения между двумя дефектными версиями усугубляют аварию. Сценарий создаёт правило полного passwordless sudo; любая уязвимость или подмена команды в deploy-скрипте после установки такого правила даёт root-доступ.

Вопрос 25 из 30

На техническом ревью обсуждают раздел «Сборка». Какой принцип остаётся верным и на обычном, и на граничном входе?

Healthcheck после развёртывания должен проверять функциональный путь и версию, а не только открытый порт процесса. Символическую ссылку current обычно переключают одним rename в той же файловой системе; последовательное удаление и создание создаёт окно отсутствия. Конфигурацию валидируют до переключения версии, отделяя секреты от артефакта и не выводя раскрытые значения в трассировку. Результат зависит от состояния рабочей копии, сети и инструментов сервера; текущая версия может быть перезаписана до завершения проверки. Развёртывание должно использовать идентифицируемый неизменяемый артефакт и проверять его контрольную сумму до активации, а не собирать произвольную ветку на сервере.

Вопрос 26 из 30

На техническом ревью обсуждают раздел «Конфигурация». На какую гарантию Bash следует опираться при техническом ревью этого участка?

Развёртывание должно использовать идентифицируемый неизменяемый артефакт и проверять его контрольную сумму до активации, а не собирать произвольную ветку на сервере. Символическую ссылку current обычно переключают одним rename в той же файловой системе; последовательное удаление и создание создаёт окно отсутствия. Откат должен ссылаться на проверенную предыдущую версию и учитывать необратимые миграции; «вернуть ссылку» недостаточно для всего состояния. Файл становится исполняемым shell-кодом, а xtrace может раскрыть секреты; кроме того, копия секретов остаётся в каталоге релиза. Конфигурацию валидируют до переключения версии, отделяя секреты от артефакта и не выводя раскрытые значения в трассировку.

Вопрос 27 из 30

На техническом ревью обсуждают раздел «Атомарная замена». На каком правиле должен строиться разбор подобных фрагментов?

Развёртывание должно использовать идентифицируемый неизменяемый артефакт и проверять его контрольную сумму до активации, а не собирать произвольную ветку на сервере. Откат должен ссылаться на проверенную предыдущую версию и учитывать необратимые миграции; «вернуть ссылку» недостаточно для всего состояния. Символическую ссылку current обычно переключают одним rename в той же файловой системе; последовательное удаление и создание создаёт окно отсутствия. Символическую ссылку current обычно переключают одним rename в той же файловой системе; последовательное удаление и создание не создаёт окно отсутствия. Конфигурацию валидируют до переключения версии, отделяя секреты от артефакта и не выводя раскрытые значения в трассировку.

Вопрос 28 из 30

На техническом ревью обсуждают раздел «Откат». Какой общий контракт помогает предсказать результат до выполнения?

Ссылка может вернуться, но уже выполненная миграция или отправленные сообщения останутся; частичный эффект не отменяется автоматически. Конфигурацию валидируют до переключения версии, отделяя секреты от артефакта и не выводя раскрытые значения в трассировку. Символическую ссылку current обычно переключают одним rename в той же файловой системе; последовательное удаление и создание создаёт окно отсутствия. Откат должен ссылаться на проверенную предыдущую версию и учитывать необратимые миграции; «вернуть ссылку» недостаточно для всего состояния. Healthcheck после развёртывания должен проверять функциональный путь и версию, а не только открытый порт процесса.

Вопрос 29 из 30

На техническом ревью обсуждают раздел «Проверка и диагностика». Какое правило лучше всего объясняет корректный способ решения?

Развёртывание должно использовать идентифицируемый неизменяемый артефакт и проверять его контрольную сумму до активации, а не собирать произвольную ветку на сервере. Откат должен ссылаться на проверенную предыдущую версию и учитывать необратимые миграции; «вернуть ссылку» недостаточно для всего состояния. Успешный 200 подтверждает ответ endpoint, но не обязательно подключение к базе, очередь, версию и критический пользовательский сценарий. Healthcheck после развёртывания должен проверять функциональный путь и версию, а не только открытый порт процесса. Deploy-пользователь должен иметь только права на каталоги релизов и конкретные действия службы; полный passwordless sudo превращает сценарий в корневой интерфейс.

Вопрос 30 из 30

На техническом ревью обсуждают раздел «Безопасность и переносимость». Какой принцип остаётся верным и на обычном, и на граничном входе?

Сценарий создаёт правило полного passwordless sudo; любая уязвимость или подмена команды в deploy-скрипте после установки такого правила даёт root-доступ. Символическую ссылку current обычно переключают одним rename в той же файловой системе; последовательное удаление и создание создаёт окно отсутствия. Deploy-пользователь должен иметь только права на каталоги релизов и конкретные действия службы; полный passwordless sudo превращает сценарий в корневой интерфейс. Откат должен ссылаться на проверенную предыдущую версию и учитывать необратимые миграции; «вернуть ссылку» недостаточно для всего состояния. Healthcheck после развёртывания должен проверять функциональный путь и версию, а не только открытый порт процесса.