Practice Test #7

아닙니다. policy assignment는 RG2에만 scope가 지정되어 있으므로, RG1의 resources는 assignment scope 밖에 있습니다. VNET1은 RG1의 virtual network이므로 이 deny policy assignment의 적용을 받지 않습니다. 따라서 이 진술은 policy 영향의 맥락에서 false이며, RG2 범위의 enforcement가 RG1 resources에 적용된다고 암시하는 선택지는 올바르지 않습니다.

아니요. RG2에 할당된 policy는 기본 제공되는 'Not allowed resource types' definition을 사용하며 Microsoft.Network/virtualNetworks를 포함합니다. 이는 RG2에서 virtual network에 대한 create 또는 update 작업이 허용되지 않음을 의미합니다. 기존 resource는 삭제되지 않지만, policy 기준의 hotspot true/false 평가에서는 정답이 Yes가 아니라 No입니다.

아니요. RG2의 assignment에는 허용되지 않는 resource types 목록에 Microsoft.Compute/virtualMachines가 포함되어 있습니다. 그 결과, RG2 내에서는 virtual machine resource에 대한 create 및 update 작업이 거부됩니다. VM1은 이미 존재하며 계속 실행되지만, 이 policy에 따라 RG2에서는 VM이 허용되지 않으므로 의도된 hotspot 정답은 No입니다.

정답입니다. 제시된 자료는 시나리오에 답하기에 충분한 정보를 제공합니다. policy definition은 'Not allowed resource types'이고, assignment scope는 RG2이며, denied types에는 classic virtual networks, ARM virtual networks, 그리고 virtual machines가 포함됩니다. 이를 통해 RG2의 resources와 write operations만 영향을 받는다는 것을 판단할 수 있습니다. 기존 resources는 제거되거나 전원이 꺼지지 않지만, 해당 resource types에 대한 create, update, 그리고 move-into-scope operations는 거부됩니다.

아니요. VNET1(Microsoft.Network/virtualNetworks 리소스)을 RG1에서 RG2로 이동하면 대상 범위(RG2)에서 VNet이 생성/업데이트되는 결과가 됩니다. Azure Policy deny 할당은 대상 범위에서의 쓰기 작업에 대해 평가됩니다. RG2에는 Microsoft.Network/virtualNetworks를 거부하는 policy 할당이 있으므로, 이동 작업은 차단됩니다. 실제로 리소스 이동은 대상 리소스 그룹에서 policy 평가를 통과해야 하는 관리 평면 작업으로 처리됩니다. “예”가 틀린 이유: Policy 범위가 중요합니다. RG1이 범위에 포함되지 않더라도, 대상(RG2)은 범위에 포함되어 해당 리소스 유형을 거부하므로 이동을 완료할 수 없습니다.

아니요. “Not allowed resource types”(deny)가 포함된 Azure Policy는 기존 리소스의 런타임 전원 상태를 변경하지 않습니다. VM1은 현재 Running이며, deny policy를 할당해도 VM이 deallocate, stop 또는 restart되지 않습니다. Policy는 관리 평면(management-plane) 작업(create/update/delete) 및 규정 준수 보고에 대한 거버넌스 제어입니다. 다른 도구(예: Azure Automation, Logic Apps 또는 remediation task가 있는 DeployIfNotExists/Modify policy)를 사용하지 않는 한 compute 상태를 변경하는 자동화/수정 메커니즘이 아닙니다. (이 시나리오에는 해당되지 않습니다.) “예”가 틀린 이유: 여기에는 deallocation을 트리거하는 policy effect가 없습니다. Deny는 RG2에서 향후 VM create/update 작업만 차단합니다.

아니오. VNET2의 address space를 수정하는 것은 Microsoft.Network/virtualNetworks 유형의 리소스에 대한 업데이트 작업입니다. RG2에 할당된 policy는 Microsoft.Network/virtualNetworks를 명시적으로 deny합니다. deny policy가 적용되어 있으면, VNet 리소스를 업데이트하는 모든 PUT/PATCH(예: address space 변경, DNS 설정, subnet 변경 등)는 RG2의 리소스에 대해 ARM control plane에서 거부됩니다. “예”가 틀린 이유: VNET2가 이미 존재하더라도, deny policy는 deny된 리소스 유형에 대한 업데이트를 여전히 차단합니다. 기존 리소스가 제거되지는 않지만, 업데이트 작업이 필요한 변경에 대해서는 사실상 “잠금” 상태가 됩니다.

정답: C (StorageV2). Blob의 hot, cool, archive를 포함한 Blob access tier를 지원하려면 StorageV2 (general-purpose v2) storage account가 필요합니다. 이는 현재 권장되는 account type이며, 가장 광범위한 storage 기능(Blob, File, Queue, Table)을 지원하고, 비용 최적화를 위해 tier 간 데이터 이동을 수행하는 lifecycle management policy도 지원합니다. 다른 선택지가 틀린 이유: - A (FileStorage)는 Azure Files (SMB/NFS) 시나리오를 위한 premium 전용 account kind입니다. Blob Storage에 대한 표준 blob tiering 모델(hot/cool/archive)을 제공하지 않으며 비용 최소화에도 적합하지 않습니다. - B (Storage)는 general-purpose v1 (GPv1)을 의미합니다. GPv1은 레거시이며 StorageV2에 비해 기능 제한이 있습니다. 시험 관점에서 modern blob tiering과 best-practice 기능이 필요할 때는 StorageV2가 정답입니다.

정답: A (Standard_GRS). Standard_GRS (Geo-Redundant Storage)는 페어링된 Azure region의 보조 region으로 데이터를 비동기적으로 복제하여, 재해가 기본 region에 영향을 미치는 경우에도 복원력을 제공합니다. 이는 region 수준의 내결함성 요구사항을 직접 충족합니다. 다른 선택지가 틀린 이유: - B (Standard_LRS)는 단일 region 내에서만 복제(구현에 따라 datacenter/zone 세트 내)하며, region 전체 장애로부터 보호하지 못합니다. - C (Standard_RAGRS)는 GRS의 모든 기능에 더해 보조 region에 대한 읽기 액세스를 포함합니다. 이 추가 읽기 액세스 기능은 비용을 증가시키며, 문제에서 요구하지 않으므로 GRS에 비해 “비용 최소화”를 충족하지 못합니다. - D (Premium_LRS)는 비용이 더 높고 여전히 로컬 중복만 제공(교차 region 재해 내성 없음)하므로, 비용 및 region DR 요구사항 모두를 충족하지 못합니다.

올바른 순서(가능한 순서 중 하나): 1) Azure Automation State Configuration에 configuration 업로드 2) configuration을 compile하여 node configuration 생성 3) node의 compliance status 확인 이것이 올바른 이유: 지속적인 일관성을 강제하려면 Azure Automation DSC에 Automation account 내 DSC configuration이 필요합니다. 업로드/가져오기 후에는 이를 compile하여 노드가 적용할 수 있는 node configuration(MOF artifacts)을 생성해야 합니다. 노드가 configuration을 적용한 뒤에는 node compliance status를 사용해 drift를 확인하고 지속적으로 모니터링합니다. 다른 선택지가 틀린 이유: VM에 tag를 할당하고 management group을 생성하는 것은 governance/조직화 작업이며, DSC configuration을 생성/compile/apply하지 않으므로 configuration 일관성을 직접적으로 관리하지 않습니다. 제공된 목록에서 DSC 운영 라이프사이클을 나타내는 작업은 업로드, compile, compliance 확인뿐입니다.

VM1은 VNET1에 있으며, private DNS zone adatum.com이 auto-registration이 활성화된 상태로 VNET1에 연결되어 있습니다. Azure Private DNS의 auto-registration은 해당 VNet 내에서 VM의 NIC에 있는 private IP address에 대한 A 레코드를 생성합니다. VM1의 private IP는 10.1.0.4이므로, 10.1.0.4를 가리키는 A 레코드(일반적으로 vm1.adatum.com)가 생성됩니다. 왜 public IP가 아닌가? Azure Private DNS zone은 private name resolution을 위한 것이며, auto-registration은 public IP address를 private zone에 게시하지 않습니다. Public IP는 일반적으로 public DNS(Azure DNS public zones 또는 외부 DNS provider)를 통해 확인되며, Private DNS를 통해 확인되지 않습니다. 왜 없음이 아닌가? VM이 연결된 VNet에 있고 auto-registration 조건을 충족하기 때문입니다. Windows Server DNS suffix(Adatum.com)는 Azure가 레코드를 등록하는 데 필요하지 않으며, VNet link와 private IP를 기반으로 Azure가 등록한다는 사실을 바꾸지 않습니다.

VM2도 VNET1에 있으며, VNET1은 auto-registration이 활성화된 private DNS zone adatum.com에 연결되어 있습니다. 따라서 Azure는 VM2의 private IP address인 10.1.0.5에 매핑되는 VM2용 A 레코드를 추가합니다. VM 내부에 구성된 DNS suffix(Contoso.com)는 오답 유도 요소입니다. 해당 설정은 이름 확인(name resolution) 중 VM의 OS가 domain suffix를 어떻게 추가하는지, 그리고 구성된 경우 on-premises DNS server에 어떻게 등록할 수 있는지에 영향을 주지만, Azure Private DNS auto-registration 동작을 결정하지는 않습니다. Azure는 private DNS zone 이름(adatum.com)과 VNet link를 사용하여 어디에 등록할지 결정합니다. 왜 public IP only 또는 둘 다가 아닌가? Auto-registration은 private DNS zone에서 public IP에 대한 레코드를 생성하지 않습니다. Private zone에 public IP를 섞으면 내부/외부 이름 확인의 분리를 훼손하게 되며, 이는 해당 기능의 설계 방식이 아닙니다.