Microsoft AZ-400: 코드형 인프라 및 구성 관리 — 학습 가이드

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft DevOps Engineer Expert AZ-400 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Azure의 코드형 인프라(IaC) 및 구성 관리를 사용하면 인프라 및 애플리케이션 설정을 반복적이고 안전하게 정의, 프로비저닝, 적용할 수 있습니다. Azure는 기본적으로 ARM JSON과 Bicep을 지원하며, Terraform 및 Ansible과도 잘 통합됩니다. 구성 상태는 PowerShell Desired State Configuration(DSC), Azure Automation DSC, Chef, Puppet으로 선언할 수 있습니다. 애플리케이션 기능 배포 및 키 관리는 Azure App Configuration과 Key Vault로 중앙 집중화됩니다. Packer로 빌드된 불변 이미지는 드리프트(drift)를 줄여줍니다. 거버넌스는 Azure Policy와 Kubernetes용 OPA/Gatekeeper를 통해 코드형 정책(policy-as-code)으로 적용됩니다.

Azure 네이티브 IaC: ARM 템플릿과 Bicep

ARM 템플릿은 Azure Resource Manager가 리소스를 생성하고 업데이트하는 데 사용하는 선언적 JSON 문서입니다. 최상위 구조에는 $schema, contentVersion, parameters, variables, resources, outputs가 포함됩니다. parameters는 환경별 입력을 허용하고, variables는 계산된 값을 도출하는 데 도움을 주며, resources는 원하는 상태를 선언하고, outputs는 리소스 ID와 같은 결과를 게시합니다. 템플릿은 템플릿 표현식과 런타임 함수(예: resourceId, reference, concat, uniqueString)를 지원하므로 이름을 구성하고 속성을 검색할 수 있습니다.

대규모 배포를 유지 관리 가능한 단위로 나누기 위해 중첩(nested) 또는 연결된(linked) 템플릿을 사용할 수 있습니다. 중첩 템플릿은 Microsoft.Resources/deployments 리소스의 template 속성에 JSON을 인라인으로 포함합니다. 연결된 템플릿은 templateLink.uri를 통해 원격 템플릿을 참조하며, 무결성을 위해 일반적으로 시간 범위가 지정된 SAS와 함께 Azure Storage에 저장됩니다. 모든 것을 단일 아티팩트에 담을 수 있고 여러 부분에 걸쳐 트랜잭션 배포를 원할 때 중첩 템플릿을 사용합니다. 매우 큰 토폴로지나 여러 리포지토리 또는 팀에서 템플릿을 재사용할 때는 연결된 템플릿을 사용합니다. deployments 리소스에서 배포 범위를 설정하여 필요에 따라 리소스 그룹, 구독, 관리 그룹 또는 테넌트로 배포 범위를 지정합니다.

ARM은 두 가지 배포 모드를 지원합니다. 증분(Incremental, 기본값) 모드는 템플릿에 선언되지 않은 것은 삭제하지 않고 템플릿에 있는 리소스를 생성하거나 업데이트합니다. 완료(Complete) 모드는 템플릿에 지정되지 않은 대상 범위의 리소스를 삭제하므로, 최소한의 드리프트를 보장하는 데 유용하지만 해당 범위에 대해 템플릿이 권한을 갖지 않는 경우 더 위험할 수 있습니다. 유효성 검사(Validate) 및 가상(What-If) 작업은 실행 전 변경 사항을 미리 보고 위험을 줄이는 데 도움이 됩니다.

Bicep은 ARM JSON으로 컴파일되는 도메인 특화 언어(DSL)로, 최고 수준의 작성 편의성을 제공합니다. 리소스 선언은 심볼릭 이름을 사용하고, 타입을 강제하며, existing 키워드를 지원하여 재배포 없이 기존 리소스를 참조할 수 있습니다. parameters, variables, outputs 및 리소스 선언은 간결하며, 부모-자식 관계와 범위가 명시적입니다. 모듈은 구성과 재사용을 가능하게 합니다. 각 모듈은 module 키워드로 참조되는 Bicep 파일이며, template spec 또는 OCI 아티팩트 레지스트리에 게시하고 사용할 수 있습니다. 조건은 리소스나 모듈에 if를 사용하여 인라인으로 표현되며, 루프는 for 표현식을 사용하여 명확한 종속성 처리와 함께 여러 인스턴스를 선언합니다. ARM JSON에서의 마이그레이션은 간단합니다. az bicep decompile(또는 bicep decompile)은 JSON을 Bicep으로 변환합니다. 그런 다음 모듈로 리팩토링하고 심볼릭 이름을 채택합니다. Bicep은 ARM과 무손실 변환이 가능하며 전체 플랫폼 기능을 지원합니다. bicep build는 배포를 위해 표준 ARM JSON을 생성합니다.

Terraform을 사용한 Azure의 크로스 플랫폼 IaC

Terraform은 멀티 클라우드 또는 공급자 독립적인 워크플로가 필요할 때 Azure 네이티브 IaC를 보완합니다. azurerm 공급자는 Azure Resource Manager 리소스를 관리하며 버전이 고정되어야 합니다. 공급자 기능을 활성화하려면 비어 있더라도 features {}를 포함해야 합니다. 다른 일반적인 공급자로는 AAD 객체를 위한 azuread와 유틸리티 값을 위한 random이 있습니다. 서비스 주체, 호스팅된 에이전트의 관리 ID(Managed Identity) 또는 Azure CLI를 통해 인증합니다. 각 환경에 대해 명확한 공급자 구성 전략을 채택하고, 입력 변수와 출력이 있는 재사용 가능한 모듈을 중앙 집중화합니다.

상태(state) 관리는 매우 중요합니다. azurerm 백엔드를 사용하여 원격 상태를 Azure Storage에 저장하세요. resource_group_name, storage_account_name, container_name, key를 구성하고, 관리 ID 또는 SAS로 인증하며, Blob 컨테이너에서 일시 삭제(soft delete) 및 버전 관리를 활성화하세요. 백엔드는 Blob 임대(lease)를 사용하여 상태를 잠그고 동시 수정을 방지합니다. 스토리지 계정에 대한 액세스는 RBAC로 제어하고, 선택적으로 Private Endpoint로 제한해야 합니다. 상태 파일은 환경별로 격리하고, 설계상 절대 상태 파일에 비밀 정보를 저장하지 마세요. 필요 시 Key Vault와 데이터 소스를 사용하여 비밀 정보를 검색하세요.

작업 공간(Workspace)은 dev, test, prod와 같은 환경 분기를 위해 동일한 구성 내에서 상태를 논리적으로 격리합니다. terraform workspace select를 사용하고, 충돌을 피하기 위해 백엔드 키가 작업 공간을 인코딩하도록 하세요(예: myapp-${terraform.workspace}.tfstate). 작업 공간은 작은 차이가 있는 환경 간의 동등성을 유지하는 데 탁월합니다. 토폴로지가 크게 달라지는 경우, 드리프트와 조건부 복잡성을 피하기 위해 별도의 구성이나 모듈을 사용하세요. 서비스 연결(service connection)과 Terraform CLI 작업을 사용하여 Azure Pipelines와 통합하여 여러 단계에 걸쳐 init/plan/apply를 표준화하고, 승인 및 정책 검사를 통해 apply를 제어하세요.

대규모 구성 관리: DSC, Azure Automation DSC, Ansible, Chef, Puppet

PowerShell DSC(Desired State Configuration)는 리소스를 통해 Windows 및 크로스 플랫폼의 상태를 선언합니다. 두 가지 전달 모드가 있습니다. 푸시(push) 모드는 MOF를 노드에 직접 보내고, 풀(pull) 모드는 노드가 정해진 일정에 따라 풀(pull) 서비스에서 MOF를 가져옵니다. 로컬 구성 관리자(Local Configuration Manager, LCM)가 정책을 적용합니다. 주요 LCM 설정은 다음과 같습니다.

ConfigurationMode: ApplyOnly(한 번만 구성, 드리프트 수정 없음), ApplyAndMonitor(드리프트 감지, 수정 없음), ApplyAndAutoCorrect(드리프트 감지 및 수정).
ConfigurationModeFrequencyMins 및 RefreshFrequencyMins는 적용 및 풀(pull) 주기를 조정합니다.
RebootNodeIfNeeded 및 ActionAfterReboot는 재시작을 처리합니다.
부분 구성을 사용하면 여러 MOF에서 노드 상태를 구성할 수 있으며, 각 MOF는 독립적으로 기능(예: 기본 OS 강화 및 앱 역할)을 대상으로 합니다.

Azure Automation State Configuration(Azure Automation DSC)은 관리형 풀(pull) 서비스입니다. PowerShell에서 구성을 작성하고 Automation 계정으로 가져온 다음, 노드 구성(MOF)을 생성하는 컴파일 작업을 시작합니다. 노드는 등록 키/엔드포인트를 사용하여 Register-AzAutomationDscNode로 등록하며, 그룹화하고 노드별 매개변수 값과 함께 구성을 할당할 수 있습니다. 규정 준수 보고는 마지막으로 적용된 구성과 드리프트 상태를 보여주며, ApplyAndAutoCorrect 모드의 노드는 다음 체크인 시 자동으로 수정됩니다. 컴파일 작업은 감사 가능한 빌드 아티팩트이며, 역할 기반 액세스 제어는 구성 작성 및 노드 할당을 제한합니다.

Ansible은 에이전트리스(agentless) 방식이며 Linux 집합의 구성 및 애드혹(ad-hoc) 오케스트레이션에 적합합니다. Azure에서는 컴퓨팅, 네트워킹, Key Vault 등을 위한 모듈을 제공하는 azure.azcollection을 사용합니다. azure_rm 플러그인을 사용한 동적 인벤토리는 구독 또는 특정 리소스 그룹 및 태그에서 호스트를 검색합니다. 자격 증명 획득은 서비스 주체, Azure CLI 또는 관리 ID를 사용할 수 있습니다. Linux 에이전트에 Ansible을 설치하고, AzureCLI@2 또는 Azure Resource Manager 서비스 연결을 통해 로그인한 후, 동적 인벤토리, 변수 그룹, 보안 파일을 참조하는 플레이북을 실행하여 Azure Pipelines와 통합합니다. Ansible은 멱등성(idempotent)을 가지며 가독성 높은 작업에 뛰어나며, 크로스 플랫폼 워크플로와 오케스트레이션을 처리하여 Windows 중심의 환경에서 DSC를 보완할 수 있습니다.

Chef와 Puppet은 성숙한 코드형 정책(policy-as-code) 모델과 규정 준수 보고 기능을 제공합니다. Azure VM에서는 Chef 및 Puppet VM 확장을 사용하여 프로비저닝 시 에이전트를 부트스트랩하여 조기 수렴(convergence)을 보장합니다. Chef Infra는 쿡북(cookbook)과 Policyfile을 사용하여 종속성을 고정하고 재현 가능한 실행을 보장합니다. Chef InSpec은 코드형 규정 준수(compliance-as-code)를 표현하고 드리프트 및 제어 상태에 대한 보고서를 Chef Automate로 전송합니다. Puppet의 매니페스트(manifest)와 모듈은 원하는 상태를 코드로 정의하며, Code Manager와 환경은 프로모션 흐름을 제공합니다. Puppet Enterprise는 중앙 집중식 보고, 역할 기반 분류 및 수정(remediation) 기능을 제공합니다. 두 도구 모두 모듈 및 리소스 공급자를 통해 Azure와 통합되며, 마이그레이션이나 혼합 환경이 필요한 경우 Azure 네이티브 DSC와 공존할 수 있습니다.

애플리케이션 구성, 불변 이미지, 그리고 코드로써의 정책(Policy as Code)

Azure App Configuration은 애플리케이션 설정과 기능 플래그를 중앙에서 관리합니다. 기능 플래그는 점진적 배포(progressive rollout)를 가능하게 합니다. 플래그를 정의하고 필요한 경우 Feature Manager 라이브러리를 통해 백분율 기반 배포 또는 사용자 타겟팅과 같은 필터를 연결할 수 있습니다. 레이블을 사용하면 환경이나 링(ring)별로 값을 분리할 수 있습니다. 구성 스냅샷은 특정 키와 레이블 세트에 대해 특정 시점의 불변 뷰를 캡처하여, 동시 키 변경으로 인한 경쟁 조건(race condition) 없이 여러 서비스에 걸쳐 일관되고 재현 가능한 배포를 가능하게 합니다. Key Vault 참조를 사용하면 시크릿은 Key Vault에 보관하면서 App Configuration에는 참조만 저장할 수 있습니다. 애플리케이션의 관리형 ID는 해당 시크릿에 대한 get 권한이 있어야 하며, 클라이언트 라이브러리는 선택적 동적 새로고침 기능과 함께 시크릿을 확인하고 캐시합니다. 두 서비스 모두에서 RBAC와 네트워크 격리를 사용하여 접근을 보호하십시오.

불변 인프라(Immutable infrastructure)는 호스트를 변경하는 대신 알려진 이미지로부터 재구축함으로써 구성 드리프트(configuration drift)를 제거합니다. Packer의 azure-arm (현재 azure) 빌더는 기본 OS에서 이미지를 생성하고, 프로비저너(shell, PowerShell, Ansible)를 실행하며, 복제된 지역과 시맨틱 버저닝을 지원하는 Shared Image Gallery에 게시합니다. 골든 이미지 파이프라인은 일반적으로 Packer 템플릿을 린트 검사하고, 이미지를 빌드하며, 취약점 및 규정 준수 스캔(예: InSpec)을 실행하고, 통합 테스트를 거쳐 갤러리로 승격시킨 후, VM Scale Sets 또는 호스트 풀을 업데이트합니다. VM Scale Sets의 롤링 또는 상태 기반 업그레이드, 자동 OS 이미지 업그레이드를 사용하면 이전 이미지 버전을 선택하여 안전하고 일관된 배포와 쉬운 롤백을 할 수 있습니다.

코드로써의 정책(Policy as code)은 가드레일을 강제합니다. Azure Policy 정의는 리소스 속성을 평가하고 자동으로 수정(auto-remediate)하기 위해 deny, audit, append, modify, 또는 deployIfNotExists와 같은 효과(effect)를 적용하는 policyRule을 포함하는 JSON 객체입니다. 재사용을 위해 정의를 매개변수화하고, 이니셔티브(정책 세트 정의)로 그룹화하여 일관된 할당과 중앙 집중식 규정 준수 추적을 수행합니다. 관리 그룹, 구독 또는 리소스 그룹 범위에서 정책을 할당하고, modify 및 deployIfNotExists 정책에 대한 수정 작업을 활성화하여 기존 리소스를 규정 준수 상태로 만듭니다. 정책 아티팩트를 소스 컨트롤에 저장하고, 풀 리퀘스트를 통해 검토하며, Bicep, ARM 또는 Terraform을 통해 배포하여 환경 간에 일관되게 승격시킵니다.

Kubernetes의 경우, OPA/Gatekeeper는 어드미션(admission) 시점의 제약 조건을 강제합니다. ConstraintTemplate은 Rego 정책과 그 스키마를 정의하고, Constraint는 해당 정책을 클러스터에 대해 인스턴스화합니다. 일반적인 제어에는 신뢰할 수 있는 레지스트리로 이미지를 제한하거나, 레이블/어노테이션을 요구하거나, 권한 있는(privileged) 파드를 방지하는 것이 포함됩니다. Gatekeeper는 GitOps 도구(Flux/Argo CD)와 통합되고 conftest를 통해 CI 테스트를 수행합니다. Azure Policy for Kubernetes는 Gatekeeper를 기반으로 구축되어 AKS 클러스터 전반에 걸쳐 Azure 네이티브 할당 및 규정 준수 뷰를 제공하며, 클라우드와 클러스터 거버넌스를 하나의 상태 대시보드 아래로 통합합니다.

실제 문제 시나리오

Spotify는 Azure 인프라를 표준화하고, 구성 드리프트를 줄이며, Windows와 Linux, AKS, VM 기반 워크로드에 걸쳐 있는 마이크로서비스 전반에 걸쳐 안전한 기능 배포를 가속화해야 합니다.

도메인(네트워킹, 데이터, 컴퓨팅)별로 Bicep 모듈을 사용하여 클라우드 리소스를 모델링하고 관리 그룹 범위의 구독을 통해 배포합니다. 이를 통해 ARM JSON의 장황함 없이 타입이 지정되고 유지보수 가능한 선언, 명확한 범위 지정, 재사용이 가능해집니다.
여러 팀이 소비하는 공유 플랫폼 서비스를 위해 소수의 연결된 ARM 템플릿 사양을 사용합니다. 템플릿 사양으로 호스팅되는 연결된 템플릿은 버전이 지정된 불변 아티팩트를 제공하고 플랫폼의 변경 주기(cadence)를 앱 팀과 분리합니다.
크로스 클라우드 엣지 및 CDN 종속성에는 Terraform을 선택하고, azurerm 백엔드를 사용하여 원격 상태(remote state)를 작업 공간(dev/test/prod)별로 Azure Storage에 저장하며, 잠금(locking)을 위해 Blob 임대를 사용합니다. 이를 통해 상태를 안전하게 격리하고 일관된 승격을 가능하게 하면서 단일 파이프라인 패턴을 유지합니다.
Azure App Configuration에서 애플리케이션 구성과 기능 플래그를 중앙 집중화합니다. 백분율 필터와 레이블이 있는 기능 플래그는 링 기반 배포를 가능하게 합니다. 구성 스냅샷은 각 배포 단계가 불변하고 감사 가능한 키 세트를 사용하도록 보장합니다.
Azure Key Vault에 시크릿을 저장하고 App Configuration에서 참조합니다. 런타임에 관리형 ID로 참조를 확인하면 재배포 없이 키 순환이 가능해지고 애플리케이션 구성 및 파이프라인에서 시크릿을 제거합니다.
VM 워크로드에 불변 이미지를 채택하고, Packer를 사용하여 골든 이미지를 빌드하여 Shared Image Gallery에 게시합니다. 파이프라인은 강화(hardening) 스크립트와 InSpec 스캔을 실행하고, 이미지에 태그를 지정하며, 통과한 버전만 승격시킵니다. VM Scale Sets는 갤러리 이미지를 사용하여 블루/그린 및 롤링 업그레이드를 수행하여 드리프트를 제거합니다.
프라이빗 서브넷에서 공용 IP 노출을 거부하고, Log Analytics로 진단 설정을 요구하며, 백업 정책을 자동 배포하는 Azure Policy 이니셔티브로 가드레일을 강제합니다. 광범위한 적용을 위해 관리 그룹 수준에서 할당하고 기존 리소스에 대한 수정 작업을 생성하여 상태(posture)를 신속하게 수렴시킵니다.
규정을 준수하지 않는 이미지와 권한 있는 파드를 차단하는 제약 조건을 적용하여 OPA/Gatekeeper로 AKS를 보호합니다. 정책은 Git에 저장 및 버전 관리되고, CI에서 conftest로 검증되며, GitOps를 통해 적용되어 클러스터 상태가 항상 정책과 일치하도록 보장합니다.
Azure Automation DSC로 Windows 서버 구성을 관리합니다. 노드는

undefined

로 등록하고

undefined

를 사용하여 드리프트를 감지하고 수정합니다. 컴파일 작업은 역할별로 MOF를 생성하고, 규정 준수 대시보드는 조사를 위해 드리프트를 표시합니다. 10.

undefined

동적 인벤토리와

undefined

모듈을 사용하여 Ansible로 Linux 구성 및 오케스트레이션을 관리합니다. Azure Pipelines는 관리형 ID로 인증하고, 플레이북을 멱등성(idempotently) 있게 실행하며, 서비스 전반의 업데이트를 조정하여 Windows의 DSC를 보완합니다. 11. 이미지와 실행 중인 호스트 모두에서 크로스 플랫폼 코드로써의 규정 준수(compliance-as-code)를 위해 Chef InSpec 프로필을 활용하고, 보고를 위해 Chef Automate에 데이터를 제공합니다. 이를 통해 감사 가능하고 테스트 가능한 제어를 파이프라인과 프로덕션에 도입하여 규제 요구 사항이 지속적으로 검증되도록 보장합니다.

이 조합은 타입이 지정된 모듈식 IaC(Bicep/Terraform), 불변 호스트(Packer), 중앙 집중식 앱 구성(App Configuration/Key Vault), 지속적인 구성 강제(Azure Automation DSC, Ansible), 강력한 거버넌스(Azure Policy, Gatekeeper)를 제공합니다. 이는 드리프트를 줄이고, 복구 및 배포 시간을 단축하며, 규정 준수를 입증 가능하게 만듭니다.

← Azure Pipelines를 사용한 CI · 모든 도메인 · 컨테이너화 및 Kubernetes →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →