Practice Test #5

"No"라고 답하면 구독 범위의 Owner 역할이 Traffic Analytics를 활성화하기에 불충분하다는 의미가 되는데, 이는 정확하지 않습니다. Owner는 필요한 Network Watcher 및 Log Analytics 관련 리소스와 설정을 생성, 업데이트, 구성할 수 있는 광범위한 권한을 제공합니다. 권한이 더 좁은 범위로 제한되거나 다른 구독에 걸친 경우 일부 시나리오에서 실패할 수는 있지만, 문제에서는 구독 수준에서 Owner를 명시적으로 할당하고 있으며 이는 해당 구독에서 가능한 가장 높은 실질적 RBAC 범위입니다. 따라서 "No"는 이 작업에 대한 Azure RBAC 기능과 일치하지 않습니다.

Operating system은 template에 캡처된 image 또는 OS disk 구성에 의해 정의됩니다. 기존 Windows Server 2019 VM에서 생성된 template은 template 자체를 수정하여 다른 image를 참조하지 않는 한 동일한 OS 구성을 기반으로 VM을 배포합니다. 문제에서는 template이 OS를 선택 가능하도록 수정되었다고 나타내지 않습니다. 따라서 이 시나리오에서 operating system은 배포 중에 구성할 수 있는 항목이 아닙니다.

Administrator username은 template의 VM OS profile 일부입니다. ARM templates는 admin 자격 증명을 parameter화하도록 수동으로 작성할 수 있지만, 기존 VM에서 저장한 template이라고 해서 이 필드가 배포 중 변경 가능하도록 노출된다고 의미하지는 않습니다. 시험 문구에서는 명시적으로 언급되지 않는 한 선택적 parameter화가 되어 있다고 가정하면 안 됩니다. 따라서 administrator username은 여기서 보장된 구성 가능 설정이 아닙니다.

Virtual machine size는 VM1에서 생성된 template의 VM hardware profile에 저장됩니다. 기술적으로는 template을 편집하여 size를 변경하거나 size parameter를 포함하도록 template을 작성할 수 있습니다. 그러나 문제는 저장된 template이 주어진 그대로일 때 배포 중 무엇을 구성할 수 있는지 묻고 있습니다. 명시적인 parameter화가 없다면, VM size는 배포 환경에서 선택 가능하다고 가정하지 않습니다. 따라서 이 시험 문제에서 virtual machine size는 최선의 정답이 아닙니다.

오답입니다. User1(조인 수행자)은 로컬 Administrators 그룹에 추가되는 것이 맞지만, Global Administrators도 기본적으로 모든 Azure AD 조인 디바이스에서 로컬 admin 권한이 부여됩니다. 따라서 User2도 포함되어야 하므로 “User1만”은 불완전합니다.

오답입니다. Global Administrators(User2)는 Azure AD 조인 디바이스에서 로컬 admin 권한이 있지만, Azure AD 조인을 수행한 사용자(User1)도 해당 특정 디바이스의 로컬 Administrators 그룹에 추가됩니다. 따라서 “User2만”은 User1을 누락합니다.

오답입니다. User3는 Cloud device administrator이지만, 해당 역할은 “Additional local administrators on Azure AD joined devices”(또는 다른 명시적 로컬 admin 할당)를 통해 구성하지 않는 한 Azure AD 조인 디바이스의 로컬 Administrators 그룹에 자동으로 추가되지 않습니다. 설정이 None이므로 User3는 포함되지 않습니다.

오답입니다. Cloud device administrator(User3)와 Intune administrator(User4) 모두 기본적으로 Azure AD 조인 디바이스의 로컬 Administrators 그룹 멤버가 자동으로 되지 않습니다. 이들은 “Additional local administrators…” 설정을 통해 명시적으로 구성된 경우에만 포함되는데, 해당 설정은 None입니다.

오답입니다. custom domain(예: contoso.com) 추가는 브랜딩, UPN, DNS 확인에 유용하지만, B2B 게스트 초대 authorization을 제어하지는 않습니다. 테넌트에 custom domain이 구성되어 있는지와 관계없이 Microsoft account 또는 다른 ID를 사용하여 게스트를 초대할 수 있습니다.

오답입니다. Organizational relationships에서 identity provider를 추가하는 것은 특정 외부 ID 소스에 대한 federation/trust를 구성하기 위한 것이며(일부 경우 cross-tenant access settings 포함), Microsoft account에 대한 게스트 초대를 활성화/비활성화하는 기본 제어가 아닙니다. 또한 초대를 차단하는 테넌트 정책 문제를 해결하지 못합니다.

오답입니다. Security administrator 역할은 보안 관련 설정(예: 보안 정책, 경고)을 관리하지만, B2B 게스트 사용자를 초대할 권한을 본질적으로 부여하지는 않습니다. 게스트 초대 기능은 External collaboration settings 및/또는 Global Administrator, User Administrator(정책에 따라), Guest Inviter 같은 역할에 의해 제어됩니다.

RDP rule의 priority를 변경하는 것은 불필요합니다. 현재 priority 300은 65000 이상인 기본 inbound rules보다 이미 먼저 평가되기 때문입니다. 즉, TCP 3389에 대한 allow rule은 DenyAllInBound가 고려되기 전에 일치합니다. RDP 트래픽을 차단하는 더 높은 priority의 다른 deny rule이 있다는 증거는 없습니다. priority를 조정해도 VM이 실행 중이어야 한다는 실제 전제 조건은 해결되지 않습니다.

network interface를 연결하는 것은 올바른 첫 번째 조치가 아닙니다. 문제에서 vm1173이라는 network interface가 이미 VM1에 추가되었다고 명시하고 있기 때문입니다. 제시된 화면은 NIC가 이미 존재하고, private IP와 public IP association이 있으며, NSG가 적용되어 있음을 확인해 줍니다. NIC가 이미 연결되어 있으므로, 그 작업을 반복해도 연결 설정에는 도움이 되지 않습니다. 더 직접적인 문제는 VM이 RDP를 수락하려면 전원이 켜져 있어야 한다는 점입니다.

DenyAllInBound rule을 삭제하는 것은 잘못되었습니다. 이는 명시적으로 허용되지 않은 트래픽을 차단하기 위한 기본 NSG rule이기 때문입니다. Azure NSG 처리는 priority 기반이므로, priority 300의 명시적 RDP allow rule이 65500의 기본 deny보다 우선합니다. 기본 deny를 제거하면 보안이 약화되며, RDP가 작동하는 데 필요하지도 않습니다. DenyAllInBound가 존재하더라도 기존 allow rule과 일치하는 트래픽은 차단되지 않습니다.

첫 단계가 아닙니다. RG1 IAM은 최종적으로 VM1 identity가 RG1 리소스를 관리할 수 있도록 권한(role assignment)을 부여하는 위치입니다. 하지만 VM1의 managed identity가 존재하기 전에는 해당 identity에 role을 할당할 수 없습니다. 올바른 순서는 다음과 같습니다: VM1에서 managed identity를 사용하도록 설정한 다음, RG1 IAM을 구성하여 필요한 role을 부여합니다.

오답입니다. VM1에서 IAM을 설정하는 것은 VM1(해당 VM 리소스)을 누가 관리할 수 있는지를 제어하며, VM1이 RG1의 다른 리소스를 관리할 수 있는 권한을 부여하지 않습니다. RBAC는 액세스되는 리소스의 범위(RG1)에 할당되어야 합니다. VM1 자체의 IAM 설정만으로는 VM1에서 실행되는 프로세스가 resource group의 리소스를 배포/관리할 수 없습니다.

오답입니다. Azure Policy는 표준을 강제하고 규정 준수를 평가하는 데 사용됩니다(예: 허용되는 SKU, 필수 tag, public IP 거부). identity에 리소스를 관리할 권한을 부여하지는 않습니다. Policies를 구성하더라도, VM1의 서비스는 여전히 managed identity와 role assignment를 통한 RBAC 권한이 필요합니다.

Azure Active Directory 블레이드에서 Groups를 수정하면 tenant 내의 그룹 멤버십과 그룹 객체가 변경됩니다. Admin1을 그룹에 추가하는 것은 액세스 전략의 일부가 될 수 있지만, 그것만으로는 Azure 리소스에 대한 권한이 부여되지 않습니다. 여전히 해당 subscription(또는 다른) scope에서 그 그룹에 대한 RBAC role assignment가 필요합니다. 따라서 이 옵션은 액세스 요구 사항을 충족하기에 불완전합니다.

Azure Active Directory Properties는 tenant 수준 설정(예: directory 속성, 사용자 설정, 일부 관리 구성)을 제어합니다. 이러한 설정은 subscription 내 Azure 리소스를 관리할 수 있는 Admin1의 권한을 부여하지 않습니다. 리소스 액세스는 Azure AD tenant 속성 변경이 아니라 Azure RBAC role assignment에 의해 관리됩니다. 이는 identity 구성과 Azure 리소스에 대한 authorization을 혼동하는 흔한 사례입니다.

Subscription Properties에는 일반적으로 subscription 이름, offer type, 그리고 때로는 directory 연결 컨텍스트와 같은 subscription 메타데이터가 포함되지만, RBAC 권한을 관리하지는 않습니다. 속성을 변경해도 Admin1에게 리소스를 생성, 수정 또는 삭제할 수 있는 권한이 부여되지 않습니다. authorization 요구 사항의 경우 적절한 scope에서 role assignment를 생성하기 위해 Access control (IAM)을 사용해야 합니다.