Practice Test #3

정답: C (self-service password reset (SSPR)에 등록). 목표가 ID가 손상되었을 가능성(user risk)을 해결하는 것이라면, 일반적인 자동 수정 조치는 암호 변경을 강제하는 것입니다. Microsoft Entra ID에서 user risk policy는 user risk가 감지되면 “password change”를 요구할 수 있습니다. 사용자가 helpdesk/admin의 개입 없이 해당 암호 변경을 완료하려면 SSPR에 등록되어 있어야 합니다(SSPR에 필요한 authentication methods 포함). 이것이 policy 결과를 가능하게 하는 실질적인 전제 조건입니다. B가 아닌 이유: MFA 등록은 risky sign-ins를 완화하고 authentication을 강화하는 데 도움이 되지만, 그 자체만으로는 손상된 ID에 대한 “require password change” 수정 흐름을 가능하게 하지는 않습니다. A가 아닌 이유: App consent는 Identity Protection risk remediation과 관련이 없으며 손상된 ID 가능성을 해결하지도 않습니다.

정답: B (user risk policy). Identity Protection의 user risk policy는 사용자 계정이 손상되었을 가능성(user risk)을 대상으로 합니다. 구성된 임계값(low/medium/high)에 user risk 수준이 도달하면 안전한 암호 변경을 요구하고(및/또는 액세스를 차단하여) 자동으로 수정 조치를 수행할 수 있습니다. 이는 사용자 ID가 손상되었을 확률에 대한 요구 사항과 직접적으로 일치합니다. A가 아닌 이유: sign-in risk policy는 개별 sign-in 시도(session/authentication events)를 평가합니다. 이는 위험한 sign-in에 대응하려는 경우(예: MFA 요구 또는 sign-in 차단)에 사용되며, 계정 자체가 손상된 것으로 의심되는 경우에 사용하는 것은 아닙니다. C가 아닌 이유: Azure AD Password Protection은 약한 암호를 금지하고 암호 복잡성을 적용하는 것(사용자 지정 금지 암호 목록 포함)에 중점을 둡니다. 이는 암호 위생을 개선하지만, 손상된 ID에 대한 risk 기반 탐지/수정 기능을 구현하지는 않습니다.

아니요. Azure AD (Entra ID) 라이선스를 Users 그룹에 할당하는 것은 enterprise application이 My Apps portal에 표시되도록 하는 데 필요하지 않습니다. My Apps 표시 여부는 enterprise application의 할당(Users and groups)과 application 속성인 “Visible to users”에 의해 제어되며, 특히 “User assignment required”가 Yes로 설정된 경우에 그렇습니다. Group-based licensing은 제품 기능(예: Conditional Access, Identity Protection, PIM 등과 같은 Entra ID P1/P2 기능)을 부여하는 데 사용됩니다. 특정 보안 기능을 사용하기 위해 라이선스가 필요할 수는 있지만, 그것만으로 My Apps에 app tile을 게시하지는 않습니다. 사용자가 이미 App1과 App2를 볼 수 있다면, 라이선스는 기본적인 My Apps 액세스의 차별 요소가 아님이 분명합니다. 올바른 해결 방법은 라이선스를 변경하는 것이 아니라 HRUsers가 App3에 할당되어 있는지(또는 App3에 동등한 할당이 있는지) 확인하는 것입니다.

아니요. 특정 그룹(Members)만 devices를 join할 수 있도록 device settings를 구성하는 것은 Azure AD device registration/join(누가 Azure AD에 devices를 join할 수 있는지)에 영향을 주며, enterprise application이 My Apps portal에 표시되는지 여부에는 영향을 주지 않습니다. My Apps는 application access experience입니다. 설명된 문제는 users가 App3를 보지 못한다는 것이며, 이는 거의 항상 App3에 대한 assignment가 누락되었거나(“User assignment required: Yes”가 주어진 경우) App3가 users에게 표시되지 않기 때문입니다. Device join restrictions는 tenant-wide device governance controls이며, app tile visibility 문제에 대해서는 범위가 잘못된 변경입니다. 시험 관점에서는 증상이 하나의 enterprise application에만 국한되어 있을 때 “broad tenant setting” 변경을 피해야 합니다. 최소 권한의 올바른 범위 remediation은 App3의 enterprise application assignments/visibility를 조정하는 것입니다.

아니요. Users 그룹에 Cloud device administrator 역할을 할당하는 것은 App3의 My Apps portal 표시 여부와 관련이 없습니다. Cloud device administrator 역할은 Entra ID에서 device object를 관리할 수 있는 권한(예: device 활성화/비활성화, 일부 통합 컨텍스트에 따라 BitLocker key 관리)을 제공하며, enterprise application 할당이나 user portal tile을 관리하기 위한 것이 아닙니다. “User assignment required”가 활성화되어 있을 때 App3가 표시되도록 하려면, 사용자(또는 사용자가 속한 그룹, 예: HRUsers)를 Enterprise applications > App3 > Users and groups에서 App3에 할당해야 합니다. 또는 앱이 모든 사용자를 대상으로 하는 경우 “User assignment required”를 비활성화할 수 있지만, 이는 access control posture를 변경하는 것이며 일반적으로 적절한 경우가 아니라면 권장되지 않습니다. 따라서 device admin 역할을 추가하는 것은 근본 원인을 해결하지 못하며, 불필요한 administrative 권한을 부여하여 least privilege 원칙을 위반하게 됩니다.

표시된 access review 설정으로부터 올바른 접근 방식을 판단할 수 있으므로 A (Pass)를 선택합니다. 제시된 자료에는 핵심 매개변수가 제공됩니다: 시작 날짜 (01/15/2021), 빈도 (Monthly), 기간 (14일), 종료 날짜 (02/15/2021), 범위 (Group1 members), 검토자 (Members/self). 이를 통해 누가 응답할 수 있는지(멤버이므로 User1 및 User2만 가능)와 언제 응답이 허용되는지(활성 review 기간 동안)를 추론할 수 있습니다. B (Fail) 옵션은 핵심 정보가 누락된 경우에만 적용됩니다(예: reviewer 유형이나 기간이 표시되지 않은 경우). 여기서는 SC-300에서 평가하는 표준 Access Reviews 동작을 사용하여 모든 하위 질문에 답할 수 있을 만큼 구성이 충분합니다.

User1은 Group1의 멤버이며 액세스 검토는 Reviewers = “Members (self)”로 구성되어 있습니다. 이는 User1이 자신의 액세스에 대한 reviewer로 명시적으로 지정되어 있으며 “Group1에 대한 액세스가 여전히 필요합니까?”라는 프롬프트에 응답할 수 있음을 의미합니다. 문제의 표에는 “Users answer the Review1 question as shown…”라고 나와 있습니다. User1의 경우 기록된 응답은 “Yes”입니다. 따라서 User1의 답변에 대한 올바른 선택은 Yes입니다. 왜 No가 아닌가: 시나리오 어디에도 User1이 No를 선택했다는 내용이 없으며, 자동 의사결정(예: “auto-apply results” 또는 “if no response remove access”)에 대한 설명도 없습니다. 이 하위 문제는 단순히 표에 제공된 사용자의 응답을 반영하라고 묻고 있습니다.

User2도 Group1의 멤버이며, 검토자로 “Members (self)”가 구성되어 있으므로 User2는 자신에 대해 응답할 수 있습니다. 문제에서는 사용자가 표에 표시된 대로 응답했다고 명시하며, User2의 기록된 응답은 “아니요”입니다. 따라서 “User2: 아직도 Group1에 대한 액세스가 필요합니까?”에 대한 올바른 선택은 아니요입니다. 왜 예가 아닌가: access review는 기본적으로 “예”를 추론하지 않습니다. 여기서 테스트되는 것은 사용자의 명시적 응답입니다. 또한 제공된 설정 어디에도 auto-approval rule을 나타내는 내용이 없습니다. access review에서는 각 reviewer의 결정이 각 user별, 각 review instance별로 기록되며, 이 시험은 일반적으로 시나리오에 명시된 응답을 올바른 옵션에 매핑할 수 있는지 확인합니다.

아니요. 첫 번째 review instance는 2021/01/15에 시작하고 기간이 14일이므로, 대략 2021/01/29까지 활성 상태입니다. 2021년 2월 5일은 그 활성 기간 밖입니다. 두 번째 instance가 있을 수 있을까요? monthly frequency인 경우, 다음 instance는 2021/02/15에 시작합니다(2021/01/15로부터 한 달 후). 2월 5일은 여전히 2월 15일 이전이므로, 2021/02/05에는 활성 review instance가 없습니다. 또한, access review 응답은 활성 instance에 연결되며, 사용자는 instance가 열려 있는 동안에만 답변할 수 있습니다. 2021/02/05는 instance 사이의 기간이므로(첫 번째가 종료된 후이고 다음이 시작되기 전), User1은 그 날짜에 Review1 질문에 다시 답변할 수 없습니다.

예. access review는 2021년 1월 15일에 시작하여 14일 동안 열려 있으므로, 1월 25일은 활성 review 기간 내에 해당합니다. 또한 reviewer가 "Members (self)"로 구성되어 있으므로, User2는 해당 열린 기간 동안 자신의 access를 review할 수 있습니다. review가 활성 상태인 동안 reviewer는 자신의 응답을 다시 확인하고 변경할 수 있으므로, User2는 1월 25일에 Review1 질문에 다시 답변할 수 있습니다. 아니요는 올바르지 않습니다. review가 아직 종료되지 않았고, User2는 자격이 있는 reviewer이기 때문입니다.

아니요. User3는 Group1의 owner이지만 member는 아닙니다(member는 User1과 User2뿐입니다). access review는 Reviewers = “Members (self)”로 구성되어 있으며, 이는 검토 대상인 사용자들(그룹 member들)만 reviewer라는 의미입니다. 그룹 ownership은 reviewer 유형에 owner가 포함되지 않는 한(예: “Group owners”) 또는 User3가 검토 대상 집합에도 포함되지 않는 한(Group1의 member인 경우) access review에 참여할 수 있는 권한을 부여하지 않습니다. 어느 쪽도 해당하지 않으므로, User3는 reviewer가 아니며 이 구성에서는 2021년 1월 22일(또는 어떤 날짜에도) Review1 질문에 답변할 수 없습니다. 이것은 흔한 시험 함정입니다. 그룹 owner의 관리 권한과 access review의 reviewer 할당을 혼동하는 것입니다. access review는 구성된 reviewer 선택을 엄격하게 따릅니다.