AZ-400 시험에서 IaC 파트는 '어떤 도구를 언제 쓰는가'를 묻습니다. ARM Template과 Bicep이 왜 같으면서도 다른지, Terraform이 멀티클라우드 환경에서 왜 선호되는지, DSC와 Cloud-Init은 어디서 등장하는지를 시나리오 형태로 이해하는 것이 핵심입니다. 도구 이름을 외우기보다 '무엇을 선언하는가'를 기준으로 분류하면 훨씬 정리가 됩니다.
IaC가 필요한 이유: 클릭은 기억을 남기지 않는다
이케아 가구를 설명서 없이 조립했다고 상상해보세요. 완성은 했지만, 6개월 뒤 똑같은 가구를 두 개 더 만들어야 할 때 어디서 시작해야 할지 막막합니다. Azure 포털 클릭으로 리소스를 만드는 것도 같습니다. 누가, 언제, 어떤 설정으로 만들었는지 추적이 안 되고, 동일 환경을 스테이징·프로덕션에 복제하려면 처음부터 반복해야 합니다.
IaC는 인프라의 '원하는 상태(desired state)'를 코드로 선언합니다. Git에 저장하면 변경 이력이 생기고 CI/CD 파이프라인이 배포를 자동화합니다. 접근 방식은 두 가지입니다.
: 최종 상태를 기술하면 도구가 현재 상태와 비교해 알아서 실행. ARM Template, Bicep, Terraform이 이 방식입니다. : 실행 단계를 순서대로 기술. Azure CLI 스크립트, PowerShell이 이 방식입니다.
시험은 주로 선언형 도구를 다룹니다. 선언형은 를 보장하기 때문입니다.
ARM Templates: Azure 리소스의 건축 설계도
건물을 짓기 전에 건축가가 기둥 위치, 창문 크기, 층수를 상세히 기재한 설계도를 그립니다. ARM Template은 Azure 리소스의 그 설계도입니다. JSON 형식으로 작성하며 Azure Resource Manager가 읽어서 리소스를 생성하고 구성합니다.
ARM Template의 주요 섹션:
: 배포 시 입력받는 값 (환경 이름, VM 크기 등) : 반복 사용되는 중간 계산값 : 생성할 리소스 목록 (핵심 섹션) : 배포 후 반환값 (생성된 리소스 URL 등)
ARM Template의 한계는 JSON 특유의 장황함입니다. 주석을 달 수 없고, 반복 리소스를 표현하려면 루프를 써야 해서 가독성이 떨어집니다. 이 문제를 해결하기 위해 Bicep이 등장했습니다.
Bicep: ARM Template을 사람이 읽기 좋게
전문 셰프용 기술 문서(그램 단위 계량)와 일반인용 가정 레시피('한 줌', '적당량')의 차이를 떠올리세요. 만드는 요리는 동일합니다. ARM Template과 Bicep의 관계도 같습니다.
Bicep은 ARM Template 위에서 동작하는 DSL입니다. Bicep 파일을 작성하면 Azure CLI나 Azure Pipelines가 내부적으로 ARM Template JSON으로 변환해 배포합니다. 핵심 특성:
: 모든 Bicep 코드는 ARM Template으로 변환됩니다. 역방향도 가능(). 주석 지원(), 더 짧은 문법, 타입 안전성 키워드로 재사용 가능한 Bicep 파일 조합 가능
ARM Template 대비 절반 이하의 줄 수로 같은 리소스를 표현합니다. 팀이 Azure 전용이고 ARM 생태계와 긴밀히 통합해야 한다면 Bicep이 정답입니다.
Terraform: 멀티클라우드의 공통 언어
여러 나라를 여행할 때 영어 하나로 소통하는 것이 각국 언어를 따로 배우는 것보다 효율적입니다. Azure와 AWS, GCP를 동시에 쓰는 기업에서 Terraform이 그 역할을 합니다.
Terraform은 HashiCorp의 오픈소스 IaC 도구로 HCL(HashiCorp Configuration Language)로 작성합니다. 핵심 개념:
: 클라우드 벤더 플러그인 (azurerm, aws, google 등) : 관리 중인 리소스 현황 파일(). 선언 코드와 실제 인프라의 차이를 이 파일로 비교합니다. : 변경사항 미리보기. 적용 전 '5개 추가·1개 수정·0개 삭제' 형식으로 확인합니다. : 실제 변경 실행 : State 파일을 Azure Blob Storage 또는 Terraform Cloud에 저장. 팀 협업 시 필수입니다.
| 기준 | Bicep | Terraform | |------|-------|-----------| | 대상 클라우드 | Azure 전용 | 멀티클라우드 | | 언어 | DSL (ARM 기반) | HCL | | State 관리 | 불필요 (ARM이 처리) | 필수 () |
시험에서 '멀티클라우드', 'HCL', 'tfstate', 'HashiCorp' 키워드가 나오면 Terraform입니다.
!Bicep vs Terraform
DSC·Cloud-Init·Ansible: OS 안을 관리하는 도구들
IaC 도구가 'VM을 만드는' 설계도라면, 구성 관리 도구는 'VM 안에서 무엇을 설치하고 설정하는지'를 관리합니다. 이 구분이 시험에서 자주 혼동됩니다.
는 PowerShell 기반 구성 관리 도구입니다. VM 내부에 설치해야 할 소프트웨어, 활성화해야 할 Windows 서비스, 파일 시스템 설정을 선언합니다. Azure Automation State Configuration과 연동하면 대규모 VM 플릿의 구성 드리프트를 자동으로 복구합니다.
은 Linux VM이 처음 부팅될 때 실행되는 초기화 스크립트입니다. 패키지 설치·사용자 생성·파일 쓰기를 YAML로 정의합니다. Ansible, Chef, Puppet도 같은 범주입니다.
: 에이전트 없이 SSH로 접속해 구성(agentless) : 루비 기반 DSL, Cookbook/Recipe 용어 사용 : 선언형 DSL, Master-Agent 아키텍처
핵심 구분: ARM/Bicep/Terraform은 인프라 프로비저닝, DSC/Cloud-Init/Ansible은 OS·소프트웨어 구성 관리입니다.
IaC 보안 스캔: 배포 전에 잡는 취약점
완성된 건물에서 소방 점검을 받는 것보다 설계 단계에서 피난 동선을 검토하는 편이 훨씬 저렴합니다. IaC 보안 스캔도 같은 원리입니다. Terraform 코드나 ARM Template을 배포하기 전에 파이프라인 안에서 취약한 설정을 자동으로 탐지합니다.
주요 도구:
: Python 기반 정적 분석. Terraform, ARM, Bicep, Kubernetes 등 다양한 IaC 형식을 지원합니다. : Terraform 전용 정적 분석. Azure Security Center 권고 사항과 연계된 규칙셋을 제공합니다.
CI/CD 파이프라인에서 IaC 스캔을 이전에 배치하면 취약한 코드는 까지 도달하지 못합니다.
시험 핵심 정리
'Azure 전용 IaC, ARM 위 DSL' → Bicep '멀티클라우드, HCL, tfstate, HashiCorp' → Terraform 'ARM Template을 읽기 쉬운 문법으로 변환' → 'Terraform 변경사항 미리보기' → 'Terraform State 팀 공유 저장소' → Remote Backend (Azure Blob Storage) 'VM 내부 소프트웨어·서비스 선언형 관리' → Azure DSC 'Linux VM 최초 부팅 초기화 스크립트' → Cloud-Init '에이전트 없이 SSH 구성 관리' → Ansible '선언형 vs 명령형' → ARM/Bicep/Terraform=선언형, Azure CLI=명령형 'IaC 정적 분석, Terraform 취약점 스캔' → Checkov / tfsec 'ARM Template 배포 전 변경 미리보기' →
Bicep=Azure 네이티브 선언형, Terraform=멀티클라우드 선언형, DSC=OS 구성 관리.