BA & SA | 10000 Interview questions

№4714 категория вопросов: #INTEGRATION

Неделя выставок на Афише: билеты с кешбэком до 40% Только с 23 февраля по 1 марта при покупке билетов на выставки, мастер-классы и экскурсии — 30% бонусами Спасибо для всех и 40% бонусами для подписчиков СберПрайм. Не пропустите! Максимум – 1000 бонусов. Начислим их после посещения мероприятия. Узнать больше #реклама 16+ afisha.ru О рекламодателе

🧑‍🎓Объяснение: Это задача на выбор подходящего уровня безопасности для B2B-интеграции. Требования: защита от перехвата (шифрование), от подделки (целостность), и аутентификация отправителя. ✅ Почему mTLS — лучший выбор: Шифрование и целостность: HTTPS (TLS) обеспечивает шифрование трафика и защиту от подделки (man-in-the-middle). Взаимная аутентификация (mutual TLS): Обычный TLS проверяет только сертификат сервера (удостоверяет подлинность партнёра для вас). mTLS добавляет проверку клиентского сертификата — партнёр также удостоверяется, что запрос идёт именно от вашей системы. Криптографическая надёжность: Сертификаты сложнее подделать или украсть, чем пароли или API-ключи. Промышленный стандарт: mTLS поддерживается всеми современными HTTP-клиентами и серверами, используется в финансовом секторе, Госуслугах и т.д. ❌ Почему другие варианты хуже: A (Basic Auth по HTTP): Во-первых, HTTP не шифрует трафик — логин и пароль передаются в открытом виде (base64, который легко декодируется). Во-вторых, Basic Auth даёт слабую аутентификацию, пароли можно подобрать или перехватить. B (API-ключ без шифрования): API-ключ — это фактически пароль. Без шифрования он передаётся открыто и может быть украден. К тому же, API-ключ не даёт криптографической гарантии подлинности отправителя. D (VPN): VPN создаёт зашифрованный туннель между сетями, что решает проблему шифрования. Но: VPN сложнее настраивать и поддерживать (нужно оборудование/софт с обеих сторон) Он не решает проблему аутентификации конкретного приложения внутри туннеля — любой сервис из вашей сети сможет отправлять запросы Избыточно для одной интеграции Совет: Для B2B-интеграций с высокими требованиями к безопасности (финансы, персональные данные) mTLS — стандарт. В спецификации обязательно укажите требования к сертификатам: кто выпускает, срок действия, процедура обновления.

№4713 категория вопросов: #INTEGRATION

Познакомьтесь с профессией нутрициолога: бесплатный курс ✅ Успейте занять место! Бонус за участие: доступ в закрытый канал Telegram-клуб. Узнать больше #реклама 16+ miin.ru О рекламодателе

🧑‍🎓Объяснение: Это классическая проблема дублирования сообщений в распределённых системах. Даже надёжные брокеры могут при сбоях доставить сообщение повторно (at-least-once delivery). ✅ Почему вариант B — правильный: Идемпотентность — это свойство операции, при котором многократное выполнение даёт тот же результат, что и однократное. В контексте интеграции это означает, что получатель должен уметь распознавать дубликаты и игнорировать их. Как это реализовать: Каждое сообщение содержит уникальный идентификатор (например, message_id или order_id) Получатель перед обработкой проверяет в своей БД, не обрабатывал ли он уже сообщение с таким ID Если обрабатывал — просто подтверждает получение и ничего не делает Это стандартный паттерн для очередей (RabbitMQ, Kafka) и для REST API с идемпотентными ключами. ❌ Почему другие варианты не решают проблему: A (Увеличить таймауты и добавить retry): Это только увеличит вероятность повторных отправок при сбоях, но не устранит дубликаты. Retry нужны для надёжности, но они должны сочетаться с идемпотентностью. C (Перейти на синхронный REST): Синхронные вызовы тоже могут дублироваться при таймаутах (клиент не получил ответ и отправил ещё раз). Проблема не решается сменой протокола. D (Хранить все отправленные сообщения): Это полезно для аудита, но не предотвращает дублирование. Если служба доставки получит дубликат, она его обработает, даже если вы храните логи. Совет: При проектировании интеграции всегда требуйте от команды реализации идемпотентности на стороне получателя. Это одно из золотых правил распределённых систем.

Бесплатный 3-х дневный курс по ландшафтному дизайну Для тех, кто хочет реализовать себя в творческом деле, работать удалённо, ни от кого не зависеть и создавать красоту своими руками Это бесплатно. Подходит новичкам! На онлайн-курсе вы: ✅ Научитесь создавать прекрасные цветники ✅ Разберетесь в трендах ландшафтного дизайна 2026 ✅ Составите планировку участка (даже без навыков рисования) ✅ Получите пошаговый план работы над проектом участка В результате прохождения интенсива вы узнаете, как стать ландшафтным дизайнером, создать сад своей мечты и зарабатывать на любимом деле ✨ Чтобы зарегистрироваться на курс - переходите по ссылке. Уроки бесплатные, поэтому количество мест ограничено. Зарегистрироваться #реклама 16+ sosnovkadesign.ru О рекламодателе

№4712 категория вопросов: #INTEGRATION

🧑‍🎓Объяснение: Это пример типичной проблемы семантической совместимости при интеграциях. Разные системы могут по-разному представлять одни и те же данные. ✅ Почему вариант B — правильный: Аналитик должен зафиксировать в требованиях правила трансформации данных (data mapping). В данном случае: Входной формат CRM: DD.MM.YYYY (строка или дата) Ожидаемый формат внешнего API: YYYY-MM-DD Задача: преобразовать на стороне интеграционного слоя (адаптера, ESB или микросервиса-интегратора) Это не требует изменения исходной CRM (что было бы сложно и дорого) и не полагается на "магию" внешнего сервиса. Чёткая спецификация маппинга — ответственность аналитика. ❌ Почему другие варианты хуже: A (Передать как есть): Надеяться, что внешний сервис "поймёт" другой формат — наивно. Скорее всего, сервис вернёт ошибку валидации или, что хуже, интерпретирует 01.02.2024 как 01 февраля 2024 вместо 02 января 2024 (в американском формате). Это приведёт к некорректным данным. C (Изменить схему CRM): Технически возможно, но это означает изменение ядра системы, что требует времени, тестирования и может затронуть другие модули. Непропорционально сложно для задачи интеграции. D (Общий API-шлюз с авто-конвертацией): Создание "умного" шлюза, который пытается угадать формат и сконвертировать, опасно. Форматы дат не всегда можно определить однозначно (например, 01/02/2024 — это январь или февраль?). Лучше явно указать правило. Совет: В документации к интеграции всегда создавайте таблицу маппинга полей, где для каждого поля указано: Поле в источнике (название, тип, формат) Поле в приёмнике (название, тип, формат) Правило преобразования (например, TO_DATE(birth_date, 'DD.MM.YYYY'))

Онлайн-школа программирования Kata Academy Хочешь стабильную работу без страха увольнений? 1С-разработчик — одна из самых защищённых IT-профессий в России и СНГ в 2026 году. Более 80% предприятий используют решения 1С! Приглашаем на курс «1С-разработчик» в Kata Academy с нуля до выхода на работу за 9 месяцев! ✅ Гарантия трудоустройства, условия прописаны в договоре ✅ Ментор, карьерный консультант, mock-собеседования, сопровождение до оффера ✅ Можно внести основную часть оплаты за курс после трудоустройства Более 4500 наших выпускников уже работают! Мы точно знаем, как привести начинающего специалиста к первому офферу! Без стажировок, только вакансии с достойной зарплатой. Поступай сейчас и начнешь IT-карьеру в этом году Перейти на сайт #реклама 16+ kata.academy О рекламодателе

№4711 категория вопросов: #INTEGRATION

🧑‍🎓Объяснение: Это классическая задача проектирования платёжной интеграции, где важно учесть и пользовательский опыт, и надёжность. ✅ Почему комбинация — оптимальное решение: Синхронный вызов для инициации платежа: Пользователь ожидает мгновенного перехода на страницу оплаты. REST-вызов позволяет сразу получить URL платёжной формы или токен для редиректа. Это естественно для пользовательского сценария. Асинхронный webhook для результата: Платёж может обрабатываться долго (fraud-проверки, 3D-Secure, межбанковские переводы). Синхронно ждать ответа — значит блокировать пользователя и держать соединение. Webhook позволяет платёжному шлюзу уведомить магазин, когда платёж точно завершён (успех/отказ). Это надёжно и не нагружает сервер магазина. Дополнительно: синхронный запрос статуса (polling) как fallback: Если webhook не пришёл (сбой сети), можно периодически опрашивать API для получения актуального статуса. Это добавляет надёжности. ❌ Почему другие варианты не подходят: A (Только REST API): Если ждать ответ синхронно, пользователь будет "висеть" в ожидании, а при сбое соединения потеряет результат. Платежи могут обрабатываться минутами — это неприемлемо. B (Только webhook): Непонятно, как пользователь сразу попадёт на страницу оплаты. Webhook — это уведомление сервера, а не редирект для клиента. D (Общая база данных): Антипаттерн интеграции. Давать внешнему сервису прямой доступ к своей БД — значит нарушать инкапсуляцию, создавать риски безопасности и зависимости от схемы данных. Совет: В реальных проектах всегда проектируйте платёжную интеграцию как комбинацию синхронного старта и асинхронного уведомления. Это стандарт, принятый во всех крупных платёжных системах (CloudPayments, YooKassa, Stripe).

ТОП-нейроупражнений для учебы на "4" и "5". Даже с СДВГ Мамы и папы! Надоели тройки, невнимательность и отказы от учебы? Ребенок не может сосредоточиться на уроках и все время отвлекается? Шамиль Ахмадуллин — создатель 70+ школ, помог 200 000+ семей — делится проверенными методами! Бесплатный 5-дневный марафон от Шамиля Ахмадуллина День 1: Супер-внимание за 15 минут ежедневно День 2: Лучшие нейроупражнения от СДВГ — концентрация на 100%! День 3: От "3" к "5" без скандалов и принуждения День 4: Как выстроить процесс обучения на учебный год, чтобы ребенку было легко и интересно учиться? День 5: Пошаговый план как помочь ребенку научиться учиться самостоятельно Итог: Школьник 11+ лет станет внимательным, самостоятельным и отличником! Тысячи родителей уже добились успеха. Бесплатная регистрация! Места заканчиваются! Перейти на сайт #реклама 16+ shamil-edu.ru О рекламодателе

№4710 категория вопросов: #INTEGRATION

🧑‍🎓Объяснение: Это задача на выбор подходящего уровня безопасности для B2B-интеграции. Требования: защита от перехвата (шифрование), от подделки (целостность), и аутентификация отправителя. ✅ Почему mTLS — лучший выбор: Шифрование и целостность: HTTPS (TLS) обеспечивает шифрование трафика и защиту от подделки (man-in-the-middle). Взаимная аутентификация (mutual TLS): Обычный TLS проверяет только сертификат сервера (удостоверяет подлинность партнёра для вас). mTLS добавляет проверку клиентского сертификата — партнёр также удостоверяется, что запрос идёт именно от вашей системы. Криптографическая надёжность: Сертификаты сложнее подделать или украсть, чем пароли или API-ключи. Промышленный стандарт: mTLS поддерживается всеми современными HTTP-клиентами и серверами, используется в финансовом секторе, Госуслугах и т.д. ❌ Почему другие варианты хуже: A (Basic Auth по HTTP): Во-первых, HTTP не шифрует трафик — логин и пароль передаются в открытом виде (base64, который легко декодируется). Во-вторых, Basic Auth даёт слабую аутентификацию, пароли можно подобрать или перехватить. B (API-ключ без шифрования): API-ключ — это фактически пароль. Без шифрования он передаётся открыто и может быть украден. К тому же, API-ключ не даёт криптографической гарантии подлинности отправителя. D (VPN): VPN создаёт зашифрованный туннель между сетями, что решает проблему шифрования. Но: VPN сложнее настраивать и поддерживать (нужно оборудование/софт с обеих сторон) Он не решает проблему аутентификации конкретного приложения внутри туннеля — любой сервис из вашей сети сможет отправлять запросы Избыточно для одной интеграции Совет: Для B2B-интеграций с высокими требованиями к безопасности (финансы, персональные данные) mTLS — стандарт. В спецификации обязательно укажите требования к сертификатам: кто выпускает, срок действия, процедура обновления.