Practice Test #2

올바른 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을 설정할 수 있습니다.

User1은 Policy1과 Policy2를 모두 받으므로, Label1과 Label2 모두 평가에 사용할 수 있습니다. Word 문서 텍스트 "Black and White"에서 Label1은 대/소문자 구분이 켜진 상태로 "White"를 찾기 때문에 일치하며, 해당 대/소문자가 정확히 존재합니다. Label2도 대/소문자 구분이 꺼진 상태로 "Black"을 찾기 때문에 일치하므로, "Black"도 감지됩니다. 따라서 이 hotspot의 올바른 식별은 Label1 및 Label2이며, 다른 옵션은 두 조건이 모두 충족되므로 올바르지 않고, "레이블 없음"은 지원되는 Office 파일 형식에 대해 명백히 틀립니다.

이 파일은 Microsoft Notepad에서 생성되며, 일반 텍스트(.txt) 파일을 생성합니다. 콘텐츠 검사를 기반으로 하는 AIP 자동 레이블 지정은 주로 지원되는 Office 파일 형식(Word, Excel, PowerPoint) 및 일부 기타 지원 형식에 대해 설계되었습니다. Notepad로 생성된 일반 텍스트 파일은 동일한 방식으로 콘텐츠를 스캔하여 자동으로 레이블이 지정되지 않습니다. 텍스트 “Black or white”에 두 대상 단어가 모두 포함되어 있더라도, 이 Notepad 파일 형식에서는 자동 레이블 지정이 트리거되지 않습니다. 또한 콘텐츠가 평가된다고 하더라도, Label1은 “White”(대문자 W)에 대해 대소문자를 구분하는 일치를 요구합니다. 텍스트에는 소문자 “white”가 포함되어 있으므로 Label1은 일치하지 않습니다. Label2는 대소문자를 구분하지 않으므로 “Black”과 일치하지만, 핵심적인 문제는 Notepad 파일에는 콘텐츠 조건을 통한 자동 레이블 지정이 적용되지 않는다는 점입니다. 따라서 해당 파일에는 어떤 레이블도 할당되지 않습니다. 다른 선택지가 틀린 이유: Label1만은 대소문자 구분(“white” != “White”) 및 파일 형식 때문에 틀렸습니다. Label2만은 Notepad 파일에는 자동 레이블 지정이 적용되지 않기 때문에 틀렸습니다. Label1 및 Label2도 한 번에 하나의 레이블만 적용할 수 있고 자동 레이블 지정도 발생하지 않으므로 불가능합니다.

아니요. 다른 VM에서 VM의 public IP로 ping하는 것은 Internet-facing endpoint로 향하는 트래픽으로 처리됩니다. ping이 성공하려면 대상 VM(VM2)에 source(또는 경로에 따라 Internet/AzureLoadBalancer)로부터의 ICMP를 허용하는 inbound rule이 있어야 합니다. 대부분의 보안 구성에서는(그리고 AZ-500 문제에서 흔히 그렇듯이) NSG에 ICMP inbound를 허용하는 rule이 포함되어 있지 않으므로, 기본 NSG 동작(implicit deny)에 의해 차단됩니다. VM1이 outbound ICMP를 보낼 수 있더라도, inbound 경로가 명시적으로 허용되지 않으면 return traffic은 허용되지 않습니다. 또한 많은 enterprise 설계에서는 outbound를 firewall/NVA를 통해 강제하고 public endpoint에 대한 ICMP를 거부합니다. 따라서 VM1은 VM2의 public IP를 성공적으로 ping할 수 없습니다. “예”가 틀린 이유: public IP는 기본적으로 도달 가능하다고 가정하기 때문입니다. Azure에서는 NSG rule이 이를 명시적으로 허용하지 않는 한 public IP를 통한 VM으로의 inbound는 열려 있지 않습니다.

예. VM1에서 VM3의 private IP로 ping하는 것은 private east-west traffic입니다. VM1과 VM3가 동일한 VNet에 있거나(또는 traffic을 허용하는 peering이 구성된 VNet들에 있는 경우), Azure system route가 자동으로 connectivity를 제공합니다. 많은 AZ-500 시나리오에서 subnet/VNet 내부의 private VM-to-VM traffic은 NSG가 이를 명시적으로 deny하지 않는 한 허용됩니다. NSG는 stateful이므로, VM1에서 VM3로의 outbound ICMP가 허용되면 return traffic도 자동으로 허용됩니다. “아니요”가 특정 경우에만 정답이 되는 이유: ICMP를 deny하는 NSG rule(또는 모든 intra-VNet traffic을 deny하는 rule)이 있거나, traffic을 ICMP를 차단하는 firewall/NVA를 통해 강제로 전달하는 UDR이 있거나, private routing relationship이 없는 경우(예: peering/VPN/ER 없이 서로 다른 VNet). 이러한 명시적인 차단이 없다면 private IP ping은 성공합니다.

아니요. 이러한 문제에서 VM5의 private IP는 일반적으로 routing은 존재하지만 security control이 east-west traffic을 차단하는 다른 network segment를 나타내는 데 사용됩니다(예: NSG deny rule로 보호되는 다른 subnet, 또는 ICMP를 허용하지 않는 application/network rule set이 있는 Azure Firewall을 통해 강제로 전달되는 traffic). VNet이 peered되어 있더라도, 어느 subnet/NIC의 NSG든 traffic을 deny할 수 있으며, UDR은 traffic을 이를 차단하는 firewall/NVA로 유도할 수 있습니다. ping은 ICMP를 사용하므로, hardened environment에서는 명시적으로 허용되지 않는 경우가 많습니다. “예”가 틀린 이유: private IP에 도달 가능하다는 것이 permission을 의미한다고 가정하기 때문입니다. Azure에서는 reachability(routes)와 permission(NSG/Firewall policy)은 별개입니다. private connectivity는 여전히 NSG rule 또는 centralized inspection/segmentation control에 의해 deny될 수 있습니다.