# Infrastructure as Code > Вибрані роботи, що демонструють цю послугу. - [Посилила безпеку даних, впровадивши 1 000 правил RBAC для розробників, екземплярів застосунків, PostgreSQL, MS SQL та інших Linux‑серверів, запобігши несанкціонованому доступу; задокументувала за допомогою автоматизації Ansible.](https://engineer.company/uk/portfolio/enhanced-data-security-by-implementing-1-000-rbac-14/) - [Розгорнула інфраструктуру Azure як код за допомогою Bicep — Container Apps, PostgreSQL Flexible Server, Front Door/WAF та мережу — у середовищах development, staging і production.](https://engineer.company/uk/portfolio/provisioned-azure-infrastructure-as-code-with-bicep-container-68/) - [Налаштувала зберігання резервних копій бази даних як infrastructure‑as‑code, провела аудит готовності до відновлення й задокументувала процедуру відновлення — назвавши залишкові прогалини, а не залишивши їх на час інциденту.](https://engineer.company/uk/portfolio/configured-database-backup-retention-as-infrastructure-as-code-72/) - [Побудувала власну інфраструктуру компанії як 19 плейбуків Ansible і 34 ролі на 12 065 рядках YAML, що зводять живий хост до оголошеного стану, де кожен play ідемпотентний.](https://engineer.company/uk/portfolio/built-the-companys-infrastructure-as-code-108/) - [Втримала всю компанію на одному хості з 512 МБ і одним ядром — git‑форж, вебсервер для семи доменів, Tor, два сервери альтернативних протоколів, резервні копії та блокування вторгнень — розглядаючи 464 МБ доступної пам'яті як зобов'язальне архітектурне обмеження.](https://engineer.company/uk/portfolio/ran-the-whole-company-on-one-512mb-host-109/) - [Загартувала SSH до 24 стверджених директив із тристадійною перевіркою — файл‑кандидат, зібрана конфігурація, а тоді власне зчитування демона — після того, як зчитування спіймало робочий сервер на мовчазному перевизначенні двох із двадцяти чотирьох.](https://engineer.company/uk/portfolio/hardened-ssh-with-three-stage-validation-111/) - [Побудувала зашифровані резервні копії поза хостом на restic із обрізанням за терміном зберігання, перевіркою цілісності та щомісячним автоматизованим навчальним відновленням, а тоді проаудитувала позицію відновлення й записала прогалини, замість лишати їх на знаходження під час інциденту.](https://engineer.company/uk/portfolio/built-encrypted-backups-with-a-monthly-restore-drill-114/) - [Побудувала моніторинг із сигналом живучості, який пінгує лише поки пам'ять і диск здорові, тож ослаблений хост здіймає тривогу, замовкаючи, — і спіймала шість імен змінних, що казали «free», де перевірка правильно вимірювала «available», на порядок різні на машині з 464 МБ.](https://engineer.company/uk/portfolio/built-dead-mans-switch-monitoring-115/) - [Змусила check mode казати правду на всій платформі, знайшовши шість зондів, які ухвалювали рішення за значенням, якого хост ніколи не давав, бо модуль command в Ansible звітує про успіх під --check, повністю пропускаючи саму команду.](https://engineer.company/uk/portfolio/made-ansible-check-mode-tell-the-truth-116/) - [Додала передпольотний play, який виконує той самий код, що й зведення, проти локальних секретів оператора приблизно за секунду, після того як наполовину застосований продакшн‑запуск загинув на дев'ятому завданні з уже записаними на живий хост налаштуваннями swap.](https://engineer.company/uk/portfolio/added-a-preflight-play-for-secrets-117/) - [Звірила зону DNS із 20 записів декларативно з API Cloudflare, з окремими входами для аудиту та експорту в BIND, і вимкнула проксі CDN назад із міркувань приватності після того, як його побудувала.](https://engineer.company/uk/portfolio/reconciled-a-dns-zone-declaratively-118/) - [Зменшила експозицію пісочниці systemd на кожному юніті, який встановлює сама платформа, — служба сигналу живучості з 9,6 UNSAFE до 1,5, звернений до інтернету git‑форж із 8,3 EXPOSED до 1,5 — і додала перевірку парсером під час зведення, знайшовши директиву з помилкою, яку мовчки ігнорували у трьох шаблонах юнітів.](https://engineer.company/uk/portfolio/cut-systemd-sandbox-exposure-across-every-unit-119/) - [Розгорнула власний git‑форж компанії на Soft Serve, приватний за замовчуванням і без вебпанелі, з портом SSH, прив'язаним до loopback за хостом‑переходом, і зробила посадкову сторінку перед ним артефактом збірки основного сайту, а не копією, яку тримають руками.](https://engineer.company/uk/portfolio/deployed-the-companys-own-git-forge-121/) - [Автоматизувала провізіювання другого сервера в другого хмарного провайдера, створивши фаєрвол перед машиною, щоб вона народжувалася за ним, із фаєрволами обох провайдерів, написаними прямо до їхніх REST API, щоб уникнути сторонньої колекції.](https://engineer.company/uk/portfolio/provisioned-a-second-server-from-code-123/) - [Розділила чотири секрети, що належать окремому хосту, після встановлення, що два хости зі спільним сигналом живучості сповіщають менше, ніж два сигнали, а не більше, і що спільна парольна фраза резервних копій робить два хости одним репозиторієм.](https://engineer.company/uk/portfolio/split-every-operational-secret-per-host-125/) - [Відрепетирувала CI‑хук на боці форжу й знайшла два дефекти, недосяжні читанням файлу: запасний варіант, який клав нерозв'язний аргумент на вхід хука, і власну змінну середовища git, яка йшла за воротами у checkout і робила 19 тестів червоними.](https://engineer.company/uk/portfolio/rehearsed-the-forge-side-ci-hook-151/) - [Опублікувала сайт як onion‑дзеркало в Tor на читабельній адресі, що починається з engineer, з ключем, згенерованим поза хостом, тож він ніколи не потрапив ні до цього репозиторію, ні на ноутбук, і лишила ці двері єдиними з чотирьох, які ніколи не рахують.](https://engineer.company/uk/portfolio/published-the-site-as-a-tor-onion-mirror-on-a-readable-168/)