1. Так, саме так у мене безпека і налаштована. І ви вірно сказали, в мене:

никакой хакер или «чайник» с кривым кодом никак не пролезет

2. Інцидент з видаленням бази стався на чужому проєкті, де мене просили зробити міграцію ;)
3.

Что мешает с ролью «User Access Administrator» выдать роль «Owner» любойучётке?

Взагалі не актуально, адже дивіться пункт 1 вище (ви праві, такі махінації в мене «невозможно в принципе»!!!)
4. Вам не здається, що ви видираєте мої слова з контексту, і потім ними ж «маніпулюєте»? Чи мені тільки так здається?)
P.S: тяжко сперечатись з людиною, яка НЕ бачить слів «на мою думку»

Ще раз повторюсь:
1. Для рекурсивних розборів існує опція «point-in-time» в усіх основних БД.
2. Вам ніхто не заважає збільшити періодичність бекапів. Кількість в 17 бекапів взята просто як приклад того, як можна «вписатись» в різні регуляторки, не витрачаючи всіх грошей світу.

КОМБІНАЦІЯ цих двох механізмів дає результат! І я в статті пишу про ОБИДВА !

1.

Ещё раз: одна учетка, под которой ты запускаешь свой код, имеет полный доступ и к БД, и к бекапам. Почему так — тебе, как сеньору, несложно будет понять :-)

- гарна спроба, але в вас не вийшло!) Ви хочете наголосити, що SP має мати права і там і там, щоб мати змогу дати Azure Backup Vault необхідні ролі для читання з БД. І так, це дійсно правда — ви праві. Але є дві невеликі деталі: перша — існують такі RBAC ролі як «Reader» та «User Access Administrator», що не дають прав менеджити ресурси (і саме ці ролі має мати SP на продакшн базу). Друга деталь — є така штука як protected branch, і обмеження/правила самого CI/CD. Створюєте правило, що запуск пайплайни можливий ЛИШЕ з «prod» гілки, а git push в неї можливий лише після МR та 2-х апрувів від інших членів команди — і ви нічого випадково чи навмисно не «похерете» (треба лише прибрати «terraform destroy» опцію). А роль, яка ці CI/CD правила налаштовує — ховаєте за «Eligible assignments» в Azure РІМ з апрувом від членів команди (благо, з усіма основними CI/CD системами в Azure Entra Id вже є інтеграція").
І якраз в різних корзинах яйця по фіналу і лежать....
2. З точки зору ціни — так, згоден з тим, що тут не все однозначно, і ваші коменти є абсолютно валідними. Проте, процитую сам себе:

немає нічого кращого, на мою думку, ніж вже готові

.... Тобто, я не стверджую, що це 100% дешевше! Я натомість кажу, що, НА МОЮ ДУМКУ, всі ті зусилля і час, які ви витратите на створення самописних скриптів, деплой і мейнтененс віртуальних машин та стореджів (написання їх Terraform модулів, плюс ціну за їх хостинг), конфігурацію Azure Logic Apps/Azure Automation... — це все нівелює ті гроші, які ви зекономите на власній інфраструктурі.... Моя думка — дешевше буде написати за пів дня один єдиний Терраформ модуль для Azure Backup Vault і все....

Якраз щоб люди не робили pg_dump/pg_restore ця стаття і написана. Не розумію що вас смутило....

1. До чого тут RPO? Яке це має відношення до теми статті? Кількість в 17 бекапів взято для прикладу, і там про це сказано. Ви можете налаштовувати будь-яку періодичність, яка вам потрібна, як забажаєте. Ця стаття для того щоб показати суть підходу, а не для CtrlC+CtrV
2. Transaction Log наразі є в усіх основних клаудних базах з коробки, це і є механізм за допомогою якого реалізується «point-in-time», про який я писав. Але він ніяк вам не допоможе, якщо вам знесуть весь сервер.
Ну ладно я «ніяким місцем не Senior»..., а хто ж тоді ті люди, які придумали всі ці «Grandfather-father-son» схеми i Azure Backup Vault ?)

1. Тобто ви хочете сказати, що вартістю такої VM можна знехтувати? А як же ви будете її включати/виключати, якщо ви хочете АВТОМАТИЗАЦІЮ процесів? Де ж тоді DevOps підхід і best practices? Виходить, ця віртуалка має мати cron, і працювати 24/7 ? Чи я не правий? Бо якщо ні — то що ж виходить, ви вручну все запускатимете і контролюватимете як виконується pg_dump/pg_restore зі швидкістю 2 равлика на годину? І, якщо мені пам’ять не підводить, то година роботи хорошого девопса коштує приблизно від $30-$50.... То, виходить, ваш варіант з вимиканням VM набагаааатоооо дорожчий.....
2. Як людина видалить бекапи, якщо створював їх Service principal ? Переплутає terraform apply з terraform destroy, і не буде дивитись в план?
3. Якщо навіть їх і видалять, то чим це страшно, коли не видалена оригінальна база (треба, виходить, вже ламати доступи до ДВОХ людей, бо в одному subscription права в одних людей/SP, а в іншому — в інших) ? «різний RBAC» має бути, як я писав...
4. З приводу видалення аккаунту — ну давайте за такою логікою взагалі нічого робити не будемо, все одно ж НЕ можна абсолютно від всього захиститись

Та не хочу я нікуди заходити, дивитись в енвайронментс, розбиратись в нотифікаціях (це ж як треба заморочитись щоб через нотифікації розібратись яка пайплайна куди деплоїлась тиждень назад). Я хочу відкрити ран і відразу бачити з якої гілки і куди пішов деплой. Що, як в мене 100-200 деплоїв за день? Я не хочу в цьому всьому копатись!
Навіщо нам переробляти пайпу задля деплою з нових гілок (hot-fix, наприклад)? А якщо у вас один СПІЛЬНИЙ «test» енв, куди девелопери деплоять і тестують свої фічі (з власних feature гілок звісно ж)? Вказати гілку і енв — єдине, що треба робити з точки зору best-practices. А все інше, всі конфіги, всі депенденсі.... хай пайплайна підхоплює сама, і робить своє діло. Єдине, що треба, це встановити необхідні рестрікшени для деплою на прод та інших важливих речей.
А з приводу «можна це зробити менш складно» — що може бути простіше, ніж додати «extend_vars $VAR_NAME» в назву job ?

А якщо ми деплоїмо з гілки «feature-shototam» на «dev2» то що ми зрозуміємо з назви гілки?

Мій підхід суто для того, щоб по назві джоби відразу розуміти куди пішов деплой. Щоб не було необхідності клікати на джобу, і перевіряти назву енву в логах. Він лише для візуалу, тільки і всього.
Якщо такої необхідності немає — ваш варіант буде навіть кращим, адже прибирає зайву складність

Цей жарт зробив мій день ))

Вибачте за стиль, я просто намагався писати «цікаво» (щоб зацепити). В мене не було мети «знецінення» іншого бачення, яке не співпадає з моїм! Я лише хотів сказати: «я роблю ось так, для досягнення таких цілей...»
Просто мінусом текстового контенту є те, що читач не завжди може оцінити «емоційне» забарвлення цього тексту. Тому багато жартівливих моментів (як я собі напочатку задумав) можна трактувати як агресивне подання матеріалу. Я обов’язково врахую це в наступний раз.

Не піценосів, а фізруків, попрошу ))

1. В вашому прикладі з locals, ви задаєте «дефолтное значение, которое определяется на основании других переменных», або даєте можливість передати кастомне значення.... Тобто ви пеередаєте кастомне значення в «child» модуль, яке ВЖЕ згенерували в «root» модулі? По факту робите так, як я раджу в статті (але не завжди)?
Тоді чому б не викинути ці locals з «child» взагалі, і не перенести їх в «root» модулі, якщо ви все рівно в «специфічних» випадках виносите їх генерування в «root» ?
Я все ж впевнений, що це спростить розуміння логіки коду.

2. Згоден, це сугубо суб’єктивно. Для мене мій варіант здається «зрозумілішим» (наприклад, для людини, яка онбордиться на проект)

3. Ви знову ж таки передаєте ВЖЕ готове значення для «some_var_changed_by_1%_of_child_modules_bool», яке було згенероване в «root» модулі (або ж ставите дефолтне значення, якщо такого немає). Ви не генеруєте значення для пропертів ресурсів в locals «child» модулю, ви лише вказуєте дефолтне значення (що ніяк не суперечить моєму підходу). Але це тяжче читати....
Ну правда, це ви опишете близько 15 lookup-пів ? І як це виглядатиме?
Це звісно суб’єктивно, знову ж таки....

P.S: знов повторюсь, що я не претендую на звяння мессії Тераформу. Я лише описую як роблю я, і для чого я так роблю.

Зовсім забув, ще є така штука як «(optional)» в описаннях variables — це щодо того, як можна одночасно «приймати» одним модулем різні об’єкти з різною кількістю пропертів в них.

1. В «ternary operator» є лише «true» або «false», так? Тобто лише два варіанти ? А якщо треба більше?
2. Що на рахунок «readability» такого підходу? Це полегшує читання коду?
3. Що робити якщо ти в «child» модулі маєш прийняти мапу об’єктів, де у кожного об’єкту по 15-20 пропертів (наприклад, ти хочеш створювати таку махіну як FrontDoor з усіма origins, routing rules, WAF і т.д (реальний кейс з мого досвіду), і мати модуль, який би передбачав можливість деплою FrontDoor за допомогою платформи (Platform engineering), яка ВЖЕ деплоїть більше 10 кастомерів, що потребують кожен «свого унікального» FrontDoor, зі своїми унікальними вимогами і значеннями до нього? Теж використовувати «ternary operator»? Як це реалізувати щоб не потрапити в дурку?

Так, ви праві — версіонування модулів вирішує цю проблему.
Але мій приклад більше про збільшення «flexibility» модулю, щоб він міг приймати і створювати більшу «різноманітність» ресурсів.

P.S: і я ж не кажу, що немає інших альтернатив. Я кажу: «я роблю ось так для досягнення того-то».

1. «прошу уточнити де в офіційній документації згадано що використання count deprecated або це bad practice?» — якщо ви читали мою статтю трохи далі, то я якраз цитую офіційну документацію, де про це згадано. До речі, в посиланні, що ви скинули, теж є про це в останньому абзаці ))

2. З приводу «не зʼясувавши причин чому було щось зроблено так або інакше» — наведіть хоч один приклад/аргумент для використання «count» замість «for_each». Іншими словами: є хоч один кейс, коли ти не зможеш реалізувати щось з «for_each», але зможеш реалізувати з «count»? Які його «переваги» в порівнянні з «for_each» ?

3. Інкапсуляція є механізмом об’єднання данних, методів та атрибутів в об’єкти, з подальшою можливістю(не завжди) скриття цих методів чи об’єктів від зовнішнього світу. І основною причиною для інкапсуляції є: «Essentially, encapsulation prevents external code from being concerned with the internal workings of an object». Тобто, щоб на данні об’єкта не можна було ніяк впливати окрім як із середини самого об’єкту.
По-перше, Тераформ не є ООП мовою програмування, в нього немає классів, методів і т.д.... Якщо ви хочете заперечити, що для інкапсуляції не є обов’язковим ООП — так, це правда, але Терраформ НЕ є не тільки ООП мовою програмування, але й взагалі НЕ є мовою програмування. Тож, цікаво, яке значення інкапсуляції ви вкладаєте в «інкапсуляцію в Тераформ»? Є якесь визначення з офіційних джерел про «інкапсуляцію в Тераформ» ?
По-друге, навіть якщо ми припустимо, що існує якась «інкапсуляція в Тераформ», і вона полягає з ваших слів в «загорнути в середину модуля трохи логіки щоб розрулити вхідні дані різного типу», то яким чином мій підхід заважає вам приймати модулем об’єкти/мапи об’єктів, або значення «locals» різних типів і «розрулювати» їх як ви вважаєте за потрібне?
Моя концепція, насамперед, полягає у формуванні неймінгу чи значень пропертів в «root» модулях, і передачі цих фактичних значень в «child» (це як передавати аргументи в функцію чи в створення об’єкту класу, якщо ви любите аналогії з програмуванням). А що ви вже далі будете з тими значеннями робити — ваша справа. Ви можете одночасно приймати об’єкти з 10 параметрами всередині, і об’єкти з 5 параметрами, але при цьому і ті, і ті будуть «прийняті» вашим «child» модулем, якщо ви опишете, що вони їх можуть приймати (default «" значення ще ніхто не відміняв). Чули щось про «duck typing» та «interfaces» в програмуванні ? Я намагаюсь досягнути саме такого ефекту!
Це робить ваші модулі більш «flexible» в плані різноманітності ресурсів, які вони зможуть створювати.

Так, я якраз про проблеми його використання і говорив!)

Наявність класів не є обов’язковою вимогою для того щоб використовувати ООП.
В GO більше ООП чим в більшості мов програмування з класами

А чому «опустили»? По-перше, «війти в айті» девопсам точно легше через меншу конкуренцію (і плювати на поріг входу). Я думаю, автор коменту саме це мав на увазі. А по-друге..., чи багато девопсів можуть дійсно писати код з ООП, а не лише скріптіки на Python? Не думаю, що Yaml-девелоперство і Terraform-задротство це саме те, як Google уявляє і описує людину, що займається DevOps практиками, в своїй книзі «Site Reliability Engineering».
Девопс описаний в книжках, і девопс, що закриває потреби бізнесу в реальному світі — то різні люди!)