CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Microsoft SC-300
Microsoft SC-300

Practice Test #2

50개 문제와 100분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

50문제100분700/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

기출 문제

1
문제 1

DRAG DROP - contoso.com의 SMTP address space를 사용하는 on-premises Microsoft Exchange organization이 있습니다. 사용자들이 Microsoft 365 services에 대한 self-service sign-up에 자신의 email address를 사용한다는 것을 발견했습니다. self-signed users가 포함된 Azure Active Directory (Azure AD) tenant에 대한 global administrator privileges를 획득해야 합니다. 어떤 네 가지 작업을 순서대로 수행해야 합니까? 답하려면 작업 목록에서 적절한 작업을 답 영역으로 이동하고 올바른 순서로 정렬하십시오. Select and Place:

파트 1:

아래 이미지에서 올바른 답을 선택하세요.

question-image

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 권한을 부여하지도 않습니다. 또한 사용자/서비스에 문제를 일으킬 수 있습니다.

2
문제 2

contoso.com이라는 이름의 Azure Active Directory (Azure AD) tenant가 있습니다. Azure AD에 등록된 애플리케이션을 실행하는 모든 사용자는 conditional access policies의 적용을 받습니다. 사용자가 legacy authentication을 사용하지 못하도록 해야 합니다. legacy authentication 시도를 필터링하기 위해 conditional access policies에 무엇을 포함해야 합니까?

Cloud apps 또는 actions는 policy가 적용되는 resource(예: Exchange Online, SharePoint, Azure management)를 결정합니다. 노출을 줄이기 위해 Exchange Online을 대상으로 지정할 수는 있지만, 이 condition은 sign-in이 legacy/basic authentication을 사용했는지 여부를 식별하지 못합니다. Legacy protocol과 modern authentication flow를 구분하려면 여전히 Client apps가 필요합니다.

User risk는 사용자 계정이 손상되었을 가능성을 나타내는 Entra ID Identity Protection signal입니다(유출된 자격 증명과 같은 탐지를 기반으로 함). 암호 변경을 요구하거나 고위험 사용자를 차단하는 데 유용하지만, authentication method 또는 protocol을 분류하지 않으므로 legacy authentication 시도를 구체적으로 필터링할 수 없습니다.

Client apps는 legacy authentication 시도를 필터링하는 올바른 condition입니다. “Other clients”(그리고 선택적으로 “Exchange ActiveSync clients”)를 선택하면 modern auth를 지원하지 않는 legacy/basic authentication protocol을 사용하는 sign-in을 대상으로 지정할 수 있습니다. 그런 다음 access를 차단하여 대상 애플리케이션 전반에서 사용자가 legacy authentication을 사용하지 못하도록 효과적으로 방지할 수 있습니다.

Sign-in risk는 특정 sign-in의 위험 수준(예: 익숙하지 않은 위치, 비정상적인 이동, anonymous IP)에 대한 Identity Protection signal입니다. 이는 MFA 요구 또는 위험한 sign-in 차단과 같은 적응형 access 결정을 내리는 데 도움이 됩니다. 그러나 client가 legacy/basic authentication을 사용했는지 여부는 탐지하지 못하므로 올바른 필터가 아닙니다.

문제 분석

핵심 개념: 이 문제는 legacy authentication를 탐지하고 제어하는 데 사용되는 Microsoft Entra ID (Azure AD) Conditional Access 조건을 테스트합니다. Legacy authentication는 modern authentication (OAuth 2.0/OpenID Connect)을 지원하지 않는 오래된 client protocol을 의미하며, 따라서 MFA 및 기타 제어를 안정적으로 적용할 수 없습니다(예: IMAP, POP, SMTP AUTH, basic auth를 사용하는 이전 Office client). 정답인 이유: Conditional Access policy에서 legacy authentication 시도를 필터링(대상 지정)하려면 Client apps condition을 사용합니다. Conditional Access에서 “Client apps”를 사용하면 sign-in이 다음 중 어디에서 오는지 지정할 수 있습니다: - Browser - Mobile apps and desktop clients - Exchange ActiveSync clients - Other clients (legacy/basic auth의 핵심 범주) “Other clients”(그리고 필요한 경우 Exchange ActiveSync도 함께)를 선택하면 legacy authentication 시도에만 구체적으로 적용되는 policy를 만들고 이후 access를 차단할 수 있습니다. 이는 사용자가 legacy authentication을 사용하지 못하도록 해야 한다는 요구 사항을 직접적으로 충족합니다. 주요 기능 / 구성 참고 사항: - 적절한 Users/Groups를 대상으로 하는 Conditional Access policy를 생성합니다. - Conditions > Client apps에서 “Other clients”(그리고 환경에 따라 선택적으로 “Exchange ActiveSync clients”)를 선택합니다. - Access controls에서 “Block access”를 선택합니다. - 이는 약한 authentication 방식에 대한 노출을 줄임으로써 Zero Trust 및 Azure Well-Architected Framework security pillar와 일치합니다. - 또한 많은 조직은 defense in depth를 위해 가능한 경우 workload 수준에서도 basic auth를 비활성화합니다(예: Exchange Online authentication policies). 흔한 오해: Risk conditions (user risk/sign-in risk)는 Identity Protection signal이며 protocol 유형(legacy vs modern)을 식별하도록 설계되지 않았습니다. Cloud apps/actions는 resource(예: Exchange Online, SharePoint)를 대상으로 하지만 사용된 authentication protocol을 구분하지는 않습니다. Protocol 구분은 Client apps를 통해 이루어집니다. 시험 팁: SC-300에서는 다음을 기억하세요: Conditional Access에서 “legacy auth”는 거의 항상 Conditions > Client apps > Other clients에 해당합니다. 문제에서 “legacy authentication 시도를 필터링”한다고 하면 “Client apps condition”을 떠올린 다음 차단하세요. 또한 legacy auth는 MFA를 우회할 수 있으므로 이를 차단하는 것은 일반적인 baseline control입니다.

3
문제 3

HOTSPOT - contoso.com이라는 Azure Active Directory (Azure AD) tenant가 있으며, 여기에는 User1이라는 사용자가 포함되어 있습니다. User1은 다음 표에 표시된 device를 가지고 있습니다.

2020년 11월 5일에 contoso.com에서 다음 설정으로 terms of use를 만들고 적용합니다. ✑ Name: Terms1 ✑ Display name: Contoso terms of use ✑ Require users to expand the terms of use: On ✑ Require users to consent on every device: On ✑ Expire consents: On ✑ Expire starting on: 2020년 12월 10일 ✑ Frequency: Monthly 2020년 11월 15일에 User1은 Device3에서 Terms1을 수락합니다. 다음 각 문장에 대해, 문장이 참이면 Yes를 선택하십시오. 그렇지 않으면 No를 선택하십시오. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

Platform Windows 10인 Device1은 contoso.com에 등록되어 있습니다.

예. 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에 대한 올바른 선택은 예입니다.

파트 2:

Platform Windows 10인 Device2는 contoso.com에 Registered되어 있습니다.

아니요. 표에 따르면 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 여부와 관계없이 계속 표시될 수 있습니다.

파트 3:

Platform iOS인 Device3는 contoso.com에 등록되어 있습니다.

예. 표에 따르면 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가 등록되어 있는지 묻고 있으므로, 올바른 선택은 예입니다.

파트 4:

2020년 11월 20일에 User1은 Device1에서 Terms1에 동의할 수 있습니다.

예. 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에만 영향을 줍니다(동의하기 전에 펼쳐야 함). 동의 가능 여부에는 영향을 주지 않습니다.

파트 5:

2020년 12월 11일에 User1은 Device2에서 Terms1에 동의할 수 있습니다.

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

파트 6:

2020년 12월 7일에 User1은 Device3에서 Terms1을 수락할 수 있습니다.

아니요. 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가 나타나지 않으며, 따라서 실질적인 정답은 아니요입니다.

4
문제 4

다음 객체를 포함하는 Azure Active Directory (Azure AD) tenant가 있습니다. ✑ Device1이라는 이름의 device 1개 ✑ User1, User2, User3, User4, User5라는 이름의 사용자 Group1, Group2, Group3, Group4, Group5라는 이름의 그룹 5개

그룹은 다음 표와 같이 구성되어 있습니다.

diagram

Microsoft 365 Enterprise E5 license를 Group1에 할당하면 몇 개의 license가 사용됩니까?

파트 1:

아래 이미지에서 올바른 답을 선택하세요.

question-image

올바른 선택은 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를 지원하지 않는다는 표준적이고 시험에 자주 출제되는 규칙이기 때문입니다.

5
문제 5

HOTSPOT - 역할 할당을 관리하는 데 사용할 역할을 식별해야 합니다. 솔루션은 위임 요구 사항을 충족해야 합니다. 무엇을 해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

Azure AD 기본 제공 역할 할당을 관리하려면 다음을 사용합니다: ______

정답: 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 역할입니다.

파트 2:

Azure 기본 제공 role assignment를 관리하려면 다음을 사용합니다: ______

정답: 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을 할당해야 합니다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

6
문제 6

Azure AD Identity Protection이 활성화된 contoso.com이라는 이름의 Azure Active Directory (Azure AD) tenant가 있습니다. 사용자 액세스를 차단하지 않고 sign-in risk remediation policy를 구현해야 합니다. 가장 먼저 무엇을 해야 합니까?

Access reviews는 Microsoft Entra ID Governance의 일부이며, 사용자가 group, application 또는 role에 대한 액세스를 계속 유지해야 하는지를 주기적으로 검증하는 데 사용됩니다. 이는 실시간 authentication flow에 참여하지 않으며 risky sign-in event를 remediation할 수 없습니다. 문제는 specifically sign-in risk remediation에 관한 것이므로, access reviews는 필요한 제어와 관련이 없습니다. 이 옵션은 authentication risk 대응이 아니라 entitlement governance를 다룹니다.

Azure AD Password Protection은 password 품질 규칙을 적용하여 사용자가 약하거나 금지된 password를 선택하지 못하도록 도와줍니다. 이는 가치 있는 예방적 보안 기능이지만, authentication 중 risky sign-in에 대해 challenge를 제공하거나 remediation하는 메커니즘은 아닙니다. Sign-in risk remediation에는 더 강력한 password policy만으로는 충분하지 않고 MFA와 같은 실시간 제어가 필요합니다. 따라서 이는 제시된 요구 사항에 대한 첫 단계가 아닙니다.

모든 사용자에 대해 self-service password reset (SSPR)을 구성하는 것은 credential compromise가 의심될 때 secure password change를 요구하는 user risk policies를 구현할 때 중요합니다. 그러나 이 문제는 sign-in risk remediation에 대해 묻고 있으며, 이는 일반적으로 risky authentication 시도 중 MFA를 요구하여 처리합니다. SSPR은 현재 sign-in의 정당성을 실시간으로 검증하지 않으므로 여기서의 주요 remediation 요구 사항을 충족하지 않습니다. 이 옵션은 user risk remediation과 sign-in risk remediation을 혼동한 것입니다.

모든 사용자에 대해 multi-factor authentication (MFA)을 구현하는 것이 올바른 첫 단계입니다. Azure AD Identity Protection의 sign-in risk policies는 risky sign-in에 대한 remediation 제어로 MFA를 사용하기 때문입니다. sign-in이 risky한 것으로 표시되면 MFA를 요구함으로써 실제 사용자가 자신의 신원을 확인하고 차단되지 않은 채 계속 액세스할 수 있습니다. 이는 추가 검증 후에도 액세스를 허용하면서 sign-in risk를 remediation해야 한다는 요구 사항과 정확히 일치합니다. 반면 password reset은 sign-in risk remediation이 아니라 user risk remediation과 관련이 있습니다.

문제 분석

핵심 개념: 이 문제는 Azure AD Identity Protection의 sign-in risk policies와 user risk policies의 차이를 이해하는지를 평가합니다. Identity Protection에서 sign-in risk는 특정 authentication 시도가 실제 사용자에 의해 승인되지 않았을 가능성을 의미하고, user risk는 사용자의 credentials가 손상되었을 가능성을 의미합니다. 정답인 이유: 액세스를 차단하지 않고 sign-in risk를 remediation하려면, 표준 제어는 multi-factor authentication (MFA)을 요구하는 것입니다. MFA를 사용하면 사용자가 위험한 sign-in 중에 자신의 신원을 증명하고, challenge를 성공적으로 완료하면 계속 액세스할 수 있습니다. 이는 액세스를 완전히 거부하지 않고 risk를 remediation해야 한다는 요구 사항을 충족합니다. 주요 기능: - Sign-in risk policies는 medium 또는 high-risk sign-in에 대해 MFA를 요구할 수 있습니다. - User risk policies는 일반적으로 secure password change를 요구하며, 이는 SSPR에 의존합니다. - MFA는 sign-in 중에 사용되는 실시간 step-up authentication 제어입니다. - SSPR은 self-service credential recovery 및 password reset 기능이며, sign-in risk에 대한 기본 remediation 수단은 아닙니다. 일반적인 오해: - 흔한 실수는 sign-in risk와 user risk를 혼동하는 것입니다. Password reset과 SSPR은 sign-in risk remediation이 아니라 user risk remediation과 관련이 있습니다. - Password Protection은 password 품질을 향상시키지만 risky sign-in을 remediation하지는 않습니다. - Access reviews는 governance 기능이며 authentication risk 대응과는 관련이 없습니다. 시험 팁: - 문제에서 sign-in risk라고 하면 MFA를 떠올리십시오. - 문제에서 user risk 또는 compromised credentials라고 하면 secure password change와 SSPR을 떠올리십시오. - policy가 sign-in event를 평가하는지, 아니면 user account 자체를 평가하는지에 특히 주의하십시오.

7
문제 7

다음 표에 표시된 리소스를 포함하는 Azure subscription이 있습니다.

어떤 리소스에 대해 access review를 만들 수 있습니까?

파트 1:

Group1은 Assigned membership type을 가진 Group입니다.

예. 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인 경우가 많습니다.

파트 2:

App1은 Azure Active Directory (Azure AD)의 Enterprise application입니다.

예. 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 구성 자체를 대상으로 하지 않습니다.

파트 3:

Contributor는 Azure subscription role입니다.

예. 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도 검토 가능하다는 점을 인식해야 합니다.

파트 4:

Role1은 Azure Active Directory (Azure AD) 역할입니다.

예. 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를 줄입니다.

8
문제 8

HOTSPOT - 네트워크에는 contoso.com이라는 이름의 온-프레미스 Active Directory 도메인이 포함되어 있습니다. 해당 도메인에는 다음 표에 표시된 객체가 포함되어 있습니다.

Azure AD Connect를 설치합니다. Domain and OU Filtering 전시와 같이 Domain and OU filtering 설정을 구성합니다. (Domain and OU Filtering 탭을 클릭하세요.)

Filter Users and Devices 전시와 같이 Filter users and devices 설정을 구성합니다. (Filter Users and Devices 탭을 클릭하세요.)

diagram

다음 각 문장에 대해, 문장이 참이면 Yes를 선택하세요. 그렇지 않으면 No를 선택하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

User1은 Group1의 멤버입니다.

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

파트 2:

User2는 어떤 그룹의 멤버도 아닙니다.

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

파트 3:

User1 및 Group2는 Group1의 멤버입니다.

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

파트 4:

Group2는 Group1의 멤버입니다.

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

파트 5:

아래 이미지에서 정답을 선택하세요.

question-image

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

파트 6:

User1은 Azure AD에 동기화됩니다.

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

파트 7:

User2는 Azure AD에 동기화됩니다.

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

파트 8:

Group2는 Azure AD에 동기화됩니다.

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

9
문제 9

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. Microsoft 365 테넌트가 있습니다. 모든 사용자는 Microsoft 365 서비스에 액세스할 때 multi-factor authentication (MFA)을 위해 Microsoft Authenticator app을 사용해야 합니다. 일부 사용자는 sign-in 요청을 시작하지 않았는데도 Microsoft Authenticator app에서 MFA 프롬프트를 받았다고 보고합니다. 사용자가 자신이 시작하지 않은 MFA 요청을 보고할 때 해당 사용자를 자동으로 차단해야 합니다. 솔루션: Azure portal에서 multi-factor authentication (MFA)에 대한 Block/unblock users 설정을 구성합니다. 이것이 목표를 충족합니까?

예가 정답입니다. Azure MFA에는 사용자가 자신이 시작하지 않은 MFA 요청을 보고할 수 있게 해주는 fraud alert 기능이 포함되어 있기 때문입니다. 이 기능이 구성되면 사용자는 의심스러운 프롬프트를 보고한 후 MFA 완료가 자동으로 차단될 수 있습니다. Azure portal의 Block/unblock users 설정은 이러한 차단된 계정을 관리하는 데 사용되는 관리 제어입니다. 이는 원치 않는 MFA 요청을 보고할 때 사용자를 자동으로 차단해야 한다는 요구 사항과 직접적으로 일치합니다.

아니요는 오답입니다. 설명된 솔루션은 단순한 수동 차단 목록이 아니라 Azure MFA fraud alert 워크플로와 연결되어 있기 때문입니다. 관리자가 그곳에서 사용자를 수동으로 차단하거나 차단 해제할 수도 있지만, 동일한 기능 세트는 사용자가 MFA 중 fraud를 보고할 때 자동 차단도 지원합니다. 따라서 이 솔루션이 목표를 충족하지 않는다고 말하는 것은 Azure MFA의 의도된 fraud 보고 동작을 간과한 것입니다. 시험에서는 이 시나리오를 Conditional Access 또는 Identity Protection policy가 아니라 MFA fraud alert에 매핑해야 합니다.

문제 분석

핵심 개념: 이 문제는 Azure MFA fraud alert와 관리자가 사기성 인증 프롬프트를 보고한 사용자를 어떻게 관리하는지에 대한 지식을 테스트합니다. Microsoft Entra ID에서 사용자는 자신이 시작하지 않은 MFA 요청을 받으면 이를 fraud로 보고할 수 있으며, 관리자가 개입할 때까지 시스템이 해당 사용자의 MFA 사용을 자동으로 차단할 수 있습니다. 정답인 이유: 예, 이는 목표를 충족합니다. Azure portal의 MFA 서비스 설정은 사용자가 MFA 요청을 사기성으로 보고할 때 사용자를 자동으로 차단하는 fraud alert 동작을 지원하기 때문입니다. Block/unblock users 설정은 fraud 보고가 발생한 후 차단된 사용자를 관리하는 데 사용됩니다. 이는 정확히 이 시나리오를 위해 의도된 기본 제공 메커니즘입니다. 주요 기능: Azure MFA fraud alert를 사용하면 사용자가 MFA 프롬프트가 자신에 의해 시작되지 않았음을 표시할 수 있습니다. 보고되면 사용자는 MFA에 대해 자동으로 차단될 수 있으며, 관리자는 나중에 적절한 경우 계정을 검토하고 차단 해제할 수 있습니다. 이는 MFA fatigue 또는 원치 않는 push notification과 같은 의심스러운 MFA 활동에 신속하게 대응하는 데 도움이 됩니다. 일반적인 오해: 일부 응시자는 Block/unblock users가 단지 수동 관리자 작업일 뿐이므로 자동 차단 요구 사항을 충족할 수 없다고 가정합니다. 그러나 차단 상태는 fraud 보고에 의해 자동으로 트리거될 수 있으며, 관리자 인터페이스는 그 결과를 관리하는 데 사용됩니다. 또 다른 일반적인 혼동은 이 기능을 sign-in risk policy 또는 Conditional Access와 혼동하는 것인데, 이는 별개의 ID 보호 제어입니다. 시험 팁: SC-300에서 사용자가 예상치 못한 MFA 프롬프트를 보고하는 내용이 나오면 Azure MFA fraud alert를 떠올리십시오. 요구 사항이 사용자가 fraud를 보고한 후 자동으로 차단하는 것이라면, Azure의 MFA 서비스 설정이 해당 동작을 구성하고 관리하는 관련 위치입니다.

10
문제 10

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 귀하는 Azure Monitor를 사용하여 Azure Active Directory (Azure AD) 활동 로그를 분석합니다. 귀하는 실패한 Azure AD 사용자 로그인 시도에 대해 매일 100개가 넘는 이메일 경고를 받습니다. 귀하 대신 새로운 security administrator가 경고를 받도록 해야 합니다. 솔루션: Azure AD에서 Insights administrator 역할에 대한 할당을 만듭니다. 이것이 목표를 충족합니까?

예는 올바르지 않습니다. Azure AD 역할 할당은 Azure Monitor 경고 전달을 제어하지 않기 때문입니다. 새 관리자가 Insights administrator 역할을 가지고 있더라도, Azure Monitor는 기존 경고 action group에 정의된 주소로 계속 이메일을 보냅니다. 목표를 충족하려면 현재 수신자 대신 새로운 security administrator를 포함하도록 action group 또는 경고 규칙 알림 설정을 수정해야 합니다.

아니요. Azure AD에서 Insights administrator 역할에 대한 할당을 생성해도 Azure Monitor 이메일 경고의 수신자는 변경되지 않습니다. Azure Monitor는 경고 규칙에 연결된 action group을 기반으로 알림을 전송하며, 해당 수신자는 그곳에서 명시적으로 구성되어야 합니다. 역할 할당은 모니터링 데이터와 설정을 보거나 관리할 수 있는 권한만 부여할 뿐, 할당된 사용자를 경고 이메일에 구독시키지는 않습니다.

문제 분석

핵심 개념: Azure Monitor 경고 이메일은 Azure AD 디렉터리 역할 할당이 아니라 경고 action group에 구성된 수신자에게 전송됩니다. 정답인 이유: Azure AD에서 Insights administrator 역할을 할당해도 기존 Azure Monitor 경고 알림이 해당 사용자에게 리디렉션되거나 구독되지 않습니다. 주요 기능: Azure Monitor는 경고 규칙과 action group을 사용하여 누가 이메일, SMS, webhook 또는 기타 알림을 받을지 정의합니다. Azure AD 역할은 경고 전달이 아니라 권한을 제어합니다. 일반적인 오해: 관리 역할과 알림 구독을 혼동하기 쉽지만, Insights administrator 또는 Security administrator와 같은 역할이 자동으로 경고 수신자가 되지는 않습니다. 시험 팁: SC-300에서 누가 Azure Monitor 경고를 받는지 묻는 문제는 Azure AD 역할 할당보다 action group과 경고 구성을 떠올리십시오.

다른 모의고사

Practice Test #1

50 문제·100분·합격 700/1000

Practice Test #3

50 문제·100분·합격 700/1000
← 모든 Microsoft SC-300 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 Microsoft SC-300 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

이동 중에도 모든 문제를 풀고 싶으신가요?

앱 받기

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.