AZ-305 거버넌스·규정 준수 설계는 단순 암기가 아닌 "어떤 상황에서 어떤 도구를 선택해야 하는가"를 판단하는 능력을 요구합니다. Management Group 계층 설계, Azure Policy 효과 선택, 비용 거버넌스, 태그 전략, IaC까지 다양한 개념이 서로 맞물려 출제됩니다. 이 포스트는 실제 시험 문제 37개를 분석하여 자주 출제되는 핵심 패턴과 선택 기준을 정리합니다.
---
Management Group과 구독 계층 설계
Management Group은 Azure 환경을 거버넌스 관점에서 묶는 컨테이너입니다. 계층 구조는 다음과 같습니다.
상위 계층에서 할당된 정책과 역할은 하위 계층 전체에 자동으로 상속됩니다. Production Management Group에 "Korea Central 지역만 허용" 정책을 설정하면 그 아래 3개 구독 모두에 정책이 적용됩니다. 형제(sibling) 관계의 Development Management Group에는 적용되지 않습니다.
시험에서 관리 그룹 계층 문제가 나오면 가장 먼저 확인해야 할 것은 "대상 구독이 정책 할당 노드의 하위인가?"입니다. 같은 테넌트 내에 있더라도 Management Group 계층이 다르면 정책이 전혀 적용되지 않습니다.
리소스 셀렉터는 범위를 확장하는 기능이 아니라 이미 정책 범위 안의 리소스 중 어떤 것을 평가할지 필터링하는 도구입니다. Azure Policy 할당 범위는 Management Group, Subscription, Resource Group 세 가지뿐이며, 개별 리소스 단위나 Entra ID 테넌트 단위로는 할당할 수 없습니다.
---
Azure Policy와 이니셔티브
Azure Policy는 "규칙을 자동으로 집행하는 시스템"입니다. RBAC가 "누가 무엇을 할 수 있는가"를 통제한다면, Policy는 "어디서, 어떻게, 어떤 조건으로 배포할 수 있는가"를 통제합니다.
Policy Effect 5가지
| Effect | 동작 방식 | 주요 사용 케이스 | |--------|----------|----------------| | Deny | ARM 레벨에서 배포 요청 즉시 거부 | 허용되지 않은 리전, 리소스 유형 차단 | | Audit | 비준수 사실을 기록만 함 (차단 없음) | 정책 도입 초기 영향 범위 파악 | | Append | 기존 값에 새 값 추가 (덮어쓰기 불가) | 태그 단순 추가 (기존 값 보존 필요 시) | | Modify | 기존 속성·태그 추가 및 수정 + remediation 지원 | 태그 자동 수정, 리소스 그룹 태그 상속 | | DeployIfNotExists | 누락 설정이 있을 때 관련 리소스 자동 배포 | TDE 자동 활성화, 에이전트 자동 설치 |
Modify와 Append를 혼동하기 쉽습니다. "기존 리소스 태그를 수정하고 기존 리소스에도 소급 적용"이라는 조건이 나오면 반드시 Modify를 선택합니다. Append는 기존 값을 덮어쓰지 못하고 remediation도 지원하지 않습니다.
DeployIfNotExists 정책에는 를 반드시 지정해야 합니다. Managed Identity가 대상 리소스를 수정할 수 있도록 RBAC 역할을 부여하기 위해서입니다. remediation을 수행하는 주체는 정책 할당에 연결된 System-assigned Managed Identity이며, 사람 계정이 직접 실행하지 않습니다. 태그 수정처럼 최소 권한만 필요한 작업이라면 Tag Contributor 역할만 부여하면 됩니다.
이니셔티브는 여러 Policy를 하나의 묶음으로 관리합니다. "지역 제한 정책 + VM 크기 제한 정책"을 이니셔티브로 묶으면 구독에 이니셔티브 하나만 할당해도 두 정책이 동시에 적용됩니다.
Policy는 기본 24시간마다 자동 평가를 실행합니다. 즉시 평가가 필요할 때는 REST API의 또는 명령을 사용합니다. 비준수 이벤트 기반 즉시 알림이 필요하다면 Azure Event Grid와 Logic Apps를 조합합니다.
!Azure Policy 효과 5가지
비용 거버넌스와 Cost Management
20개 이상의 구독에서 프로젝트별 비용을 추적해야 한다면, 구독 구조를 바꾸지 않고 모든 리소스에 , , 태그를 붙이고 Microsoft Cost Management에서 태그 값을 기준으로 비용을 필터링합니다.
Cost Management의 예산(Budget) 기능은 실제 비용 또는 예측 비용이 임계값에 도달했을 때 이메일이나 Action Group으로 자동 알림을 발송합니다. 최대 5개의 임계값을 설정할 수 있습니다. Azure Advisor는 비용 절감 권고를 제공하지만 예산 초과 알림 기능은 없습니다.
24시간 365일 상시 운영 워크로드라면 예약 인스턴스(Reserved Instances)를 고려합니다. 1년 또는 3년 선약정으로 VM, SQL Database, App Service 등에서 종량제 대비 최대 72%까지 비용을 절감하며 가용성과 SLA에는 영향이 없습니다. Spot VM은 최대 90% 절감이 가능하지만 Azure가 언제든 중단시킬 수 있어 프로덕션 상시 운영에는 사용하면 안 됩니다.
---
태그 전략과 리소스 잠금
태그는 리소스에 메모 스티커를 붙이는 것과 같습니다. , 처럼 키-값 쌍으로 정보를 부착합니다. 중요한 특성이 있습니다. 태그는 상위에서 하위 계층으로 자동 상속되지 않습니다. 리소스 그룹에 태그를 붙여도 그 안의 리소스에는 자동으로 붙지 않습니다.
모든 리소스에 필수 태그를 강제하려면 Policy의 Deny 효과(신규 배포 차단)와 Modify 효과(기존 리소스 소급 수정)를 함께 사용합니다. 리소스 그룹 태그를 자식 리소스에 자동 상속시키는 내장 정책("Inherit a tag from the resource group")도 Modify effect를 사용합니다.
리소스 잠금(Resource Lock)은 프로덕션 리소스를 실수로 삭제하거나 변경하지 않도록 보호합니다.
Delete 잠금: 삭제만 차단하며 설정 변경은 가능합니다. ReadOnly 잠금: 모든 쓰기 작업을 차단합니다. 수정도 삭제도 불가능합니다.
리소스 잠금은 RBAC와 독립적입니다. Owner 권한이 있어도 잠금이 걸린 리소스는 삭제하거나 수정할 수 없습니다. Contributor 권한이 있어도 특정 리소스 생성(예: 공용 IP 할당)을 차단하려면 Azure Policy Deny를 사용합니다.
---
서비스 비교표
Policy Effect 선택 기준
| 시나리오 | 선택 Effect | 이유 | |---------|------------|------| | 허용되지 않은 리전에 배포 차단 | Deny | ARM 레벨 사전 차단 (preventive) | | 비준수 리소스 현황 파악 (차단 없이) | Audit | 감지만, 차단 안 함 | | 리소스 그룹 태그를 자식 리소스에 상속 | Modify | 기존 속성 수정 + remediation | | 기존 리소스에 누락 태그 소급 적용 | Modify | remediation task 지원 | | VM 생성 시 진단 에이전트 자동 설치 | DeployIfNotExists | 누락 리소스/설정 자동 배포 | | SQL DB에 TDE 자동 활성화 | DeployIfNotExists | 누락 설정 자동 배포 + remediation | | 태그 없는 리소스 배포 자체 차단 | Deny | 사전 방지 (preventive control) |
거버넌스 도구 비교
| 도구 | 핵심 역할 | 한계 | |-----|---------|------| | Azure Policy | 규정 준수 평가·강제 (조건 제어) | 역할 할당, ARM 템플릿 배포 불가 | | Azure RBAC | 사용자/그룹의 작업 권한 제어 | 배포 조건(리전·SKU) 제한 불가 | | Azure Blueprints | Policy + 역할 + ARM + RG 패키지 | 테넌트 간 공유 불가 | | Resource Lock | 삭제·수정 차단 (Owner도 포함) | 비준수 탐지, 자동 수정 불가 | | Cost Management | 비용 추적·예산·알림 | 리소스 배포 제어 불가 |
---
시험에서 자주 헷갈리는 선택 기준
시나리오 1: 리소스 그룹 위치 정책을 적용했는데도 다른 리전에 리소스가 배포됨
리소스 그룹 위치 정책은 리소스 그룹이 생성되는 리전만 제어합니다. App Service나 SQL Database는 리소스 그룹과 다른 리전에 배포될 수 있습니다. 구독 수준에서 리소스 위치를 대상으로 하는 별도의 Deny 정책을 추가해야 합니다. 내장 정책 "Allowed locations"는 리소스 그룹과 리소스 위치를 동시에 제어합니다.
시나리오 2: Blueprints definition과 assignment 개수 계산
테넌트 N개 + definition 최솟값 → N개 (Blueprints는 테넌트 경계를 넘지 못함) 구독 M개 + assignment 최솟값 → M개 (assignment는 구독 단위 1:1 적용)
단일 테넌트 내 여러 구독이라면 definition 1개로 여러 구독에 assignment를 만들 수 있습니다. 테넌트가 다르면 반드시 테넌트별로 definition을 별도로 생성해야 합니다.
시나리오 3: 사전 차단 vs 사후 탐지
"배포 자체를 막아야 한다"는 조건이 나오면 Azure Policy Deny를 선택합니다. Microsoft Defender for Cloud의 규정 준수 대시보드는 배포 후에 위반 사항을 확인하는 사후 탐지(reactive) 도구입니다. 배포 전에 막으려면(preventive) Azure Policy Deny가 유일한 선택입니다.
시나리오 4: 여러 고객 테넌트 중앙 관리
MSP가 여러 고객 테넌트의 리소스를 자체 테넌트에서 단일 콘솔로 관리해야 할 때는 Azure Lighthouse를 사용합니다. 에이전트 설치 없이 Azure Resource Manager 위임으로 크로스 테넌트 접근이 가능합니다. Azure Arc는 온프레미스·멀티클라우드 리소스를 Azure로 온보딩하는 도구로 목적이 다릅니다.
---
실무 적용 팁
Management Group은 조직 구조보다 정책 적용 패턴을 기준으로 설계합니다. "같은 규칙을 공유하는 구독들"을 같은 Management Group에 묶습니다. 루트 Management Group에는 조직 전체에 반드시 적용해야 하는 최소한의 보안 기준만 배치합니다.
새로운 정책을 도입할 때는 Audit 모드로 시작하여 영향 범위를 파악한 후 Deny로 전환하는 것이 안전합니다.
ARM 템플릿 또는 Bicep을 Azure DevOps 파이프라인과 연동하면 Git에 모든 변경 이력이 기록되고 동일 템플릿을 반복 실행해도 항상 동일한 상태(멱등성)가 보장됩니다. Azure Blueprints는 현재 deprecated 상태이므로 신규 프로젝트에는 사용하지 않는 것이 좋습니다.
예약 인스턴스는 VM뿐만 아니라 Azure SQL Database, App Service, Cosmos DB 등 다양한 서비스에서 지원됩니다. 인스턴스 유연성 옵션을 활성화하면 동일 VM 계열 내에서 크기를 변경해도 예약 할인이 자동으로 적용됩니다.
---
정리