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를 만들고 워크로드를 다시 보호하는 것)입니다.

Vault1은 Central US에 위치한 Recovery Services vault입니다. Azure VM 백업은 vault가 VM과 동일한 region에 있어야 합니다. VM1은 Central US에 있으므로 VM1은 Vault1에 백업할 수 있습니다. share1(Azure Files)은 West US에 있는 storage1에 있으므로 Central US vault로 보호할 수 없습니다. blob1(Blob container)은 Recovery Services vault를 사용하여 백업하지 않습니다. SQL1은 East US의 Azure SQL Database(PaaS)이며 Recovery Services vault로 보호되지 않고 대신 기본 제공 백업/LTR을 사용합니다. 따라서 Vault1에 해당되는 것은 VM1뿐이므로 옵션 A가 정답이며 share1/blob1/SQL1이 포함된 모든 옵션은 오답입니다.

Vault2는 West US에 위치한 Recovery Services vault입니다. Azure Files share 백업(스토리지 계정 수준이 아닌 share 수준)은 Recovery Services vault에서 지원되며 스토리지 계정과 동일한 region에 있어야 합니다. storage1은 West US에 있으므로 storage1에 있는 share1은 Vault2로 백업할 수 있습니다. VM1은 Central US에 있으므로 West US vault로 백업할 수 없습니다. blob1(blob container)은 Recovery Services vault로 보호되지 않습니다. “storage1만”은 Azure Backup이 전체 스토리지 계정을 하나의 보호 항목으로 보호하는 것이 아니라 Azure Files share를 보호하므로 올바르지 않습니다. SQL1(East US) 또한 Recovery Services vault로 백업할 수 없습니다. 따라서 share1만 유효하며 정답은 B입니다.

Pass. 올바른 구성은 다음과 같습니다: 1) assignableScopes: "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e" - 이렇게 하면 custom role을 Subscription1 내에서만(리소스 그룹 또는 그 하위 범위에서) 할당할 수 있습니다. "/"를 선택하면 어디에서든 할당이 가능해져(범위가 너무 넓음) 부적절합니다. "/subscriptions/.../resourceGroups"를 선택하는 것은 RBAC에 대한 올바른 scope 형식이 아닙니다. subscription 또는 특정 resource group ID와 같은 유효한 scope를 지정해야 합니다. 2) permissions: - actions: ["*"]로 리소스를 조회/생성/수정/삭제할 수 있도록 허용합니다. - notActions: ["Microsoft.Authorization/*"]로 리소스 그룹 범위에서 access permissions( role assignments/definitions ) 관리를 방지합니다. Microsoft.Resources/* 같은 다른 notActions 옵션은 리소스 관리 자체를 차단하게 되고, Microsoft.Security/*는 RBAC access management와 관련이 없습니다.