💡 Инструкция: Выберите один ответ из пяти. Время — 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, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Это объясняется тем, что сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Это объясняется тем, что сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Это объясняется тем, что сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Это объясняется тем, что ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Вопрос 3 из 30
Проследите выполнение фрагмента. Какой результат верен для темы «Аутентификация»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Аутентификация Копировать
# Проследите выполнение и выберите точный результат.
def show
order = current_user.orders.find(params[:id])
render json: OrderSerializer.new(order)
end
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Такой итог следует из правила: аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
После проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю. Такой итог следует из правила: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
После проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю. Такой итог следует из правила: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
После проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю. Такой итог следует из правила: аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Такой итог следует из правила: аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Вопрос 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
RecordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей. Механизм результата таков: сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
RecordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей. Механизм результата таков: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Маршруты разводят `/api/v1/orders` и `/api/v2/orders` по разным пространствам имён. Механизм результата таков: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Механизм результата таков: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
RecordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей. Механизм результата таков: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Вопрос 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
)
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Наблюдение согласуется с тем, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Наблюдение согласуется с тем, что ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
RecordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей. Наблюдение согласуется с тем, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Наблюдение согласуется с тем, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Наблюдение согласуется с тем, что диагностика 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
Структурная запись содержит request_id, route, status и duration без полного тела запроса. Этот вывод опирается на правило: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Этот вывод опирается на правило: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания. Этот вывод опирается на правило: аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели. Этот вывод опирается на правило: надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Идемпотентный ключ позволяет повторному 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 должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id. Причина — сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены. Причина — диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены. Причина — ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. Причина — сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Вопрос 8 из 30
Какой отказ связан с причиной в коде, а не с внешним шумом, в теме «Версионирование»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Версионирование Копировать
# Обычный запуск проходит. Найдите скрытый риск.
namespace :api do
namespace :v1 do
resources :orders, only: :index
end
namespace :v2 do
resources :orders, only: :index
end
end
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. Этот риск связан с тем, что версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. Этот риск связан с тем, что версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Этот риск связан с тем, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Этот риск связан с тем, что версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Этот риск связан с тем, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Вопрос 9 из 30
Что может сломаться при переносе этого решения «Аутентификация» в рабочую систему? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Аутентификация Копировать
# Обычный запуск проходит. Найдите скрытый риск.
def show
order = current_user.orders.find(params[:id])
render json: OrderSerializer.new(order)
end
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. Уязвимое место возникает потому, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id. Уязвимое место возникает потому, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id. Уязвимое место возникает потому, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id. Уязвимое место возникает потому, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены. Уязвимое место возникает потому, что аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам.
Вопрос 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
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. К такому сбою приводит правило: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. К такому сбою приводит правило: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. К такому сбою приводит правило: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. К такому сбою приводит правило: ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению. К такому сбою приводит правило: сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели.
Вопрос 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 должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента.
Копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил. Источник риска: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма. Источник риска: диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Единый 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 задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию. Проблема возникает из-за того, что надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей.
Retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию. Проблема возникает из-за того, что диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам.
Вопрос 13 из 30
Какой контракт нужно помнить при ревью кода по теме «Сериализация»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента. Поэтому ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели. Поэтому ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Поэтому ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели. Поэтому идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Сериализация API должна быть явным представлением ресурса: набор полей, форматы дат и вложенность не обязаны совпадать со схемой модели. Поэтому структурная запись содержит request_id, route, status и duration без полного тела запроса.
Вопрос 14 из 30
Какое общее правило связывает результат и риск в разделе «Версионирование»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Из этого следует, что маршруты разводят `/api/v1/orders` и `/api/v2/orders` по разным пространствам имён.
Версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций. Из этого следует, что структурная запись содержит request_id, route, status и duration без полного тела запроса.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Из этого следует, что маршруты разводят `/api/v1/orders` и `/api/v2/orders` по разным пространствам имён.
Версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций. Из этого следует, что recordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей.
Версионирование должно обозначать несовместимый контракт и иметь срок поддержки; номер в URL или заголовке сам по себе не предотвращает расхождение реализаций. Из этого следует, что маршруты разводят `/api/v1/orders` и `/api/v2/orders` по разным пространствам имён.
Вопрос 15 из 30
На какой контракт языка или библиотеки опирается результат блока «Аутентификация»? Нужен вариант без логического разрыва между первой и второй частью.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Наблюдаемое следствие: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Наблюдаемое следствие: после проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Наблюдаемое следствие: после проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Наблюдаемое следствие: ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Наблюдаемое следствие: после проверки подписи токена контроллер отдельно убеждается, что заказ принадлежит текущему пользователю.
Вопрос 17 из 30
Как сформулировать правило блока «Наблюдаемость и диагностика» без лишних обещаний? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ошибка API должна иметь подходящий HTTP-статус, стабильный код и безопасные детали; необработанное исключение не является контрактом клиента. Это правило даёт такой результат: структурная запись содержит request_id, route, status и duration без полного тела запроса.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Это правило даёт такой результат: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Это правило даёт такой результат: структурная запись содержит request_id, route, status и duration без полного тела запроса.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Это правило даёт такой результат: recordInvalid превращается в 422 с машинным кодом и перечнем допустимых ошибок полей.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Это правило даёт такой результат: структурная запись содержит request_id, route, status и duration без полного тела запроса.
Вопрос 18 из 30
Как сформулировать правило блока «Надёжность в эксплуатации» без лишних обещаний? Верный вариант не содержит частично правильной подмены причины или следствия.
Диагностика API должна связывать запрос, SQL, фоновые задания и внешние вызовы через корреляционный идентификатор и измерять задержку по этапам. Практическое следствие правила: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Практическое следствие правила: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Практическое следствие правила: ответ содержит только id, name и строку времени ISO 8601, не раскрывая служебные столбцы модели.
Надёжный API задаёт таймауты, лимиты, идемпотентность команд и обратное давление; ускорение одного контроллера не устраняет перегрузку зависимостей. Практическое следствие правила: структурная запись содержит request_id, route, status и duration без полного тела запроса.
Аутентификация устанавливает личность, авторизация проверяет право на конкретное действие; наличие корректного токена не даёт доступ ко всем ресурсам. Практическое следствие правила: идемпотентный ключ позволяет повторному POST вернуть прежний результат вместо второго списания.
Вопрос 19 из 30
Какой рефакторинг переводит правило «Сериализация» из договорённости в проверяемый контракт? Правильным считается только полностью согласованное утверждение.
Ruby Ruby — Сериализация Копировать
# Выберите изменение, которое исправляет причину.
payload = {
id: user.id,
name: user.name,
created_at: user.created_at.iso8601
}
render json: payload
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Так закрывается риск: передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены.
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Так закрывается риск: передача `render json: model` без контроля постепенно публикует новые атрибуты после миграций, включая внутренние флаги и токены.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Так закрывается риск: поиск `Order.find(params[:id])` до проверки владельца позволяет авторизованному пользователю читать чужие записи по последовательным id.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Так закрывается риск: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. Так закрывается риск: передача `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
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. Это изменение устраняет проблему: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Это изменение устраняет проблему: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ. Это изменение устраняет проблему: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. Это изменение устраняет проблему: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. Это изменение устраняет проблему: журналирование токена, пароля или всего 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
Создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события. Решение адресует следующий дефект: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Решение адресует следующий дефект: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события. Решение адресует следующий дефект: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события. Решение адресует следующий дефект: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Решение адресует следующий дефект: единый 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 по маршрутам, сохранив выборочную трассировку медленных запросов. Именно эта мера закрывает риск: единый rescue StandardError, возвращающий 400, смешивает дефект сервера с ошибкой клиента и мешает повтору/оповещению.
Определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API. Именно эта мера закрывает риск: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Именно эта мера закрывает риск: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов. Именно эта мера закрывает риск: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события. Именно эта мера закрывает риск: журналирование токена, пароля или всего 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
Хранить ключ вместе с отпечатком команды и ответом, ограничивать срок и отклонять повтор с другим содержимым. После изменения не должен сохраняться риск: журналирование токена, пароля или всего JSON ради диагностики создаёт утечку и затрудняет поиск из-за объёма.
Хранить ключ вместе с отпечатком команды и ответом, ограничивать срок и отклонять повтор с другим содержимым. После изменения не должен сохраняться риск: копирование контроллера целиком для каждой версии создаёт расходящиеся исправления безопасности и бизнес-правил.
Ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ. После изменения не должен сохраняться риск: retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию.
Хранить ключ вместе с отпечатком команды и ответом, ограничивать срок и отклонять повтор с другим содержимым. После изменения не должен сохраняться риск: retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию.
Разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии. После изменения не должен сохраняться риск: retry клиента без ключа после сетевого обрыва может повторить уже зафиксированную операцию.
Вопрос 25 из 30
Какой контрпример проверит реальную границу механизма «Сериализация»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Проверить nil, часовой пояс, большие числа и пустые связи: JSON-форма должна быть стабильной. Этот сценарий проверяет исправление: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Этот сценарий проверяет исправление: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Проверить одновременные запросы с одним ключом: уникальность и блокировка должны работать атомарно. Этот сценарий проверяет исправление: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Проверить nil, часовой пояс, большие числа и пустые связи: JSON-форма должна быть стабильной. Этот сценарий проверяет исправление: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить nil, часовой пояс, большие числа и пустые связи: JSON-форма должна быть стабильной. Этот сценарий проверяет исправление: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Вопрос 26 из 30
Какой сценарий должен падать на старой реализации и проходить после исправления «Версионирование»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Так проверяется решение: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. Так проверяется решение: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить клиента, который прислал неизвестную или уже снятую версию: ответ должен быть машинно различимым. Так проверяется решение: ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ.
Проверить клиента, который прислал неизвестную или уже снятую версию: ответ должен быть машинно различимым. Так проверяется решение: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить клиента, который прислал неизвестную или уже снятую версию: ответ должен быть машинно различимым. Так проверяется решение: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Вопрос 27 из 30
Какой случай покажет, что исправление «Аутентификация» не держится на удачном входе? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Проверка относится к изменению: ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Проверка относится к изменению: хранить ключ вместе с отпечатком команды и ответом, ограничивать срок и отклонять повтор с другим содержимым.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Проверка относится к изменению: ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Проверка относится к изменению: разделять общий прикладной слой и версионированное представление/преобразование, публикуя политику вывода старой версии.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. Проверка относится к изменению: ограничивать запрос областью доступных записей и централизовать политику действий, а не фильтровать готовый ответ.
Вопрос 28 из 30
Что нужно воспроизвести отдельно перед выпуском изменения «Ошибки протокола»? Верный вариант не содержит частично правильной подмены причины или следствия.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. Сценарий подтверждает надёжность решения: создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Сценарий подтверждает надёжность решения: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. Сценарий подтверждает надёжность решения: создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Сценарий подтверждает надёжность решения: создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. Сценарий подтверждает надёжность решения: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Вопрос 29 из 30
Какую границу контракта «Наблюдаемость и диагностика» нужно закрепить отдельным тестом? Верный вариант не содержит частично правильной подмены причины или следствия.
Проверить ошибки парсинга JSON, конфликт версии и ограничение частоты: это разные протокольные исходы. На этой границе проверяется мера: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. На этой границе проверяется мера: определить контракт представления отдельно от модели, покрыть его проверкой схемы и считать добавление поля изменением API.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. На этой границе проверяется мера: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить различие 401 и 403/404 в принятой модели угроз, не раскрывая существование закрытого ресурса. На этой границе проверяется мера: определить безопасные поля, маскирование и метрики p50/p95/p99 по маршрутам, сохранив выборочную трассировку медленных запросов.
Проверить прокси и повтор запроса: внешний trace id нельзя безусловно считать доверенным или уникальным. На этой границе проверяется мера: создать небольшую таблицу доменных ошибок и статусов, а неожиданные исключения оставлять 500 с внутренним идентификатором события.