Microsoft SC-300

Guest Inviter role의 Admins 및 users는 초대할 수 있습니다: 예. Azure AD External Identities에서 “Guest invite settings”에는 administrators 및 Guest Inviter role이 할당된 users가 external users를 초대하도록 명시적으로 허용하는 옵션이 포함되어 있습니다. 이는 guest accounts를 생성할 수 있는 대상을 제한하면서도 전체 admin 권한 없이 delegated invitations를 가능하게 하므로 일반적인 기본 구성입니다. 왜 아니요가 아닌가요? 이것이 아니요로 설정된 경우, admins만(또는 구성에 따라 아무도) 초대할 수 있으며, Guest Inviter role은 초대에 대해 효과가 없게 됩니다. 대부분의 이 유형의 시험 문제 exhibit에서는 이 설정이 활성화되어 있으며, 문장에 Guest Inviter role이 포함되어 있다는 것은 이것이 허용됨을 의미합니다. 실질적인 영향: 이것이 활성화되면, SharePoint에서 공유하는 user는 admin이거나 Guest Inviter role을 가지고 있는 경우에만 B2B invitation을 트리거할 수 있습니다(또는 다른 invite settings가 members/guests도 허용하는 경우).

멤버는 초대할 수 있음: 아니요. 이 설정은 표준 멤버 사용자(일반 내부 사용자)가 디렉터리에 외부 게스트를 초대할 수 있는지 여부를 제어합니다. No로 설정되면 admin 및/또는 Guest Inviter role의 사용자만 초대할 수 있습니다. 이는 일반적인 보안 정책이며 최소 권한 원칙(Azure Well-Architected Framework: Security pillar)에 부합합니다. 제어되지 않은 게스트 초대는 위험(데이터 과다 공유, 관리되지 않는 외부 ID)을 증가시킬 수 있기 때문입니다. 왜 Yes가 아닌가요? 멤버가 초대할 수 있다면, 모든 내부 사용자가 콘텐츠를 외부와 공유하는 것만으로 게스트 계정을 생성할 수 있게 되며, 이는 규제가 있는 환경에서는 종종 제한됩니다. 이 문제의 시나리오는 게스트 초대 설정과 passcode에 초점을 맞추고 있으며, 일반적으로 이러한 문제의 보기에는 멤버가 초대할 수 없도록 표시됩니다. 운영 참고: SharePoint sharing이 활성화되어 있더라도, Azure AD guest invitation policy는 여전히 멤버에 의한 새 guest object 생성을 차단할 수 있으며, 이로 인해 새 guest invitation에 의존하는 외부 공유를 방지할 수 있습니다.

게스트는 초대할 수 있음: 아니요. 이 설정은 기존 게스트 사용자가 추가 외부 사용자를 초대할 수 있는지를 결정합니다. 대부분의 조직에서는 외부 액세스의 “viral” 증가를 방지하고 거버넌스 제어(access reviews, entitlement management, sponsorship)를 관리 가능하게 유지하기 위해 이 기능을 비활성화합니다. 왜 예가 아닌가요? 게스트가 다른 게스트를 초대하도록 허용하면 감사 및 거버넌스가 더 어려운 외부 액세스 체인이 생성될 수 있으며, 의도된 비즈니스 승인 프로세스를 우회할 수 있습니다. SC-300에서는 특정 협업 요구 사항과 보완 제어가 없는 한 게스트가 초대할 수 없어야 한다는 것이 예상되는 모범 사례입니다. 시나리오에 미치는 영향: 이 설정은 누가 email passcode를 받는지를 직접 결정하지는 않지만, 새로운 게스트 계정을 생성하는 초대/공유를 특정 사용자가 시작할 수 있는지 여부에는 영향을 줍니다.

활성화되면, Email one-time passcode (OTP)는 다른 지원되는 identity provider가 없는 B2B guest user를 Azure AD가 인증할 수 있게 합니다. 이는 Azure AD account, federated identity 또는 Microsoft account로 sign in할 수 없는 사용자를 위한 것입니다. 따라서 Outlook.com 사용자는 일반적으로 email OTP를 받는 대신 자신의 Microsoft account로 인증합니다. 이 설정이 활성화되어 있는 것은 여전히 올바르게 예로 식별되지만, 그렇다고 해서 모든 external user에게 passcode가 전송된다는 의미는 아닙니다.

user flows (Preview)를 통해 guest self-service sign up 활성화: 아니요. 이 설정은 user flows를 사용하는 Azure AD External Identities self-service sign-up(External Identities/B2C 스타일 경험과 관련된 기능)과 관련이 있습니다. 이는 표준 B2B invitation 및 SharePoint sharing 흐름과는 별개입니다. 많은 Microsoft 365 tenant 구성에서 이 preview 기능은 기본적으로 활성화되어 있지 않으며, 시험 자료의 화면에서는 비활성화된 상태로 표시되는 경우가 많습니다. 왜 예가 아닌가요? 이를 활성화하면 external user에 대해 user flows를 통한 특정 self-service sign-up 경험이 허용되지만, SharePoint external sharing invitation에는 필요하지 않습니다. 이 문제의 초점은 guest invite 설정과 Email OTP에 있으며, user flows 구축에는 있지 않습니다. 시험 팁: “self-service sign-up via user flows”를 “Email one-time passcode”와 혼동하지 마세요. OTP는 B2B를 위한 authentication fallback이고, user flows는 별도의 external identity onboarding 메커니즘입니다.

예. User1@outlook.com은 Outlook.com domain에 있으며, 이는 tenant의 Collaboration restrictions 허용 목록("지정된 domain에만 초대 허용")에 명시적으로 포함되어 있습니다. 따라서 User1을 초대하는 것은 허용되며, 사용자가 아직 초대를 redeem(수락)하지 않았더라도 directory에 guest object가 존재할 수 있습니다. 중요한 구분은 (1) directory에서 Guest user로 초대/생성되는 것과 (2) 초대를 redeem하는 것 사이의 차이입니다. guest는 수락 전에 userType=Guest로 표시될 수 있습니다. 그러나 redemption이 완료되기 전까지는 일반적으로 할당된 리소스에 액세스하기 위한 sign-in을 완료할 수 없습니다. restriction 설정은 허용된 domain에 대해 guest object가 존재하는 것을 막지 않으며, 허용되지 않은 domain에 대한 초대만 차단합니다.

아니요. "Allow invitations only to the specified domains"가 설정되어 있고 Outlook.com만 나열되어 있으므로, fabrikam.com에 대한 초대는 허용되지 않습니다. 즉, User2@fabrikam.com에 대한 새로운 초대는 차단되어야 하며, 사용자는 이 제한 하에서 새로 초대를 수락할 수 없어야 합니다. 많은 시험 시나리오에서 fabrikam.com Guest가 이미 수락한 것으로 설명된다면, 이는 해당 Guest가 제한이 적용되기 전에 초대 및 redemption을 완료했거나, 다른 메커니즘이 Guest를 생성한 경우에만 가능합니다. 그러나 표시된 구성과 문제의 의도를 기준으로 보면, fabrikam.com은 초대가 허용된 도메인이 아니므로, 제시된 진술은 현재 제한 하에서는 사실이 아닌 것으로 처리해야 합니다.

Pass. 이미지는 tenant가 가장 제한적인 옵션으로 설정되어 있음을 나타냅니다: "지정된 도메인에만 invitations 허용" 그리고 표시된 지정/대상 도메인은 Outlook.com입니다. 이것이 나머지 답변을 결정하는 핵심 제어입니다: Outlook.com 주소는 초대할 수 있고, 다른 도메인은 초대할 수 없습니다. SC-300에서 이 설정을 보면, 즉시 다음과 같이 연결하세요: 허용된 도메인 = 초대 가능; 그 외 모든 도메인 = invitation 차단. 그런 다음 각 사용자의 이메일 도메인과 그 사용자가 새로운 invite 대상인지 아니면 이미 존재하는 guest인지 평가하세요. 그 접근 방식이 나머지 하위 질문에 답하는 데 정확히 필요합니다.

예. User1@outlook.com이 허용된 도메인 목록에 있으므로 초대를 보낼 수 있고 사용자는 이를 redeem(수락)할 수 있습니다. 수락 후 guest는 tenant에서 인증할 수 있으며, 할당/권한 부여된 경우 enterprise application에 액세스할 수 있습니다. Collaboration restrictions는 허용된 도메인에 대한 수락을 막지 않습니다. 이는 승인되지 않은 도메인의 사용자를 초대하는 것(그리고 일반적으로 redeeming하는 것)을 방지하도록 설계되었습니다. enterprise application 할당(또는 group 할당)이 이미 되어 있고 추가적인 차단 요소(Conditional Access, 사용자 비활성화 등)가 없다고 가정하면, User1은 초대를 수락한 다음 액세스 권한을 얻을 수 있어야 합니다.

아니요. 올바른 정답이 No가 되는 경우는, 평가 중인 시나리오에서 User2가 유효하게 invitation을 redeemed한 guest가 될 수 없었던 경우뿐입니다. 그러나 collaboration restrictions는 주로 특정 domain에 대해 새로운 B2B invitation을 보낼 수 있는지를 제어하며, directory에 이미 존재하고 invitation을 이미 redeemed한 guest의 액세스를 자동으로 revoke하지는 않습니다. User2@fabrikam.com이 restriction이 구성되기 전에 이미 invitation을 수락했다면, permission이 계속 할당되어 있는 한 User2는 일반적으로 enterprise application에 계속 액세스할 수 있습니다. 따라서 이유는 현재 allow list 자체가 이미 수락된 guest의 sign-in을 차단하기 때문이어서는 안 됩니다. 설명은 새로운 invitation 차단과 기존 guest 액세스 revoke를 구분해야 합니다.

아니요. External collaboration 설정은 지정된 도메인에 대해서만 초대를 허용하도록 구성되어 있으며, 표시된 유일한 허용 도메인은 Outlook.com입니다. 따라서 Outlook.com 이메일 주소를 가진 게스트만 새로 초대받고 초대를 사용할 수 있습니다. 이 문장은 User1이 아니라 User3에 대한 것이며, User3는 시나리오에서 언급된 Outlook.com 게스트가 아니므로 User3의 도메인도 허용 목록에 포함되어 있지 않는 한 User3는 초대를 수락할 수 없습니다. 현재 설명은 User3가 아니라 User1에 대해 답하고 있으며 제한 사항에 따른 User3의 자격을 평가하지 않기 때문에 올바르지 않습니다.

Pass. self-service (unmanaged/viral) tenant에서 global admin 권한을 얻기 위한 올바른 순서는 admin takeover process입니다: 1) Azure AD tenant에 self-signed user account를 생성합니다 (contoso.com을 사용하는 unmanaged tenant의 사용자). 2) 해당 사용자로 Microsoft 365 admin center에 로그인합니다. 3) “Become the admin” 메시지에 응답합니다 (이 단계에서 takeover가 시작되고 domain verification이 요청됩니다). 4) domain ownership를 증명하고 verification을 완료하기 위해 contoso.com DNS zone에 TXT record를 생성합니다. 다른 나열된 작업이 잘못되었거나 필요하지 않은 이유: admin center에서 “Add the domain name”은 일반적으로 managed tenant 설정의 일부이지만, takeover에서는 domain이 이미 tenant에 존재합니다. 중요한 단계는 takeover flow에서 요청되는 TXT record를 통해 ownership를 검증하는 것입니다. “Remove the domain name”은 관련이 없으며 admin 권한을 부여하지도 않습니다. 또한 사용자/서비스에 문제를 일으킬 수 있습니다.

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에는 Department1 administrative unit에만 범위가 지정된 User Administrator 역할이 있습니다. Department1에는 사용자로 User1 및 User2가 포함되어 있지만, User3 및 User4는 Group2의 구성원으로만 나타나며 administrative unit의 구성원으로 표시되지 않습니다. Administrative unit 멤버십은 group 멤버십과 별개이므로, Group2 내부에 있다고 해서 User3 또는 User4가 Department1에 속하게 되는 것은 아닙니다. 따라서 Admin1은 User3 및 User4의 비밀번호를 재설정할 수 없으므로, 정답은 아니요입니다.

Admin1은 Department1 범위로 지정된 User Administrator이며, Group2는 해당 administrative unit에 포함된 그룹입니다. administrative unit 범위로 지정된 User Administrator는 해당 unit 내의 그룹을 관리할 수 있으며, 여기에는 해당 그룹의 멤버십 업데이트도 포함됩니다. User1도 Department1에 있으므로, 대상 그룹과 추가되는 사용자 모두 administrative unit의 범위 내에 있습니다. 따라서 Admin1은 User1을 Group2에 추가할 수 있으므로, 정답은 예입니다.

Admin2는 전체 Azure AD tenant에 적용되는 Directory scope의 User Administrator role을 가지고 있습니다. Directory-scoped assignment는 administrative unit 경계에 의해 제한되지 않습니다. User1은 tenant의 일반 사용자이며 보호된 privileged role에 대한 언급이 없으므로, Admin2는 User1의 비밀번호를 재설정할 수 있습니다. 따라서 정답은 예입니다.

A가 정답인 이유는, 표시된 구성에서는 평가된 비밀번호가 Azure AD Password Protection에 의해 차단되기 때문입니다. 차단되는 이유: - "Pr0jectlitw@re"에는 일반적인 치환이 적용된 두 개의 금지 용어가 포함되어 있습니다: "Pr0ject"는 금지어 "project"와 일치하며(0→o, 대소문자 구분 없음), "litw@re"는 "Litware"와 일치합니다(@→a). Azure AD Password Protection의 fuzzy matching은 정확히 이러한 패턴을 탐지하도록 설계되었습니다. - "T@ilw1nd"는 "Tailwind"의 leet 변형입니다(@→a, 1→i). 이는 금지 용어 "Tailwind"와 매우 유사하게 일치합니다. - "C0nt0s0"는 "Contoso"의 leet 변형입니다(0→o). 이는 금지 용어 "Contoso"와 매우 유사하게 일치합니다. "오답"이 틀린 이유: 보기에는 Enforce custom list = Yes 및 Mode = Enforced로 명확히 표시되어 있으므로, 이러한 비밀번호는 단순히 기록되는 것이 아니라 실제로 거부됩니다.

이미지는 App1의 주요 enterprise application 설정을 보여줍니다: Enabled for users to sign-in은 Yes로 설정되어 있고, User assignment required는 No로 설정되어 있으며, Visible to users는 Yes로 설정되어 있습니다. 이러한 설정은 누가 app에 액세스할 수 있는지와 사용자 대상 portal에 표시되는지를 모두 판단하기에 충분합니다. 스크린샷이 필요한 구성 값을 명확하게 제공하므로, 이 항목은 exhibit만으로 답할 수 있습니다. 따라서 선택된 응답이 적절합니다.

모든 사용자는 홈페이지 URL에서 App1에 액세스할 수 있습니다. 이유: Enterprise application에서 “User assignment required?”는 사용자가 앱에 sign in하기 위해 명시적으로 앱에 할당되어야 하는지를 결정합니다. 제시된 화면에는 User assignment required = No로 표시됩니다. 이는 tenant의 모든 사용자가 애플리케이션에 액세스/sign in을 시도할 수 있음을 의미합니다(예: 홈페이지 URL로 직접 이동하거나 OAuth/SAML sign-in을 시작하는 경우). 단, 다른 제한 사항(Conditional Access, 앱 자체에서 적용하는 app roles 등)이 없다고 가정합니다. 다른 선택지가 틀린 이유: - 아무도 없음: sign-in이 활성화되어 있고 assignment가 필요하지 않으므로 틀렸습니다. - Owners만: owners는 app registration/enterprise app을 관리하지만, assignment가 필요하지 않을 때 sign in할 수 있는 유일한 사용자는 아닙니다. - Users and groups만: 이는 User assignment required가 Yes로 설정된 경우에만 맞습니다.

App1은 모든 사용자에 대해 Microsoft Office 365 app launcher에 표시됩니다. 이유: app tile은 (1) app에 대한 액세스 권한이 있고 (2) app이 표시되도록 설정된 사용자에게 표시됩니다. 제시된 화면에서는 Visible to users? = Yes로 되어 있으므로, app이 사용자 대상 portal에 표시될 수 있습니다. User assignment required = No이므로, 모든 사용자는 명시적인 할당 없이도 사실상 액세스 권한을 가집니다. 따라서 이 app은 Microsoft 365 app launcher(그리고 마찬가지로 My Apps)에서 모든 사용자에게 표시될 수 있습니다. 다른 옵션이 틀린 이유: - 아무도 아님: Visible to users가 No이거나 sign-in이 비활성화된 경우에 해당합니다. - Owners만: ownership은 launcher 표시 여부를 제어하지 않습니다. - Users and groups만: assignment가 required인 경우에 해당하지만, 이 구성에서는 그렇지 않습니다.

예. Membership type이 Assigned인 그룹은 직접적이고 수동적인 멤버십 관리를 지원합니다. 즉, 적격한 directory object를 멤버로 추가할 수 있습니다(그룹의 type 제약 조건 적용). Assigned membership을 가진 Security 그룹의 경우, 사용자, 디바이스, 그리고(이 시나리오에서 중요하게) 다른 security group을 중첩 멤버로 추가할 수 있습니다. 이는 액세스 할당을 단순화하기 위해 일반적으로 사용됩니다(예: 중첩된 security group을 Azure role 또는 enterprise application에 할당). 왜 “아니요”가 아닌가: Membership type이 Dynamic User 또는 Dynamic Device인 경우에만 “아니요”가 맞습니다. dynamic group은 수동 추가/제거를 허용하지 않기 때문입니다. 멤버십은 dynamic rule에서 계산됩니다. Group1은 명시적으로 Assigned라고 되어 있으므로, group nesting이 지원되는 곳(예: 다른 Security 그룹 내부)에 추가할 수 있습니다.

아니요. Membership type이 Dynamic User인 그룹은 assigned security group을 중첩할 수 있는 방식처럼 다른 그룹의 멤버로 추가할 수 없습니다. Dynamic group은 규칙 기반 컨테이너입니다. 멤버십은 user attribute를 기반으로 자동 계산되며, 다른 그룹의 중첩 멤버로 사용되도록 설계되지 않았습니다. 또한 dynamic group에는 포함할 수 있는 대상과 관리 방식에 대한 제한이 있습니다. dynamic group에는 멤버를 수동으로 추가할 수 없으며, 일반적으로 중첩 멤버십을 만들기 위해 dynamic group 자체를 다른 그룹 내부의 “member object”로 사용할 수도 없습니다. 시험 관점에서는 dynamic group을 중첩할 수 없는 멤버십 소스로 간주하십시오. 따라서 “아니요”를 선택하는 것이 platform 제약을 올바르게 반영하며, access를 간접적으로 부여하기 위해 Dynamic User group을 다른 그룹 내부에 중첩할 수 있다고 잘못 가정하는 것을 방지합니다.

아니요. Membership type이 Dynamic Device인 그룹도 rule-based이며 다른 그룹 내부의 nested member로 사용되지 않습니다. Dynamic Device 그룹은 device attributes(예: deviceOSType, deviceOwnership 또는 extension attributes)를 기반으로 평가되며, 규칙과 일치하는 devices를 자동으로 포함합니다. 그룹의 membership은 계산되어 결정되므로, Azure AD는 nested 시나리오에서 다른 그룹에 추가할 member object로 dynamic device 그룹 자체를 취급하는 것을 지원하지 않습니다. 또한 대상 그룹이 devices를 members로 지원하더라도, 그것은 device object를 직접 추가하는 것과는 다르며 dynamic device 그룹을 nested group으로 추가할 수 있음을 의미하지는 않습니다. 따라서 올바른 선택은 dynamic 그룹이 member로서 nesting 대상이 될 수 없음을 나타내는 “아니요”입니다.

예. Group4의 Membership type은 Assigned이며, 이는 수동으로 관리되는 group이라는 의미이고 대상 group type이 group nesting을 지원하는 경우 member로 추가될 수 있습니다. Azure AD에서 assigned Security group은 nesting을 지원하는 주요 group type입니다(Security group을 다른 Security group 내부에 포함). 이는 일반적인 운영 패턴입니다. 역할 기반 또는 애플리케이션 기반 Security group을 생성한 다음, 관리 작업을 줄이고 least privilege에 맞추기 위해 그 안에 부서별 또는 기능별 Security group을 중첩합니다. 왜 “아니요”가 아닌가: Group4가 dynamic(user/device)인 경우이거나 대상 group type이 group을 member로 지원하지 않는 경우(예: Microsoft 365 group)라면 “아니요”가 적용됩니다. 하지만 여기서의 질문은 Assigned group이 원칙적으로 자격이 있는지 여부뿐이므로 정답은 “예”입니다.

GroupA는 Assigned membership를 가진 Security group입니다. Security group은 사용자와 (중첩된) security group을 멤버로 추가하는 것을 지원합니다. 제공된 옵션 중 추가할 수 있는 것은 다음과 같습니다: - User1 (user object) - Group1 (Assigned security group) - Group4 (Assigned security group) Group2 (Dynamic User) 또는 Group3 (Dynamic Device)는 중첩 멤버로 추가할 수 없습니다. Dynamic group은 규칙 기반이며 중첩 group 멤버로 지원되지 않기 때문입니다. 따라서 올바른 집합은 “User1, Group1 및 Group4만”입니다 (Option D). 다른 옵션이 틀린 이유는 Group2 및/또는 Group3를 포함하고 있기 때문이며, 이들은 dynamic group이어서 GroupA의 멤버로 추가할 수 없습니다.

GroupB는 Assigned membership를 사용하는 Microsoft 365 group입니다. Microsoft 365 groups는 협업 그룹이며(Teams, Outlook groups, SharePoint, Planner에서 사용됨), 다른 groups를 멤버로 추가하는 것을 지원하지 않습니다(중첩 그룹 없음). 멤버십은 groups가 아니라 개별 사용자(및 잠재적으로 guest)를 대상으로 합니다. 따라서 나열된 후보 객체(User1 및 Group1/Group2/Group3/Group4) 중 직접 멤버로 추가할 수 있는 것은 User1뿐입니다. Group1과 Group4가 Assigned이고, GroupA (security)가 중첩을 허용하더라도, Microsoft 365 groups는 허용하지 않습니다. 따라서 정답은 “User1만” (Option A)입니다. 다른 모든 옵션은 Microsoft 365 group의 멤버로 하나 이상의 groups를 포함하고 있으므로 지원되지 않아 오답입니다.

예. 보기의 User administrator 역할에 대한 PIM 설정은 Activation maximum duration이 8시간으로 구성되어 있음을 보여줍니다. PIM에서 이 값은 eligible 활성화가 자동으로 만료되고 사용자가 상승된 권한을 잃기 전에 활성 상태로 유지될 수 있는 최대 시간을 설정합니다. 다른 선택지가 틀린 이유: “아니요”를 선택하면 구성된 최대 기간이 8시간이 아닌 다른 값(예: 1시간, 4시간 또는 24시간)이라는 의미가 되며, 이는 표시된 역할 설정과 모순됩니다. 또한 이것은 assignment expiration(eligible/active assignment duration)과 관련된 것이 아닙니다. 이는 eligible 사용자가 역할을 활성화한 후의 activation session duration을 구체적으로 의미합니다.

Yes. 제시된 화면은 “Require justification on activation”이 활성화되어 있음을 나타냅니다. 이는 적격 사용자가 User administrator role을 활성화할 때, 활성화 워크플로의 일부로 비즈니스 justification(자유 텍스트)을 입력해야 함을 의미합니다. 다른 선택지가 틀린 이유: “No”는 해당 설정이 비활성화된 경우에만 맞습니다. Justification은 활성화 시점의 제어(JIT elevation)이며, role을 Active로 할당할 때 적용되는 “Require justification on active assignment”와는 별개입니다. 시험에서는 이름이 비슷한 이 두 설정을 혼동하도록 자주 출제하므로, Assignment 섹션이 아니라 Activation 섹션을 보고 있는지 반드시 확인하세요.

예. 문장에 “활성화 시 티켓 정보 요구는 No입니다.”라고 되어 있습니다. 이는 활성화 중에 티켓팅이 필요하지 않음을 보여주는 보기와 일치합니다. PIM에서 티켓 정보는 일반적으로 ITSM 프로세스(예: 변경/요청 티켓 번호 요구)와 통합되어 감사 가능성을 지원합니다. 다른 선택지가 틀린 이유: “아니요”를 선택하면 티켓 정보가 필요함(Yes로 설정됨)을 의미하며, 이는 사용자가 활성화 시점에 티켓 세부 정보를 제공하도록 강제합니다. 또한 티켓 요구 사항은 justification 및 MFA와는 별개이므로, 이러한 제어의 어떤 조합이든 요구할 수 있습니다.

예. 보기에는 “On activation, require Azure MFA”가 활성화되어 있습니다. 이는 적격 사용자가 역할이 활성화되기 전에 활성화 프로세스의 일부로 MFA를 완료해야 함을 의미합니다(또는 Conditional Access/session state에 따라 유효한 MFA claim이 있어야 함). 다른 선택지가 틀린 이유: “No”는 활성화에 MFA가 필요하지 않은 경우에만 맞습니다. 또한 이 설정은 “Require Azure Multi-Factor Authentication on active assignment”와는 다르며, 이는 assignment를 Active로 만드는 경우에 적용됩니다. 여기서는 적격 사용자에 대한 활성화 시점 요구 사항임이 명시되어 있습니다.

Yes. 제시된 화면은 “활성화하려면 승인이 필요”가 활성화되어 있음을 나타냅니다. 이 설정에서는 적격 사용자의 활성화 요청이 즉시 역할을 부여하지 않으며, 승인자가 승인할 때까지 보류 상태로 들어갑니다. 다른 선택지가 틀린 이유: “No”는 자체 활성화가 허용됨을 의미합니다(MFA/justification 같은 다른 제어의 적용 대상일 수 있음). 승인은 영향도가 높은 역할에 사용되는 강력한 거버넌스 제어이며, least privilege 및 separation of duties와도 부합합니다.

아니요. “Require approval to activate”가 Yes로 설정된 경우, 승인자(한 명 이상의 사용자 또는 그룹)가 구성되어 있어야 합니다. 보기에는 승인자가 구성되어 있는 것으로 표시됩니다(None 아님). PIM에서 승인 workflow는 승인자 없이 작동할 수 없습니다. 다른 선택지가 틀린 이유: “예”라고 답하면 승인자 목록이 비어 있다는 의미가 됩니다. 이는 작동하는 승인 요구 사항과도, 보기와도 일치하지 않습니다. 실제 배포에서 승인자가 정말 none이라면, 승인할 사람이 없기 때문에 activation 요청은 차단됩니다.

예. 보기에는 “Allow permanent eligible assignment”가 No로 설정되어 있습니다. 이는 User administrator role을 Eligible로 할당할 때, 해당 할당에 종료 날짜/시간이 반드시 있어야 하며 무기한일 수 없음을 의미합니다. 다른 선택지가 틀린 이유: “아니요”는 영구 Eligible assignment가 허용된다는 의미가 되며, 이는 거버넌스를 약화시킬 수 있습니다(사용자가 영구적으로 eligible 상태로 남아 있을 수 있음). 영구 eligibility를 허용하지 않는 것은 주기적인 검토를 보장하고 시간 경과에 따른 상시 privilege 노출을 줄이기 위한 일반적인 identity governance 제어입니다.

예. 보기에는 적격 할당이 15일 후에 만료된다고 표시되어 있습니다. 영구적인 적격 할당은 허용되지 않으므로, PIM은 기간이 제한된 적격 할당 기간을 적용하며, 구성된 값은 15일입니다. 다른 선택지가 틀린 이유: “아니요”는 적격 할당 만료 기간이 15일이 아니라는 의미입니다(예: 30일 또는 1년). 또한 이를 활성화 최대 기간(8시간)과 혼동하지 마세요. 적격 할당 기간은 사용자가 활성화할 수 있는 자격이 얼마나 오래 유지되는지를 제어하고, 활성화 기간은 활성화 후 역할이 얼마나 오래 활성 상태로 유지되는지를 제어합니다.

예. 보기에는 “Allow permanent active assignment”가 No로 설정되어 있습니다. 이는 User administrator role을 Active로 무기한 할당할 수 없음을 의미하며, 모든 active assignment는 기간이 제한되어야 합니다. 다른 선택지가 틀린 이유: “No”는 영구적인 active assignment가 허용된다는 의미가 되며, 이는 상시 privilege를 생성하고 일반적으로 privileged role에는 권장되지 않습니다. PIM은 항상 켜져 있는 access를 최소화하도록 설계되었으며, 기간이 제한된 active assignment는 active assignment가 필요한 경우(예: 프로젝트 진행 중)를 위한 governance 메커니즘입니다.

예. 제시된 화면에는 활성 할당이 1개월 후에 만료되는 것으로 표시됩니다. 영구적인 활성 할당은 허용되지 않으므로, PIM은 만료를 요구하며 구성된 기간은 1개월입니다. 다른 선택지가 틀린 이유: “아니요”는 활성 할당 만료 기간이 다르다는 의미입니다. 또한 이것은 활성화 기간(8시간)과 동일하지 않습니다. 활성 할당 만료는 Active로 할당된 사용자(제한된 기간 동안의 상시 역할 멤버십)에 적용되며, JIT를 활성화하는 eligible 사용자에게 적용되는 것이 아닙니다.

예. 문장에는 “활성 할당에 Azure Multi-Factor Authentication 필요는 아니요입니다”라고 되어 있으며, 보기에서는 활성 할당을 생성할 때 MFA가 필요하지 않음을 보여줍니다. 이 설정은 역할을 Active로 할당하는 관리 작업을 제어합니다. 다른 선택지가 틀린 이유: “아니요”는 활성 할당에 MFA가 필요하다는 의미가 됩니다. 미묘한 차이에 유의하세요. 할당 작업에 MFA가 필요하지 않더라도, 활성화에는 MFA를 요구할 수 있습니다(여기서는 활성화됨). 이는 PIM에서 별도의 제어입니다.

예. 보기에는 “활성 할당에 대한 justification 요구”가 비활성화됨(No)으로 표시되어 있습니다. 이는 관리자가 User administrator 역할을 Active로 할당할 때 PIM에 의해 justification을 입력하도록 강제되지 않음을 의미합니다. 다른 선택지가 틀린 이유: “아니요”는 활성 할당에 justification이 필요하다는 의미가 됩니다. 다시 말하지만, 이것을 “activation 시 justification 요구”와 혼동하지 마세요. 이 설정은 활성화되어 있으며 역할을 활성화하는 eligible 사용자에게 적용됩니다.

8시간. 제시된 화면에서는 활성화 시 Azure MFA를 요구하고 활성화 최대 기간을 8시간으로 설정합니다. 실제로 eligible 사용자는 role을 활성화할 때마다 MFA를 수행해야 하며, 각 활성화는 최대 8시간 동안 지속될 수 있습니다. 8시간이 지나면 활성화가 만료되고 사용자는 role을 다시 활성화해야 하며(따라서 MFA도 다시 충족해야 함) role을 다시 획득할 수 있습니다. 다른 옵션이 틀린 이유: 15일과 1개월은 assignment 만료 값(eligible 및 active assignment 수명)입니다. 이는 MFA를 얼마나 자주 수행하는지를 정의하지 않습니다. MFA는 eligible/active assignment 만료 타이머가 아니라 활성화 이벤트(및 잠재적으로 Conditional Access session policy)와 연결됩니다.

'Require approval to activate'가 PIM에서 활성화되면, 활성화는 해당 역할의 Approvers 설정에 나열된 사용자 또는 그룹의 승인을 받아야 합니다. 제시된 화면은 구성된 승인자가 영구적으로 할당된 User administrator임을 나타내므로, 활성화가 완료되기 전에 필요한 승인자는 이것입니다. Global Administrator 또는 Privileged Role Administrator는 PIM 설정을 관리할 수 있지만, 명시적으로 구성되지 않는 한 자동으로 활성화 승인자가 되지는 않습니다. 따라서 승인은 일반적인 관리 권한만이 아니라 구성된 승인자 목록에 따라 달라집니다.

정답: A. Directory Extensions. Azure AD Connect의 Directory Extensions는 추가적인 on-premises AD DS attributes를 extension attributes로 Azure AD에 동기화하는 데 사용되는 설정입니다. 이는 라이선싱(또는 기타 cloud controls)이 기본 동기화 집합에 포함되지 않은 attribute에 의해 구동되어야 할 때 일반적으로 필요합니다. 동기화가 완료되면 이러한 attributes는 Azure AD에서 dynamic group rules, access decisions, 및 governance processes에 사용할 수 있습니다. B가 아닌 이유 (Domain Filtering): Domain filtering은 어떤 on-premises AD domains가 동기화에 포함될지를 제어합니다. 어떤 attributes가 동기화되는지를 제어하지는 않으므로, user properties를 기반으로 한 라이선싱 요구 사항을 충족하는 데 도움이 되지 않습니다. C가 아닌 이유 (Optional Features): Optional features는 특정 hybrid capabilities(예: password writeback, group writeback, device writeback, Exchange hybrid)를 활성화합니다. 이는 dynamic licensing logic에 필요한 추가 user attributes를 추가/동기화하는 메커니즘이 아닙니다.

정답: C. Dynamic User membership type을 가진 Azure Active Directory 그룹. Dynamic User 그룹은 사용자 특성 또는 규칙에 따라 라이선스를 자동으로 할당해야 할 때 가장 적합한 선택입니다. Azure AD group-based licensing은 사용자를 직접 포함하는 security groups 및 Microsoft 365 groups에 라이선스를 할당하는 것을 지원하며, dynamic user groups는 해당 멤버십을 자동화하는 데 일반적으로 사용됩니다. 옵션 A가 틀린 이유는 group-based licensing에서 nested groups가 처리되지 않기 때문입니다. 옵션 B는 라이선싱에 본질적으로 유효하지 않은 것은 아니지만, 수동 멤버십 관리가 필요하며 Dynamic User 그룹만큼 자동적이고 특성 기반의 할당 요구 사항을 효과적으로 충족하지는 못합니다.

App1에 사용자를 할당하는 작업은 enterprise application(service principal)에서 수행됩니다. Application Administrator와 Cloud Application Administrator는 사용자 및 그룹 할당을 포함하여 enterprise application을 관리할 수 있으므로, Admin1과 Admin3이 이 작업을 수행할 수 있습니다. Application Developer는 자신이 만든 application registration을 관리할 수 있으며, 자신이 소유한 application의 경우 해당 enterprise application의 여러 측면(할당 포함)도 관리할 수 있으므로 Admin2도 포함됩니다. User1은 admin role이 없고 App1의 소유자라고 명시되지 않았으므로 App1에 사용자를 할당할 수 없습니다.

Azure AD에 App2를 등록한다는 것은 테넌트에 app registration(application object)을 생성하는 것을 의미합니다. 문제에서 테넌트가 기본 App registrations 설정을 사용한다고 명시하고 있습니다. 기본적으로 Microsoft Entra ID는 관리자가 아닌 사용자도 애플리케이션을 등록할 수 있도록 허용합니다("Users can register applications" = Yes). 이 기본 설정에서는 관리자뿐만 아니라 인증된 모든 사용자가 app registration을 생성할 수 있습니다. 즉, Admin1, Admin2, Admin3 및 User1 모두 App2를 등록할 수 있습니다. 등록을 Admin1 및/또는 Admin3로만 제한하는 선택지는 테넌트 설정이 app registration을 관리자로 제한하도록 변경되었거나, 추가적인 거버넌스 제어가 적용된 경우에만 맞습니다. 문제에서 기본 설정이라고 했으므로, 가장 범위가 넓은 선택지가 정답입니다.