Practice Test #9

Subscription1은 ManagementGroup21에 있으며, ManagementGroup21은 ManagementGroup11 아래에 있고, ManagementGroup11은 Tenant Root Group 아래에 있습니다. 따라서 Subscription1은 Tenant Root Group에 할당된 policy를 상속받습니다. parameter virtualNetworks가 설정된 “Not allowed resource types” policy가 Tenant Root Group에 할당되어 있습니다. 이는 exemption이 구성되지 않는 한(여기서는 언급되지 않음) 테넌트 전체에서 Microsoft.Network/virtualNetworks 생성이 거부됨을 의미합니다. “Allowed resource types” policy는 ManagementGroup12에만 scope가 지정되어 있으므로 ManagementGroup11 아래에 있는 Subscription1에는 적용되지 않습니다. 설령 적용되더라도 여러 policy는 함께 평가되며, 어떤 deny라도 있으면 배포가 차단됩니다. 따라서 Tenant Root Group policy가 virtualNetworks를 명시적으로 deny하므로 Subscription1에서 virtual network를 생성할 수 없습니다.

Subscription2는 ManagementGroup12에 있으므로 Tenant Root Group과 ManagementGroup12의 policy를 모두 상속합니다. Tenant Root Group의 policy는 Microsoft.Network/virtualNetworks만 차단하지만, ManagementGroup12의 'Allowed resource types' policy는 virtualNetworks만 허용하고 다른 모든 resource type은 거부합니다. virtual machine은 Microsoft.Compute/virtualMachines이므로 허용 목록에 없고 deployment가 거부됩니다. 따라서 해당 설명은 false이므로 정답은 No입니다.

구독은 한 번에 하나의 management group에만 속할 수 있지만, 충분한 권한이 있다면(일반적으로 대상 범위에서 Management Group Contributor/Owner 권한과 현재 범위에서의 적절한 권한) 한 management group에서 다른 management group으로 이동(re-parent)할 수 있습니다. Subscription1은 현재 ManagementGroup21에 있습니다. ManagementGroup21은 ManagementGroup11의 하위입니다. Subscription1을 ManagementGroup11에 추가(이동)하는 것은 허용됩니다. 이는 구독의 상위 management group을 ManagementGroup21에서 ManagementGroup11로 변경하는 것뿐입니다. 이는 거버넌스 작업이며 management group의 구조 규칙을 위반하지 않습니다. 이동 후에도 Subscription1은 Tenant Root Group 정책을 계속 상속하며, ManagementGroup11에 할당된 모든 정책을 상속하고(그리고 ManagementGroup21에만 특정하게 할당된 정책은 더 이상 상속하지 않게 됩니다). 따라서 Subscription1을 ManagementGroup11에 추가할 수 있습니다(즉, 그곳으로 이동할 수 있습니다).

예. Azure Storage account(ARM 기반)는 일반적으로 구독 간 이동을 지원하며, 대상 구독이 동일한 Azure AD tenant에 있고 이동 작업이 제약 조건을 위반하지 않는 경우에 가능합니다(예: resource lock을 제거해야 하며, policy가 이동을 차단할 수 있음). Storage account는 일부 governance/security 리소스처럼 본질적으로 특정 구독에 “고정(pinned)”되어 있지 않습니다. 왜 아니요가 아닌가: Storage 이동의 일반적인 차단 요인은 보통 외부 종속성(예: access key/connection string을 사용하는 앱, private endpoint, 또는 network rule)이지, Storage account 자체를 이동하는 것에 대한 Azure 플랫폼의 제한이 아닙니다. 시험 관점에서 Storage account는 Azure Resource Manager move를 사용하여 구독 간 이동 가능한 리소스로 간주됩니다.

예. Azure virtual network (VNet)은 resource move를 사용하여 다른 subscription(동일 tenant)으로 이동할 수 있습니다. 이는 지원되는 ARM 시나리오입니다. 중요한 종속성 참고(시험 관련): VNet에 종속 리소스(subnet에 연결된 NICs, private endpoints, gateways, peerings 등)가 있는 경우, 종속 리소스를 함께 이동해야 하거나 특정 구성을 제거/재생성해야 할 수 있습니다(예: VNet peerings는 이동 후 다시 설정해야 하는 경우가 많음). 하지만 이 문제는 어떤 리소스를 이동할 수 있는지를 묻고 있으며, VNet은 “이동 지원” 범주에 포함됩니다. 아니요가 아닌 이유: VNet은 Recovery Services vaults처럼 제한적인 리소스가 아니라, 표준 ARM networking 리소스이며 subscription 재구성 시 흔히 이동됩니다.

예. Azure virtual machine (VM)은 다른 subscription으로 이동할 수 있지만, VM을 종속 리소스와 함께 이동해야 합니다(최소: NIC(들) 및 managed disk; 설계에 따라 종종 public IP, NSG, 그리고 load balancer 연결도 포함). 이 이동은 ARM 메타데이터 작업이며 VM을 “재생성”하지는 않지만, 종속성은 일관되게 유지되어야 합니다. 왜 아니요가 아닌가: VM은 subscription 간 이동에 대해 표준적으로 지원되는 리소스 유형입니다. 일반적인 시험 함정은 disk를 남겨둔 채 VM 객체만 이동할 수 없다는 점을 잊는 것이지만, 종속성과 함께 올바르게 처리하면 VM 리소스 자체는 이동 가능합니다.

예. Managed disks는 구독 간 이동을 지원합니다. 실제로 VM을 이동할 때, VM의 스토리지 종속성을 그대로 유지하기 위해 해당 Managed disks를 동일한 이동 작업의 일부로 함께 이동하는 것이 일반적입니다. 아니오가 아닌 이유: Managed disks는 ARM 리소스이며 vaults 또는 특정 identity/governance 리소스처럼 제한되지 않습니다. 주요 고려 사항은 종속성 무결성(디스크가 VM에 연결되어 있음)과 관련 리소스를 함께 이동하도록 보장하는 것입니다. VM을 남겨둔 채 디스크만 단독으로 이동하려고 하면 VM 구성이 깨지지만, 디스크 리소스 유형 자체는 이동이 지원되며 실제로는 VM1과 함께 이동해야 합니다.

아니요. Site Recovery (ASR)에 사용되는 Recovery Services vault는 일반적으로 구독 간 이동이 불가능하며, 특히 Site Recovery 구성/보호된 항목(복제 메타데이터, fabrics, protection containers, replicated items)을 포함하고 있는 경우에는 더욱 그렇습니다. Microsoft의 Recovery Services vault 이동 제한은 AZ-104 시험에서 자주 다루는 포인트로, 백업 항목 또는 ASR 복제가 있는 vault는 리소스 이동이 지원되지 않습니다. 왜 예가 아닌가: vault를 이동하면 페일오버/페일백 작업에 필요한 신뢰성 체인과 복구 메타데이터가 손상될 위험이 있습니다. 지원되는 접근 방식은 보통 VM에 대해 복제를 비활성화/보호 중지를 수행하고, vault 콘텐츠를 정리한 다음, 대상 구독에서 다시 구성하는 것(또는 AZPT2에 새 vault를 만들고 워크로드를 다시 보호하는 것)입니다.