🎯 AZ-104: Azure Administrator

정답 기술 해설

Azure AD의 디바이스 설정은 조직의 디바이스 ID 관리 정책을 정의하는 중앙 지점입니다. 요구사항을 충족하기 위해 두 가지 설정이 필요합니다.

• Users may join devices to Azure AD: Selected
  이 설정은 디바이스를 Azure AD에 조인할 수 있는 사용자를 제어합니다. 'All'로 두면 모든 사용자가 디바이스를 등록할 수 있어 관리되지 않는 디바이스가 늘어날 수 있습니다. 'Selected'로 설정하고 특정 보안 그룹(예: 'IT 관리자 그룹')을 지정하면, 최소 권한 원칙(Principle of Least Privilege)을 준수하여 허가된 관리자만이 디바이스를 등록하도록 제한할 수 있습니다.
• Require Multi-Factor Auth to join devices: Yes
  이 설정은 디바이스 조인 프로세스에 추가적인 보안 계층을 적용합니다. 'Yes'로 설정하면 사용자가 디바이스를 Azure AD에 조인할 때 암호 외에 MFA 인증을 반드시 거쳐야 합니다. 이는 자격 증명이 유출되었을 경우에도 비인가된 디바이스 등록을 방지하는 효과적인 ID 보호 수단입니다.

정답 기술 해설

정답은 **D**입니다. 문제에서 요구하는 작업(구독 이름 변경, 관리 그룹 재구성)은 구독 자체의 메타데이터와 관리 설정에 해당합니다. 이러한 작업은 Azure 역할 기반 액세스 제어(RBAC)로 관리되는 리소스 사용 권한과는 구별됩니다. Azure Portal에서 구독의 이름이나 관리 그룹 할당 변경은 해당 구독을 선택한 후 **속성(Properties)** 블레이드에서 수행됩니다. 청구 관련 작업 역시 구독 속성 및 청구 관리 영역에서 처리됩니다.

오답 분석

• A, B: Azure AD 그룹 및 속성 수정은 구독 관리와 직접적인 관련이 없습니다. Azure AD는 ID 및 액세스 관리를 위한 서비스이며, 구독은 리소스 프로비저닝 및 청구의 경계입니다.
• C: 액세스 제어(IAM)는 구독 내에서 리소스를 생성, 읽기, 수정, 삭제할 수 있는 역할(예: 소유자, 기여자, 읽기 권한자)을 사용자에게 할당하는 데 사용됩니다. 구독의 이름을 바꾸거나 관리 그룹을 변경하는 권한은 포함하지 않습니다.

정답 기술 해설

• Recovery Services Vaults - 3개: Azure Backup의 핵심 원칙 중 하나는 백업 데이터가 원본 데이터와 동일한 지리적 지역에 위치해야 한다는 것입니다. 이는 데이터 주권(Data Sovereignty) 규정을 준수하고, 백업 및 복원 작업 시 네트워크 대기 시간을 최소화하기 위함입니다. 시나리오에 3개의 지역(West US, East US, Central US)이 언급되었으므로, 각 지역마다 하나씩 총 **3개**의 자격 증명 모음(Vault)이 필요합니다.
• Backup Policies - 6개: 백업 정책은 백업 일정과 보존 기간을 정의하며, 보호하려는 워크로드 유형에 따라 다르게 생성됩니다. 각 자격 증명 모음 내에서 'Azure 가상 머신'과 'Azure 파일 공유'는 서로 다른 유형의 워크로드이므로 별도의 정책이 필요합니다. 따라서 3개의 각 자격 증명 모음마다 2개(VM용 1개, 파일 공유용 1개)의 정책이 필요하므로, 총 3 * 2 = **6개**의 정책이 필요합니다.

정답 기술 해설

Azure Monitor에서 메트릭 기반 경고를 구성하는 논리적인 순서는 '무엇을 할지(Action)' 정의, '언제 할지(Rule)' 정의, '데이터 수집(Data Source)' 확인의 흐름을 따릅니다.

1. 작업 그룹(Action Group) 만들기: 경고가 트리거될 때 수행될 작업을 정의하는 재사용 가능한 컬렉션입니다. 요구사항의 'SMS, 이메일, Teams로 다중 채널 알림'은 작업 그룹을 통해 구성됩니다. 알림 대상을 먼저 정의해야 경고 규칙에 연결할 수 있습니다.
2. 경고 규칙(Alert Rule) 만들기: 모니터링의 핵심 로직입니다. 대상 리소스(VM1, VM2), 신호(CPU, 메모리 등), 임계값(80%, 90% 등), 그리고 트리거 시 실행할 작업 그룹을 지정합니다.
3. VM 진단 설정(Diagnostic Settings) 구성: CPU 사용률은 기본 플랫폼 메트릭이지만, 메모리나 디스크 같은 게스트 OS 내부 메트릭은 Azure Monitor가 기본적으로 수집하지 못합니다. VM 진단 확장을 설치하고 진단 설정을 구성하여 이러한 게스트 OS 메트릭을 Azure Monitor 메트릭 저장소 또는 Log Analytics 작업 영역으로 보내야 경고 규칙에서 사용할 수 있습니다.

정답 기술 해설

Azure Policy 관련 작업을 수행하기 위한 핵심 기본 제공 역할은 **'Resource Policy Contributor'**입니다. 이 역할은 정책 및 이니셔티브 정의 생성/수정/삭제, 정책 할당 생성/삭제, 정책 예외 생성 등 정책 수명 주기 관리에 필요한 모든 권한을 포함합니다.

• User1 (이니셔티브 정의): 이니셔티브 '정의'를 생성하려면 `Microsoft.Authorization/policySetDefinitions/write` 권한이 필요하며, 이는 'Resource Policy Contributor' 역할에 포함됩니다.
• User4 (이니셔티브 할당): 이니셔티브를 리소스 그룹에 '할당'하려면 `Microsoft.Authorization/policyAssignments/write` 권한이 필요하며, 이 또한 'Resource Policy Contributor' 역할에 포함됩니다.

따라서 두 사용자 모두의 요구사항을 충족하는 최소 권한의 역할은 'Resource Policy Contributor'입니다.

정답 기술 해설

정답은 **A**입니다. 시나리오의 핵심 요구사항은 Azure Files에 대해 **Azure AD 기반 인증**과 **감사 로깅**을 구현하는 것입니다. Azure Storage 계정에서 파일 공유에 대한 'ID 기반 액세스'를 활성화하면 Azure AD Kerberos 또는 Azure AD DS 인증을 사용할 수 있습니다. 이 기능을 통해 사용자와 그룹에 Azure RBAC 역할을 할당하여 공유 수준 권한(예: Storage File Data SMB Share Reader)을 부여하고, Windows ACL(액세스 제어 목록)을 사용하여 디렉터리/파일 수준 권한을 제어할 수 있습니다. 모든 인증 및 권한 부여 작업은 Azure AD를 통해 이루어지므로, 접근 기록이 감사 로그에 남아 HIPAA 규정 준수 요구사항을 충족시킵니다.

오답 분석

• B: 계층적 네임스페이스는 Azure Data Lake Storage Gen2의 기능으로, 파일 공유가 아닌 Blob 스토리지에 적용됩니다.
• C: 계정 종류를 변경하는 것만으로는 ID 기반 액세스가 활성화되지 않습니다. 별도의 구성 단계가 필요합니다.
• D: SAS 토큰은 Azure AD ID와 통합되지 않으며, 사용자 수준의 감사가 아닌 토큰 기반의 임시 액세스를 제공하므로 요구사항을 충족하지 못합니다.

정답 기술 해설

정답은 **B**입니다. 이 시나리오의 핵심은 사용자 속성을 기반으로 한 **그룹 멤버십 자동화**와 이를 이용한 **정책 적용 자동화**입니다. Azure AD 동적 그룹(Dynamic Groups)은 관리자가 정의한 규칙(예: `user.department -eq "Finance"`)에 따라 사용자 멤버십을 자동으로 업데이트합니다. 신규 재무팀 직원은 자동으로 그룹에 추가되고, 퇴사자는 자동으로 제거됩니다. 이 동적 그룹을 조건부 액세스 정책(Conditional Access Policies)의 대상으로 지정하면, 재무 그룹 멤버들에게만 특정 보안 요구사항(예: MFA 강제, 특정 위치에서만 액세스 허용)을 자동으로 적용할 수 있어 관리 오버헤드를 크게 줄일 수 있습니다. 이 조합은 Azure AD P1/P2 라이선스가 필요한 강력한 자동화 기능입니다.

오답 분석

• A: Azure AD B2C는 외부 고객용 ID 관리 솔루션입니다.
• C: Azure AD Identity Protection은 로그인 위험을 탐지하는 보안 기능으로, 부서 기반 자동화와는 목적이 다릅니다.
• D: Logic App/MIM은 과도하게 복잡한 해결책입니다. Azure AD 기본 기능으로 충분히 해결 가능합니다.

정답 기술 해설

Azure에서 사용자 지정 RBAC 역할을 생성하는 모범 사례는 완전히 새로 만드는 것보다 기존 기본 제공 역할을 템플릿으로 사용하는 것입니다. 요구사항이 "모든 리소스를 읽을 수 있는" 권한을 기반으로 하므로, 기본 **Reader** 역할이 가장 적합한 시작점입니다. PowerShell을 사용하여 사용자 지정 역할을 만들려면 먼저 템플릿 역할의 정의를 수정 가능한 JSON 형식으로 내보내야 합니다. `Get-AzRoleDefinition "Reader"` cmdlet은 Reader 역할의 모든 속성(Actions, NotActions 등)을 포함하는 객체를 검색합니다. 이 객체를 파이프라인(`|`)을 통해 `ConvertTo-Json` cmdlet으로 전달하면, 역할 정의가 JSON 텍스트로 변환됩니다. 이 JSON 파일을 파일로 저장하고, 필요한 권한(감사 로그 접근 등)을 `Actions`에 추가한 뒤, `New-AzRoleDefinition` 명령의 입력으로 사용하여 새 사용자 지정 역할을 생성할 수 있습니다.

정답 기술 해설

정답은 **D**입니다. Azure Backup 서비스의 아키텍처에서 **Recovery Services 자격 증명 모음(Vault)**은 모든 백업 작업의 기반이 되는 최상위 리소스입니다. 자격 증명 모음은 백업 데이터의 스토리지 컨테이너 역할을 하며, 백업 정책, 백업 항목, 복원 지점 등 모든 관련 구성을 중앙에서 관리하는 관리 경계입니다. 따라서 Azure VM, SQL 데이터베이스, 파일 공유 등 어떤 리소스를 백업하든, 가장 먼저 수행해야 할 작업은 해당 리소스가 있는 지역에 자격 증명 모음을 생성하는 것입니다.

오답 분석

• A, C: 복구 계획(Recovery Plan)과 백업 정책(Backup Policy)은 모두 자격 증명 모음이 생성된 *후에* 그 안에서 구성되는 하위 항목입니다.
• B: Azure Backup 서버(MABS)는 온프레미스 워크로드를 Azure로 백업하기 위해 사용하는 구성 요소로, Azure 내의 리소스를 직접 백업하는 이 시나리오에서는 필요하지 않습니다.

정답 기술 해설

정답은 **B**입니다. **Azure Storage Explorer**는 대규모 데이터를 안정적으로 업로드/다운로드할 수 있도록 설계된 GUI 도구입니다. 내부적으로 AzCopy 유틸리티를 사용하여 병렬 전송 및 중단 시 이어하기(resume) 기능을 제공하므로, 50TB와 같은 대규모 온라인 데이터 마이그레이션에 매우 적합합니다.

오답 분석

• A, D: 파일 탐색기를 사용한 드라이브 매핑은 대규모 데이터 전송에 불안정하며, 네트워크 중단 시 처음부터 다시 시작해야 할 수 있어 부적합합니다.
• C: Azure Import/Export 서비스는 물리적 디스크를 배송하는 오프라인 방식입니다. 이는 네트워크 대역폭이 매우 제한적이거나 데이터 크기가 훨씬 클 때 유용하지만, '다운타임 최소화'라는 온라인 마이그레이션 요구사항과는 거리가 있습니다.

정답 기술 해설

• Statement 1 (Yes): Azure IaaS VM의 OS 디스크와 데이터 디스크는 VHD(가상 하드 디스크) 파일로 구현됩니다. Azure Storage에서 VHD 파일은 랜덤 읽기/쓰기 액세스에 최적화된 **페이지 Blob(Page Blobs)**을 사용하여 저장됩니다. 시나리오에 VM이 포함되므로 페이지 Blob이 필요합니다.
• Statement 2 (No): **Archive Tier**는 액세스 빈도가 거의 없는 데이터를 매우 저렴한 비용으로 장기간 보관하기 위한 스토리지 계층입니다. 데이터에 액세스하려면 몇 시간의 검색 대기 시간이 필요합니다(리하이드레이션). 시나리오의 데이터는 즉시 액세스가 필요하므로 Archive Tier는 적합하지 않습니다.
• Statement 3 (No): **Azure Files Premium**은 트랜잭션 집약적인 고성능 워크로드(예: 데이터베이스, 고성능 컴퓨팅)에 적합한 SSD 기반 스토리지를 제공합니다. 시나리오에서 고성능이 요구되지만, 이것이 반드시 Premium Tier를 의미하지는 않으며 표준 Tier로도 충분할 수 있습니다.

정답 기술 해설

• Container1: 시나리오의 '데이터 분류'에 따라 CAD 파일(블루프린트)은 **Premium storage**가 필요하며, 컨테이너는 **Blob** 서비스에 해당합니다. '추가 정보' 표에서 Blob을 지원하고 Premium 성능을 가진 유일한 계정은 **storage3**입니다.
• Share1: 문서 공유는 **Azure Files** 서비스를 사용합니다. 시나리오에서 일반 문서에 대한 Premium 요구사항은 없습니다. '추가 정보' 표에서 Files를 지원하는 표준 성능 계정은 **storage2**와 **storage4**입니다. 따라서 두 계정 모두 사용 가능합니다.

정답 기술 해설

Azure Storage의 **객체 복제(Object Replication)** 기능을 사용하기 위한 두 가지 핵심 전제 조건이 있습니다.

1. 계정 유형: 원본 계정과 대상 계정은 모두 **범용 v2(General-purpose v2)** 유형이어야 합니다.
2. 지역: 대상 계정은 원본 계정과 **다른 지역**에 있어야 합니다.

따라서 지역 간 복제를 지원하는 storage5를 생성하려면 계정 유형으로 **'General purpose v2'**를 선택해야 합니다. 대상 계정으로는 '추가 정보'에 명시된 계정 중 GPv2 유형이면서 원본(East US)과 다른 지역에 있는 **storageacct123(West Europe)**만이 유일한 유효한 선택지입니다.

오답 분석

• blobstorage789: 계정 유형이 GPv2가 아니므로 대상이 될 수 없습니다.
• same_region_gpv2: 원본과 동일한 지역에 있으므로 지역 간 복제 대상이 될 수 없습니다.

정답 기술 해설

정답은 **E**입니다. **Azure Network Watcher**의 **IP 흐름 확인(IP flow verify)** 기능은 특정 가상 머신에서 특정 원본/대상 IP 주소 및 포트 간의 5-튜플 패킷 파라미터를 기반으로 네트워크 연결을 테스트하도록 설계되었습니다. 이 테스트는 트래픽이 허용되는지 또는 거부되는지 여부를 반환하며, 만약 트래픽이 NSG(네트워크 보안 그룹)에 의해 거부된 경우, 해당 트래픽을 차단한 특정 규칙의 이름을 정확히 알려줍니다. 따라서 "문제가 NSG와 관련이 있는지 확인"하는 데 가장 직접적이고 정확한 도구입니다.

오답 분석

• A: VNet 다이어그램은 리소스 간의 관계를 시각적으로 보여줄 뿐, 실시간 트래픽 흐름이나 규칙 적용 여부를 진단하지는 못합니다.
• B: 진단 설정은 로그 및 메트릭 데이터를 내보내는 구성이며, 그 자체로 연결 문제를 직접 진단하는 도구는 아닙니다.
• C: Traffic Manager는 DNS 기반의 트래픽 부하 분산 서비스로, NSG 규칙과는 관련이 없습니다.
• D: Azure Advisor는 모범 사례에 대한 권장 사항을 제공하지만, 특정 연결 실패의 근본 원인을 실시간으로 진단하지는 않습니다.

정답 기술 해설

정답은 **B**입니다. 서로 다른 Azure 가상 네트워크(VNet) 간에 프라이빗 IP 주소 공간을 통해 직접 통신을 설정하는 가장 효율적이고 관리 부담이 적은 방법은 **VNet 피어링(VNet Peering)**입니다. 피어링을 설정하면 두 VNet이 Azure의 고속 백본 네트워크를 통해 직접 연결되어, 마치 단일 VNet인 것처럼 낮은 대기 시간과 높은 대역폭으로 통신할 수 있습니다. VPN 게이트웨이와 같은 추가적인 인프라 구성이 필요 없어 '관리 노력 최소화' 요구사항에 완벽하게 부합합니다.

오답 분석

• A: NSG는 VNet 내 또는 서브넷 수준에서 트래픽을 필터링하는 방화벽 규칙 집합입니다. VNet 간의 연결 자체를 설정하는 기능은 없습니다.
• C: VM의 IP 주소를 변경해도 다른 VNet의 주소 공간과 통신할 수 없습니다. VNet 간에 라우팅 경로가 없기 때문입니다.
• D: 사용자 정의 경로(UDR)는 특정 트래픽을 강제로 다른 경로(예: 가상 어플라이언스)로 보내는 데 사용됩니다. UDR만으로는 VNet 간의 연결 경로가 생성되지 않습니다.

정답 기술 해설

온프레미스 데이터 센터와 Azure VNet 간에 인터넷을 통해 암호화된 터널을 생성하는 표준적인 하이브리드 연결 방법은 **사이트-투-사이트(Site-to-Site) VPN**입니다. 이를 구현하기 위해 Azure 측에서 반드시 생성해야 할 핵심 구성 요소는 다음과 같습니다.

• 가상 네트워크 게이트웨이 (Virtual Network Gateway): Azure VNet의 VPN 연결 엔드포인트 역할을 하는 Azure 관리형 서비스입니다.
• 로컬 네트워크 게이트웨이 (Local Network Gateway): 연결하려는 온프레미스 네트워크(뉴욕 사무실)의 공인 IP 주소와 주소 공간을 Azure에 알려주는 객체입니다.

이 두 게이트웨이를 생성한 후, 이들을 논리적으로 연결하는 **'연결(Connection)'** 리소스를 만들어 S2S VPN 터널 구성을 완료합니다.

정답 기술 해설

이 문제는 Azure에서 N계층 애플리케이션을 위한 표준 참조 아키텍처를 묻고 있습니다.

• 인터넷 -> 웹 계층: 외부 사용자의 HTTPS 트래픽을 처리하기 위해 OSI 7계층에서 작동하는 Application Gateway를 사용합니다. 이는 SSL 종료, URL 기반 라우팅, 웹 애플리케이션 방화벽(WAF)과 같은 고급 기능을 제공하여 웹 트래픽을 안전하고 효율적으로 웹 계층의 VM으로 분산시킵니다.
• 내부 계층 간 통신: 웹 계층과 애플리케이션 계층, 애플리케이션 계층과 데이터 계층 간의 통신은 내부 트래픽이므로 인터넷에 노출되지 않아야 합니다. 이를 위해 프라이빗 IP 주소를 사용하는 내부 부하 분산 장치(Internal Load Balancer)를 사용하여 내부 트래픽을 각 계층의 VM으로 분산합니다.
• 보안: 각 계층을 별도의 서브넷에 배치하고 각 서브넷에 네트워크 보안 그룹(NSG)을 적용하여 계층 간에 필요한 포트(예: Web -> App은 TCP 8080, App -> DB는 TCP 1433)만 허용함으로써 '포트 최소화' 요구사항을 충족하고 제로 트러스트(Zero Trust) 네트워킹 원칙을 구현합니다.

정답 기술 해설

NSG 규칙은 우선순위(Priority) 번호가 낮을수록 먼저 처리됩니다. 일치하는 첫 번째 규칙이 적용되고 나머지 규칙은 처리되지 않습니다. 만약 어떤 규칙과도 일치하지 않으면, 각 방향(인바운드/아웃바운드)의 마지막에 있는 기본 `DenyAll` 규칙이 적용됩니다.

• Statement 1 (Yes): 인터넷(Source: Internet)에서 웹 서버(Destination: 10.10.1.0/24)로의 TCP 포트 443 트래픽은 NSG1의 `Allow_Web_Inbound` 규칙(우선순위 100)과 일치합니다. 이 규칙은 'Allow'이므로 트래픽이 **허용**됩니다.
• Statement 2 (No): 웹 서버(Source: 10.10.1.0/24)에서 데이터베이스 서버(Destination: 10.10.3.0/24)로의 TCP 포트 80 트래픽은 NSG2의 인바운드 규칙 중 어느 것과도 일치하지 않습니다. `Allow_App_to_DB` 규칙은 포트 1433만 허용합니다. 따라서 마지막 기본 규칙인 `DenyAllInBound`에 의해 트래픽이 **거부**됩니다.
• Statement 3 (Yes): 애플리케이션 서버(Source: 10.10.2.0/24)에서 데이터베이스 서버(Destination: 10.10.3.0/24)로의 TCP 포트 1433 트래픽은 NSG2의 `Allow_App_to_DB` 규칙(우선순위 110)에 의해 명시적으로 **허용**됩니다.

정답 기술 해설

정답은 **A**입니다. 외부 사용자가 인터넷을 통해 웹 서버에 접속하게 하려면 외부에서 내부로 향하는 트래픽, 즉 **인바운드(Inbound)** 트래픽을 허용해야 합니다. 요구사항에 따라 HTTPS(암호화된 웹 트래픽) 접근을 허용해야 하므로, 표준 TCP 포트인 **443**에 대한 인바운드 규칙이 필요합니다. 또한, 최소 권한의 원칙에 따라 이 규칙은 인터넷 트래픽을 직접 수신해야 하는 **웹 서버가 포함된 서브넷에만** 연결해야 합니다. 애플리케이션이나 데이터베이스 서브넷과 같이 내부 통신만 필요한 곳에 불필요하게 인터넷 포트를 열어두는 것은 보안에 매우 취약합니다.

오답 분석

• B, D: 아웃바운드(Outbound) 규칙은 VM에서 외부로 나가는 트래픽을 제어합니다. 사용자가 서버에 접속하는 것은 인바운드이므로 목적에 맞지 않습니다.
• C: NSG를 모든 서브넷에 연결하면 내부 애플리케이션 및 데이터베이스 서브넷에도 불필요한 인터넷 포트가 열리게 되어 심각한 보안 위험을 초래합니다.