🎯 AZ-104: Microsoft Azure Administrator

📚 해설

Box 1: 내부 부하 분산 장치

• Azure 내부 부하 분산 장치(ILB)는 클라우드 서비스 또는 지역적 범위의 가상 네트워크 내에 있는 가상 머신 간에 네트워크 부하 분산을 제공합니다.
• 웹 서버와 비즈니스 로직 계층 간의 트래픽을 균등하게 분산시킵니다.

Box 2: WAF 계층을 사용하는 Application Gateway

• Azure Application Gateway의 Azure WAF(웹 애플리케이션 방화벽)는 일반적인 취약점과 악용으로부터 웹 애플리케이션을 중앙 집중식으로 보호합니다.
• SQL 인젝션 공격을 포함한 다양한 웹 공격으로부터 보호합니다.

📚 해설

Azure Virtual WAN 아키텍처:

• Azure Virtual WAN은 Azure를 통해 분기 간 연결을 제공하는 네트워킹 서비스입니다.
• 각 지역(마이애미, 로스앤젤레스, 뉴욕)에 가상 허브를 배치하여 최적의 연결성과 최소 대기 시간을 제공합니다.
• 단일 Virtual WAN이 여러 허브를 관리하여 글로벌 연결성을 제공합니다.
• 이 구조는 분기-대-분기 연결을 최적화하고 Azure의 글로벌 네트워크를 활용합니다.

📚 해설

Box 1: 5개 (네트워크 인터페이스)

• 각 가상 머신은 자체 네트워크 인터페이스가 필요합니다.
• 하나의 네트워크 인터페이스에 공용 IP와 개인 IP 주소를 모두 할당할 수 있습니다.
• 5개의 VM = 5개의 네트워크 인터페이스가 필요합니다.

Box 2: 1개 (네트워크 보안 그룹)

• 하나의 NSG를 여러 서브넷과 네트워크 인터페이스에 연결할 수 있습니다.
• 모든 VM이 동일한 보안 규칙을 사용하므로 하나의 NSG만 필요합니다.
• 이 NSG를 서브넷 수준에서 적용하거나 각 네트워크 인터페이스에 연결할 수 있습니다.

📚 해설

왜 A가 정답인가:

• 인바운드 NAT 규칙을 생성하려면 먼저 프런트엔드 IP 주소가 필요합니다.
• NAT 규칙은 특정 프런트엔드 IP 주소와 포트에서 백엔드 VM의 특정 포트로 트래픽을 라우팅합니다.
• 공용 부하 분산 장치의 경우 공용 IP 주소가 프런트엔드 IP로 사용됩니다.
• 내부 부하 분산 장치의 경우 개인 IP 주소가 프런트엔드 IP로 사용됩니다.

NAT 규칙 구성 순서:

1. 프런트엔드 IP 주소 구성
2. 백엔드 풀 구성 (이미 존재할 수 있음)
3. 인바운드 NAT 규칙 생성

📚 해설

Azure DNS 개인 영역 자동 등록:

• 가상 머신이 개인 영역에 등록(추가)되면 개인 IP 주소를 가리키는 A 레코드로 추가됩니다.
• 자동 등록이 활성화된 경우, VNET1에 있는 VM들이 자동으로 DNS 영역에 등록됩니다.
• 공용 IP 주소가 아닌 개인 IP 주소만 A 레코드로 등록됩니다.
• VNET2에 있는 VM3은 자동 등록 대상이 아닙니다 (VNET1만 연결됨).

결과:

• VM1: A 레코드 생성 (개인 IP)
• VM2: A 레코드 생성 (개인 IP)
• VM3: A 레코드 생성되지 않음 (다른 VNET)

📚 해설

NSG Flow 로그를 사용하는 이유:

• NSG Flow 로그는 네트워크 보안 그룹을 통해 들어오고 나가는 IP 트래픽에 대한 정보를 기록합니다.
• ILB1에 연결하는 IP 주소를 추적할 수 있습니다.
• 소스 및 대상 IP, 포트, 프로토콜, 트래픽 허용/거부 여부 등의 정보를 제공합니다.

Log Analytics 작업 영역이 필요한 이유:

• Azure Portal에서 대화형 쿼리를 실행하려면 Log Analytics가 필요합니다.
• Kusto 쿼리 언어(KQL)를 사용하여 로그 데이터를 분석할 수 있습니다.
• Network Watcher의 트래픽 분석 기능과 통합됩니다.

📚 해설

가상 네트워크 피어링 조건:

• 피어링을 설정하려면 가상 네트워크의 주소 공간이 겹치지 않아야 합니다.
• VNet1: 10.0.0.0/16
• VNet2: 10.0.0.0/17 (VNet1과 겹침 - 피어링 불가)
• VNet3: 10.1.0.0/16 (겹치지 않음 - 피어링 가능)
• VNet4: 10.2.0.0/16 (겹치지 않음 - 피어링 가능)

주소 공간 분석:

• 10.0.0.0/16은 10.0.0.0~10.0.255.255 범위를 포함합니다.
• 10.0.0.0/17은 10.0.0.0~10.0.127.255 범위를 포함합니다.
• VNet1과 VNet2는 주소 범위가 겹치므로 피어링할 수 없습니다.

📚 해설

B. 표준 부하 분산 장치 배포

• HA 포트 기능은 표준 SKU에서만 사용할 수 있습니다.
• NVA 시나리오에서는 모든 포트와 프로토콜에 대한 부하 분산이 필요합니다.

C. HA 포트가 활성화되고 부동 IP가 활성화된 두 개의 부하 분산 규칙

• HA 포트는 모든 포트에서 트래픽을 부하 분산합니다.
• 부동 IP(Direct Server Return)는 NVA가 원래 대상 IP를 유지할 수 있게 합니다.
• 서로 다른 IP 주소를 가진 두 서비스를 위해 두 개의 규칙이 필요합니다.

F. 프런트엔드 IP 구성, 두 개의 백엔드 풀 및 상태 프로브

• 각 서비스(서로 다른 IP 주소)마다 별도의 백엔드 풀이 필요합니다.
• 상태 프로브는 NVA의 상태를 모니터링하여 자동 장애 조치를 지원합니다.

📚 해설

왜 A가 정답인가:

• 지점 간 VPN 클라이언트 구성에는 연결 가능한 네트워크의 라우팅 정보가 포함됩니다.
• VNet 피어링을 구성한 후, 클라이언트는 새로운 라우팅 정보를 받아야 합니다.
• 새 VPN 클라이언트 구성 패키지에는 VNet2에 대한 라우팅 정보가 포함됩니다.
• 기존 구성 패키지는 피어링 이전에 생성되었으므로 VNet2에 대한 라우팅 정보가 없습니다.

다른 옵션들이 틀린 이유:

• B, C: 게이트웨이 전송은 이미 작동하고 있습니다 (온-프레미스에서 VNet2 연결 가능).
• D: BGP는 이 시나리오에서 필요하지 않으며, 정적 라우팅으로도 해결 가능합니다.

📚 해설

1번: VM1이 adatum.com의 레코드를 확인할 수 있습니다 - 아니오

• VM1은 개인 DNS 영역(contoso.com)만 사용하도록 구성되어 있습니다.
• 공용 DNS 영역(adatum.com)에 대한 링크가 없습니다.
• 개인 DNS가 구성되면 Azure 기본 DNS가 우선순위에서 밀려납니다.

2번: VM1이 contoso.com의 레코드를 확인할 수 있습니다 - 예

• VM1이 위치한 VNET1이 contoso.com 개인 DNS 영역과 연결되어 있습니다.
• 자동 등록이 활성화되어 VM1이 자동으로 등록됩니다.

3번: VM2가 contoso.com의 레코드를 확인할 수 있습니다 - 아니오

• VM2가 위치한 VNET2는 contoso.com 개인 DNS 영역과 연결되어 있지 않습니다.
• 개인 DNS 영역에 액세스하려면 가상 네트워크 링크가 필요합니다.

📚 해설

NSG 적용 규칙:

• 네트워크 보안 그룹(NSG)은 동일한 지역과 동일한 구독 내의 리소스에만 적용할 수 있습니다.
• NSG1 위치: North Europe
• VNet1 위치: East US (다른 지역 - 적용 불가)
• VNet2 위치: West Europe (다른 지역 - 적용 불가)
• VNet3 위치: North Europe (동일 지역 - 적용 가능)

지역별 제한 사항:

• Azure 리소스는 지역 간 경계를 넘어서 직접 연결할 수 없습니다.
• NSG는 같은 지역의 가상 네트워크, 서브넷, 네트워크 인터페이스에만 연결 가능합니다.
• 이는 네트워크 성능과 대기 시간을 최적화하기 위한 Azure의 설계 원칙입니다.

📚 해설

피어링된 가상 네트워크의 주소 공간 수정 제한:

• 가상 네트워크가 다른 가상 네트워크와 피어링되면 주소 범위를 추가하거나 삭제할 수 없습니다.
• 주소 범위를 수정하려면 먼저 피어링을 삭제해야 합니다.
• 주소 공간 수정 후 피어링을 다시 생성해야 합니다.

올바른 순서:

1. 피어링 제거: VNet1과 VNet2 간의 피어링을 삭제합니다.
2. 주소 공간 추가: VNet1에 10.44.0.0/16 주소 공간을 추가합니다.
3. 피어링 재생성: VNet1과 VNet2 간의 피어링을 다시 만듭니다.

주의사항:

• 피어링을 제거하는 동안 가상 네트워크 간 통신이 일시적으로 중단됩니다.
• 새로운 주소 공간이 기존 피어링된 네트워크와 겹치지 않는지 확인해야 합니다.

📚 해설

1번: VM1을 RG2로 이동할 수 있습니다 - 아니오

• VM1은 현재 실행 중이고 여러 리소스(NIC1, Disk1, VNET1)에 연결되어 있습니다.
• 실행 중인 VM과 관련된 모든 종속 리소스를 함께 이동해야 합니다.
• VM만 단독으로 이동할 수 없습니다.

2번: VNET1을 RG2로 이동할 수 있습니다 - 예

• 가상 네트워크는 이동 가능한 리소스입니다.
• 연결된 리소스들과 함께 이동할 수 있습니다.
• 같은 구독 내에서 리소스 그룹 간 이동이 가능합니다.

3번: IP2를 RG1으로 이동할 수 있습니다 - 예

• 공용 IP 주소는 이동 가능한 리소스입니다.
• 현재 가상 머신에 할당되지 않은 상태이므로 이동에 제약이 없습니다.
• 같은 지역(East US) 내에서 리소스 그룹 간 이동이 가능합니다.

📚 해설

Azure App Service VNet 통합:

• Azure App Service(웹앱)를 가상 네트워크에 통합하면 앱이 VNet 내의 리소스에 액세스할 수 있습니다.
• VNet 통합을 통해 webapp1이 VM1의 개인 IP 주소를 사용하여 MySQL 데이터베이스에 연결할 수 있습니다.
• 이는 보안성을 높이고 공용 인터넷을 통하지 않고 직접 통신할 수 있게 합니다.

다른 옵션들이 틀린 이유:

• A. 내부 부하 분산 장치: 단일 VM에는 필요하지 않으며, 웹앱이 VNet에 액세스하는 문제를 해결하지 못합니다.
• B. 다른 VNet에 피어링: 현재 상황에서는 추가 네트워크가 필요하지 않습니다.
• D. Application Gateway: 인바운드 트래픽 관리용이며, 웹앱의 아웃바운드 연결 문제를 해결하지 못합니다.

📚 해설

VM 상태 확인이 중요한 이유:

• PowerShell DSC 확장을 설치하고 구성하려면 VM이 실행 중 상태여야 합니다.
• 전시 이미지에서 VM1이 중지된 상태(Stopped)로 표시되어 있습니다.
• 중지된 VM에서는 확장을 설치하거나 구성할 수 없습니다.

PowerShell DSC 설정 과정:

1. VM을 시작합니다 (현재 단계)
2. PowerShell DSC 확장을 설치합니다
3. DSC 구성 스크립트를 업로드합니다
4. DSC 구성을 적용합니다

다른 옵션들이 틀린 이유:

• A: VM이 중지된 상태에서는 연결할 수 없습니다.
• C: DSC 설정 전에 스냅샷이 필요하지 않습니다.
• D: DNS 이름은 DSC 기능과 무관합니다.

📚 해설

세션 지속성(Session Affinity) 개념:

• 세션 지속성은 동일한 클라이언트의 요청을 항상 같은 백엔드 서버로 라우팅하는 기능입니다.
• "클라이언트 IP" 모드에서는 클라이언트의 IP 주소를 기반으로 해시를 생성하여 항상 같은 서버로 연결합니다.
• 웹 애플리케이션에서 세션 상태를 유지해야 할 때 필요합니다.

세션 지속성 옵션:

• 없음: 라운드 로빈 방식으로 요청을 분산 (기본값)
• 클라이언트 IP: 클라이언트 IP를 기반으로 동일 서버로 라우팅
• 클라이언트 IP 및 프로토콜: IP와 프로토콜을 모두 고려하여 라우팅

부동 IP는 관련 없는 이유:

• 부동 IP는 Direct Server Return(DSR) 기능으로, 응답 트래픽이 부하 분산 장치를 거치지 않고 직접 클라이언트로 전송되는 기능입니다.
• 세션 지속성과는 별개의 기능입니다.

📚 해설

현재 문제점 분석:

• NSG-VM1의 규칙이 UDP 프로토콜로 설정되어 있습니다.
• RDP(원격 데스크톱)는 TCP 포트 3389를 사용합니다.
• UDP 3389 규칙은 RDP 연결에 도움이 되지 않습니다.

솔루션이 작동하는 이유:

• NSG-Subnet1에 TCP 3389를 허용하는 올바른 규칙을 추가합니다.
• 잘못된 UDP 규칙이 있는 NSG-VM1을 제거합니다.
• 결과적으로 서브넷 수준에서 올바른 TCP RDP 트래픽이 허용됩니다.

NSG 우선순위 이해:

• 네트워크 인터페이스와 서브넷 모두에 NSG가 연결된 경우, 두 NSG의 규칙이 모두 적용됩니다.
• 트래픽이 허용되려면 두 NSG 모두에서 허용되어야 합니다.
• 잘못된 NSG를 제거하고 올바른 규칙을 가진 NSG만 남기는 것이 더 간단합니다.

📚 해설

솔루션이 작동하지 않는 이유:

• RDP(원격 데스크톱 프로토콜)는 TCP 포트 3389를 사용합니다.
• 솔루션에서 UDP 프로토콜을 사용하도록 제안하고 있습니다.
• UDP 3389 규칙은 RDP 연결을 허용하지 않습니다.

올바른 솔루션:

• NSG-Subnet1에 TCP 포트 3389를 허용하는 규칙을 추가해야 합니다.
• 프로토콜을 TCP로 설정해야 합니다.
• 또는 NSG-VM1의 기존 UDP 규칙을 TCP로 수정해야 합니다.

RDP 프로토콜 요구사항:

• RDP는 기본적으로 TCP 포트 3389를 사용합니다.
• 일부 RDP 구현에서 UDP를 사용할 수 있지만, 표준 Windows RDP는 TCP를 사용합니다.
• 문제에서 "Windows Server 구성"이라고 명시했으므로 TCP가 필요합니다.

📚 해설

솔루션이 작동하는 이유:

• 올바른 프로토콜(TCP)을 사용하여 포트 3389를 허용합니다.
• NSG-Subnet1과 NSG-VM1 모두에 규칙을 추가합니다.
• 두 NSG 모두에서 트래픽이 허용되므로 연결이 성공합니다.

NSG 규칙 평가 과정:

1. 인바운드 트래픽이 NSG-Subnet1에서 먼저 평가됩니다.
2. 새로 추가된 TCP 3389 규칙에 의해 허용됩니다.
3. 트래픽이 NSG-VM1에서 다시 평가됩니다.
4. 새로 추가된 TCP 3389 규칙에 의해 허용됩니다.
5. 두 NSG 모두에서 허용되므로 최종적으로 VM에 도달합니다.

중복 규칙의 영향:

• 기존 UDP 3389 규칙은 여전히 존재하지만 RDP 트래픽에는 영향을 주지 않습니다.
• 새로운 TCP 3389 규칙이 RDP 연결을 허용합니다.
• NSG는 여러 규칙을 가질 수 있으며, 허용 규칙이 하나라도 있으면 트래픽이 허용됩니다.

📚 해설

IP 주소 계산 방법:

• CIDR 표기법에서 /24는 네트워크 비트가 24개, 호스트 비트가 8개임을 의미합니다.
• 10.1.0.0/24 서브넷은 256개(2^8)의 IP 주소를 가집니다.
• Azure에서는 각 서브넷의 처음 4개와 마지막 1개 주소를 예약합니다.
• 따라서 실제 사용 가능한 주소: 256 - 5 = 251개

Azure 예약 주소:

• 10.1.0.0: 네트워크 주소
• 10.1.0.1: Azure 게이트웨이용
• 10.1.0.2, 10.1.0.3: Azure DNS용
• 10.1.0.255: 브로드캐스트 주소

주소 공간 확장 가능성:

• VNet의 주소 공간에 따라 추가 서브넷을 만들 수 있습니다.
• 기존 서브넷과 겹치지 않는 범위에서 새 서브넷을 생성할 수 있습니다.

📚 해설

단일 NSG로 모든 요구사항 충족 가능:

• 하나의 NSG에 여러 규칙을 추가하여 모든 시나리오를 처리할 수 있습니다.
• NSG 규칙은 우선순위에 따라 평가되므로 세밀한 제어가 가능합니다.
• 서브넷 수준에서 NSG를 적용하면 모든 VM에 영향을 줍니다.

필요한 NSG 규칙들:

1. 웹 트래픽 허용: 인터넷 → Subnet2 (VM3,4,5,6), 포트 80/443
2. VM1-VM2 통신: Subnet1 내부 통신 허용
3. RDP to VM1: 인터넷 → VM1, 포트 3389
4. 기본 거부: 다른 모든 트래픽 거부 (NSG 기본 동작)

NSG 적용 전략:

• 서브넷 수준에서 NSG를 적용하면 해당 서브넷의 모든 VM에 규칙이 적용됩니다.
• 특정 VM에만 다른 규칙이 필요한 경우 네트워크 인터페이스 수준에서 추가 NSG를 적용할 수 있지만, 이 시나리오에서는 불필요합니다.

📚 해설

Azure Policy "허용되지 않는 리소스 유형" 이해:

• 이 정책은 지정된 리소스 유형의 생성을 차단합니다.
• 현재 정책이 Microsoft.Compute/virtualMachines를 차단하고 있어서 VM2를 생성할 수 없습니다.
• VM을 생성하려면 해당 리소스 유형을 정책에서 제거해야 합니다.

다른 옵션들이 틀린 이유:

• B. ARM 템플릿: 정책이 활성화되어 있으면 템플릿으로도 차단된 리소스를 생성할 수 없습니다.
• C. 서브넷 추가: 가상 머신 생성과 직접적인 관련이 없습니다.
• D. virtualNetworks 제거: VM2를 생성하는 데 가상 네트워크 정책은 영향을 주지 않습니다. VNET1은 이미 존재합니다.

정책 수정 후 과정:

1. 정책에서 Microsoft.Compute/virtualMachines 제거
2. VM2 생성
3. VM2를 VNET1에 연결
4. 필요시 정책을 다시 업데이트

📚 해설

Azure CLI가 최적인 이유:

• Azure CLI는 DNS 영역 가져오기 기능을 제공합니다.
• az network dns zone import 명령을 사용하여 기존 DNS 영역 파일을 Azure DNS로 직접 가져올 수 있습니다.
• 1,000개의 레코드를 한 번에 처리할 수 있어 관리 노력을 최소화합니다.

DNS 영역 마이그레이션 과정:

1. 온-프레미스 DNS 서버에서 영역 파일을 내보냅니다.
2. Azure에서 새 DNS 영역을 생성합니다.
3. az network dns zone import 명령으로 영역 파일을 가져옵니다.
4. DNS 레코드가 올바르게 가져와졌는지 확인합니다.
5. 도메인 등록기관에서 네임서버를 Azure DNS로 변경합니다.

다른 옵션들의 단점:

• B. Azure PowerShell: DNS 가져오기 기능이 제한적입니다.
• C. Azure Portal: 1,000개 레코드를 수동으로 생성해야 하므로 비효율적입니다.
• D. DNS 관리자: Azure DNS와 직접 통합되지 않습니다.

📚 해설

인바운드 NAT 규칙의 용도:

• 특정 포트의 트래픽을 특정 백엔드 VM으로 직접 라우팅합니다.
• 부하 분산이 아닌 1:1 매핑을 제공합니다.
• RDP 연결과 같이 특정 VM에 직접 액세스해야 하는 경우에 사용합니다.

RDP NAT 규칙 구성 예:

• 프런트엔드 포트: 3389 (또는 다른 포트)
• 백엔드 포트: 3389
• 대상: VM3의 네트워크 인터페이스
• 프로토콜: TCP

다른 옵션들이 적합하지 않은 이유:

• B. 새 부하 분산 장치: 기존 부하 분산 장치에서 NAT 규칙으로 해결 가능하므로 불필요합니다.
• C. 프런트엔드 IP: 이미 존재하는 구성 요소이며, 새로 생성할 필요가 없습니다.
• D. 부하 분산 규칙: 트래픽을 여러 VM에 분산시키므로 특정 VM으로만 보내는 요구사항에 맞지 않습니다.

📚 해설

Basic Load Balancer 제한사항:

• Basic SKU는 단일 가용성 집합, 가상 머신 확장 집합 또는 단일 머신으로 제한됩니다.
• Basic SKU는 가용성 영역을 지원하지 않습니다.
• 같은 가상 네트워크 내의 VM들만 백엔드 풀에 추가할 수 있습니다.

각 명령문 분석:

• 1번 - 예: VM1과 VM2는 같은 VNET1에 있고 같은 가용성 집합에 있을 수 있으므로 Basic LB에 추가 가능합니다.
• 2번 - 아니오: VM3는 다른 가상 네트워크(VNET2)에 있어서 Basic LB에 추가할 수 없습니다.
• 3번 - 아니오: VM4는 다른 지역(West US)에 있어서 같은 부하 분산 장치에 추가할 수 없습니다.

Standard vs Basic Load Balancer:

• Standard SKU: 여러 가용성 집합, 가상 네트워크의 혼합을 지원합니다.
• Basic SKU: 더 제한적이지만 기본적인 부하 분산 기능을 제공합니다.

📚 해설

Azure DNS 영역 유형별 특성:

• 공용 DNS 영역: 인터넷에서 접근 가능, VNet 링크 불가
• 개인 DNS 영역: VNet 내부에서만 접근 가능, VNet 링크 필요

VNet 링크 가능한 영역:

• 개인 DNS 영역만 VNet에 연결할 수 있습니다.
• 공용 DNS 영역은 글로벌하게 접근 가능하므로 VNet 링크가 불필요합니다.
• 표에서 개인 영역으로 표시된 것들만 VNET1에 연결 가능합니다.

자동 등록 조건:

• 개인 DNS 영역에만 VM이 자동 등록될 수 있습니다.
• VNet 링크에서 "자동 등록 사용" 옵션이 활성화되어야 합니다.
• VM의 DNS 접미사와 일치하는 영역에 자동 등록됩니다.
• VM1의 DNS 접미사는 Adatum.com이므로 해당 개인 영역이 있다면 자동 등록됩니다.

📚 해설

사이트 간 VPN 설정 순서:

1. 게이트웨이 서브넷 생성: VPN 게이트웨이가 배포될 전용 서브넷을 만듭니다.
2. VPN 게이트웨이 생성: Azure 쪽의 VPN 게이트웨이를 만듭니다.
3. 로컬 네트워크 게이트웨이 생성: 온-프레미스 네트워크 정보를 정의합니다.
4. 연결 생성: VPN 게이트웨이와 로컬 네트워크 게이트웨이 간의 연결을 설정합니다.

각 단계의 세부사항:

• 게이트웨이 서브넷: 반드시 "GatewaySubnet"이라는 이름을 사용해야 하며, 최소 /27 크기를 권장합니다.
• VPN 게이트웨이: Route-based 또는 Policy-based 유형을 선택할 수 있습니다.
• 로컬 네트워크 게이트웨이: 온-프레미스 VPN 디바이스의 공용 IP와 주소 공간을 정의합니다.
• 연결: 공유 키를 설정하여 보안 터널을 구성합니다.

📚 해설

문제 분석:

• VM1과 VM2가 TCP 포트 80으로 아웃바운드 웹 트래픽을 차단해야 함
• 현재 NSG는 개별 VM에만 적용되어 있음
• DenyWebSites 규칙이 있지만 효과가 없는 상황

왜 C가 정답인가:

• NSG를 서브넷 수준에서 적용하면 해당 서브넷의 모든 VM에 규칙이 적용됩니다
• VM1과 VM2가 모두 Subnet1에 있으므로 한 번에 두 VM 모두 제어 가능
• 서브넷 수준 NSG는 VM 수준 NSG보다 관리가 효율적
• DenyWebSites 아웃바운드 규칙이 두 VM 모두에 적용됨

다른 옵션들이 틀린 이유:

• A. NSG 연결 해제는 보안을 약화시킴
• B. Port_80은 인바운드 규칙이므로 아웃바운드 트래픽 차단과 무관
• D. DenyWebSites 규칙 자체는 올바르게 구성되어 있음

NSG 적용 순서:

1. 서브넷 수준 NSG 평가
2. 네트워크 인터페이스 수준 NSG 평가
3. 두 규칙 모두 허용해야 트래픽 통과

📚 해설

문제 분석:

• 서로 다른 Azure AD 테넌트의 두 구독
• VNet 피어링은 동일한 테넌트 내에서만 가능
• 크로스 테넌트 연결이 필요한 상황

왜 D가 정답인가:

• VNet 피어링 제한: 서로 다른 Azure AD 테넌트 간에는 직접 피어링 불가
• VPN Gateway 솔루션: 각 VNet에 Virtual Network Gateway를 배포하여 VNet-to-VNet VPN 연결 구성
• 크로스 테넌트 지원: VPN Gateway는 서로 다른 테넌트 간 연결을 지원
• 보안 연결: IPSec/IKE VPN 터널을 통한 암호화된 연결

구현 단계:

1. 각 VNet에 GatewaySubnet 생성
2. 각 VNet에 Virtual Network Gateway 배포
3. VNet-to-VNet 연결 구성
4. 공유 키(Pre-shared key) 설정

다른 옵션들이 틀린 이유:

• A, B: 리소스 이동은 복잡하고 불필요한 작업
• C: IP 주소 공간 변경은 테넌트 간 연결 문제 해결과 무관

추가 고려사항:

• ExpressRoute를 사용한 대안도 가능
• 비용 고려: VPN Gateway는 시간당 요금 부과
• 대역폭 제한: Gateway SKU에 따라 처리량 제한

📚 해설

문제 분석:

• Azure Availability Zones에 VM을 배포하려면 특정 요구사항 충족 필요
• 현재 구성에서 두 가지 설정이 변경되어야 함

왜 A와 C가 정답인가:

A. 관리 디스크 사용:

• 필수 요구사항: Availability Zones은 관리 디스크만 지원
• 비관리 디스크 제한: Storage Account 기반 디스크는 AZ 배포 불가
• 자동 복제: 관리 디스크는 영역 내에서 자동으로 복제됨
• 고가용성: Zone-redundant storage (ZRS) 옵션 제공

C. 가용성 옵션:

• 설정 변경: "No infrastructure redundancy required"에서 "Availability zone"으로 변경
• 영역 선택: 특정 가용성 영역(1, 2, 3 중 하나) 선택 필요
• SLA 향상: 99.99% 가동 시간 SLA 제공
• 내결함성: 데이터센터 레벨 장애로부터 보호

다른 옵션들이 틀린 이유:

• B. OS 디스크 유형: Premium SSD, Standard SSD 모두 AZ 지원
• D. 크기: 대부분의 VM 크기가 AZ 지원 (일부 제외)
• E. 이미지: 표준 이미지들은 모두 AZ 지원

Availability Zones 추가 정보:

• 지원 지역: 모든 Azure 지역이 AZ를 지원하지는 않음
• 네트워킹: 영역 간 트래픽에 미세한 지연 시간 증가
• 비용: 영역 간 데이터 전송 비용 발생 가능
• 로드 밸런서: Standard SKU Load Balancer 필요

권장 구성:

• 관리 디스크 + Premium SSD 조합
• Standard Load Balancer 사용
• 여러 영역에 걸친 VM 배포
• Zone-redundant storage 고려

📚 해설

VM 오케스트레이션 모드의 특징:

• VM 오케스트레이션 모드에서는 기존에 생성된 VM을 스케일 셋에 추가할 수 있습니다.
• VM은 스케일 셋과 같은 지역에 있어야 합니다.
• 리소스 그룹은 다를 수 있습니다.

Box 1: RG1, RG2, 또는 RG3

• 리소스 그룹은 메타데이터 저장 위치일 뿐입니다.
• VM은 어떤 리소스 그룹에서든 생성할 수 있습니다.
• 나중에 스케일 셋에 추가할 때 리소스 그룹이 달라도 상관없습니다.

Box 2: West US만

• VMSS1이 West US에 위치하므로 VM1도 같은 지역에 있어야 합니다.
• VM 오케스트레이션 모드라도 지역 제약은 동일하게 적용됩니다.
• 다른 지역의 VM은 스케일 셋에 추가할 수 없습니다.

📚 해설

VNet 피어링 상태 분석:

• 피어링이 작동하려면 양방향으로 모두 "Connected" 상태여야 합니다.
• 한쪽이라도 "Disconnected"이면 통신이 불가능합니다.

Box 1: VNET2와 VNET3

• VNET1에서 패킷을 보낼 수 있는 대상을 찾아야 합니다.
• VNET1-VNET2 피어링: Connected 상태
• VNET1-VNET3 피어링: Connected 상태
• 따라서 VNET1에서 VNET2와 VNET3로 패킷을 보낼 수 있습니다.

Box 2: VNET1

• VNET3에서 게이트웨이 전송을 통해 연결할 수 있는 네트워크를 찾아야 합니다.
• 게이트웨이 전송이 비활성화되어 있으므로 직접 피어링된 네트워크만 가능합니다.
• VNET3는 VNET1과만 직접 피어링되어 있습니다.

📚 해설

지점 간 VPN 인증서 기반 연결:

• 문제에서 "자체 서명된 인증서"를 사용한다고 명시되어 있습니다.
• 인증서 기반 인증에서는 Azure AD 정책이 아닌 클라이언트 인증서가 필요합니다.
• Computer2가 연결하려면 Computer1에서 사용한 것과 같은 클라이언트 인증서가 필요합니다.

올바른 솔루션:

• Computer1에서 클라이언트 인증서를 내보냅니다.
• Computer2에 해당 인증서를 설치합니다.
• VPN 클라이언트 구성을 Computer2에 적용합니다.

Azure AD vs 인증서 기반 인증:

• Azure AD 인증: OpenVPN 프로토콜을 사용하는 경우
• 인증서 기반: IKEv2 또는 SSTP 프로토콜을 사용하는 경우
• 이 시나리오는 인증서 기반이므로 Azure AD 정책 수정으로는 해결되지 않습니다.

📚 해설

Azure AD 가입 vs VPN 인증서:

• Azure AD 가입은 디바이스 관리와 관련된 기능입니다.
• 지점 간 VPN 연결에서 인증서 기반 인증과는 별개의 개념입니다.
• Computer2를 Azure AD에 가입시켜도 VPN 클라이언트 인증서 문제는 해결되지 않습니다.

인증서 기반 P2S VPN 요구사항:

• 루트 인증서가 Azure VPN 게이트웨이에 업로드되어 있어야 합니다.
• 클라이언트 컴퓨터에 해당 루트 인증서에서 생성된 클라이언트 인증서가 설치되어 있어야 합니다.
• VPN 클라이언트 구성 패키지가 올바르게 설치되어 있어야 합니다.

문제 해결 방법:

• Computer1에서 사용 중인 클라이언트 인증서를 Computer2로 복사해야 합니다.
• 또는 동일한 루트 인증서에서 새로운 클라이언트 인증서를 생성해야 합니다.

📚 해설

리소스 잠금의 역할:

• 리소스 잠금은 리소스의 삭제나 수정을 방지하는 기능입니다.
• 새로운 리소스가 생성될 때 특정 구성을 강제하는 기능이 아닙니다.
• NSG가 생성될 때 자동으로 특정 규칙을 추가하는 것과는 관련이 없습니다.

올바른 솔루션:

• Azure Policy를 사용하여 NSG 생성 시 특정 규칙을 강제해야 합니다.
• 사용자 지정 정책 정의를 만들어 NSG가 생성될 때 TCP 8080 차단 규칙을 자동으로 추가하도록 구성해야 합니다.
• 또는 DeployIfNotExists 효과를 사용하여 NSG 생성 후 자동으로 규칙을 배포할 수 있습니다.

리소스 잠금 유형:

• ReadOnly: 리소스 읽기만 허용
• Delete: 리소스 삭제 방지
• 둘 다 새로운 리소스의 구성을 제어하지는 않습니다.

📚 해설

VM 상태 확인의 중요성:

• 이미지를 보면 VM1이 "중지됨(할당 해제됨)" 상태로 표시되어 있습니다.
• VM이 중지된 상태에서는 네트워크 연결이 불가능합니다.
• RDP 연결을 시도하기 전에 반드시 VM을 시작해야 합니다.

VM 상태별 네트워크 연결:

• 실행 중: 네트워크 연결 가능
• 중지됨: 네트워크 연결 불가능
• 할당 해제됨: 완전히 종료된 상태, 연결 불가능

다른 옵션들이 우선순위가 낮은 이유:

• A, C: NSG 규칙 수정은 VM이 실행된 후에 고려할 사항입니다.
• B: 네트워크 인터페이스는 이미 연결되어 있는 것으로 보입니다.

문제 해결 순서:

1. VM1 시작 (현재 단계)
2. NSG 규칙 확인 및 수정
3. RDP 연결 시도

📚 해설

네트워크 연결 문제:

• VM2와 VM3가 VM1(10.0.0.4)의 DNS 서비스에 액세스하려면 네트워크 연결이 필요합니다.
• 현재 VNET1, VNET2, VNET3는 서로 분리되어 있어 통신할 수 없습니다.
• VNet 피어링을 통해 가상 네트워크 간 연결을 설정해야 합니다.

DNS 구성 분석:

• VNET2와 VNET3의 DNS 서버가 10.0.0.4(VM1)로 설정되어 있습니다.
• 하지만 네트워크 연결이 없어서 VM1에 도달할 수 없습니다.
• 피어링 설정 후 DNS 쿼리가 VM1으로 전달될 수 있습니다.

다른 옵션들이 적합하지 않은 이유:

• A. 조건부 전달자: 기본 네트워크 연결 문제를 해결하지 못합니다.
• B, C. 서비스 엔드포인트: Azure 서비스 연결용이며, 커스텀 DNS 서비스와는 무관합니다.

피어링 설정 후 효과:

• VM2와 VM3가 VM1의 DNS 서버(10.0.0.4)에 접근 가능
• 모든 DNS 쿼리가 VM1을 통해 처리됨
• 중앙 집중식 DNS 관리 가능

📚 해설

Network Watcher IP Flow Verify 기능:

• 특정 IP와 포트 조합에 대한 네트워크 보안 그룹 규칙의 영향을 테스트합니다.
• 트래픽이 허용되는지 거부되는지, 어떤 규칙에 의해 결정되는지 확인할 수 있습니다.
• NSG 규칙의 우선순위와 효과를 실시간으로 검증합니다.

NSG 규칙 우선순위 분석:

• NSG 규칙은 우선순위 번호가 낮을수록 먼저 평가됩니다.
• 일치하는 규칙을 찾으면 이후 규칙은 평가하지 않습니다.
• Allow와 Deny 규칙이 모두 있을 때 우선순위에 따라 결과가 달라집니다.

각 테스트 결과 해석:

• 첫 번째 테스트와 두 번째 테스트의 차이점을 분석해야 합니다.
• 소스 IP, 대상 IP, 포트 번호의 변화가 결과에 미치는 영향을 확인합니다.
• NSG 규칙의 소스/대상 범위와 매칭되는지 검토해야 합니다.

📚 해설

요구사항 분석:

• 인터넷에서 RDP(포트 3389) 접근을 차단해야 합니다.
• 온-프레미스에서 RDP 접근은 허용해야 합니다.
• 포트 443을 통한 애플리케이션 접근은 계속 허용해야 합니다.

NSG 규칙 설계:

• 허용 규칙: 온-프레미스 IP 범위에서 포트 3389로의 접근 허용
• 거부 규칙: 인터넷(Any)에서 포트 3389로의 접근 거부
• 허용 규칙: 인터넷에서 포트 443으로의 접근 허용

다른 옵션들이 적합하지 않은 이유:

• A. 로컬 네트워크 게이트웨이: VPN 연결 설정과 관련되며, RDP 접근 제어와는 무관합니다.
• C. 공용 IP 제거: 애플리케이션에 대한 인터넷 접근도 차단되므로 요구사항에 맞지 않습니다.
• D. 주소 공간 수정: 네트워크 접근 제어 문제를 해결하지 못합니다.

NSG 규칙 우선순위:

1. 온-프레미스 → RDP 허용 (낮은 우선순위 번호)
2. 인터넷 → RDP 거부 (높은 우선순위 번호)
3. 인터넷 → HTTPS 허용

📚 해설

ASG(Application Security Group) 작동 방식:

• ASG는 네트워크 인터페이스에 연결되어 가상 머신을 논리적으로 그룹화합니다.
• VM1에 ASG1을 적용하려면 VM1의 네트워크 인터페이스(NIC1)를 ASG1에 연결해야 합니다.
• ASG는 NSG 규칙에서 소스나 대상으로 사용될 수 있습니다.

ASG 연결 과정:

1. Azure Portal에서 NIC1로 이동
2. "Application security groups" 설정 선택
3. ASG1을 NIC1에 연결
4. NSG 규칙에서 ASG1을 참조하여 트래픽 제어

다른 옵션들이 틀린 이유:

• B. ASG1 속성 수정: ASG 자체의 속성을 변경해도 VM과의 연결은 만들어지지 않습니다.
• C. NSG1 속성 수정: NSG는 ASG를 참조할 수 있지만, VM을 ASG에 멤버로 만들지는 않습니다.

ASG 사용의 장점:

• IP 주소 대신 논리적 그룹으로 보안 규칙 관리
• VM 추가/제거 시 NSG 규칙 수정 불필요
• 마이크로 세그멘테이션 구현 용이

📚 해설

ExpressRoute + VPN 동시 사용 요구사항:

• ExpressRoute와 VPN 게이트웨이가 같은 VNet에서 공존하려면 특정 조건이 필요합니다.
• ExpressRoute는 이미 게이트웨이 서브넷을 사용하고 있으므로 별도로 만들 필요가 없습니다.
• 비용 최소화를 위해 가장 저렴한 VPN 게이트웨이 SKU를 선택해야 합니다.

선택된 옵션들의 이유:

• A. 연결 만들기: VPN 게이트웨이와 로컬 네트워크 게이트웨이 간의 사이트 간 연결이 필요합니다.
• B. 로컬 사이트 VPN 게이트웨이: 온-프레미스 VPN 디바이스 정보를 정의하는 Azure 리소스입니다.
• C. VpnGw1 SKU: ExpressRoute와 공존할 수 있는 최소 VPN 게이트웨이 SKU입니다.

제외된 옵션들의 이유:

• D. 게이트웨이 서브넷: ExpressRoute 게이트웨이가 이미 사용 중이므로 별도로 만들 필요 없습니다.
• E. Basic SKU: ExpressRoute와 동시에 사용할 수 없으며, 장애 조치 기능이 제한적입니다.

비용 최소화 전략:

• VpnGw1은 ExpressRoute와 공존 가능한 최저가 SKU입니다.
• Route-based VPN을 지원하여 동적 라우팅이 가능합니다.

📚 해설

VNet 피어링 상태 이해:

• Connected: 피어링이 정상적으로 작동하는 상태
• Disconnected: 피어링이 비활성화되거나 문제가 있는 상태
• Initiated: 한쪽에서만 피어링을 설정한 상태

Box 1: vNET6만

• vNET5에서 패킷을 보낼 수 있는 대상을 확인해야 합니다.
• vNET1과의 피어링: Disconnected 상태
• vNET2와의 피어링: Disconnected 상태
• vNET6과의 피어링만 Connected 상태이므로 vNET6으로만 패킷 전송 가능합니다.

Box 2: peering1 삭제

• vNET1과의 피어링이 "Enabled but disconnected" 상태입니다.
• 이는 원격 피어링에 문제가 있음을 의미합니다.
• 문제를 해결하려면 기존 피어링을 삭제하고 다시 생성해야 합니다.

피어링 문제 해결 과정:

1. 문제가 있는 피어링 삭제
2. 원격 VNet에서도 해당 피어링 삭제
3. 양쪽에서 새로운 피어링 생성
4. Connected 상태 확인

📚 해설

Basic Load Balancer 특성:

• Basic Load Balancer는 단일 가용성 집합 또는 가상 머신 확장 집합 내의 VM을 지원합니다.
• 상태 프로브를 통해 백엔드 인스턴스의 상태를 모니터링합니다.
• 인바운드 연결만 관리하며, 아웃바운드 연결에는 직접 영향을 주지 않습니다.

1번 - 예: VM1과 VM2를 백엔드 풀에 추가할 수 있습니다

• VM1과 VM2가 같은 가용성 집합에 있다면 Basic Load Balancer에 추가 가능합니다.
• 두 VM이 같은 가상 네트워크에 있으므로 연결 가능합니다.

2번 - 예: 상태 프로브가 VM의 상태를 감지합니다

• Load Balancer의 상태 프로브는 백엔드 VM의 애플리케이션 상태를 모니터링합니다.
• 프로브가 실패하면 해당 VM으로 새로운 연결을 보내지 않습니다.
• 이를 통해 자동 장애 조치가 가능합니다.

3번 - 아니오: 아웃바운드 연결은 영향받지 않습니다

• 상태 프로브 실패는 인바운드 트래픽 분산에만 영향을 줍니다.
• VM에서 외부로 나가는 아웃바운드 연결은 계속 유지됩니다.
• Load Balancer는 인바운드 연결만 관리합니다.

📚 해설

Standard Load Balancer 특성:

• Standard Load Balancer는 기본적으로 보안이 강화된 모델을 사용합니다.
• 백엔드 풀의 VM들은 직접적인 인터넷 접근을 가져서는 안 됩니다.
• 모든 트래픽이 Load Balancer를 통해 흘러야 합니다.

Box 1: VM1에서 공용 IP 주소 제거

• 공용 Load Balancer는 VM들에 대한 아웃바운드 연결을 제공합니다.
• VM에 직접 연결된 공용 IP가 있으면 Load Balancer의 아웃바운드 규칙이 제대로 작동하지 않을 수 있습니다.
• 또한 보안상 모든 트래픽이 Load Balancer를 통해 흘러야 합니다.

Box 2: NSG 생성 및 구성

• Standard Load Balancer는 기본적으로 모든 트래픽을 거부합니다.
• 트래픽이 VM에 도달하려면 명시적으로 NSG에서 허용해야 합니다.
• NSG 없이는 Load Balancer를 통한 트래픽도 VM에 도달할 수 없습니다.

추가 구성 사항:

• VM1의 개인 IP를 정적으로 변경하는 것이 좋습니다.
• Load Balancer 백엔드 풀에 VM1 추가
• 상태 프로브 구성
• 부하 분산 규칙 생성

📚 해설

네트워크 인터페이스 위치 제약:

• 네트워크 인터페이스는 연결할 가상 네트워크와 같은 지역에 있어야 합니다.
• 표에서 가상 네트워크들의 위치를 확인해보면 East US에만 VNet이 있습니다.
• 다른 지역에는 가상 네트워크가 없으므로 네트워크 인터페이스를 생성할 수 없습니다.

Azure 네트워킹 지역 제약사항:

• 네트워크 인터페이스는 항상 가상 네트워크의 서브넷에 연결되어야 합니다.
• 가상 네트워크와 다른 지역에 네트워크 인터페이스를 만들 수 없습니다.
• 이는 네트워크 성능과 대기 시간을 최적화하기 위한 Azure의 설계 원칙입니다.

리소스 간 지역 의존성:

• VM → NIC: 같은 지역에 있어야 함
• NIC → VNet: 같은 지역에 있어야 함
• VNet → Subnet: 같은 VNet 내에 존재

표 분석 결과:

• East US에 VNet이 존재하므로 NIC1 생성 가능
• West Europe, North Europe에는 VNet이 없으므로 NIC1 생성 불가능

📚 해설

문제 상황 분석:

• VM1은 개인 DNS 영역(contoso.com)은 확인할 수 있습니다.
• 하지만 공용 DNS 영역(adatum.com)은 확인할 수 없습니다.
• 다른 인터넷 호스트는 확인할 수 있으므로 기본 DNS 연결은 정상입니다.

공용 DNS 영역 동작 원리:

• 공용 DNS 영역이 작동하려면 도메인 등록기관에서 Azure DNS의 네임서버로 위임되어야 합니다.
• adatum.com이 Azure DNS에서 호스팅되고 있지만, 등록기관에서 네임서버가 올바르게 설정되지 않은 것 같습니다.
• DNS 쿼리가 Azure DNS로 전달되지 않아서 확인할 수 없습니다.

다른 옵션들이 틀린 이유:

• A. DNS 접미사: 단순히 FQDN 완성을 도와줄 뿐, 이름 확인 자체를 해결하지 않습니다.
• C. SRV 레코드: 서비스 위치 정보용 레코드로, DNS 위임 문제와는 무관합니다.
• D. IAM 설정: 권한 문제가 아니라 DNS 위임 문제입니다.

해결 과정:

1. Azure DNS에서 adatum.com 영역의 네임서버 확인
2. 도메인 등록기관 포털에 접속
3. adatum.com 도메인의 네임서버를 Azure DNS 네임서버로 변경
4. DNS 전파 대기 (최대 48시간)

📚 해설

Azure Network Watcher 주요 기능:

• Network Watcher는 Azure 네트워크 모니터링 및 진단 서비스입니다.
• 다양한 네트워크 문제 해결 도구를 제공합니다.
• 실시간 네트워크 분석과 문제 진단이 가능합니다.

작업1: IP flow verify

• 특정 패킷이 VM에 도달할 수 있는지 NSG 규칙을 통해 확인합니다.
• 5-tuple(소스 IP, 대상 IP, 소스 포트, 대상 포트, 프로토콜) 정보를 입력하면 허용/거부 여부를 알려줍니다.
• 어떤 NSG 규칙이 트래픽을 차단하는지 정확히 식별할 수 있습니다.
• 인바운드와 아웃바운드 트래픽 모두 테스트 가능합니다.

작업2: Connection troubleshoot

• VM에서 다른 리소스로의 연결을 테스트합니다.
• 외부 호스트, FQDN, URI, IPv4 주소로의 아웃바운드 연결을 검증할 수 있습니다.
• 연결 실패 시 어느 지점에서 문제가 발생했는지 단계별로 분석합니다.
• 홉바이홉(hop-by-hop) 분석을 통해 네트워크 경로 추적이 가능합니다.

다른 Network Watcher 기능들:

• Connection monitor: 지속적인 연결 모니터링
• NSG flow logs: NSG를 통과하는 트래픽 로깅
• Topology: 네트워크 토폴로지 시각화
• Next hop: 라우팅 경로 확인

📚 해설

Azure DNS 설정 우선순위:

• NIC 수준 DNS 설정이 VNet 수준 DNS 설정보다 우선순위가 높습니다.
• NIC에 커스텀 DNS가 설정되면 VNet의 DNS 설정은 무시됩니다.
• Azure 기본 DNS가 설정된 NIC는 VNet의 DNS 설정을 상속받습니다.

1번 - 예: VM1이 VNet DNS 서버를 사용합니다

• VM1의 NIC는 "Azure 기본"으로 설정되어 있습니다.
• 따라서 VNET1에 구성된 DNS 서버(192.168.10.15, 193.77.134.10)를 사용합니다.
• VM1은 VNet 수준의 DNS 설정을 상속받습니다.

2번 - 아니오: VM2가 VNet DNS 서버를 사용하지 않습니다

• VM2의 NIC에 커스텀 DNS(8.8.8.8, 8.8.4.4)가 설정되어 있습니다.
• NIC 수준 설정이 우선하므로 VNet의 DNS 설정은 무시됩니다.
• VM2는 Google DNS 서버를 사용합니다.

3번 - 예: VM3이 VNet DNS 서버를 사용합니다

• VM3의 NIC도 "Azure 기본"으로 설정되어 있습니다.
• VM1과 마찬가지로 VNET1의 DNS 설정을 상속받습니다.
• 192.168.10.15와 193.77.134.10 DNS 서버를 사용합니다.

DNS 설정 우선순위 요약:

1. NIC 수준 커스텀 DNS (최고 우선순위)
2. VNet 수준 DNS (NIC가 기본값일 때)
3. Azure 제공 DNS (기본값)

📚 해설

Azure 리소스 이동 제약사항:

• 리소스 이동은 동일한 구독 내에서만 가능합니다.
• 일부 리소스는 지역 간 이동에 제약이 있습니다.
• 종속성이 있는 리소스들은 함께 이동해야 할 수 있습니다.

RG1에서 RG2로 이동 가능한 리소스:

• 가상 네트워크: 일반적으로 이동 가능하지만 종속 리소스를 고려해야 합니다.
• 스토리지 계정: 대부분의 경우 이동 가능합니다.
• 가상 머신: 네트워크 인터페이스, 디스크 등과 함께 이동해야 합니다.
• 공용 IP: 현재 사용 중이 아니라면 이동 가능합니다.

RG2에서 RG1으로 이동 가능한 리소스:

• RG2의 리소스 목록과 유형을 확인해야 합니다.
• 동일한 지역 내에서 이동하는 것이 일반적으로 더 안전합니다.
• 사용 중인 리소스는 이동 전에 중지해야 할 수 있습니다.

리소스 이동 시 고려사항:

• 종속성: VM과 연결된 디스크, NIC 등은 함께 이동
• 다운타임: 일부 리소스는 이동 중 서비스 중단
• 네트워킹: IP 주소나 DNS 설정 변경 필요할 수 있음
• 권한: 양쪽 리소스 그룹에 대한 적절한 권한 필요

📚 해설

Network Watcher IP Flow Verify 기능:

• 특정 IP와 포트 조합에 대한 네트워크 보안 그룹 규칙의 영향을 테스트합니다.
• 트래픽이 허용되는지 거부되는지, 어떤 규칙에 의해 결정되는지 확인할 수 있습니다.
• NSG 규칙의 우선순위와 효과를 실시간으로 검증합니다.

NSG 규칙 우선순위 분석:

• NSG 규칙은 우선순위 번호가 낮을수록 먼저 평가됩니다.
• 일치하는 규칙을 찾으면 이후 규칙은 평가하지 않습니다.
• Allow와 Deny 규칙이 모두 있을 때 우선순위에 따라 결과가 달라집니다.

각 테스트 결과 해석:

• 첫 번째 테스트와 두 번째 테스트의 차이점을 분석해야 합니다.
• 소스 IP, 대상 IP, 포트 번호의 변화가 결과에 미치는 영향을 확인합니다.
• NSG 규칙의 소스/대상 범위와 매칭되는지 검토해야 합니다.

📚 해설

요구사항 분석:

• 인터넷에서 RDP(포트 3389) 접근을 차단해야 합니다.
• 온-프레미스에서 RDP 접근은 허용해야 합니다.
• 포트 443을 통한 애플리케이션 접근은 계속 허용해야 합니다.

NSG 규칙 설계:

• 허용 규칙: 온-프레미스 IP 범위에서 포트 3389로의 접근 허용
• 거부 규칙: 인터넷(Any)에서 포트 3389로의 접근 거부
• 허용 규칙: 인터넷에서 포트 443으로의 접근 허용

다른 옵션들이 적합하지 않은 이유:

• A. 로컬 네트워크 게이트웨이: VPN 연결 설정과 관련되며, RDP 접근 제어와는 무관합니다.
• C. 공용 IP 제거: 애플리케이션에 대한 인터넷 접근도 차단되므로 요구사항에 맞지 않습니다.
• D. 주소 공간 수정: 네트워크 접근 제어 문제를 해결하지 못합니다.

NSG 규칙 우선순위:

1. 온-프레미스 → RDP 허용 (낮은 우선순위 번호)
2. 인터넷 → RDP 거부 (높은 우선순위 번호)
3. 인터넷 → HTTPS 허용

📚 해설

ASG(Application Security Group) 작동 방식:

• ASG는 네트워크 인터페이스에 연결되어 가상 머신을 논리적으로 그룹화합니다.
• VM1에 ASG1을 적용하려면 VM1의 네트워크 인터페이스(NIC1)를 ASG1에 연결해야 합니다.
• ASG는 NSG 규칙에서 소스나 대상으로 사용될 수 있습니다.

ASG 연결 과정:

1. Azure Portal에서 NIC1로 이동
2. "Application security groups" 설정 선택
3. ASG1을 NIC1에 연결
4. NSG 규칙에서 ASG1을 참조하여 트래픽 제어

다른 옵션들이 틀린 이유:

• B. ASG1 속성 수정: ASG 자체의 속성을 변경해도 VM과의 연결은 만들어지지 않습니다.
• C. NSG1 속성 수정: NSG는 ASG를 참조할 수 있지만, VM을 ASG에 멤버로 만들지는 않습니다.

ASG 사용의 장점:

• IP 주소 대신 논리적 그룹으로 보안 규칙 관리
• VM 추가/제거 시 NSG 규칙 수정 불필요
• 마이크로 세그멘테이션 구현 용이

📚 해설

ExpressRoute + VPN 동시 사용 요구사항:

• ExpressRoute와 VPN 게이트웨이가 같은 VNet에서 공존하려면 특정 조건이 필요합니다.
• ExpressRoute는 이미 게이트웨이 서브넷을 사용하고 있으므로 별도로 만들 필요가 없습니다.
• 비용 최소화를 위해 가장 저렴한 VPN 게이트웨이 SKU를 선택해야 합니다.

선택된 옵션들의 이유:

• A. 연결 만들기: VPN 게이트웨이와 로컬 네트워크 게이트웨이 간의 사이트 간 연결이 필요합니다.
• B. 로컬 사이트 VPN 게이트웨이: 온-프레미스 VPN 디바이스 정보를 정의하는 Azure 리소스입니다.
• C. VpnGw1 SKU: ExpressRoute와 공존할 수 있는 최소 VPN 게이트웨이 SKU입니다.

제외된 옵션들의 이유:

• D. 게이트웨이 서브넷: ExpressRoute 게이트웨이가 이미 사용 중이므로 별도로 만들 필요 없습니다.
• E. Basic SKU: ExpressRoute와 동시에 사용할 수 없으며, 장애 조치 기능이 제한적입니다.

비용 최소화 전략:

• VpnGw1은 ExpressRoute와 공존 가능한 최저가 SKU입니다.
• Route-based VPN을 지원하여 동적 라우팅이 가능합니다.

📚 해설

VNet 피어링 상태 이해:

• Connected: 피어링이 정상적으로 작동하는 상태
• Disconnected: 피어링이 비활성화되거나 문제가 있는 상태
• Initiated: 한쪽에서만 피어링을 설정한 상태

Box 1: vNET6만

• vNET5에서 패킷을 보낼 수 있는 대상을 확인해야 합니다.
• vNET1과의 피어링: Disconnected 상태
• vNET2와의 피어링: Disconnected 상태
• vNET6과의 피어링만 Connected 상태이므로 vNET6으로만 패킷 전송 가능합니다.

Box 2: peering1 삭제

• vNET1과의 피어링이 "Enabled but disconnected" 상태입니다.
• 이는 원격 피어링에 문제가 있음을 의미합니다.
• 문제를 해결하려면 기존 피어링을 삭제하고 다시 생성해야 합니다.

피어링 문제 해결 과정:

1. 문제가 있는 피어링 삭제
2. 원격 VNet에서도 해당 피어링 삭제
3. 양쪽에서 새로운 피어링 생성
4. Connected 상태 확인

📚 해설

Basic Load Balancer 특성:

• Basic Load Balancer는 단일 가용성 집합 또는 가상 머신 확장 집합 내의 VM을 지원합니다.
• 상태 프로브를 통해 백엔드 인스턴스의 상태를 모니터링합니다.
• 인바운드 연결만 관리하며, 아웃바운드 연결에는 직접 영향을 주지 않습니다.

1번 - 예: VM1과 VM2를 백엔드 풀에 추가할 수 있습니다

• VM1과 VM2가 같은 가용성 집합에 있다면 Basic Load Balancer에 추가 가능합니다.
• 두 VM이 같은 가상 네트워크에 있으므로 연결 가능합니다.

2번 - 예: 상태 프로브가 VM의 상태를 감지합니다

• Load Balancer의 상태 프로브는 백엔드 VM의 애플리케이션 상태를 모니터링합니다.
• 프로브가 실패하면 해당 VM으로 새로운 연결을 보내지 않습니다.
• 이를 통해 자동 장애 조치가 가능합니다.

3번 - 아니오: 아웃바운드 연결은 영향받지 않습니다

• 상태 프로브 실패는 인바운드 트래픽 분산에만 영향을 줍니다.
• VM에서 외부로 나가는 아웃바운드 연결은 계속 유지됩니다.
• Load Balancer는 인바운드 연결만 관리합니다.

📚 해설

Standard Load Balancer 특성:

• Standard Load Balancer는 기본적으로 보안이 강화된 모델을 사용합니다.
• 백엔드 풀의 VM들은 직접적인 인터넷 접근을 가져서는 안 됩니다.
• 모든 트래픽이 Load Balancer를 통해 흘러야 합니다.

Box 1: VM1에서 공용 IP 주소 제거

• 공용 Load Balancer는 VM들에 대한 아웃바운드 연결을 제공합니다.
• VM에 직접 연결된 공용 IP가 있으면 Load Balancer의 아웃바운드 규칙이 제대로 작동하지 않을 수 있습니다.
• 또한 보안상 모든 트래픽이 Load Balancer를 통해 흘러야 합니다.

Box 2: NSG 생성 및 구성

• Standard Load Balancer는 기본적으로 모든 트래픽을 거부합니다.
• 트래픽이 VM에 도달하려면 명시적으로 NSG에서 허용해야 합니다.
• NSG 없이는 Load Balancer를 통한 트래픽도 VM에 도달할 수 없습니다.

추가 구성 사항:

• VM1의 개인 IP를 정적으로 변경하는 것이 좋습니다.
• Load Balancer 백엔드 풀에 VM1 추가
• 상태 프로브 구성
• 부하 분산 규칙 생성

📚 해설

네트워크 인터페이스 위치 제약:

• 네트워크 인터페이스는 연결할 가상 네트워크와 같은 지역에 있어야 합니다.
• 표에서 가상 네트워크들의 위치를 확인해보면 East US에만 VNet이 있습니다.
• 다른 지역에는 가상 네트워크가 없으므로 네트워크 인터페이스를 생성할 수 없습니다.

Azure 네트워킹 지역 제약사항:

• 네트워크 인터페이스는 항상 가상 네트워크의 서브넷에 연결되어야 합니다.
• 가상 네트워크와 다른 지역에 네트워크 인터페이스를 만들 수 없습니다.
• 이는 네트워크 성능과 대기 시간을 최적화하기 위한 Azure의 설계 원칙입니다.

리소스 간 지역 의존성:

• VM → NIC: 같은 지역에 있어야 함
• NIC → VNet: 같은 지역에 있어야 함
• VNet → Subnet: 같은 VNet 내에 존재

표 분석 결과:

• East US에 VNet이 존재하므로 NIC1 생성 가능
• West Europe, North Europe에는 VNet이 없으므로 NIC1 생성 불가능

📚 해설

문제 상황 분석:

• VM1은 개인 DNS 영역(contoso.com)은 확인할 수 있습니다.
• 하지만 공용 DNS 영역(adatum.com)은 확인할 수 없습니다.
• 다른 인터넷 호스트는 확인할 수 있으므로 기본 DNS 연결은 정상입니다.

공용 DNS 영역 동작 원리:

• 공용 DNS 영역이 작동하려면 도메인 등록기관에서 Azure DNS의 네임서버로 위임되어야 합니다.
• adatum.com이 Azure DNS에서 호스팅되고 있지만, 등록기관에서 네임서버가 올바르게 설정되지 않은 것 같습니다.
• DNS 쿼리가 Azure DNS로 전달되지 않아서 확인할 수 없습니다.

다른 옵션들이 틀린 이유:

• A. DNS 접미사: 단순히 FQDN 완성을 도와줄 뿐, 이름 확인 자체를 해결하지 않습니다.
• C. SRV 레코드: 서비스 위치 정보용 레코드로, DNS 위임 문제와는 무관합니다.
• D. IAM 설정: 권한 문제가 아니라 DNS 위임 문제입니다.

해결 과정:

1. Azure DNS에서 adatum.com 영역의 네임서버 확인
2. 도메인 등록기관 포털에 접속
3. adatum.com 도메인의 네임서버를 Azure DNS 네임서버로 변경
4. DNS 전파 대기 (최대 48시간)

📚 해설

Azure Network Watcher 주요 기능:

• Network Watcher는 Azure 네트워크 모니터링 및 진단 서비스입니다.
• 다양한 네트워크 문제 해결 도구를 제공합니다.
• 실시간 네트워크 분석과 문제 진단이 가능합니다.

작업1: IP flow verify

• 특정 패킷이 VM에 도달할 수 있는지 NSG 규칙을 통해 확인합니다.
• 5-tuple(소스 IP, 대상 IP, 소스 포트, 대상 포트, 프로토콜) 정보를 입력하면 허용/거부 여부를 알려줍니다.
• 어떤 NSG 규칙이 트래픽을 차단하는지 정확히 식별할 수 있습니다.
• 인바운드와 아웃바운드 트래픽 모두 테스트 가능합니다.

작업2: Connection troubleshoot

• VM에서 다른 리소스로의 연결을 테스트합니다.
• 외부 호스트, FQDN, URI, IPv4 주소로의 아웃바운드 연결을 검증할 수 있습니다.
• 연결 실패 시 어느 지점에서 문제가 발생했는지 단계별로 분석합니다.
• 홉바이홉(hop-by-hop) 분석을 통해 네트워크 경로 추적이 가능합니다.

다른 Network Watcher 기능들:

• Connection monitor: 지속적인 연결 모니터링
• NSG flow logs: NSG를 통과하는 트래픽 로깅
• Topology: 네트워크 토폴로지 시각화
• Next hop: 라우팅 경로 확인

📚 해설

Azure DNS 설정 우선순위:

• NIC 수준 DNS 설정이 VNet 수준 DNS 설정보다 우선순위가 높습니다.
• NIC에 커스텀 DNS가 설정되면 VNet의 DNS 설정은 무시됩니다.
• Azure 기본 DNS가 설정된 NIC는 VNet의 DNS 설정을 상속받습니다.

1번 - 예: VM1이 VNet DNS 서버를 사용합니다

• VM1의 NIC는 "Azure 기본"으로 설정되어 있습니다.
• 따라서 VNET1에 구성된 DNS 서버(192.168.10.15, 193.77.134.10)를 사용합니다.
• VM1은 VNet 수준의 DNS 설정을 상속받습니다.

2번 - 아니오: VM2가 VNet DNS 서버를 사용하지 않습니다

• VM2의 NIC에 커스텀 DNS(8.8.8.8, 8.8.4.4)가 설정되어 있습니다.
• NIC 수준 설정이 우선하므로 VNet의 DNS 설정은 무시됩니다.
• VM2는 Google DNS 서버를 사용합니다.

3번 - 예: VM3이 VNet DNS 서버를 사용합니다

• VM3의 NIC도 "Azure 기본"으로 설정되어 있습니다.
• VM1과 마찬가지로 VNET1의 DNS 설정을 상속받습니다.
• 192.168.10.15와 193.77.134.10 DNS 서버를 사용합니다.

DNS 설정 우선순위 요약:

1. NIC 수준 커스텀 DNS (최고 우선순위)
2. VNet 수준 DNS (NIC가 기본값일 때)
3. Azure 제공 DNS (기본값)

📚 해설

Azure 리소스 이동 제약사항:

• 리소스 이동은 동일한 구독 내에서만 가능합니다.
• 일부 리소스는 지역 간 이동에 제약이 있습니다.
• 종속성이 있는 리소스들은 함께 이동해야 할 수 있습니다.

RG1에서 RG2로 이동 가능한 리소스:

• 가상 네트워크: 일반적으로 이동 가능하지만 종속 리소스를 고려해야 합니다.
• 스토리지 계정: 대부분의 경우 이동 가능합니다.
• 가상 머신: 네트워크 인터페이스, 디스크 등과 함께 이동해야 합니다.
• 공용 IP: 현재 사용 중이 아니라면 이동 가능합니다.

RG2에서 RG1으로 이동 가능한 리소스:

• RG2의 리소스 목록과 유형을 확인해야 합니다.
• 동일한 지역 내에서 이동하는 것이 일반적으로 더 안전합니다.
• 사용 중인 리소스는 이동 전에 중지해야 할 수 있습니다.

리소스 이동 시 고려사항:

• 종속성: VM과 연결된 디스크, NIC 등은 함께 이동
• 다운타임: 일부 리소스는 이동 중 서비스 중단
• 네트워킹: IP 주소나 DNS 설정 변경 필요할 수 있음
• 권한: 양쪽 리소스 그룹에 대한 적절한 권한 필요

📚 해설

문제 분석:

• Standard SKU Internal Load Balancer에 VM을 추가하는 상황
• VM1에 Basic SKU 공용 IP를 할당하는 솔루션 제시

왜 B가 정답인가:

• SKU 불일치: Standard Load Balancer는 Standard SKU 공용 IP만 지원
• Basic SKU 제한: Basic 공용 IP는 Standard Load Balancer와 호환되지 않음
• 내부 로드 밸런서: Internal Load Balancer는 공용 IP가 필수가 아님
• VM2 누락: VM2에 대한 처리가 없음

올바른 솔루션:

• Standard SKU 사용: Standard SKU 공용 IP 또는 공용 IP 없이 구성
• Network Security Group: 적절한 NSG 규칙 구성
• Backend Pool 구성: 두 VM 모두를 백엔드 풀에 추가
• Health Probe 설정: 상태 확인 프로브 구성

Standard vs Basic SKU 차이점:

• Standard: 99.99% SLA, Zone-redundant, 더 높은 처리량
• Basic: 99.9% SLA, Zone 지원 없음, 낮은 처리량
• 호환성: 같은 SKU끼리만 조합 가능

Internal Load Balancer 특징:

• 프라이빗 IP만 사용
• VNet 내부 트래픽 분산
• 온프레미스 연결 지원
• 공용 인터넷 액세스 없음

📚 해설

문제점 분석:

• VM2를 중지하면 백엔드 풀에 추가할 수 없습니다.
• Load Balancer의 백엔드 풀에는 실행 중인 VM들이 추가되어야 합니다.
• 중지된 VM은 네트워크 트래픽을 처리할 수 없습니다.

올바른 접근법:

• VM1과 VM2 모두 실행 상태여야 합니다.
• 두 VM이 같은 가상 네트워크에 있어야 합니다.
• 적절한 SKU의 리소스들을 사용해야 합니다.

Standard Load Balancer 백엔드 풀 요구사항:

• VM들이 같은 가상 네트워크에 위치
• VM들이 실행 중 상태
• 적절한 네트워크 보안 그룹 구성
• Standard SKU 리소스 사용 (필요시)

📚 해설

솔루션이 작동하는 이유:

• Standard SKU 공용 IP는 Standard Load Balancer와 호환됩니다.
• 각 VM에 Standard SKU 공용 IP를 연결하면 필요한 호환성이 확보됩니다.
• VM들이 같은 가상 네트워크(VNET1)에 있으므로 백엔드 풀에 추가 가능합니다.

Standard Load Balancer의 장점:

• 가용성 영역 지원
• 더 높은 성능과 처리량
• HA 포트 지원
• 아웃바운드 규칙 지원

Internal Load Balancer 고려사항:

• Internal Load Balancer이므로 인터넷에서 직접 접근할 수 없습니다.
• 공용 IP는 VM의 아웃바운드 연결에 사용됩니다.
• Load Balancer 자체는 개인 IP 주소를 사용합니다.

📚 해설

P2S VPN 인증서 기반 인증:

• 지점 간 VPN에서 인증서 기반 인증을 사용할 때, 각 클라이언트에는 유효한 클라이언트 인증서가 필요합니다.
• Computer1이 이미 연결되어 있다면 올바른 클라이언트 인증서를 가지고 있습니다.
• 이 인증서를 Computer2로 복사하면 같은 인증 자격을 사용할 수 있습니다.

인증서 내보내기/가져오기 과정:

1. Computer1에서 개인 키와 함께 클라이언트 인증서 내보내기 (.pfx 파일)
2. 안전한 방법으로 Computer2로 인증서 파일 전송
3. Computer2에 인증서 가져오기 (개인 인증서 저장소)
4. VPN 클라이언트 구성 적용
5. VPN 연결 테스트

보안 고려사항:

• 인증서 내보낼 때 강력한 암호 설정
• 안전한 채널을 통한 인증서 전송
• 불필요한 복사본 삭제
• 인증서 만료일 확인

대안 방법:

• 루트 인증서에서 새로운 클라이언트 인증서 생성
• 각 클라이언트마다 고유한 인증서 사용 (권장)

📚 해설

NSG 규칙 우선순위 이해:

• NSG 규칙은 우선순위 번호가 낮을수록 먼저 평가됩니다.
• HTTPS는 TCP 포트 443을 사용합니다.
• Rule5가 TCP 443을 다루는 규칙으로 보이며, 현재 거부 상태일 가능성이 높습니다.

선택된 솔루션 분석:

• Rule5를 "허용"으로 변경하여 HTTPS 트래픽을 허용합니다.
• 우선순위를 401로 설정하여 다른 거부 규칙보다 먼저 평가되도록 합니다.
• 이는 최소한의 변경으로 목표를 달성하는 효율적인 방법입니다.

다른 옵션들이 적합하지 않은 이유:

• A. Rule4 프로토콜 수정: Rule4가 어떤 규칙인지 명확하지 않고, 불필요한 변경일 수 있습니다.
• B. Rule1 삭제: 기존 보안 규칙을 삭제하는 것은 위험할 수 있습니다.
• D. 새 규칙 생성: 우선순위 501은 기존 거부 규칙보다 늦게 평가될 수 있어 효과가 없을 수 있습니다.

HTTPS 보안 고려사항:

• SSL/TLS 인증서 적절히 구성
• HTTP(포트 80)에서 HTTPS로 리디렉션 설정
• 보안 헤더 구성

📚 해설

리소스 공급자 등록 취소의 효과:

• Microsoft.ClassicNetwork 공급자 등록 취소는 클래식 네트워킹 리소스 생성을 차단합니다.
• 하지만 이것이 NSG 생성 시 자동으로 특정 규칙을 추가하는 기능과는 무관합니다.
• 최신 ARM 기반 NSG는 Microsoft.Network 공급자를 사용합니다.

목표 달성을 위한 올바른 방법:

• Azure Policy 사용: NSG 생성 시 특정 규칙을 강제하는 정책 정의
• ARM 템플릿: 표준화된 NSG 템플릿 사용
• PowerShell/CLI 스크립트: NSG 생성 후 자동으로 규칙 추가

Azure Policy 접근법 예시:

• DeployIfNotExists 효과를 사용하여 NSG에 특정 규칙 자동 배포
• Append 효과를 사용하여 NSG 생성 시 규칙 자동 추가
• Deny 효과를 사용하여 특정 규칙이 없는 NSG 생성 차단

클래식 vs ARM 네트워킹:

• 클래식: 레거시 배포 모델, 권장하지 않음
• ARM: 현재 권장되는 리소스 관리자 모델
• 클래식 네트워크 차단이 ARM 기반 NSG 자동 구성과는 별개 문제

📚 해설

VNet 피어링 조건 분석:

피어링 가능 조건:

• IP 주소 공간이 겹치지 않아야 함
• 서로 다른 구독 간 피어링 지원
• 서로 다른 지역 간 글로벌 피어링 지원

각 명제 분석:

명제 1: VNET1 ↔ VNETA - 아니오

• VNET1: 10.10.0.0/16
• VNETA: 10.10.128.0/17
• IP 충돌: 10.10.128.0/17은 10.10.0.0/16 범위에 포함됨
• 결과: 주소 공간 겹침으로 피어링 불가

명제 2: VNET2 ↔ VNETA - 예

• VNET2: 10.20.0.0/16
• VNETA: 10.10.128.0/17
• IP 분석: 완전히 다른 주소 범위
• 결과: 주소 공간 겹침 없음, 피어링 가능

명제 3: VNET3 ↔ VNETA - 아니오

• VNET3: 172.16.0.0/16
• VNETA: 10.10.128.0/17
• 위치 분석: VNET3은 West Europe, VNETA는 Canada Central
• IP 분석: 주소 공간은 겹치지 않음
• 결과: 실제로는 피어링 가능하지만, 문제에서는 아니오가 정답

IP 주소 범위 계산:

• 10.10.0.0/16: 10.10.0.0 ~ 10.10.255.255
• 10.10.128.0/17: 10.10.128.0 ~ 10.10.255.255
• 10.20.0.0/16: 10.20.0.0 ~ 10.20.255.255
• 172.16.0.0/16: 172.16.0.0 ~ 172.16.255.255

피어링 모범 사례:

• 주소 공간 사전 계획
• 서브넷 충돌 방지
• 네트워크 보안 그룹 고려
• 라우팅 테이블 검토

📚 해설

문제 분석:

• 131.107.100.50에서 TCP 포트 443 연결 실패
• Load Balancer 규칙은 정상
• VM2의 NSG 규칙에 문제가 있음

왜 B가 정답인가:

• 반대 효과: 연결을 허용해야 하는데 거부 규칙을 추가함
• 우선순위 문제: 64999는 매우 낮은 우선순위 (높은 숫자 = 낮은 우선순위)
• 논리적 오류: 트래픽을 차단하는 것이 아니라 허용해야 함
• 목표 불일치: 연결 성공이 목표인데 거부 규칙 생성

NSG 규칙 우선순위 이해:

• 우선순위 범위: 100-4096 (낮은 숫자 = 높은 우선순위)
• 100-110: 매우 높은 우선순위
• 1000-2000: 일반적인 사용자 정의 규칙
• 64999: 기본 거부 규칙과 유사한 매우 낮은 우선순위

올바른 솔루션 접근:

• 허용 규칙 생성: 131.107.100.50에서 포트 443으로의 인바운드 허용
• 적절한 우선순위: 기존 거부 규칙보다 높은 우선순위 설정
• Load Balancer 고려: AzureLoadBalancer 태그 허용
• 기존 규칙 검토: 차단하는 규칙 식별 및 수정

Load Balancer와 NSG 상호작용:

• Health Probe: AzureLoadBalancer 태그 허용 필요
• 클라이언트 IP: 원본 클라이언트 IP 보존
• 포트 매핑: 프론트엔드와 백엔드 포트 고려
• SNAT: 아웃바운드 연결 시 IP 변환

트러블슈팅 단계:

1. 현재 NSG 규칙 분석
2. 효과적인 보안 규칙 확인
3. Load Balancer 상태 프로브 검증
4. Network Watcher 활용
5. 적절한 허용 규칙 추가

📚 해설

규칙 삭제의 위험성:

• BlockAllOther443 규칙을 삭제하면 다른 원하지 않는 소스에서도 포트 443 접근이 가능해집니다.
• 이는 보안상 위험하며, 최소 권한 원칙에 어긋납니다.
• 특정 IP(131.107.100.50)만 허용하려는 목표에 맞지 않습니다.

더 나은 접근법:

• 131.107.100.50에 대한 특별한 허용 규칙을 높은 우선순위로 추가
• 기존 차단 규칙은 유지하여 보안 수준 유지
• 선택적 접근 허용으로 보안 위험 최소화

NSG 보안 모범 사례:

• 기본 거부: 명시적으로 허용되지 않은 모든 트래픽 차단
• 최소 권한: 필요한 최소한의 접근만 허용
• 우선순위 관리: 허용 규칙을 거부 규칙보다 높은 우선순위로 설정
• 소스 특정: 가능한 한 구체적인 소스 IP/범위 사용

올바른 규칙 설계:

• 우선순위 100: 131.107.100.50 → TCP 443 허용
• 우선순위 200: BlockAllOther443 (기존 규칙 유지)
• 이렇게 하면 특정 IP만 허용하고 나머지는 차단

📚 해설

규칙 우선순위만으로는 해결되지 않는 이유:

• Allow_131.107.100.50 규칙이 이미 존재한다면, 우선순위 변경만으로는 충분하지 않을 수 있습니다.
• 규칙의 포트, 프로토콜, 대상 등이 올바르게 구성되어 있는지 확인해야 합니다.
• 단순히 우선순위만 변경해서는 근본적인 연결 문제가 해결되지 않을 수 있습니다.

종합적인 문제 해결이 필요한 이유:

• 규칙의 소스, 대상, 포트, 프로토콜이 모두 정확해야 합니다.
• Load Balancer 상태 프로브 허용 여부 확인
• 다른 상위 우선순위 규칙에 의한 차단 가능성
• VM 내부 방화벽이나 애플리케이션 수준 차단

완전한 해결책 요소들:

• NSG 규칙: 올바른 허용 규칙과 우선순위
• Load Balancer: 건강 프로브와 부하 분산 규칙
• VM 구성: 내부 방화벽과 애플리케이션 설정
• 네트워크: 라우팅과 DNS 해결

디버깅 접근법:

1. NSG 플로우 로그 활성화하여 트래픽 흐름 확인
2. Network Watcher로 연결 테스트
3. VM 내부 네트워크 설정 확인
4. Load Balancer 상태 프로브 상태 확인

📚 해설

기본 제공 정책의 한계:

• Azure의 기본 제공 정책 정의 중에는 NSG 생성 시 특정 포트를 차단하는 규칙을 자동으로 추가하는 정책이 없습니다.
• 기본 제공 정책들은 주로 리소스 생성을 제한하거나 특정 설정을 강제하는 용도입니다.
• TCP 포트 8080을 특별히 차단하는 세부적인 기본 제공 정책은 존재하지 않습니다.

올바른 솔루션:

• 사용자 지정 정책 정의: 특정 요구사항에 맞는 커스텀 정책 작성
• DeployIfNotExists 효과: NSG 생성 후 자동으로 규칙 배포
• Append 효과: NSG 생성 시 자동으로 속성 추가

사용자 지정 정책 예시:

• 조건: NSG가 생성되었고 TCP 8080 차단 규칙이 없는 경우
• 효과: 자동으로 TCP 8080을 차단하는 규칙 추가
• 범위: 가상 네트워크 간 트래픽

Azure Policy 효과 유형:

• Deny: 리소스 생성 차단
• Audit: 규정 준수 상태 기록
• Append: 리소스에 속성 추가
• DeployIfNotExists: 조건부 리소스 배포
• Modify: 기존 리소스 속성 수정

📚 해설

온-프레미스에서 Pod IP 직접 접근이 필요한 이유:

• 온-프레미스 클라이언트가 Pod의 IP 주소를 직접 사용해야 합니다.
• 이를 위해서는 Pod IP가 VNet 주소 공간 내에서 라우팅 가능해야 합니다.
• Azure CNI만이 Pod에 VNet 서브넷의 IP 주소를 직접 할당합니다.

Azure CNI의 특징:

• Pod마다 VNet 서브넷에서 IP 주소 할당
• Pod IP가 VNet 내에서 직접 라우팅 가능
• 온-프레미스에서 VPN/ExpressRoute를 통해 Pod에 직접 접근 가능
• 더 복잡한 네트워킹 시나리오 지원

다른 옵션들이 적합하지 않은 이유:

• A. kubenet: Pod IP가 클러스터 내부에서만 라우팅 가능, 외부 직접 접근 불가
• C. 하이브리드 연결: App Service용 기능으로 AKS와 무관
• D. Azure Private Link: 서비스 엔드포인트 연결용으로 Pod IP 직접 접근과는 다름

kubenet vs Azure CNI 비교:

• kubenet: NAT 사용, IP 절약, 외부 직접 접근 제한
• Azure CNI: 직접 IP 할당, 더 많은 IP 사용, 외부 직접 접근 가능

네트워크 정책 고려사항:

• Azure CNI는 Calico, Azure Network Policies 지원
• 온-프레미스 방화벽에서 Pod IP 범위 허용 필요
• VNet 서브넷 크기 계획 중요 (Pod 수 * Node 수)

📚 해설

Standard Load Balancer의 보안 모델:

• Standard Load Balancer는 기본적으로 "secure by default" 모델을 사용합니다.
• 백엔드 풀의 VM들이 직접적인 인터넷 연결을 가지면 보안 위험이 증가합니다.
• Internal Load Balancer의 경우 VM들에 공용 IP가 필요하지 않습니다.

공용 IP 제거의 효과:

• VM2에서 공용 IP를 제거하면 Standard Load Balancer 요구사항에 부합합니다.
• 모든 인바운드 트래픽이 Load Balancer를 통해 제어됩니다.
• 아웃바운드 연결은 Load Balancer의 아웃바운드 규칙으로 관리됩니다.

Internal Load Balancer 특성:

• VNet 내부 트래픽만 처리
• 개인 IP 주소 사용
• 인터넷 직접 접근 차단
• 높은 보안 수준 제공

VM 연결 요구사항:

• 같은 가상 네트워크(VNET1)에 위치
• 적절한 NSG 규칙 구성
• 공용 IP 제거 (Internal LB의 경우)
• Load Balancer 프로브 허용

아웃바운드 연결 고려사항:

• 공용 IP 제거 후 인터넷 접근이 필요하면 NAT Gateway 또는 다른 솔루션 필요
• Load Balancer 아웃바운드 규칙으로 관리 가능

📚 해설

문제 분석:

• VM1에서 VM2로의 연결 성능 문제
• 평균 왕복 시간(RTT) 측정이 필요
• 지속적인 모니터링이 요구됨

왜 C가 정답인가:

• RTT 측정: Connection monitor는 평균 RTT를 포함한 상세한 네트워크 성능 메트릭 제공
• 지속적 모니터링: 시간에 따른 연결 상태 및 성능 추적
• 히스토리 데이터: 성능 트렌드 분석 가능
• 알림 설정: 성능 임계값 초과 시 자동 알림

Connection Monitor 주요 기능:

• 연결 메트릭: RTT, 패킷 손실률, 연결 성공률
• 토폴로지 맵: 네트워크 경로 시각화
• 임계값 설정: 성능 기준 정의 및 알림
• 다중 프로토콜: TCP, HTTP, ICMP 지원
• 정기 테스트: 설정 가능한 간격으로 자동 테스트

다른 옵션들이 틀린 이유:

A. IP flow verify:

• 패킷 허용/차단 여부만 확인
• RTT나 성능 측정 기능 없음
• 일회성 테스트만 가능

B. Connection troubleshoot:

• 특정 시점의 연결 상태만 확인
• 지속적인 모니터링 불가
• RTT 평균값 제공하지 않음

D. NSG flow logs:

• 트래픽 흐름 로깅만 수행
• 성능 메트릭 측정 불가
• RTT 정보 제공하지 않음

Connection Monitor 구성 단계:

1. Network Watcher 리소스 활성화
2. Connection Monitor 생성
3. 소스(VM1)와 대상(VM2) 지정
4. 테스트 구성 (프로토콜, 포트, 빈도)
5. 임계값 및 알림 설정
6. 모니터링 시작 및 결과 분석

성능 문제 해결 흐름:

• 1단계: Connection Monitor로 RTT 측정
• 2단계: 네트워크 경로 분석
• 3단계: 병목 지점 식별
• 4단계: NSG/UDR 규칙 최적화
• 5단계: VM 성능 검토

📚 해설

사용자 지정 Azure Policy가 올바른 솔루션인 이유:

• 사용자 지정 정책을 통해 NSG 생성 시 특정 규칙을 자동으로 추가할 수 있습니다.
• DeployIfNotExists 효과를 사용하여 조건부 리소스 배포가 가능합니다.
• 구독 수준에서 할당하면 모든 NSG 생성에 적용됩니다.

사용자 지정 정책 설계:

• 조건: NSG가 생성되고 TCP 포트 8080 차단 규칙이 없는 경우
• 효과: DeployIfNotExists로 차단 규칙 자동 생성
• 대상: VirtualNetwork 소스에서 VirtualNetwork 대상으로의 트래픽
• 포트: TCP 8080
• 작업: Deny

정책 JSON 구조 예시:

• policyRule.if: NSG 리소스 유형과 규칙 부재 조건
• policyRule.then.effect: "DeployIfNotExists"
• policyRule.then.details: ARM 템플릿으로 규칙 배포

구현 과정:

1. Azure Policy 정의 작성 (JSON)
2. 구독 수준에서 정책 할당
3. 관리되는 ID 권한 부여
4. 규정 준수 평가 및 수정

Azure Policy 효과들:

• DeployIfNotExists: 조건 만족 시 리소스 자동 배포
• Append: 리소스에 속성 자동 추가
• Modify: 기존 리소스 속성 수정

📚 해설

Load Balancer SKU별 제약사항:

• Basic과 Standard Load Balancer는 서로 다른 제약 조건을 가집니다.
• 각 SKU에 맞는 VM 배치 전략이 필요합니다.
• 네트워킹 리소스의 SKU 호환성을 고려해야 합니다.

Box 1: Basic Load Balancer

• Basic Load Balancer는 매우 제한적입니다.
• VM들이 같은 가용성 집합 또는 가상 머신 확장 집합에 있어야 합니다.
• 단일 머신도 지원하지만, 여러 VM의 경우 가용성 집합 필수
• 가용성 영역 지원하지 않음

Box 2: Standard Load Balancer

• Standard Load Balancer는 훨씬 유연합니다.
• VM들이 같은 가상 네트워크에 있기만 하면 됩니다.
• 가용성 집합, 가상 머신 확장 집합, 단일 머신의 혼합 지원
• 가용성 영역 간 로드 밸런싱 지원

SKU 비교 요약:

• Basic: 제한적, 가용성 집합 필수, 무료
• Standard: 유연함, VNet 수준 지원, 유료, 더 많은 기능

설계 고려사항:

• Basic LB: 3개 VM을 하나의 가용성 집합에 배치
• Standard LB: 3개 VM을 동일 VNet 내 자유롭게 배치
• Standard LB 사용 시 가용성 영역 활용 권장

📚 해설

고가용성 S2S VPN 아키텍처:

• 2분 미만의 장애 조치 시간을 달성하려면 이중화 구성이 필요합니다.
• Azure VPN Gateway의 액티브-액티브 구성과 온-프레미스 이중화가 필요합니다.
• BGP 라우팅을 통한 자동 장애 조치 구성

공용 IP 주소: 4개

• Azure VPN Gateway 액티브-액티브 구성: 2개 공용 IP
• 온-프레미스 VPN 디바이스 2개: 각각 1개씩 공용 IP
• 총 4개의 공용 IP 주소 필요

가상 네트워크 게이트웨이: 1개

• 하나의 VPN Gateway를 액티브-액티브 모드로 구성
• 내부적으로 2개의 게이트웨이 인스턴스가 생성됨
• 각 인스턴스가 별도의 공용 IP 사용
• 자동 장애 조치 지원

로컬 네트워크 게이트웨이: 2개

• 온-프레미스 VPN 디바이스별로 1개씩
• 각각 다른 공용 IP 주소와 BGP 설정
• 이중화된 연결 경로 제공

고가용성 요구사항 충족:

• Azure 측: 액티브-액티브 VPN Gateway
• 온-프레미스 측: 2개 VPN 디바이스
• 라우팅: BGP로 자동 장애 조치
• 연결: 총 4개 터널 (2x2 매트릭스)

📚 해설

Azure 내부 DNS 해석:

• Azure 가상 네트워크 내에서 VM의 개인 IP 주소에 대한 역방향 DNS 조회는 internal.cloudapp.net 도메인을 사용합니다.
• VM1의 개인 IP 10.0.0.4에 대한 역방향 조회는 VM 이름과 internal 도메인을 결합합니다.
• 이는 Azure의 기본 내부 DNS 명명 규칙입니다.

Azure DNS 명명 규칙:

• 개인 IP 역방향 DNS: {vmname}.internal.cloudapp.net
• 공용 IP 역방향 DNS: {vmname}.{region}.cloudapp.azure.com
• 내부 전용: VNet 내에서만 해석 가능

다른 옵션들이 틀린 이유:

• A. core.windows.net: Azure 서비스 엔드포인트용 도메인
• B. azure.com: Azure 포털 및 관리 서비스용
• C. westeurope.cloudapp.azure.com: 공용 IP용 도메인 (개인 IP가 아님)

역방향 DNS 동작:

• 10.0.0.4 → vm1.internal.cloudapp.net
• VNet 내부에서만 유효
• Azure DNS 서비스에 의해 자동 관리
• 커스텀 설정 불가능

네트워크 위치별 DNS 해석:

• 같은 VNet: internal.cloudapp.net 사용
• 인터넷: 공용 DNS 이름 (있는 경우)
• 온-프레미스: VPN/ExpressRoute 통해 internal 도메인 해석 가능

📚 해설

AzureLoadBalancer 서비스 태그의 역할:

• AzureLoadBalancer는 Azure Load Balancer의 상태 프로브 트래픽을 식별하는 서비스 태그입니다.
• 이는 실제 사용자 트래픽이 아닌 Load Balancer의 내부 상태 확인 트래픽입니다.
• 131.107.100.50에서 오는 실제 클라이언트 트래픽과는 별개입니다.

문제점 분석:

• 클라이언트(131.107.100.50)의 트래픽은 AzureLoadBalancer 태그에 포함되지 않습니다.
• AzureLoadBalancer 규칙만으로는 실제 사용자 연결 문제가 해결되지 않습니다.
• 클라이언트 IP에서 VM으로의 직접 경로가 필요합니다.

Load Balancer 트래픽 흐름:

1. 클라이언트 → Load Balancer (공용 IP)
2. Load Balancer → 백엔드 VM (DNAT)
3. VM → 클라이언트 (직접 응답 또는 Load Balancer 경유)

올바른 솔루션:

• 특정 클라이언트 IP(131.107.100.50)를 허용하는 규칙
• 또는 Load Balancer의 프런트엔드 IP에서 오는 트래픽 허용
• 적절한 우선순위로 기존 거부 규칙보다 먼저 평가되도록 설정

서비스 태그별 용도:

• AzureLoadBalancer: LB 상태 프로브
• Internet: 인터넷 트래픽
• VirtualNetwork: VNet 내부 트래픽
• 특정 IP: 정확한 소스 지정

📚 해설

정책 기반 vs 경로 기반 VPN Gateway:

• 정책 기반 (PolicyBased): 사이트 간 VPN만 지원, P2S 지원 안 함
• 경로 기반 (RouteBased): 사이트 간 VPN과 지점 간 VPN 모두 지원
• 지점 간 VPN을 사용하려면 반드시 경로 기반 게이트웨이가 필요합니다.

선택된 작업들의 이유:

• E. GW1 삭제: 기존 정책 기반 게이트웨이를 제거해야 함
• C. 경로 기반 게이트웨이 생성: P2S VPN을 지원하는 새 게이트웨이 필요

VPN Gateway 유형 변경 불가:

• 기존 VPN Gateway의 유형을 정책 기반에서 경로 기반으로 직접 변경할 수 없습니다.
• 반드시 기존 게이트웨이를 삭제하고 새로 생성해야 합니다.
• 이 과정에서 기존 사이트 간 VPN 연결이 일시적으로 중단됩니다.

다른 옵션들이 틀린 이유:

• A. 서비스 엔드포인트: Azure 서비스 연결용, P2S VPN과 무관
• B. GW1 재설정: 게이트웨이 유형은 변경되지 않음
• D. 연결 추가: 정책 기반 GW는 P2S 연결 지원 안 함
• F. 공용 IP 주소 공간: P2S VPN과 무관한 개념

P2S VPN 구성 요소:

• 경로 기반 VPN Gateway (필수)
• 클라이언트 인증서 또는 Azure AD 인증
• VPN 클라이언트 구성 패키지
• 적절한 주소 풀 설정

131.107.100.50에서 TCP 포트 443을 통해 App1에 대한 연결을 성공적으로 설정할 수 있도록 해야 합니다.
솔루션: 131.107.100.50 소스의 모든 트래픽을 거부하고 비용이 64999인 인바운드 보안 규칙을 만듭니다.
이것이 목표를 충족합니까?