Practice Test #2

예. Device1은 문제의 device inventory 표를 기준으로 contoso.com에 등록되어 있습니다. Azure AD에서 “Registered”는 해당 디바이스가 사용자와 연결된 Entra ID의 device object를 가지고 있음을 의미하며(BYOD 시나리오에서 일반적), Conditional Access의 device-based conditions에서 사용할 수 있습니다. 이는 “Azure AD joined”(기업 소유이며 Entra ID에 직접 joined됨) 및 “Hybrid Azure AD joined”(on-prem AD에 joined되고 Entra ID에 등록됨)와는 구별됩니다. 이 문제의 처음 세 개 하위 질문은 단순히 표에 표시된 디바이스 상태를 확인하는 것이며, Terms of Use 설정에서 도출되는 것이 아닙니다. 따라서 Device1에 대한 올바른 선택은 예입니다.

아니요. 표에 따르면 Device2는 contoso.com에 Registered되어 있지 않습니다. Windows 10 device가 Azure AD joined 또는 Hybrid Azure AD joined인 경우, 일반적으로 device 목록에서 “Registered”로 표시되지 않습니다. 대신 “Azure AD joined” 또는 “Hybrid Azure AD joined”로 표시됩니다. 반대로, unmanaged 상태이며 device registration 없이 browser를 통해 sign in하는 데만 사용되는 경우에도 registered로 표시되지 않습니다. 표에서 Device2가 “Registered” 상태가 아님을 나타내므로, 정답은 아니요입니다. 이는 나중에 Conditional Access policy가 compliant 또는 hybrid-joined device를 요구하는 경우에만 중요합니다. 그러나 Terms of Use 자체는 user가 authenticate할 수 있고 CA policy가 적용되는 한 registration 여부와 관계없이 계속 표시될 수 있습니다.

예. 표에 따르면 Device3 (iOS)는 contoso.com에 등록되어 있습니다. iOS 디바이스는 사용자가 Microsoft Authenticator와 같은 앱에 work account를 추가하거나, Intune Company Portal을 통해 등록하거나, 그 밖의 방식으로 workplace join/registration을 설정할 때 일반적으로 Azure AD registered 상태가 됩니다. 이렇게 하면 사용자에 연결된 device object가 Entra ID에 생성되어 Conditional Access를 위한 device identity signal을 사용할 수 있습니다. Platform (iOS)은 등록을 막지 않으며, 단지 Windows 10과 비교했을 때 등록 방식이 달라질 뿐입니다. 문제에서 device 목록을 명시적으로 제시하고 Device3가 등록되어 있는지 묻고 있으므로, 올바른 선택은 예입니다.

예. 2020년 11월 20일에 User1은 Device1에서 Terms1에 동의할 수 있습니다. “Require users to consent on every device”가 활성화되어 있으므로, 11월 15일에 Device3에서 Terms1에 동의한 것은 Device1에 대한 요구 사항을 충족하지 않습니다. User1이 Device1에서 sign in하고 Terms1을 적용하는 Conditional Access policy에 도달하면, Azure AD는 해당 device에 대해 Terms1 동의를 요청합니다. 설정 중 어떤 것도 만료 시작일 이전의 동의를 막지 않습니다. Expiration은 2020년 12월 10일에 시작되도록 구성되어 있으므로, 11월 20일에는 동의 프로세스가 정상적으로 작동하며 사용자는 동의할 수 있습니다. “Require users to expand the terms of use” 설정은 UX에만 영향을 줍니다(동의하기 전에 펼쳐야 함). 동의 가능 여부에는 영향을 주지 않습니다.

예. User1은 모든 디바이스에서 동의가 필요하고, Device3에서의 이전 동의는 Device2에 대한 요구 사항을 충족하지 않기 때문에 2020년 12월 11일에 Device2에서 Terms1에 동의할 수 있습니다. User1이 Device2에서 리소스에 액세스하고 Conditional Access policy가 적용되면, Azure AD는 Terms1에 대한 프롬프트를 표시하고 동의를 허용할 수 있습니다. expiration 설정은 동의를 막지 않으며, 기존 동의를 언제 다시 갱신해야 하는지만 결정합니다. Device3에서의 동의는 디바이스별로 동의가 별도로 추적되기 때문에 Device2와는 관련이 없습니다.

아니요. 2020년 12월 7일에 User1은 Device3에서 Terms1을 다시 수락할 수 없습니다(그럴 필요도 없습니다). 이는 Device3의 기존 동의(2020년 11월 15일에 수락됨)가 그 시점에 여전히 유효하기 때문입니다. 만료 시작 날짜는 2020년 12월 10일이므로, 그 날짜 이전에는 동의가 만료된 것으로 간주되지 않습니다. 12월 7일은 12월 10일 이전이므로, Device3의 동의 기록은 계속 유효하며 Azure AD는 일반적인 sign-in 흐름 중에 재수락을 요청하지 않습니다. 시험 맥락에서의 중요한 뉘앙스: 사용자는 policy evaluation에 의해 prompt가 표시될 때만 수락할 수 있습니다(일반적으로 스스로 "지금 다시 수락"하는 self-service 작업은 없습니다). 12월 7일에는 동의가 여전히 유효하므로 prompt가 나타나지 않으며, 따라서 실질적인 정답은 아니요입니다.

올바른 선택은 Pass입니다. 사용된 라이선스 수는 그룹 구성에서 확인할 수 있기 때문입니다. Microsoft 365 E5가 Group1에 할당되면, Azure AD group-based licensing은 Group1의 직접적인 사용자 멤버에게만 라이선스를 할당합니다. Group1의 직접 멤버는 User1과 User3이며, Group2와 Group4(그룹)도 포함됩니다. Nested group membership은 group-based licensing에서 평가되지 않으므로, User2(in Group2)와 User4(in Group4)는 Group1을 통해 라이선스를 받지 않습니다. Group3에는 device(Device1)가 포함되어 있지만, device는 Microsoft 365 user licenses를 소비하지 않으며, Group3는 Group1 아래에 nested되어 있지도 않습니다. Group5는 관련이 없습니다. 따라서 User1과 User3만 라이선스를 받으므로, 2개의 라이선스가 사용됩니다. “Fail” 옵션은 잘못된 선택입니다. 이는 group-based licensing에서 nested groups를 지원하지 않는다는 표준적이고 시험에 자주 출제되는 규칙이기 때문입니다.

정답: Privileged role administrator. 이 Microsoft Entra ID (Azure AD) directory 역할은 Entra ID 역할의 역할 할당을 관리하도록 특별히 설계되었습니다. 전체 Global Administrator 권한이 없어도 위임된 관리자가 기본 제공 directory 역할을 할당하고 제거할 수 있으므로, 최소 권한 원칙에 부합합니다. 다른 선택지가 틀린 이유: - Global administrator도 역할 할당을 관리할 수 있지만, 과도한 권한을 가지며 일반적으로 더 범위가 제한된 역할이 있을 때 최적의 위임 선택은 아닙니다. - Security administrator는 보안 기능(예: 보안 정책, 경고)에 중점을 두며, Entra ID 역할 할당을 관리하는 표준 역할이 아닙니다. - User access administrator는 Entra ID directory 역할 할당이 아니라 Azure 리소스(ARM)에 대한 액세스를 관리하기 위한 Azure RBAC 역할입니다.

정답: User access administrator. 이것은 Azure RBAC 기본 제공 role로, subscription/resource group/resource 범위에서 role assignment를 생성하고 관리하여 Azure 리소스에 대한 액세스를 관리할 수 있습니다. 여기에는 role assignment를 쓰기 위한 권한(Microsoft.Authorization/roleAssignments/*)이 포함되며, 이는 RBAC 관리를 위임하는 데 정확히 필요한 권한입니다. 다른 선택지가 틀린 이유: - Global administrator와 Privileged role administrator는 Microsoft Entra ID directory role이며, subscription에서 role assignment를 관리하기 위한 Azure RBAC 권한을 자동으로 부여하지 않습니다. - Security administrator 또한 보안 관리를 위한 directory role이며, role assignment를 관리하는 데 필요한 Azure RBAC 권한을 제공하지 않습니다. 실무에서는 Entra ID 거버넌스(directory role)와 Azure RBAC(resource role)를 함께 사용하는 경우가 많지만, 올바른 plane에 올바른 role을 할당해야 합니다.

예. Assigned membership를 가진 security group을 포함하여 group에 대한 access review를 생성할 수 있습니다. Group access review는 Microsoft Entra ID Identity Governance의 주요 access review 시나리오 중 하나로, reviewer는 각 user가 해당 group의 member로 계속 남아 있어야 하는지 검증합니다. Group의 membership type(Assigned vs Dynamic)은 access review 생성 가능 여부를 막지 않습니다. “아니요”가 틀린 이유: Access review는 dynamic group이나 privileged group으로 제한되지 않습니다. Assigned membership group은 app, SharePoint site 및 Azure resource에 대한 access를 부여하는 데 일반적으로 사용되므로 정기적인 review의 표준 대상입니다. 실제로 group membership review는 group membership이 자주 downstream access를 결정하기 때문에 가장 먼저 구현되는 governance control인 경우가 많습니다.

예. Enterprise application(service principal)에 대한 access review를 생성하여 해당 application에 대한 사용자 및 그룹 할당을 검토할 수 있습니다. 이는 핵심 Identity Governance 기능으로, 특히 SSO와 통합된 영향도가 높은 SaaS 앱에 대해 적절한 사용자만 애플리케이션 액세스를 유지하도록 보장합니다. “아니요”가 틀린 이유: Enterprise applications는 access reviews에서 “Applications”로 명시적으로 지원됩니다(할당된 사용자/그룹 검토). 이는 developer object인 app registrations를 검토하는 것과는 다릅니다. Access review는 enterprise application의 할당 대상(누가 sign in할 수 있는지 / 어떤 app roles를 가지고 있는지)을 대상으로 하며, app registration 구성 자체를 대상으로 하지 않습니다.

예. Contributor는 Azure subscription role(Azure RBAC built-in role)입니다. Access reviews는 subscription, resource group 또는 resource와 같은 scope에서 role assignment를 주기적으로 검증하기 위해 Azure resource role(Azure RBAC role)에 대해 생성할 수 있습니다. 이는 Contributor와 같은 강력한 role이 계속 엄격하게 통제되도록 보장하는 데 일반적으로 사용됩니다. “아니요”가 틀린 이유: Azure RBAC는 Microsoft Entra directory role과 동일하지 않지만, Identity Governance는 Azure resource role(종종 PIM과 통합됨)에 대한 access reviews를 지원합니다. 이 시험에서는 group/app access뿐만 아니라 Azure RBAC assignment도 검토 가능하다는 점을 인식해야 합니다.

예. Azure Active Directory (Microsoft Entra ID) 역할(디렉터리 역할)인 Role1은 access reviews를 사용하여 할당을 검토할 수 있습니다. 이는 특히 privileged roles(예: Global Administrator, User Administrator)에 중요하지만, 구성 및 라이선스에 따라 access reviews는 일반적으로 역할 할당에 적용될 수 있습니다. “아니요”가 틀린 이유: Access reviews는 디렉터리 역할 할당을 관리하기 위한 핵심 제어 수단이며, 시간이 지나도 올바른 관리자만 역할 할당을 유지하도록 보장하기 위해 Privileged Identity Management (PIM)와 함께 자주 사용됩니다. 이는 least privilege를 지원하고 상시 administrative access를 줄입니다.

표시된 자료는 User1이 Group1의 멤버임을 증명할 object table을 제공하지 않습니다. 문장은 해당 멤버십이 사실인지 묻고 있지만, 보이는 configuration 화면은 Group1이 선택된 filtering group임만 보여주므로, 제공된 증거만으로는 이 문장을 검증할 수 없습니다. 따라서 현재의 '예'는 근거가 없습니다. filtering configuration은 synchronization scope에 영향을 주지만, 그것만으로 User1에 대한 group membership 사실을 확정하지는 않습니다.

표시된 자료에는 object table 또는 User2의 멤버십이 나와 있지 않습니다. Azure AD Connect filtering 화면은 OU1 및 OU2가 선택되어 있고 group-based filtering에 Group1이 사용된다는 것만 보여줄 뿐, User2가 어떤 그룹에도 속하지 않는다는 것을 증명하지는 않습니다. 이 문장은 sync behavior가 아니라 AD 사실에 관한 것이므로, '예'라고 답하려면 제공된 자료에 없는 증거가 필요합니다. 따라서 현재 답변은 자료에 의해 정당화되지 않습니다.

제공된 스크린샷에는 Group1 멤버십을 보여줄 object table이 포함되어 있지 않습니다. filter는 Group1을 사용하도록 구성되어 있지만, 그것만으로 어떤 object가 Group1의 멤버인지가 확정되지는 않습니다. 이 문장은 두 개의 멤버십 주장으로 구성되어 있으므로, '예'라고 답하려면 둘 다 명시적으로 표시되어야 합니다. 그 근거가 없으므로 현재 답변은 뒷받침되지 않습니다.

필터링 예시는 Group1을 선택된 synchronization group으로 식별하지만, Group1의 멤버는 나열하지 않습니다. 따라서 제공된 자료에는 Group2가 Group1의 멤버라는 직접적인 증거가 없습니다. 중첩된 group이 무시된다는 참고 사항은 그러한 중첩이 존재하는 경우의 동작을 설명하지만, 이 시나리오에서 그것이 존재한다는 것을 증명하지는 않습니다. 결과적으로 '예'는 표시된 예시에 의해 뒷받침되지 않습니다.

스크린샷은 synchronization scope를 평가하는 데 필요한 Azure AD Connect 구성을 보여줍니다: OU1 및 OU2만 선택되어 있으며, group-based filtering에 대해 Group1이 선택된 group입니다. 또한 membership 확장에 nested groups가 지원되지 않는다는 중요한 규칙도 보여줍니다. 그러나 User1, User2 및 Group2의 membership 문장이 참인지 판단하려면 여전히 시나리오에서 참조된 object table이 필요합니다. 이미지만으로는 filtering logic을 이해하기에 충분하지만, 보이지 않는 membership 사실 자체를 추론하기에는 충분하지 않습니다.

User1은 두 가지 조건이 모두 참인 경우에만 Azure AD에 동기화됩니다. User1은 선택된 OU에 있어야 하며, User1은 Group1의 직접 멤버여야 합니다. 스크린샷은 필터링 규칙을 확인해 주지만, User1의 OU 위치나 실제 그룹 멤버십은 보여주지 않습니다. 따라서 설명은 해당 사실들이 제시된 화면만으로 입증된 것처럼 서술해서는 안 됩니다. OU filtering은 후보 범위를 정의하고, group-based filtering은 그다음 Group1의 직접 멤버로 동기화를 제한합니다.

User2가 Group1의 직접 멤버가 아니면, User2가 OU1 또는 OU2에 있더라도 Azure AD에 동기화되지 않습니다. 스크린샷은 Group1에 대해 group-based filtering이 활성화되어 있고, 멤버십 확장에서 nested groups가 무시된다는 점을 보여줍니다. 그러나 스크린샷만으로는 User2의 group memberships를 독립적으로 증명하지는 않습니다. 올바른 판단 근거는 동기화가 단순히 OU 배치에만 의존하는 것이 아니라, OU scope와 함께 Group1의 직접 멤버십에 달려 있다는 것입니다.

Group2는 Group2 객체 자체가 선택된 OU 내에 있고 Group1의 직접 멤버인 경우에만 동기화됩니다. 중첩 그룹이 무시된다는 설명은 Azure AD Connect가 Group2를 통해 그 내부의 객체까지 멤버십을 확장하지 않는다는 의미일 뿐이며, 그것만으로 Group2가 Group1의 멤버인지 여부를 증명하지는 않습니다. 스크린샷은 필터링 구성을 보여주지만, Group2의 실제 멤버십이나 OU 위치는 보여주지 않습니다. 따라서 설명은 보이지 않는 사실을 단정하기보다 규칙을 설명해야 합니다.