Microsoft AZ-500

예. Microsoft.Compute/virtualMachines(종종 “virtualMachines”로 표시됨)를 포함하는 허용되지 않는 resource types 목록을 지정하는 RG1 범위의 policy assignment는 RG1 내에서 해당 resource type에 대한 create 작업을 거부합니다. Deny effect가 있는 Azure Policy는 resource를 create 또는 update하려는 요청이 있을 때 Azure Resource Manager에 의해 평가됩니다. 범위가 RG1이므로 제한은 RG1의 resource에만 적용됩니다. 이것은 기존 VM을 소급하여 삭제하거나 비활성화하지는 않습니다. 대신 policy를 위반하는 향후 create/update 요청을 방지합니다. 또한 해당 작업이 ARM write로 구현되고 policy 조건에 의해 명시적으로 거부되지 않는 한 runtime 작업을 자동으로 차단하지도 않습니다(대부분의 “허용되지 않는 resource types” policy는 resource 생성에 중점을 둡니다). 따라서 virtualMachines가 RG1 범위에서 허용되지 않는다는 설명은 참입니다.

예. Microsoft.Compute/virtualMachines를 포함하는 Allowed resource types를 지정하는 RG2 범위의 policy assignment는 RG2에서 create/update 작업에 대해 나열된 유형만 허용함을 의미합니다. virtualMachines가 허용 목록에 있으면, 해당 policy에 의해 VM 생성이 허용됩니다(다른 policy assignments가 이를 deny하지 않는다고 가정). Azure Policy에서 “Allowed resource types”는 일반적으로 목록에 없는 모든 리소스 유형에 대해 Deny effect로 구현됩니다. 따라서 허용 목록에 virtualMachines가 포함되어 있으면 해당 범위에서 그 유형이 명시적으로 허용됩니다. 이는 resource group에 배포할 수 있는 항목을 제한하기 위한 일반적인 governance control입니다. 따라서 RG2 범위에서 virtualMachines가 허용된다는 설명은 참입니다.

예. 이 문장은 lock 구성에 대한 것입니다: Lock1은 Read-only이며 VM1에 생성되었습니다. VM resource에 직접 적용된 Read-only lock은 ARM 작업을 통해 VM resource를 수정할 수 없음을 의미합니다. 여기에는 상태 또는 구성을 변경하는 작업(예: start/stop/restart, resizing, updating extensions)이 포함되며, 이러한 작업은 ARM을 통해 실행되고 write 작업으로 처리되기 때문입니다. 시험 문제에서 lock이 “on VM1”에 생성되었다고 설명되면, 이는 lock scope가 VM resource 자체임을 의미합니다(resource group에서 상속된 것이 아님). 그 scope는 RG-level lock보다 더 좁지만, 여전히 VM1에 대한 수정을 차단하기에는 충분합니다. 따라서 Lock1을 설명하는 이 문장은 참입니다.

예. 이 문장은 lock 구성에 대한 것입니다: Lock2는 Read-only이며 RG2에 생성되었습니다. resource group 범위의 Read-only lock은 resource group과 그 안의 모든 resources에 적용됩니다(inheritance). 즉, RG2의 모든 resource는 ARM 관점에서 사실상 read-only가 됩니다. lock이 적용되어 있는 동안에는 해당 RG에서 resources를 생성, 삭제 또는 수정할 수 없습니다. 이것은 중요한 환경에 대한 우발적인 변경을 방지하기 위해 사용되는 강력한 보호 메커니즘입니다. 이 문제의 맥락에서는, Azure Policy가 RG2에서 VM type을 허용하더라도 Read-only lock이 생성 또는 수정 작업을 여전히 차단한다는 의미이기도 합니다. 따라서 Lock2가 Read-only이며 RG2에 생성되었다는 문장은 참입니다.

아니요. VM1에 적용된 Lock1이 Read-only lock이므로 VM1을 시작할 수 없습니다. VM 시작은 ARM control-plane 작업(Microsoft.Compute/virtualMachines/start/action)이며, VM resource에 대한 write/modify 작업으로 처리됩니다. Read-only lock은 write 작업을 차단하므로 시작 요청은 Azure Resource Manager에 의해 거부됩니다. VM1이 현재 Stopped (Deallocated) 상태이더라도, deallocated 상태가 lock을 우회하게 하지는 않습니다. Lock은 management 작업 시점에 평가됩니다. 또한 RG1의 “not allowed resource types”에 대한 Azure Policy는 주로 새 resource 생성에 영향을 미치며, 시작 작업을 직접적으로 막는 것은 Read-only lock입니다. 따라서 “VM1을 시작할 수 있습니다”라는 문장은 거짓입니다.

아니요. VM2를 시작할 수 없습니다. 왜냐하면 Lock2가 RG2 범위에 적용된 Read-only lock이기 때문입니다. Resource group lock은 VM2를 포함하여 해당 그룹의 모든 resource에 상속됩니다. VM1과 마찬가지로, VM을 시작하는 것은 ARM을 통해 실행되는 management operation이며 VM resource state의 수정으로 간주됩니다. Resource group 수준의 Read-only lock은 start/stop/restart 및 configuration 변경을 포함하여 해당 그룹의 resource에 대한 모든 write operation을 차단합니다. RG2의 Azure Policy가 virtualMachines를 허용하더라도 lock을 override하지는 않습니다. lock은 ARM에 의해 독립적으로 적용되며 여전히 해당 operation을 거부합니다. 따라서 “VM2를 시작할 수 있습니다”라는 문장은 거짓입니다.

아니요. RG2의 Azure Policy가 virtualMachines resource type을 허용하더라도, RG2에 있는 Read-only lock(Lock2) 때문에 해당 resource group에서 새로운 리소스를 생성할 수 없습니다. VM 생성은 ARM create operation(쓰기)이며, resource group 범위의 Read-only lock에 의해 차단됩니다. 이것은 시험의 핵심 포인트입니다. Azure Policy는 요청이 규정을 준수하는지와 수락될 수 있는지를 결정하지만, 요청이 규정을 준수하더라도 lock이 작업을 차단할 수 있습니다. 즉, “policy에 의해 허용됨”이 Read-only lock이 존재할 때 “실행 가능함”을 의미하지는 않습니다. RG2에서 VM을 생성하려면 lock을 제거하거나 변경해야 합니다(예: Read-only를 제거하거나 다른 protection strategy를 사용). 따라서 “RG2에서 virtual machine을 생성할 수 있습니다”라는 문장은 거짓입니다.

User1은 per-user MFA에 대해 Enabled 상태입니다. Enabled는 사용자가 MFA registration에 대해 활성화되었음을 의미하지만, Enforced 상태와 동일한 방식으로 sign-in에 대해 MFA가 아직 엄격하게 적용되지는 않음을 의미합니다. 134.18.14.10이 trusted IP range에 없고 phone 기반 method만 사용할 수 있더라도, 문장에서는 User1이 반드시 phone을 사용하여 인증되어야 한다고 말하고 있으며, 이는 Enabled 상태의 사용자에게는 보장되지 않습니다. 따라서 정답은 아니요입니다.

User2는 per-user MFA에 대해 Enforced 상태이므로, trusted IP bypass가 적용되지 않는 한 sign-in 시 MFA가 필요합니다. sign-in은 Seattle office에서 이루어집니다. 그러나 Seattle 사용자는 public NAT segment 190.15.1.0/24를 통해 egress합니다. trusted IP 목록에는 10.10.0.0/16(Seattle internal space)이 포함되어 있지만 190.15.1.0/24는 포함되어 있지 않습니다. Azure AD는 수신한 public source IP를 평가하므로, Seattle에서의 sign-in은 trusted IP configuration과 일치하지 않으며 MFA는 여전히 필요합니다. 문장에서는 User2가 Microsoft Authenticator app을 사용해야 한다고 주장합니다. 이는 올바르지 않습니다. verification options에서 app 기반 방법이 허용되지 않기 때문입니다(“Notification through mobile app” 및 “Verification code from mobile app or hardware token”이 모두 선택 해제됨). phone call/SMS만 활성화된 상태에서는 User2에게 Authenticator app 사용을 요구할 수 없습니다. 따라서 이 문장은 거짓입니다.

User2는 Enforced이므로 일반적으로 MFA가 필요합니다. 하지만 로그인은 public NAT segment 194.25.2.0/24를 사용하는 New York office에서 이루어집니다. 이 정확한 public range는 trusted IPs 목록에 포함되어 있습니다. Azure AD는 source IP를 194.25.2.x로 인식하므로, 요청은 trusted IP range와 일치하며 해당 로그인에 대해 MFA는 건너뜁니다. MFA가 우회되므로, User2는 이 로그인에 대해 phone call 또는 SMS challenge(또는 어떤 MFA method도) 완료할 필요가 없습니다. 따라서 “User2는 phone을 사용하여 인증되어야 합니다”라는 진술은 이 시나리오에서 사실이 아닙니다. 172.16.0.0/16(New York internal space)의 존재는 Azure AD의 평가와 관련이 없다는 점에 유의하세요. 이는 Azure AD가 확인하는 public egress IP가 아니기 때문입니다.

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 소스를 차단하는 것을 동시에 수행할 수 없습니다.

Group1의 평가된 멤버십 결과는 정확히 두 명의 사용자, 즉 User2와 User4입니다. 이 결과는 (a) User2와 User4만 명시적으로 추가된 Assigned group이거나, (b) 프롬프트 이미지에 표시된 규칙과 일치하는 사용자가 User2와 User4뿐인 Dynamic user group인 경우와 일치합니다(예: 특정 department, job title 또는 user type). 다른 옵션은 맞지 않습니다: - A (멤버 없음)는 어떤 사용자도 할당되지 않았고/않거나 어떤 사용자도 dynamic rule과 일치하지 않아야 합니다. - B (User2만)는 User4가 할당된 목록에 없거나 dynamic rule을 충족하지 않아야 합니다. - D (User1, User2, User3 및 User4)는 모든 사용자가 명시적으로 할당되었거나 모두 dynamic rule과 일치해야 함을 의미하지만, 시나리오의 멤버십 평가에 따르면 그렇지 않습니다.

Group2의 평가된 멤버십에는 User1 및 User3만 포함됩니다. 이는 규칙이 정확히 해당 두 사용자의 특성과 일치하는 Dynamic user group의 전형적인 예입니다(예: user.department -eq "HR"가 User1 및 User3과 일치하고, User2 및 User4는 다른 부서에 속함). 또는 해당 두 사용자만 명시적으로 추가된 Assigned group일 수도 있습니다. 오답은 다음과 같이 제외할 수 있습니다: - A (멤버 없음)는 표시된 평가된 멤버십과 모순됩니다. - B (User3만)는 User1이 할당되지 않았거나 및/또는 dynamic rule을 충족하지 않아야 합니다. - D (User1, User2, User3 및 User4)는 모든 사용자가 할당되었거나 규칙과 일치해야 하는데, 이는 시나리오의 멤버십 결과로 뒷받침되지 않습니다. AZ-500에서는 dynamic membership이 자동으로 계산되며 엄격하게 규칙에 의해 결정된다는 점을 기억하세요. 이는 일반적으로 대규모 환경에서 least privilege를 적용하는 데 사용됩니다.

정답입니다. 올바른 순서는 다음과 같습니다: 1) access review program을 생성합니다. 2) access review control을 생성합니다. 3) Reviewers를 Group owners로 설정합니다. 이유: 요구 사항에 따르면 review는 새로운 review collection에 할당됩니다. 이는 Access Review Program이며, review를 여기에 할당하기 전에 먼저 존재해야 합니다. 다음으로 실제 access review("control")를 생성/구성해야 하며, 여기서 무엇을 검토할지와 해당 일정/설정을 정의합니다. 마지막으로, review는 resource owners가 검토해야 하므로 reviewers를 resource의 owners로 설정합니다. 제공된 옵션 중에서는 group 기반 access review에 대해 “resource owners”와 가장 잘 일치하는 항목이 “Set Reviewers to Group owners”입니다. 다른 선택지가 틀린 이유: “Selected users”와 “Members”는 “resource owners” 요구 사항을 충족하지 않습니다. “Create an access review audit”는 설정 단계가 아닙니다. auditing은 생성되는 객체라기보다 logs와 reporting을 통해 본질적으로 제공됩니다.

Windows용 Azure Disk Encryption은 지원되는 Windows Server 버전이 필요하며, Windows Server 2008 R2는 ADE에서 지원되지 않습니다. 따라서 디스크 암호화를 활성화하기 전에 VM1을 지원되는 운영 체제 버전으로 변경해야 합니다. 여기서 결정적인 문제는 티어가 아니며, VM이 지원되는 OS에서 실행되고 필요한 extension을 사용할 수 있는 한 VM size/type 자체가 차단 요인은 아닙니다.

Linux의 Azure Disk Encryption은 특정 승인된 배포판과 이미지들을 지원하며, Ubuntu 16.04-DAILY-LTS는 ADE에서 지원되는 프로덕션 이미지가 아닙니다. 암호화를 활성화하려면 VM2를 공식적으로 지원되는 Ubuntu LTS marketplace image와 같은 지원되는 운영 체제 버전/image로 변경해야 합니다. tier는 이미 Standard이므로 문제가 아니며, 이 시나리오에서 L4s VM type은 ADE의 차단 요인이 아닙니다.

올바른 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 필드는 아닙니다.