💡 Инструкция: Выберите один ответ из пяти. Время — 85 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 6 тематических результатов и разбор всех ответов.
Вопрос 1 из 30
Что произойдёт после последней строки в примере по теме «Сериализация»? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Сериализация Копировать
# Проследите выполнение и выберите точный результат.
payload = {
id: user.id,
name: user.name,
created_at: user.created_at.iso8601
}
render json: payload
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Это объясняется тем, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Это объясняется тем, что сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Это объясняется тем, что сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Это объясняется тем, что ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Это объясняется тем, что сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Вопрос 3 из 30
Проследите выполнение фрагмента. Какой результат верен для темы «Аутентификация»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Аутентификация Копировать
# Проследите выполнение и выберите точный результат.
def show
order = current_user.orders.find(params[:id])
render json: OrderSerializer.new(order)
end
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Такой итог следует из правила: аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Такой итог следует из правила: аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
После проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю. Такой итог следует из правила: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
После проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю. Такой итог следует из правила: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
После проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю. Такой итог следует из правила: аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Вопрос 4 из 30
Не запуская пример, выберите точный итог для блока «Ошибки протокола». Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Ошибки протокола Копировать
# Проследите выполнение и выберите точный результат.
rescue_from ActiveRecord::RecordInvalid do |error|
render json: {
error: 'validation_failed',
fields: error.record.errors.to_hash
}, status: :unprocessable_entity
end
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Механизм результата таков: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
RecordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей. Механизм результата таков: сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
RecordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей. Механизм результата таков: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
RecordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей. Механизм результата таков: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Маршруты разводят `/api/v1/orders` и `/api/v2/orders` по разным пространствам имён. Механизм результата таков: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Вопрос 5 из 30
Разберите выражения по порядку. Как завершится фрагмент из раздела «Наблюдаемость и диагностика»? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Наблюдаемость и диагностика Копировать
# Проследите выполнение и выберите точный результат.
Rails.logger.info(
event: 'api_request_finished',
request_id: request.request_id,
route: request.path_parameters[:controller],
status: response.status,
duration_ms: elapsed_ms
)
RecordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей. Наблюдение согласуется с тем, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Наблюдение согласуется с тем, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Наблюдение согласуется с тем, что ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Наблюдение согласуется с тем, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Наблюдение согласуется с тем, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Вопрос 6 из 30
Какой вариант верно описывает состояние объектов после выполнения кода «Надёжность в эксплуатации»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Надёжность в эксплуатации Копировать
# Проследите выполнение и выберите точный результат.
result = PaymentCommand.call(
user: current_user,
amount: params[:amount],
idempotency_key: request.headers['Idempotency-Key']
)
render json: result, status: result.created? ? :created : :ok
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Этот вывод опирается на правило: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Этот вывод опирается на правило: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Этот вывод опирается на правило: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Этот вывод опирается на правило: аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Этот вывод опирается на правило: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Вопрос 7 из 30
Какой отказ связан с причиной в коде, а не с внешним шумом, в теме «Сериализация»? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Сериализация Копировать
# Обычный запуск проходит. Найдите скрытый риск.
payload = {
id: user.id,
name: user.name,
created_at: user.created_at.iso8601
}
render json: payload
Передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены. Причина — ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. Причина — сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены. Причина — сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id. Причина — сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены. Причина — диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Вопрос 8 из 30
Какой отказ связан с причиной в коде, а не с внешним шумом, в теме «Версионирование»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Версионирование Копировать
# Обычный запуск проходит. Найдите скрытый риск.
namespace :api do
namespace :v1 do
resources :orders, only: :index
end
namespace :v2 do
resources :orders, only: :index
end
end
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Этот риск связан с тем, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Этот риск связан с тем, что версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Этот риск связан с тем, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. Этот риск связан с тем, что версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. Этот риск связан с тем, что версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций.
Вопрос 9 из 30
Что может сломаться при переносе этого решения «Аутентификация» в рабочую систему? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Аутентификация Копировать
# Обычный запуск проходит. Найдите скрытый риск.
def show
order = current_user.orders.find(params[:id])
render json: OrderSerializer.new(order)
end
Поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id. Уязвимое место возникает потому, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены. Уязвимое место возникает потому, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id. Уязвимое место возникает потому, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. Уязвимое место возникает потому, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id. Уязвимое место возникает потому, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Вопрос 10 из 30
Какое допущение делает этот код по теме «Ошибки протокола» ненадёжным? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Ошибки протокола Копировать
# Обычный запуск проходит. Найдите скрытый риск.
rescue_from ActiveRecord::RecordInvalid do |error|
render json: {
error: 'validation_failed',
fields: error.record.errors.to_hash
}, status: :unprocessable_entity
end
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. К такому сбою приводит правило: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. К такому сбою приводит правило: сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. К такому сбою приводит правило: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. К такому сбою приводит правило: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. К такому сбою приводит правило: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Вопрос 11 из 30
Какое допущение делает этот код по теме «Наблюдаемость и диагностика» ненадёжным? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Наблюдаемость и диагностика Копировать
# Обычный запуск проходит. Найдите скрытый риск.
Rails.logger.info(
event: 'api_request_finished',
request_id: request.request_id,
route: request.path_parameters[:controller],
status: response.status,
duration_ms: elapsed_ms
)
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. Источник риска: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Источник риска: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. Источник риска: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. Источник риска: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. Источник риска: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Вопрос 12 из 30
Какое допущение делает этот код по теме «Надёжность в эксплуатации» ненадёжным? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Надёжность в эксплуатации Копировать
# Обычный запуск проходит. Найдите скрытый риск.
result = PaymentCommand.call(
user: current_user,
amount: params[:amount],
idempotency_key: request.headers['Idempotency-Key']
)
render json: result, status: result.created? ? :created : :ok
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. Проблема возникает из-за того, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию. Проблема возникает из-за того, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию. Проблема возникает из-за того, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию. Проблема возникает из-за того, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Проблема возникает из-за того, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Вопрос 13 из 30
Какой контракт нужно помнить при ревью кода по теме «Сериализация»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Поэтому ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели. Поэтому идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента. Поэтому ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели. Поэтому ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели. Поэтому структурная запись содержит request_id, route, status и duration без полного тела запроса.
Вопрос 14 из 30
Какое общее правило связывает результат и риск в разделе «Версионирование»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Из этого следует, что маршруты разводят `/api/v1/orders` и `/api/v2/orders` по разным пространствам имён.
Версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций. Из этого следует, что recordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей.
Версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций. Из этого следует, что структурная запись содержит request_id, route, status и duration без полного тела запроса.
Версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций. Из этого следует, что маршруты разводят `/api/v1/orders` и `/api/v2/orders` по разным пространствам имён.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Из этого следует, что маршруты разводят `/api/v1/orders` и `/api/v2/orders` по разным пространствам имён.
Вопрос 15 из 30
На какой контракт языка или библиотеки опирается результат блока «Аутентификация»? Нужен вариант без логического разрыва между первой и второй частью.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Наблюдаемое следствие: после проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Наблюдаемое следствие: после проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Наблюдаемое следствие: после проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Наблюдаемое следствие: ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Наблюдаемое следствие: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Вопрос 17 из 30
Как сформулировать правило блока «Наблюдаемость и диагностика» без лишних обещаний? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента. Это правило даёт такой результат: структурная запись содержит request_id, route, status и duration без полного тела запроса.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Это правило даёт такой результат: структурная запись содержит request_id, route, status и duration без полного тела запроса.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Это правило даёт такой результат: структурная запись содержит request_id, route, status и duration без полного тела запроса.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Это правило даёт такой результат: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Это правило даёт такой результат: recordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей.
Вопрос 18 из 30
Как сформулировать правило блока «Надёжность в эксплуатации» без лишних обещаний? Верный вариант не содержит частично правильной подмены причины или следствия.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Практическое следствие правила: структурная запись содержит request_id, route, status и duration без полного тела запроса.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Практическое следствие правила: ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Практическое следствие правила: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Практическое следствие правила: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Практическое следствие правила: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Вопрос 19 из 30
Какой рефакторинг переводит правило «Сериализация» из договорённости в проверяемый контракт? Правильным считается только полностью согласованное утверждение.
Ruby Ruby — Сериализация Копировать
# Выберите изменение, которое исправляет причину.
payload = {
id: user.id,
name: user.name,
created_at: user.created_at.iso8601
}
render json: payload
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. Так закрывается риск: передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Так закрывается риск: передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Так закрывается риск: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Так закрывается риск: поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id.
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Так закрывается риск: передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены.
Вопрос 20 из 30
Какой рефакторинг делает контракт блока «Версионирование» явным и проверяемым? Верный вариант не содержит частично правильной подмены причины или следствия.
Ruby Ruby — Версионирование Копировать
# Выберите изменение, которое исправляет причину.
namespace :api do
namespace :v1 do
resources :orders, only: :index
end
namespace :v2 do
resources :orders, only: :index
end
end
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. Это изменение устраняет проблему: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. Это изменение устраняет проблему: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Это изменение устраняет проблему: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ. Это изменение устраняет проблему: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. Это изменение устраняет проблему: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Вопрос 22 из 30
Что следует изменить в решении «Ошибки протокола», чтобы закрыть исходный риск? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Ошибки протокола Копировать
# Выберите изменение, которое исправляет причину.
rescue_from ActiveRecord::RecordInvalid do |error|
render json: {
error: 'validation_failed',
fields: error.record.errors.to_hash
}, status: :unprocessable_entity
end
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Решение адресует следующий дефект: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Решение адресует следующий дефект: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события. Решение адресует следующий дефект: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события. Решение адресует следующий дефект: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события. Решение адресует следующий дефект: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Вопрос 23 из 30
Что следует изменить в решении «Наблюдаемость и диагностика», чтобы закрыть исходный риск? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Наблюдаемость и диагностика Копировать
# Выберите изменение, которое исправляет причину.
Rails.logger.info(
event: 'api_request_finished',
request_id: request.request_id,
route: request.path_parameters[:controller],
status: response.status,
duration_ms: elapsed_ms
)
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Именно эта мера закрывает риск: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события. Именно эта мера закрывает риск: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Именно эта мера закрывает риск: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Именно эта мера закрывает риск: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Именно эта мера закрывает риск: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Вопрос 24 из 30
Какое изменение устраняет причину проблемы в теме «Надёжность в эксплуатации», а не маскирует симптом? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Надёжность в эксплуатации Копировать
# Выберите изменение, которое исправляет причину.
result = PaymentCommand.call(
user: current_user,
amount: params[:amount],
idempotency_key: request.headers['Idempotency-Key']
)
render json: result, status: result.created? ? :created : :ok
Хранить ключ вместе с отпечатком команды и ответом, ограничивать срок и отклонять повтор с другим содержимым. После изменения не должен сохраняться риск: retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию.
Ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ. После изменения не должен сохраняться риск: retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию.
Хранить ключ вместе с отпечатком команды и ответом, ограничивать срок и отклонять повтор с другим содержимым. После изменения не должен сохраняться риск: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Хранить ключ вместе с отпечатком команды и ответом, ограничивать срок и отклонять повтор с другим содержимым. После изменения не должен сохраняться риск: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. После изменения не должен сохраняться риск: retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию.
Вопрос 25 из 30
Какой контрпример проверит реальную границу механизма «Сериализация»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Проверить nil, часовой пояс, большие числа и пустые связи: JSON-форма должна быть стабильной. Этот сценарий проверяет исправление: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить nil, часовой пояс, большие числа и пустые связи: JSON-форма должна быть стабильной. Этот сценарий проверяет исправление: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить nil, часовой пояс, большие числа и пустые связи: JSON-форма должна быть стабильной. Этот сценарий проверяет исправление: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Этот сценарий проверяет исправление: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Проверить одновременные запросы с одним ключом: уникальность и блокировка должны работать атомарно. Этот сценарий проверяет исправление: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Вопрос 26 из 30
Какой сценарий должен падать на старой реализации и проходить после исправления «Версионирование»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. Так проверяется решение: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Так проверяется решение: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить клиента, который прислал неизвестную или уже снятую версию: ответ должен быть машинно различимым. Так проверяется решение: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить клиента, который прислал неизвестную или уже снятую версию: ответ должен быть машинно различимым. Так проверяется решение: ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ.
Проверить клиента, который прислал неизвестную или уже снятую версию: ответ должен быть машинно различимым. Так проверяется решение: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Вопрос 27 из 30
Какой случай покажет, что исправление «Аутентификация» не держится на удачном входе? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Проверка относится к изменению: ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Проверка относится к изменению: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. Проверка относится к изменению: ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Проверка относится к изменению: ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Проверка относится к изменению: хранить ключ вместе с отпечатком команды и ответом, ограничивать срок и отклонять повтор с другим содержимым.
Вопрос 28 из 30
Что нужно воспроизвести отдельно перед выпуском изменения «Ошибки протокола»? Верный вариант не содержит частично правильной подмены причины или следствия.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Сценарий подтверждает надёжность решения: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Сценарий подтверждает надёжность решения: создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Сценарий подтверждает надёжность решения: создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Сценарий подтверждает надёжность решения: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. Сценарий подтверждает надёжность решения: создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события.
Вопрос 29 из 30
Какую границу контракта «Наблюдаемость и диагностика» нужно закрепить отдельным тестом? Верный вариант не содержит частично правильной подмены причины или следствия.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. На этой границе проверяется мера: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. На этой границе проверяется мера: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. На этой границе проверяется мера: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. На этой границе проверяется мера: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. На этой границе проверяется мера: создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события.