Practice Test #2

1개의 NSG를 생성합니다. 모든 VM이 동일한 subnet에 있으므로, subnet에 단일 NSG를 연결하여 해당 subnet의 모든 NIC/VM에 대한 트래픽을 제어할 수 있습니다. 이렇게 하면 NSG 수를 최소화할 수 있으며, 이는 일반적인 시험 패턴입니다: subnet별로 서로 다른 정책이 필요하거나 서로 다른 NIC에 서로 다른 NSG를 적용해야 하는 경우가 아니라면 하나의 subnet-level NSG를 사용합니다. 여기서는 하나의 NSG 내부에서 ASG 기반 규칙으로 요구 사항을 표현할 수 있습니다(Internet 액세스를 위한 AppGroup12 대상 및 VM4 제한을 위한 AppGroup4 대상). 2~4개의 NSG를 생성해도 필요한 규칙 수는 줄어들지 않으며 관리 오버헤드만 증가하므로, “NSG 수를 최소화”해야 한다는 요구 사항을 위반합니다.

단일 NSG에 3개의 보안 규칙(inbound)을 생성합니다. 1) 필요한 포트에서 Internet -> AppGroup12 (VM1 및 VM2) 허용(포트는 지정되지 않았으므로, 개념적으로는 “트래픽”). 이는 다른 VM은 기본 DenyAllInBound에 의해 계속 차단되므로 “Internet에서 VM1 및 VM2로만 트래픽 허용”을 충족합니다. 2) AppGroup3 (VM3) -> AppGroup4 (VM4) 허용. 이렇게 하면 VM3가 VM4에 연결할 수 있습니다. 3) VirtualNetwork -> AppGroup4 거부. 기본 AllowVnetInBound가 그렇지 않으면 VM1/VM2(및 다른 모든 VNet 소스)가 VM4에 연결하도록 허용하기 때문에 이것이 필요합니다. VM3는 계속 허용되고 다른 모든 VNet 소스는 거부되도록 규칙 (2)를 규칙 (3)보다 더 높은 우선순위(더 낮은 숫자)에 배치합니다. 규칙이 2개뿐이면 기본 허용 때문에 VM3를 허용하면서 다른 모든 VNet 소스를 차단하는 것을 동시에 수행할 수 없습니다.

올바른 effect는 DeployIfNotExists입니다. 요구 사항은 모든 VM에 특정 antimalware VM extension이 설치되도록 보장하는 것이기 때문입니다. DeployIfNotExists는 규정 준수를 평가하고, 필요한 관련 리소스/구성(이 경우 VM extension)이 없을 때 포함된 ARM template를 통해 이를 자동으로 배포할 수 있습니다. 이는 VM extension, diagnostic settings 및 기타 “구성되어 있어야 하는” 요구 사항을 적용하는 표준 패턴입니다. 왜 Deny가 아닌가요? Deny는 조건을 충족하지 않는 생성 또는 업데이트 작업만 방지할 뿐이며, extension 없이 이미 배포된 기존 VM을 수정하지 못합니다. 또한 신중하게 범위를 지정하지 않으면 정상적인 VM 작업을 방해할 수도 있습니다. 왜 Append가 아닌가요? Append(및 이를 대체하는 최신 방식인 Modify)는 생성/업데이트되는 리소스에 속성을 추가하거나 변경하는 데 사용되지만, Microsoft.Compute/virtualMachines/extensions와 같은 별도의 child resource를 안정적으로 생성할 수는 없습니다. 따라서 DeployIfNotExists만이 부재를 감지하고 extension을 설치하여 규정 준수 상태에 도달할 수 있는 유일한 옵션입니다.

DeployIfNotExists policy에서 policy rule의 details 섹션에는 관련 리소스가 이미 존재하고 규정을 준수하는지 확인하기 위한 existenceCondition이 포함됩니다. VM extension 시나리오에서는 이 조건이 virtual machine에 필요한 antimalware extension이 있는지 확인합니다. Template은 나중에 deployment definition 내부에서 수정 조치를 위해 배포할 내용을 설명하는 데 사용되며, resources는 ARM template 내의 섹션일 뿐 여기서 묻는 policy 필드는 아닙니다.

아니요. Ping은 ICMP를 사용하며, NSG 규칙은 명시적인 allow와 일치하는 트래픽만 허용합니다(또는 더 높은 우선순위의 deny/limit가 없으면 기본 “AllowVNetInBound”). 일반적인 ASG 기반 web tier 설계에서는 VM4(또는 해당 subnet)의 custom inbound rule이 특정 source ASG(예: “App” ASG의 VM1/VM2)에서 VM4가 포함된 destination ASG(“Web”)로의 TCP/80(그리고 경우에 따라 TCP/443)을 허용합니다. inbound 규칙이 TCP 80/443으로 제한되어 있으면 ICMP는 포함되지 않으므로, VM1은 VM4로 ping을 성공적으로 보낼 수 없습니다. 또한 web port를 제외한 intra-VNet 트래픽에 대해 더 높은 우선순위의 deny rule이 있다면, 해당 deny가 기본 AllowVNetInBound를 재정의합니다. 따라서 VM1이 web service에 도달하도록 허용될 수 있더라도, ICMP echo request는 차단되며 ping은 실패합니다.

아니요. sub-question 0와 동일한 이유가 적용됩니다: ICMP는 TCP/UDP가 아니며, NSG 규칙이 web server ASG에 web traffic만 허용하도록 작성된 경우 일반적으로 허용되지 않습니다. VM2가 VM4와 동일한 subnet/VNet에 있더라도, VM4의 ASG에 대해 TCP 80(및/또는 443)만 허용하는 custom inbound rule set은 ICMP와 일치하지 않으므로, 해당 트래픽은 deny로 처리됩니다(명시적인 deny rule이 있거나, allow rules 평가 후 기본 DenyAllInBound가 적용됨). 시험 팁: '같은 VNet이면 ping이 된다'고 가정하지 마세요. NSG는 ICMP를 차단할 수 있으며, ASG 기반 segmentation은 lateral movement 위험을 줄이기 위해 필요하지 않은 protocol을 의도적으로 차단하는 경우가 많습니다.

예. VM4의 web server에 연결한다는 것은 VM1에서 VM4로의 TCP port 80 (HTTP)이 허용된다는 의미입니다. ASG를 사용하는 경우, 이는 일반적으로 VM4의 NIC/subnet에 대한 inbound NSG rule로 구현되며, Source = VM1을 포함하는 ASG(예: “AppServers” 또는 “Mgmt”), Destination = VM4를 포함하는 ASG(“WebServers”), Service = TCP/80, Action = Allow로 설정되고, deny rules보다 높은 priority를 가집니다. NSG 처리는 흐름을 허용하려면 VM1의 outbound와 VM4의 inbound가 모두 허용되어야 하지만, outbound는 명시적으로 deny되지 않는 한 일반적으로 기본적으로 허용됩니다(AllowVNetOutBound). 따라서 결정적인 제어는 VM4에 대한 TCP/80 inbound allow입니다. 그러므로 ping (ICMP)이 차단되어 있더라도 VM1은 HTTP connection을 설정할 수 있습니다.