Practice Test #1
50개 문제와 100분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
3중 AI 검증 답안 및 해설
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
기출 문제
HOTSPOT - Group3라는 그룹과 Department1이라는 administrative unit를 포함하는 Azure Active Directory (Azure AD) 테넌트가 있습니다. Department1에는 Users 보기의 사용자들이 있습니다. (Users 탭을 클릭하세요.)
Department1에는 Groups 보기의 그룹들이 있습니다. (Groups 탭을 클릭하세요.)
Department1에는 Assignments 보기의 user administrator 할당이 표시되어 있습니다. (Assignments 탭을 클릭하세요.)
Group2의 멤버는 Group2 보기와 같습니다. (Group2 탭을 클릭하세요.)
다음 각 문장에 대해, 문장이 참이면 Yes를 선택하세요. 그렇지 않으면 No를 선택하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:
아래 이미지에서 올바른 답을 선택하세요.
Groups 전시는 Department1에 Group1과 Group2가 포함되어 있음을 보여줍니다. 이는 administrative unit 범위의 User Administrator가 해당 administrative unit의 멤버인 그룹을 관리할 수 있기 때문에 중요합니다. 이미지는 원래 시험 맥락에서 메타 Pass/Fail 질문을 묻는 것이 아니라, 단순히 이후 진술에 대한 근거 자료입니다. 따라서 현재 이를 메타 확인으로 처리하는 것은 올바르지 않습니다.
아래 이미지에서 올바른 답을 선택하세요.
Group2 예시는 User3 및 User4가 Group2의 직접 멤버임을 보여줍니다. 이는 administrative unit에 속한 group의 멤버십이 해당 사용자들을 자동으로 administrative unit 자체의 멤버로 만들지는 않기 때문에 중요합니다. 이미지는 Admin1의 scope를 평가하기 위한 보조 컨텍스트이며, 별도의 Pass/Fail 지식 확인이 아닙니다. 따라서 현재 이를 메타 확인으로 처리하는 것은 올바르지 않습니다.
Admin1은 User3 및 User4의 비밀번호를 재설정할 수 있습니다.
Admin1에는 Department1 administrative unit에만 범위가 지정된 User Administrator 역할이 있습니다. Department1에는 사용자로 User1 및 User2가 포함되어 있지만, User3 및 User4는 Group2의 구성원으로만 나타나며 administrative unit의 구성원으로 표시되지 않습니다. Administrative unit 멤버십은 group 멤버십과 별개이므로, Group2 내부에 있다고 해서 User3 또는 User4가 Department1에 속하게 되는 것은 아닙니다. 따라서 Admin1은 User3 및 User4의 비밀번호를 재설정할 수 없으므로, 정답은 아니요입니다.
Admin1은 User1을 Group 2에 추가할 수 있습니다.
Admin1은 Department1 범위로 지정된 User Administrator이며, Group2는 해당 administrative unit에 포함된 그룹입니다. administrative unit 범위로 지정된 User Administrator는 해당 unit 내의 그룹을 관리할 수 있으며, 여기에는 해당 그룹의 멤버십 업데이트도 포함됩니다. User1도 Department1에 있으므로, 대상 그룹과 추가되는 사용자 모두 administrative unit의 범위 내에 있습니다. 따라서 Admin1은 User1을 Group2에 추가할 수 있으므로, 정답은 예입니다.
Admin 2는 User1의 비밀번호를 재설정할 수 있습니다.
Admin2는 전체 Azure AD tenant에 적용되는 Directory scope의 User Administrator role을 가지고 있습니다. Directory-scoped assignment는 administrative unit 경계에 의해 제한되지 않습니다. User1은 tenant의 일반 사용자이며 보호된 privileged role에 대한 언급이 없으므로, Admin2는 User1의 비밀번호를 재설정할 수 있습니다. 따라서 정답은 예입니다.
Microsoft 365 tenant가 있습니다. Sign-ins activity report에 외부 계약자가 Exchange admin center에 로그인한 것으로 표시됩니다. 매월 말에 Exchange admin center에 대한 액세스를 검토하고 필요한 경우 로그인을 차단해야 합니다. 무엇을 만들어야 합니까?
디렉터리 외부 사용자를 대상으로 하는 access package는 entitlement management에서 외부 사용자가 리소스에 대한 액세스를 요청하고 부여받을 수 있도록 하는 데 사용됩니다. Access packages에 만료 및 검토 기능이 포함될 수는 있지만, 이미 감지된 admin 액세스 경로를 매월 기준으로 검토하는 가장 직접적인 도구는 아닙니다. 문제는 구체적으로 반복 검토와 필요한 경우 액세스를 차단하는 기능을 묻고 있으며, 이는 access review로 더 직접적으로 처리됩니다. 이 옵션은 검토 메커니즘 자체보다는 프로비저닝 워크플로에 초점을 둡니다.
디렉터리 내부 사용자를 대상으로 하는 access package는 내부 사용자를 위한 것이므로 외부 계약자 시나리오에는 맞지 않습니다. 또한 기존 privileged access의 주기적 검증보다는 액세스 요청 및 할당 수명 주기를 강조합니다. 문제의 사용자는 외부 사용자이므로 이 옵션은 사용자 범위와 주요 목적 모두에서 맞지 않습니다. 따라서 최선의 답이 아닙니다.
guest users를 대상으로 하는 group-based access review가 가장 적절한 선택입니다. 이는 액세스를 부여하는 그룹의 멤버인 외부 사용자에 대한 반복 검토를 지원하기 때문입니다. Microsoft Entra ID Governance에서 검토가 매월 실행되도록 구성하고 검토자가 각 guest에게 여전히 액세스가 필요한지 확인하도록 할 수 있습니다. 검토자가 액세스를 거부하거나 사용자가 응답하지 않으면 결과를 자동으로 적용하여 guest를 그룹에서 제거할 수 있습니다. 그룹에서 제거되면 계약자는 Exchange admin center에 대한 액세스를 허용했던 권한을 잃게 됩니다.
application-based access review는 enterprise application에 대한 액세스를 대상으로 하지만, Exchange admin center는 일반적으로 표준 app assignment가 아니라 administrative role assignments를 통해 액세스합니다. 계약자의 권한이 역할 또는 그룹에서 오는 경우 application object를 검토하는 것은 실제 privileged access 경로를 신뢰성 있게 관리하지 못할 수 있습니다. 이 시나리오에서는 액세스를 부여하는 그룹에서 guest의 멤버십을 검토하는 것이 더 안전하고 시험 관점에도 더 부합하는 선택입니다. 따라서 이 옵션은 group-based access review보다 덜 적절합니다.
문제 분석
핵심 개념: 이 문제는 Microsoft Entra ID Governance access reviews와 외부 사용자에 대한 privileged access를 주기적으로 검증하는 방법을 테스트합니다. 외부 계약자가 Exchange admin center와 같은 admin 환경에 액세스할 수 있는 경우, 실질적인 거버넌스 제어는 해당 액세스를 부여하는 멤버십을 검토하고 더 이상 액세스가 적절하지 않으면 사용자를 제거하는 것입니다. 정답인 이유: guest users를 대상으로 하는 group-based access review를 사용하면 계약자에게 액세스를 부여하는 그룹의 guest 멤버십을 검토하고, 검토를 매월 예약하며, 거부되거나 응답하지 않은 사용자를 자동으로 제거할 수 있습니다. 해당 administrative permissions를 부여하는 것이 그 그룹이라면, guest를 그 그룹에서 제거하면 지속적인 액세스가 차단됩니다. 이는 매월 말에 액세스를 검토하고 필요한 경우 로그인을 차단해야 한다는 요구 사항을 직접적으로 충족합니다. 주요 기능: - Access reviews는 매월 일정으로 반복되도록 설정할 수 있습니다. - 검토는 guest users를 구체적으로 대상으로 할 수 있습니다. - Auto-apply results를 사용하면 거부되거나 응답이 없는 후 검토된 그룹에서 사용자를 제거할 수 있습니다. - Group-based reviews는 privileged access가 security groups 또는 role-assignable groups를 통해 부여될 때 일반적으로 사용됩니다. - 이는 최소 권한 원칙과 외부 액세스의 주기적 재검증을 지원합니다. 일반적인 오해: access reviews와 access packages를 혼동하기 쉽습니다. Access packages는 주로 액세스를 요청하고 프로비저닝하는 데 사용되며, 기존 admin center 액세스 경로를 직접 검토하는 데 가장 적합한 도구는 아닙니다. 또한 admin center 액세스를 application access로 검토해야 한다고 생각하는 것도 흔한 실수이지만, Microsoft 365 admin 액세스는 일반적으로 일반 enterprise app 할당이 아니라 역할 또는 그룹에 의해 제어됩니다. 시험 팁: - 요구 사항이 주기적 검증이라면 access reviews를 떠올리십시오. - 액세스가 멤버십을 통해 부여된다면 group-based access review를 선택하십시오. - 시나리오가 액세스 요청 및 프로비저닝에 관한 것이라면 access packages를 사용하십시오. - 문제에서 app assignment가 액세스 메커니즘이라고 명확히 언급하지 않는 한 Microsoft admin portals에 대한 application-based reviews는 주의해서 선택하십시오.
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. Microsoft 365 tenant가 있습니다. 10개 부서로 구성된 100명의 IT 관리자가 있습니다. 전시된 access review를 생성합니다. (Exhibit 탭을 클릭하세요.)
모든 access review 요청이 Megan Bowen에게 수신되는 것을 발견합니다. 각 부서의 관리자가 해당 부서의 access review를 받도록 해야 합니다. 해결 방법: IT 관리자 사용자 계정의 속성을 수정합니다. 이것이 목표를 충족합니까?
아래 이미지에서 올바른 답을 선택하세요.
Pass. IT administrator 사용자 계정의 속성을 수정하면 목표를 달성할 수 있습니다. access review가 reviewer로 “(Preview) Manager”를 사용하도록 구성되어 있기 때문입니다. 이 설정은 검토 대상 각 사용자에게 Microsoft Entra ID에서 Manager attribute가 채워져 있어야 합니다. 사용자에게 Manager 필드가 없으면 Entra ID는 누가 검토해야 하는지 확인할 수 없으며, 요청을 구성된 fallback reviewer(Megan Bowen)에게 보냅니다. 이는 관찰된 동작과 일치합니다. 각 부서 manager가 해당 부서의 review를 받도록 하려면, 각 IT admin의 Manager를 올바른 부서 manager로 설정해야 합니다(또는 hybrid 환경인 경우 on-premises AD에서 올바르게 동기화되도록 해야 합니다). manager가 올바르게 할당되면 review 요청은 해당 manager에게 라우팅되고, manager가 없는 사용자만 fallback reviewer에게 전달됩니다. 다른 대안(여기서는 선택되지 않음)은 review 구성을 변경하여 group별로 특정 reviewer를 사용하도록 하는 것이지만, 제안된 솔루션은 “Manager” reviewer type의 종속성을 직접 해결합니다.
DRAG DROP - Microsoft 365 E5 tenant가 있습니다. App1이라는 cloud app을 구매합니다. Microsoft Cloud App Security를 사용하여 App1의 실시간 session-level monitoring을 사용하도록 설정해야 합니다. 어떤 순서로 작업을 수행해야 합니까? 답하려면 작업 목록에서 적절한 작업을 답 영역으로 이동하고 올바른 순서로 정렬하십시오. Select and Place:
아래 이미지에서 올바른 답을 선택하세요.
정답. Microsoft Cloud App Security (Defender for Cloud Apps)로 real-time session-level monitoring을 활성화하기 위한 올바른 작업 순서는 다음과 같습니다: 1) Azure Active Directory (Azure AD)에서 App1을 게시합니다 (그래서 Entra ID와 통합된 enterprise app이 되어 SSO/Conditional Access 대상 지정이 가능해집니다). 2) Microsoft Cloud App Security에서 App1의 Connected apps 설정을 수정합니다 (Conditional Access App Control/reverse proxy를 위해 앱을 구성/온보딩하여 세션을 모니터링할 수 있게 합니다). 3) Microsoft Cloud App Security에서 session policy를 생성합니다 (monitor-only, block download, protect downloads 등과 같은 real-time monitoring/controls를 정의합니다). 4) session controls가 구성된 conditional access policy를 생성합니다 ("Use Conditional Access App Control"을 설정하여 세션을 proxy를 통해 라우팅하고 session policy를 적용합니다). 다르게 순서를 정했을 때 다른 선택지가 틀린 이유: 앱이 게시/온보딩되기 전에 Conditional Access policy를 생성하면 앱을 올바르게 대상으로 지정하거나 proxy 처리할 수 없습니다. proxy 라우팅을 활성화하지 않고 session policy를 생성하면 real time으로 적용되지 않습니다.
네트워크에는 contoso.com이라는 이름의 Active Directory forest가 있으며, 이 forest는 Azure AD Connect를 사용하여 contoso.com이라는 이름의 Azure Active Directory (Azure AD) tenant에 연결되어 있습니다. extensionAttribute15 attribute가 NoSync로 설정된 사용자의 동기화를 방지해야 합니다. Azure AD Connect에서 무엇을 해야 합니까?
오답입니다. Windows Azure Active Directory (Microsoft Entra ID) connector에 대한 inbound synchronization rule은 Azure AD의 object가 metaverse로 흐르는 방식(Azure AD -> metaverse)에 영향을 줍니다. 이는 어떤 on-prem AD 사용자가 import되고 export를 위해 staging되는지를 제어하지 않습니다. extensionAttribute15는 on-prem AD에서 제공되므로 filtering은 AD DS connector의 inbound path에 적용되어야 합니다.
오답입니다. Full Import run profile은 연결된 directory에서 connector space로 object를 다시 읽어오는 역할만 합니다. filtering criteria를 정의하지는 않습니다. 변경 후 Full Import/Full Sync를 실행할 수는 있지만, run profile 자체는 synchronization을 방지하는 메커니즘이 아닙니다. 실제 메커니즘은 synchronization rule(scoping/filtering)입니다.
정답입니다. Active Directory Domain Services connector에 대한 inbound synchronization rule을 생성하는 것은 on-prem AD에서 시작되는 object에 대해 attribute-based filtering을 구현하는 표준 방법입니다. extensionAttribute15가 "NoSync"로 설정된 사용자가 metaverse에 projected/joined되지 않도록 rule의 scope를 설정할 수 있으며, 이를 통해 해당 사용자가 Azure AD로 export되는 것을 방지할 수 있습니다.
오답입니다. Export run profile은 connector space의 보류 중인 변경 내용을 연결된 directory로 푸시할 뿐입니다(예: Azure AD connector를 통해 metaverse -> Azure AD). 어떤 object가 synchronization 범위에 포함되는지는 결정하지 않습니다. 사용자가 이미 metaverse/connector space에 있다면 export는 변경 내용을 전송하려고 시도합니다. filtering은 export 구성으로 하는 것이 아니라 synchronization rule을 통해 수행해야 합니다.
문제 분석
핵심 개념: 이 문제는 Azure AD Connect sync engine (Microsoft Entra Connect)에서 custom synchronization rule을 사용한 Azure AD Connect synchronization filtering을 테스트합니다. Attribute-based filtering은 on-premises Active Directory connector의 inbound rule을 통해 metaverse join/projection flow를 수정하여 구현됩니다. 정답인 이유: extensionAttribute15가 on-premises AD에서 "NoSync"와 같을 때 사용자의 동기화를 방지하는 것이 요구 사항입니다. extensionAttribute15는 AD attribute이므로, 이를 평가하는 올바른 위치는 Active Directory Domain Services (AD DS)에서 metaverse로 들어오는 inbound path입니다. AD DS connector에 대해 scoping filter(또는 object가 projected/joined되지 않도록 하는 transformation)를 설정하는 inbound synchronization rule을 생성(또는 복제 후 사용자 지정)하여 extensionAttribute15=NoSync인 object가 synchronization에서 제외되도록 합니다. 이렇게 하면 해당 사용자는 metaverse에 들어가지 않으므로 Microsoft Entra ID (Azure AD)로 export되지 않습니다. 주요 기능 및 모범 사례: - Synchronization Rules Editor를 사용하여 custom inbound rule을 생성하고(일반적으로 기본 “In from AD - User Join”/“In from AD - User Common” 패턴을 복제), scoping filter를 추가합니다: extensionAttribute15 EQUAL NoSync. 그런 다음 extensionAttribute15가 NoSync가 아닌 object만 포함되도록 rule을 구성하거나, precedence를 사용하여 제외 로직이 우선 적용되도록 합니다. - 업그레이드 가능성을 유지하기 위해 custom rule은 기본 rule과 분리하여 유지합니다(기본값을 직접 편집하지 말고 복제). - rule을 변경한 후에는 새 scoping이 일관되게 적용되도록 Full Synchronization (Full Import + Full Sync)을 실행합니다. 일반적인 오해: 대상이 Azure AD이므로 filtering도 Azure AD connector에서 수행해야 한다고 생각하는 경우가 많습니다. 그러나 Azure AD connector의 inbound rule은 Azure AD object가 metaverse로 흐르는 방식(Azure AD -> metaverse)을 제어하며(주로 writeback 또는 hybrid 시나리오에서 사용), AD object가 export 대상으로 선택되는 방식을 제어하지는 않습니다. Run profile(Full Import/Export)은 처리 단계를 제어할 뿐, filtering logic을 제어하지 않습니다. 시험 팁: - filtering에 사용되는 attribute가 on-prem AD에 있다면, “AD DS connector inbound rule”을 떠올리십시오. - 포함/제외에는 sync rule을 사용하고, import/sync/export 실행에는 run profile만 사용하십시오. - rule 방향을 기억하십시오: AD DS inbound = AD에서 metaverse로, Azure AD outbound = metaverse에서 Azure AD로.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Identity Governance를 사용하여 애플리케이션 액세스 할당을 추적해야 합니다. 솔루션은 delegation 요구 사항을 충족해야 합니다. 가장 먼저 무엇을 해야 합니까?
User consent settings를 수정하면 최종 사용자가 admin 개입 없이 애플리케이션이 자신의 데이터에 액세스할 수 있도록 permissions(OAuth scopes)을 부여할 수 있는지에 영향을 줍니다. 이는 permission consent에 관한 것이지, enterprise application에 사용자를 할당하고 governance 워크플로를 통해 해당 할당을 추적하는 것에 관한 것이 아닙니다. delegated management boundaries를 설정하지도 않고 access package 기반 추적도 제공하지 않습니다.
delegation이 필요한 Entitlement Management에서 catalog를 생성하는 것이 올바른 첫 단계입니다. Catalogs는 catalog owners가 리소스(예: enterprise applications)를 추가하고 access packages를 관리할 수 있는 administrative boundary를 정의합니다. 이를 통해 일상적인 운영에 global administrators가 필요하지 않으면서도 승인, 만료 및 검토를 통해 액세스 할당을 추적하고 governance를 수행할 수 있습니다.
program을 생성하는 것은 이 작업의 올바른 첫 단계가 아닙니다. Microsoft Entra entitlement management에서 액세스 할당을 governance하고 추적하려면 먼저 catalog를 생성해야 합니다. catalog는 delegated administration과 리소스 구성을 지원하는 컨테이너이기 때문입니다. catalog가 존재한 후에야 enterprise application을 리소스로 추가하고 그 주위에 access packages와 policies를 구축할 수 있습니다.
Admin consent request settings는 사용자가 스스로 consent할 수 없을 때 애플리케이션 permissions(consent)에 대해 admin 승인을 요청하는 방식을 제어합니다. 이는 entitlement management의 액세스 할당 추적 및 delegation 모델과는 관련이 없습니다. 누가 access packages를 관리하는지 위임하는 데 도움이 되지 않으며, 앱 할당에 대한 만료 및 access reviews와 같은 lifecycle controls도 제공하지 않습니다.
문제 분석
핵심 개념: 이 문제는 Microsoft Entra ID Identity Governance, 특히 Entitlement Management에 관한 것으로, access packages를 통해 애플리케이션, 그룹 및 SharePoint 사이트에 대한 액세스 할당을 관리하고 추적하는 데 사용됩니다. delegation 요구 사항은 일반적으로 서로 다른 사람이 global admin이 아니어도 액세스를 관리할 수 있도록 함을 의미합니다(catalog owners, access package managers, approvers). 정답인 이유: Identity Governance(Entitlement Management)를 사용하여 애플리케이션 액세스 할당을 추적하려면 리소스(예: enterprise applications)를 delegation 및 관리가 가능한 컨테이너에 배치해야 합니다. 가장 먼저 필요한 기본 단계는 catalog를 생성하는 것입니다. catalog는 delegation의 경계입니다. catalog owners를 할당하여 해당 catalog 내에서 리소스를 추가하고 access packages를 생성/관리할 수 있게 합니다. catalog가 없으면 리소스와 access packages의 소유권 범위를 적절히 지정하고 관리를 위임할 수 없습니다. 주요 기능 및 모범 사례: - Catalogs는 정의된 범위 내에서 non-admin 사용자가 리소스와 access packages를 관리할 수 있도록 하여 delegated administration을 가능하게 합니다. - catalog를 생성한 후 enterprise application을 리소스로 추가하고, access package를 생성하고, 정책(누가 요청할 수 있는지, 승인, 만료)을 정의하며, 지속적인 governance를 위해 access reviews를 사용합니다. - 이는 Azure Well-Architected Framework의 보안 원칙인 least privilege, centralized governance, auditable access lifecycle(request, approval, assignment, review, removal)와 일치합니다. 일반적인 오해: 많은 응시자는 “액세스 할당 추적”을 consent settings와 혼동합니다. User/admin consent settings는 앱에 OAuth permissions가 부여되는 방식을 제어하며, governance 워크플로를 통해 시간이 지남에 따라 사용자에게 앱을 할당하는 방식을 제어하는 것이 아닙니다. consent는 앱에 대한 permissions에 관한 것이고, entitlement management는 액세스 lifecycle 및 delegation에 관한 것입니다. 시험 팁: “Identity Governance”, “delegation”, “track assignments”, “access packages”, 또는 “Entitlement Management”가 보이면 다음을 떠올리세요: Catalog -> 리소스 추가 -> access package -> policies/approvals/reviews. consent settings(user/admin consent)는 일반적으로 application registration 및 enterprise app permission governance에서 테스트되며, entitlement management delegation이 아닙니다.
DRAG DROP - User1, User2 및 User3라는 세 명의 사용자가 포함된 Microsoft 365 E5 구독이 있습니다. 다음 표에 표시된 대로 사용자를 구성해야 합니다.
각 사용자를 구성하려면 어떤 portal을 사용해야 합니까? 답하려면 적절한 portal을 올바른 사용자에게 끌어다 놓으십시오. 각 portal은 한 번, 여러 번 또는 전혀 사용되지 않을 수 있습니다. 콘텐츠를 보려면 창 사이의 분할 막대를 끌거나 스크롤해야 할 수 있습니다. 참고: 각 정답 선택에는 1점이 부여됩니다. 선택 후 배치:
User1: User administrator 역할
예. “User administrator” 역할은 Microsoft Entra ID (Azure AD)의 기본 제공 directory 역할입니다. 이 역할은 tenant 설정 및 역할 범위에 따라 사용자 및 그룹 관리 권한(예: 사용자 생성 및 삭제, 비관리자 사용자의 암호 재설정, 그룹 멤버십 관리)을 부여합니다. 이 시나리오에서는 User1이 User administrator 역할로 구성되어야 하므로 올바른 선택은 예입니다. 이것은 Exchange, Purview 또는 Intune RBAC 역할이 아니며, identity 관리를 위해 사용되는 directory 역할입니다. 시험에서는 사용자/그룹에 대한 “administrator role”과 같은 키워드는 문제에서 명시적으로 “role group”(Exchange), “compliance role”(Purview) 또는 “Intune role”(Endpoint Manager)이라고 하지 않는 한 일반적으로 Entra directory 역할을 의미합니다.
User1: Device Administrators 역할
예. “Device Administrators”는 Microsoft Entra ID (Azure AD) 디렉터리 역할입니다(종종 “Azure AD Joined Device Local Administrator” 기능으로 표시됨). 멤버는 디바이스 설정에 따라 Azure AD-joined 디바이스에서 로컬 관리자 권한을 부여받을 수 있습니다. 요구 사항에 User1에게 Device Administrators 역할이 필요하다고 명시되어 있으므로, 정답은 예입니다. 이것은 Intune RBAC 역할이 아닙니다. Intune RBAC는 Intune 내부의 관리 작업을 제어하는 반면, “Device Administrators”는 Azure AD-joined 디바이스에 대한 디바이스 수준 로컬 관리자 할당 동작을 제어하는 디렉터리 역할입니다. SC-300에서는 디바이스 관련 디렉터리 역할이 여전히 Exchange나 Purview가 아니라 Entra ID에 있다는 점을 알아두세요.
User1: Identity Governance Administrator 역할
예. “Identity Governance Administrator”는 entitlement management, access reviews, lifecycle workflows(라이선스 및 기능 가용성에 따라 다름)와 같은 identity governance 기능을 관리하는 데 사용되는 Microsoft Entra ID (Azure AD) 기본 제공 역할입니다. User1은 Identity Governance Administrator 역할로 구성되어야 하므로, 올바른 선택은 예입니다. 이것은 Purview compliance 역할이 아닙니다. “governance”라는 단어가 포함되어 있지만, identity governance는 Entra 기능(access packages, access reviews)이며 Entra admin 환경을 통해 관리됩니다. 시험에서는 “Identity Governance”가 Microsoft Purview가 아니라 Entra ID를 강하게 의미합니다.
User2: Records Management 역할
예. “Records Management”는 retention labels, record declaration, disposition reviews(구성에 따라 다름)와 같은 records management 기능을 관리하는 데 사용되는 Microsoft Purview(Microsoft 365 compliance) 역할입니다. User2는 Records Management 역할로 구성되어야 하므로 정답은 예입니다. 이것은 Entra directory 역할도 아니고 Exchange role group도 아닙니다. 시험 관점에서 retention, records, eDiscovery, audit 또는 compliance policies와 관련된 항목은 일반적으로 compliance role groups/permissions를 사용하여 Microsoft 365 compliance(Purview) portal에서 할당됩니다.
User2: Quarantine Administrator 역할 그룹
예. “Quarantine Administrator”는 격리된 메시지 관리(보기, 릴리스, 보고)를 허용하는 Exchange Online/EOP 관련 역할 그룹입니다. Microsoft 365에서 quarantine은 Exchange Online Protection/Defender for Office 365와 연결된 이메일 보안 운영의 일부입니다. 따라서 User2에 Quarantine Administrator 역할 그룹이 있어야 한다면, 올바른 선택은 예입니다. 이것은 Purview records/compliance 권한이 아니며 Entra 디렉터리 역할도 아닙니다. 이 문제의 핵심 단서는 “role group”이라는 문구와 “Quarantine”이라는 용어이며, 이는 Entra ID가 아니라 Exchange/보안 메일 흐름 제어에서 관리됩니다.
User3: Endpoint Security Manager 역할
예. “Endpoint Security Manager”는 Intune (Microsoft Endpoint Manager) RBAC 역할입니다. 이 역할은 security baselines, endpoint security policies (AV, firewall, disk encryption) 및 관련 구성과 같이 Intune 내의 endpoint security 기능을 관리하는 데 사용됩니다. User3에 Endpoint Security Manager 역할을 구성해야 하므로 정답은 예입니다. 이것은 Entra directory 역할(tenant 전체의 identity 역할)이 아니며 Exchange/Purview 역할도 아닙니다. SC-300에서는 Intune RBAC 역할이 Endpoint Manager admin center에서 할당되며, Intune의 management plane 내 작업을 제어한다는 점을 기억하세요.
User3: Intune Role Administrator 역할
예. “Intune Role Administrator”는 Microsoft Endpoint Manager 내에서 Intune 역할 및 할당(RBAC administration)을 관리할 수 있도록 하는 Intune RBAC 역할입니다. User3는 Intune Role Administrator 역할로 구성되어야 하므로, 올바른 선택은 예입니다. 이는 Privileged Role Administrator와 같은 Entra 역할과는 구별됩니다. Intune Role Administrator는 Intune RBAC 범위로 한정됩니다. 시험 패턴상 역할 이름에 명시적으로 “Intune”이 포함되어 있으면 Entra admin center가 아니라 Microsoft Endpoint Manager admin center에서 관리됩니다.
User1: ______
User1은 Azure Active Directory admin center(Microsoft Entra admin center)에서 구성해야 합니다. User1에 필요한 역할인 User administrator, Device Administrators, Identity Governance Administrator는 모두 Microsoft Entra ID(Azure AD) directory 역할입니다. Directory 역할은 Entra/Azure AD portal의 Roles and administrators에서 할당 및 관리됩니다(또는 eligible/just-in-time이 사용되는 경우 Privileged Identity Management를 통해 관리됨). Exchange admin center는 Exchange 역할 그룹용이고, Microsoft 365 compliance center는 Purview compliance 권한용이며, Endpoint Manager는 Intune RBAC용입니다. 따라서 User1에 대한 올바른 portal은 Azure Active Directory admin center입니다.
User2: ______
User2는 Records Management 역할이 그곳에 할당되는 Microsoft Purview compliance 역할이므로 Microsoft 365 compliance center에 매핑됩니다. 그러나 Quarantine Administrator는 Exchange Online/EOP 역할 그룹이며 일반적으로 Exchange admin center에서 할당됩니다. 이 drag-and-drop은 사용자당 하나의 portal을 요구하므로, 예상 정답은 Records Management 요구 사항을 기준으로 User2에 대해 compliance center입니다. 다른 옵션들은 전반적으로 적절하지 않습니다: Azure AD는 Entra directory 역할용이고, Endpoint Manager는 Intune RBAC용이며, SharePoint admin center는 관련이 없습니다.
User3: ______
User3는 Microsoft Endpoint Manager admin center에서 구성해야 합니다. 필요한 두 역할인 Endpoint Security Manager와 Intune Role Administrator는 모두 Intune RBAC 역할입니다. Intune RBAC 역할은 Endpoint Manager admin center(Intune admin center)에서 생성/할당되고 범위가 지정됩니다(그룹, scope tags 및 역할 할당에 대해). 이러한 권한은 사용자가 Intune 내에서 수행할 수 있는 작업(device configuration, endpoint security policies, RBAC management)을 제어합니다. 이러한 역할은 Azure AD admin center에서 할당되지 않으며(Entra directory roles를 할당하는 경우는 제외), Exchange 또는 Purview와도 관련이 없습니다. 따라서 User3에 대한 올바른 포털은 Microsoft Endpoint Manager admin center입니다.
contoso.com이라는 이름의 Azure Active Directory (Azure AD) tenant가 있습니다. 회사 이름이 Fabrikam, Inc.인 사용자의 리소스 액세스를 제공하기 위해 entitlement management를 구현합니다. Fabrikam은 fabrikam.com이라는 domain을 사용합니다. 액세스가 더 이상 필요하지 않을 때 Fabrikam 사용자는 tenant에서 자동으로 제거되어야 합니다. 다음 설정을 구성해야 합니다: ✑ Block external user from signing in to this directory: 아니요 ✑ Remove external user: 예 ✑ Number of days before removing external user from this directory: 90 Identity Governance blade에서 무엇을 구성해야 합니까?
Access packages는 group, application, SharePoint site와 같은 리소스를 묶고 requestor, approval, expiration과 같은 assignment policy를 정의하는 데 사용됩니다. 이는 누가 액세스를 요청할 수 있는지와 해당 access package assignment가 얼마나 오래 지속되는지를 제어하지만, 문제에 나열된 tenant 전체 외부 사용자 lifecycle 설정이 있는 곳은 아닙니다. 외부 사용자의 sign in 차단, directory에서 외부 사용자 제거, 제거 전 일 수 지정 옵션은 access package별로 구성되지 않습니다. 따라서 Access packages는 이러한 설정에 대한 올바른 blade가 아닙니다.
Entitlement management settings가 올바른 위치인 이유는 이것이 entitlement management를 통해 관리되는 외부 사용자의 lifecycle에 대한 tenant 수준 제어이기 때문입니다. 문제에 나온 특정 설정들—sign-in 차단 여부, 외부 사용자 제거 여부, 제거 전 대기 일 수—은 개별 리소스가 아니라 entitlement management settings 영역에서 구성합니다. 이를 통해 Azure AD는 마지막 access package assignment가 종료된 후 guest account를 자동으로 정리할 수 있으며, 이는 액세스가 더 이상 필요하지 않을 때 Fabrikam 사용자를 제거해야 한다는 요구 사항을 직접 충족합니다. 시험에서는 entitlement management와 연결된 외부 사용자 lifecycle 설정이 보이면 package 수준 구성이 아니라 settings 페이지를 떠올리십시오.
Terms of use는 사용자가 리소스에 액세스하기 전에 수락해야 하는 법적 또는 규정 준수 고지를 제시하기 위한 것입니다. 일반적으로 수락을 강제하기 위해 Conditional Access와 통합되지만, guest account deprovisioning 또는 directory 정리와는 관련이 없습니다. 문제의 설정은 액세스가 더 이상 필요하지 않을 때 외부 사용자에게 어떤 일이 발생하는지에 대한 것이며, 이는 Terms of use의 범위를 벗어납니다. 따라서 이 옵션은 올바르지 않습니다.
Access reviews settings는 group, application 및 privileged role에 대한 사용자 액세스의 정기적인 검토를 관리하는 데 사용됩니다. 액세스를 유지할지 제거할지 결정하는 데 도움이 될 수는 있지만, 문제에 명시된 정확한 entitlement management guest lifecycle 설정을 제공하지는 않습니다. 특히 외부 sign-in 차단, 외부 user object 제거, 지연 제거 기간 설정에 대한 제어는 access review settings가 아니라 entitlement management settings의 일부입니다. Access reviews는 entitlement management를 보완할 수는 있지만, 이 요구 사항을 구성하는 위치는 아닙니다.
문제 분석
핵심 개념: 이 문제는 Microsoft Entra ID (Azure AD) Identity Governance, 특히 외부(B2B) 사용자에 대한 Entitlement Management 제어와 더 이상 액세스가 필요하지 않을 때 해당 사용자를 tenant에서 자동으로 제거하는 방법을 테스트합니다. 나열된 설정(block sign-in, remove external user, 그리고 제거 전 일 수)은 tenant 수준의 Entitlement Management lifecycle 제어입니다. 정답인 이유: 필요한 세 가지 설정은 Identity Governance > Entitlement management > Settings 영역(일반적으로 “Entitlement management settings”라고 함)에서 구성합니다. 이곳에서 마지막 access package assignment가 종료된 후 외부 사용자에게 어떤 일이 발생할지 정의하며, 여기에는 사용자가 계속 sign in할 수 있는지 여부와 지정된 일 수 후 directory에서 자동으로 제거할지 여부가 포함됩니다. 요구 사항을 충족하려면 다음과 같이 설정합니다: - Block external user from signing in to this directory: 아니요 - Remove external user: 예 - Number of days before removing external user from this directory: 90 이 설정은 액세스가 더 이상 필요하지 않은 후 Fabrikam guest account가 자동으로 정리되도록 하여 least privilege를 지원하고 남아 있는 guest 위험을 줄입니다. 주요 기능 및 모범 사례: - Entitlement Management는 access package를 통해 시간 제한이 있는 액세스를 제공하며 expiration 및 assignment policy를 적용할 수 있습니다. - “Remove external user” 설정은 “guest account sprawl”을 방지하는 데 도움이 되는 governance 제어입니다. - Azure Well-Architected Framework의 security pillar와 일치합니다: attack surface 감소, lifecycle management 적용, deprovisioning 자동화. - 실제 시나리오에서 조직은 즉시 다시 초대해야 하는 오버헤드 없이 재요청을 수용하기 위해 일반적으로 30/60/90일과 같은 grace period를 선택합니다. 일반적인 오해: 많은 사람이 이것이 access package별로 구성된다고 생각하지만, 이러한 특정 토글(block sign-in 및 일 수를 포함한 remove external user)은 package별 설정이 아닙니다. 이는 entitlement management에 의해 관리되는 외부 사용자에게 적용되는 Entitlement Management tenant 설정입니다. 시험 팁: - “Remove external user”와 “Number of days before removing external user”가 보이면 access reviews가 아니라 Entitlement management settings(tenant 수준)를 떠올리십시오. - Access reviews는 group/app 액세스를 제거할 수 있지만, 이 특정 구성 UI를 직접 나타내지는 않습니다. - Terms of use는 사용자 동의에 관한 것이지 lifecycle 제거에 관한 것이 아닙니다. (참고: Entitlement management settings 및 외부 사용자 lifecycle 동작에 대한 Microsoft Entra ID Identity Governance 설명서.)
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 사용자는 Azure Monitor를 사용하여 Azure Active Directory (Azure AD) 활동 로그를 분석합니다. 매일 Azure AD 사용자 로그인 실패 시도에 대한 이메일 경고를 100개 이상 받습니다. 사용자 대신 새로운 보안 관리자가 경고를 받도록 해야 합니다. 솔루션: Azure AD에서 Diagnostics settings를 수정합니다. 이것이 목표를 충족합니까?
예는 올바르지 않습니다. Diagnostics settings는 Azure Monitor 알림 수신자를 관리하지 않습니다. 이는 Microsoft Entra 로그를 모니터링 또는 스토리지 대상으로 내보내는 데 사용되며, 누가 경고 이메일을 받는지 변경하는 역할은 하지 않습니다. 로그인 실패 경고를 새로운 보안 관리자에게 보내려면, 올바른 변경 위치는 Azure Monitor action group 또는 alert rule 구성입니다.
아니요: GitHub app connector를 추가해도 OAuth authentication/consent request 모니터링은 활성화되지 않습니다. OAuth request는 consent grant, permission 및 token issuance를 추적하는 identity provider signal(Microsoft Entra ID 및/또는 Google Workspace)과 OAuth app governance 기능을 통해 모니터링하는 것이 가장 적절합니다. GitHub connector는 GitHub 측 event에 초점을 맞추며, 그 자체만으로는 명시된 모니터링 요구 사항을 충족하지 않습니다.
문제 분석
핵심 개념: Microsoft Defender for Cloud Apps (MDCA) app connector는 연결된 SaaS 앱의 활동에 대한 가시성과 제어를 제공합니다. OAuth authentication request를 모니터링하는 것은 특히 OAuth 기반 액세스(OAuth app)와 타사 앱에 토큰을 부여하는 consent/authorization flow를 검색하고 관리하는 것과 관련이 있습니다. 정답인 이유: Microsoft 365 Defender portal에서 GitHub app connector를 추가하는 것은 OAuth authentication request를 모니터링한다는 목표를 충족하지 않습니다. GitHub connector는 GitHub audit/activity 데이터(예: repository 및 organization event)를 MDCA로 수집하여 governance 및 threat detection을 수행하도록 설계되었습니다. 이 connector는 Microsoft Entra ID (Azure AD) 또는 Google Workspace에서 발생하는 OAuth consent 및 token grant를 모니터링하는 데 필요한 OAuth app governance signal을 제공하지 않습니다. OAuth authentication/consent request를 모니터링하려면 일반적으로 Microsoft Entra ID(및 지원되는 경우 Google Workspace)와 통합되는 OAuth app governance 기능을 사용하여 OAuth app, 위험한 permission, 비정상적인 consent 동작을 탐지하고 제어합니다. 주요 기능 및 모범 사례: - Microsoft identity의 경우, OAuth app, permission 및 consent event에 대한 가시성을 확보하려면 MDCA/Defender for Cloud Apps와 Microsoft Entra ID 통합을 구성하고(관련 로그 활성화) 사용합니다. - OAuth app governance(사용 가능한 경우)를 사용하여 app publisher verification, permission risk를 평가하고 app 비활성화 또는 consent 취소를 통해 수정합니다. - Azure Well-Architected Framework(Security pillar)에 맞춰 OAuth permission에 최소 권한 원칙을 적용하고, consent를 지속적으로 모니터링하며, governance control(admin consent workflow, publisher verification, 해당되는 경우 conditional access)을 구현합니다. 일반적인 오해: "어떤 app connector든" OAuth 모니터링을 활성화한다고 생각하기 쉽습니다. 실제로 connector는 해당 SaaS 앱의 telemetry 범위로 제한됩니다. GitHub connector의 가시성은 GitHub event에 관한 것이며, identity provider의 OAuth consent flow에 관한 것이 아닙니다. OAuth authentication request는 주로 GitHub connector 데이터 내에서가 아니라 identity provider(Entra ID/Google)에서 관찰됩니다. 시험 팁: SC-300에서는 (1) MDCA connector를 통한 SaaS 활동 모니터링과 (2) Entra ID 및 OAuth app governance를 통한 OAuth app/consent governance를 구분하세요. 문제에서 "OAuth authentication/consent request"를 언급하면, GitHub와 같은 일반적인 SaaS connector가 아니라 identity provider 통합과 OAuth app governance를 떠올리세요.
다음을 포함하는 Azure Active Directory (Azure AD) tenant가 있습니다: User1이라는 사용자가 포함되어 있습니다. User1이 새 catalog를 만들고 자신이 소유한 catalog에 리소스를 추가할 수 있도록 해야 합니다. 어떻게 해야 합니까?
오답입니다. Groups administrator 역할은 group 관리(create/update/delete group, membership 관리)를 허용하지만 Entitlement Management catalog 생성을 제어하지는 않습니다. Catalog 생성은 Identity Governance 아래의 Entitlement management settings에 의해 관리됩니다. User1이 Groups administrator이더라도 tenant settings가 이를 제한하면 catalog 생성이 여전히 차단될 수 있습니다.
오답입니다. Service support administrator는 지원 중심 역할이며 Identity Governance/Entitlement Management 기능과 관련이 없습니다. 이 역할은 catalog를 만들거나 catalog 리소스를 관리할 권한을 부여하지 않습니다. 이 선택지는 directory 지원 역할과 governance 기능 권한을 구분할 수 있는지를 테스트하는 distractor입니다.
정답입니다. Identity Governance > Entitlement management settings에서 누가 catalog를 만들 수 있는지와 catalog owner가 리소스를 추가할 수 있는지에 영향을 주는 관련 제어를 구성합니다. 이곳은 User1(또는 User1을 포함하는 group)이 catalog를 만들고 자신이 소유한 catalog 내에서 리소스를 관리할 수 있도록 활성화하는 적절한 위치이며, tenant 전체 governance settings와도 일치합니다.
오답입니다. General catalog의 roles and administrators를 수정하는 것은 해당 단일 기존 catalog 내의 권한에만 영향을 줍니다. 새 catalog를 만들 수 있는 권한은 부여하지 않습니다. 또한 요구 사항에는 새 catalog 생성이 포함되어 있는데, 이는 하나의 catalog에 범위가 지정된 역할이 아니라 tenant 수준의 Entitlement management settings에 의해 제어됩니다.
문제 분석
핵심 개념: 이 문제는 Microsoft Entra ID (Azure AD) Identity Governance, 특히 Entitlement Management catalog와 누가 catalog를 만들고 자신이 소유한 catalog 내에서 리소스를 관리할 수 있는지를 제어하는 tenant 전체 설정을 다룹니다. Catalog는 access package와 해당 리소스(group, app, SharePoint site 등)를 담는 컨테이너입니다. 정답이 맞는 이유: User1이 새 catalog를 만들고 자신이 소유한 catalog에 리소스를 추가할 수 있도록 하려면, Entitlement Management settings에서 non-admin 사용자(또는 특정 사용자 집합)가 catalog를 만들 수 있도록 활성화/허용해야 합니다. 이는 Identity Governance (Entitlement management) settings에서 수행하며, 여기서 누가 catalog를 만들 수 있는지와 catalog owner가 리소스를 추가할 수 있는지를 구성합니다. 이러한 설정은 tenant 수준 제어이며, 이 설정이 없으면 사용자가 catalog owner이더라도 구성된 제한에 따라 catalog 생성이나 리소스 추가가 차단될 수 있습니다. 주요 기능 및 모범 사례: - Entitlement management settings에는 “누가 catalog를 만들 수 있는가” (예: admin만, 모든 사용자, 선택된 사용자/group) 및 관련 governance 제어가 포함됩니다. - Catalog owner는 자신의 catalog를 관리할 수 있지만, 그 기능은 tenant settings와 리소스별 권한에 의해 제한됩니다(예: Azure AD group를 리소스로 추가하려면 해당 group에 대한 권한이 있거나 이를 요청할 수 있도록 허용되어야 함). - Azure Well-Architected Framework 관점(Security 및 Governance pillar)에서, 승인된 사용자/group로 catalog 생성을 제한하면 sprawl를 줄이고 일관된 access governance를 보장할 수 있습니다. 일반적인 오해: - Azure AD admin 역할(예: Groups administrator)을 할당해도 Entitlement Management catalog 생성 권한이 직접 부여되지는 않습니다. 이러한 역할은 directory object를 관리하며 entitlement management policy를 관리하지 않습니다. - “General” catalog의 역할을 수정하는 것은 해당 특정 catalog에만 영향을 주며 User1이 새 catalog를 만들 수 있게 하지는 않습니다. 시험 팁: - Entitlement Management에서는 (1) tenant 전체 Entitlement management settings와 (2) catalog별 역할(catalog owner/reader) 및 access package별 policy의 구분을 기억하세요. - 요구 사항에 “새 catalog 생성”이 언급되면 먼저 tenant settings를 떠올리세요. “특정 catalog 관리”가 언급되면 catalog 역할을 떠올리세요. - SC-300은 Identity Governance 기능을 어디에서 구성하는지 자주 묻습니다: Azure AD directory 역할이 아니라 Identity Governance 블레이드입니다.
지금 학습 시작하기
Cloud Pass를 다운로드하고 모든 Microsoft SC-300 기출 문제를 풀어보세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
앱 받기
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.