Создаст ли сервис автоматически объект при передаче данных в query параметрах

Что проверяют

Не знание фреймворка, а привычку опираться на контракт вместо догадки. И умение проверять побочный эффект, а не только код ответа: создание объекта видно не в теле ответа, а в базе, логах и последующем запросе.

Как отвечать

Правильный ответ начинается с «зависит от того, что написано в спецификации». Сами по себе query-параметры ничего не создают: фреймворк только разбирает строку запроса и складывает значения в объект в памяти, например через @RequestParam или @ModelAttribute в Spring. Запись появляется, когда так решила бизнес-логика.

Дальше показать порядок действий. Посмотреть OpenAPI и требования, уточнить у аналитика или разработчика, потом проверить фактически: отправить запрос, посмотреть базу и логи, дёрнуть чтение и убедиться, что объект есть или его нет. Отдельно проговорить семантику: если ресурс создаётся на GET, это дефект дизайна, потому что GET считается безопасным и его повторяют браузеры, кэши, прокси и краулеры. Набор проверок: обязательные и необязательные параметры, пустое значение, неизвестный параметр, дубль одного имени, регистр, кодирование, длина URL, инъекции, повтор запроса и идемпотентность.

Где спотыкаются

Останавливаются на коде ответа. Пришло 200, значит всё хорошо, а строка в базе так и не появилась либо появилась дважды. Проверка побочного эффекта это отдельный шаг, и его ждут в ответе.

Отвечают уверенным «да, создаст», опираясь на прошлый проект. Вопрос сформулирован так, чтобы проверить, зададите ли вы уточняющий вопрос, и однозначный ответ без оговорок здесь и есть ошибка.

Не думают про повтор и про неизвестные параметры. Повторный одинаковый запрос может породить дубль, а лишний параметр может молча игнорироваться или давать 400. И то и другое поведение обязано быть в контракте, иначе это готовый баг на требования.