50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
파일을 ______ 하면 해당 파일의 데이터는 적절한 key를 가진 뷰어가 읽고 사용할 수 있게 됩니다.
정답: D. Encrypting. 파일을 Encrypting 하면 encryption algorithm과 cryptographic key를 사용하여 읽을 수 있는 plaintext를 읽을 수 없는 ciphertext로 변환합니다. 적절한 key(그리고 이를 사용할 권한)를 가진 뷰어(사용자, 서비스 또는 애플리케이션)만 파일을 decrypt하여 데이터를 다시 읽고 사용할 수 있게 만들 수 있습니다. 이는 문장의 표현인 “적절한 key를 가진 뷰어가 읽고 사용할 수 있음”과 정확히 일치합니다. 다른 선택지가 틀린 이유: - A. Archiving: 일반적으로 파일을 묶거나 장기 스토리지로 이동(보존, 백업 또는 규정 준수 목적)하는 것을 의미합니다. Archived 데이터는 별도로 encrypted되지 않는 한 key 없이도 읽을 수 있을 수 있습니다. - B. Compressing: 데이터를 더 효율적으로 인코딩하여 파일 크기를 줄입니다. Compressed 파일은 decompress할 수 있는 누구나 읽을 수 있으며, 본질적으로 cryptographic key가 필요하지 않습니다. - C. Deduplicating: 중복 데이터 블록을 제거하여 스토리지를 절약합니다. 이는 데이터가 저장되는 방식을 바꾸는 것이지, 누가 읽을 수 있는지를 바꾸는 것이 아닙니다. 시험 팁: 문제에 “key”, “ciphertext”, “decrypt”, 또는 “authorized된 뷰어만 읽을 수 있음”이 언급되면 encryption을 가리키는 것입니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
HOTSPOT - 다음 각 문장에 대해 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure Active Directory (Azure AD)에서 사용자 지정 역할을 만들 수 있습니다.
예. Azure Active Directory (Microsoft Entra ID)에서 사용자 지정 역할을 만들 수 있습니다. 이는 일반적으로 사용자 지정 디렉터리 역할(custom directory roles)이라고 합니다. 이러한 역할을 사용하면 User Administrator 또는 Security Administrator와 같은 기본 제공 역할에만 의존하는 대신, 특정 권한 집합(디렉터리 수준 권한)을 가진 역할을 정의할 수 있습니다. 이는 업무 기능에 필요한 정확한 권한만 부여함으로써 최소 권한 원칙을 지원합니다. “아니요”가 틀린 이유: Entra ID는 기본 제공 역할만으로 제한되지 않습니다. 많은 조직이 기본 제공 역할로 시작하지만, 더 세분화된 관리 요구 사항을 충족하기 위해 사용자 지정 역할을 사용할 수 있습니다. 흔한 시험 함정에 유의하세요. Entra ID 사용자 지정 디렉터리 역할을 Azure RBAC 사용자 지정 역할과 혼동하지 마세요. 둘 다 존재하지만 적용 범위가 다릅니다(디렉터리 vs Azure 리소스). 이 문장은 “in Azure AD”라고 명시하고 있으므로 여전히 참입니다.
Global administrator는 Azure Active Directory (Azure AD)의 역할입니다.
예. Global administrator는 Azure Active Directory (Microsoft Entra ID)의 역할입니다. 이는 가장 높은 권한을 가진 디렉터리 역할이며, 사용자, 그룹, app registrations 및 다양한 tenant-wide 설정 관리를 포함해 tenant 전반에 걸친 광범위한 권한을 가집니다. 권한이 매우 강력하므로, 모범 사례는 Global administrator의 수를 최소화하고, 전용 admin 계정을 사용하며, 강력한 인증(MFA)과 privileged access controls로 보호하는 것입니다. “아니요”가 틀린 이유: Global administrator는 가장 기본적인 built-in Entra ID 역할 중 하나이며 Microsoft identity 문서와 시험 목표에서 자주 언급됩니다. 또 다른 흔한 혼동은 Azure subscription 역할(Owner/Contributor)과의 혼동인데, Global administrator는 Azure resource RBAC 역할이 아니라 디렉터리 역할입니다.
Azure Active Directory (Azure AD) 사용자는 하나의 role만 할당될 수 있다.
아니오. Azure AD (Microsoft Entra ID) 사용자는 여러 role을 할당받을 수 있다. role 할당은 사용자당 하나의 role로 제한되지 않는다. 예를 들어, 사용자는 User Administrator와 Application Administrator를 동시에 맡을 수 있으며, 또는 security 및 compliance 운영을 위한 추가 role을 보유할 수도 있다. 이러한 유연성은 실제 운영 요구를 지원하지만, 과도한 privilege를 방지하기 위해 신중하게 관리되어야 한다. “예”가 틀린 이유: Entra ID role-based access는 누적(additive)되도록 설계되어 있다. 사용자를 하나의 role로만 제한하는 것은 비현실적이며 조직이 지나치게 광범위한 role에 의존하도록 만들 수 있다. security best-practice 관점에서는 여전히 least privilege와 separation of duties를 따라야 하지만, 플랫폼 기능 자체는 (직접 또는 지원되는 경우 group-based role assignment를 통해) 여러 role 할당을 확실히 허용한다.
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
Windows Hello for Business에서 인증에 사용되는 사용자의 생체 인식 데이터는 ______
정답: B. Windows Hello for Business에서는 사용자의 생체 인식 데이터(생체 인식 템플릿)가 로컬 장치에만 저장됩니다. 생체 인식은 암호화 키(일반적으로 TPM으로 보호됨)를 잠금 해제하기 위한 로컬 제스처로 사용됩니다. Azure AD/Entra ID는 생체 인식 템플릿을 수신하거나 저장하지 않으며, 인증을 검증하는 데 필요한 연관된 공개 키 정보만 보유합니다. 다른 선택지가 틀린 이유: A는 WHfB가 표준 모델에서 생체 인식 데이터를 외부 장치에 저장하지 않기 때문에 틀립니다. 템플릿은 등록이 이루어진 장치에 보관됩니다. C는 Azure AD가 생체 인식 템플릿을 저장하지 않기 때문에 틀립니다. 생체 정보를 중앙에 저장하면 프라이버시 및 침해 위험이 증가합니다. D는 생체 인식 템플릿이 사용자의 장치들 간에 복제되지 않기 때문에 틀립니다. 각 장치는 자체 로컬 생체 인식 등록과 자체 키 자료 등록을 가집니다.
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
Azure Active Directory (Azure AD)는 인증 및 권한 부여에 ______ 사용됩니다.
정답: B. identity provider. Azure Active Directory (Azure AD)는 현재 Microsoft Entra ID로 브랜딩되었으며, Microsoft의 클라우드 identity provider(IdP) 및 identity and access management 서비스입니다. 이는 인증(자격 증명 및 로그인 검증)을 수행하고, 애플리케이션과 Azure 서비스가 액세스를 부여하는 데 사용하는 클레임을 포함한 보안 토큰(예: OAuth 2.0/OpenID Connect/SAML 토큰)을 발급함으로써 권한 부여를 지원합니다. 또한 Conditional Access, MFA, RBAC와 통합되어 액세스 결정을 강제합니다. 다른 선택지가 틀린 이유: A (XDR 시스템): XDR(예: Microsoft Defender XDR)은 엔드포인트, ID, 이메일, 앱 전반의 위협을 상관 분석하고 대응하는 것이며, 사용자를 인증하는 서비스가 아닙니다. C (management group): Management group은 구독을 구성하고 대규모로 policy/RBAC를 적용하기 위한 Azure 거버넌스 계층 구조이며, 인증을 제공하지 않습니다. D (SIEM 시스템): SIEM(예: Microsoft Sentinel)은 보안 모니터링 및 인시던트 대응을 위해 로그/이벤트를 수집하고 분석하지만, 로그인 및 토큰 발급을 위한 IdP 역할을 하지는 않습니다.
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
Microsoft 365 security center에서 ______를 사용하여 동일한 공격과 관련된 경고의 집계를 확인할 수 있습니다.
정답: D. Incidents. Microsoft 365 Defender에서 incident는 동일한 공격 또는 캠페인의 일부로 판단되는 여러 경고를 그룹화하고 상관관계 분석을 수행하는 데 사용되는 기본 컨테이너입니다. incident 보기에서는 관련 경고, 영향을 받은 엔터티(사용자/디바이스/mailboxes), 증거, 심각도, 권장 remediation 단계 등을 보여주는 집계된 “attack story”를 제공합니다. 이는 문제에서 설명한 “동일한 공격과 관련된 경고의 집계”와 정확히 일치합니다. 다른 선택지가 틀린 이유: - A. Reports: Reports는 대시보드와 분석(추세, 볼륨, 보안 상태)을 제공하지만, 관련 경고를 위한 운영상의 집계 객체로 사용되지는 않습니다. - B. Hunting: Advanced hunting은 텔레메트리 전반에서 쿼리(KQL)를 사용해 선제적으로 조사하는 기능으로, 의심스러운 활동을 발견하는 데 도움이 되지만 경고를 자동으로 단일 케이스로 집계하지는 않습니다. - C. Attack simulator: (예: phishing simulations)과 같은 시뮬레이션 공격을 수행하여 사용자를 교육하고 준비 상태를 평가하는 데 사용되며, 진행 중인 실제 공격에서 발생한 경고를 상관관계 분석하는 용도는 아닙니다.
HOTSPOT - 다음 각 문장에 대해 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure Active Directory (Azure AD) Identity Protection은 사용자의 risk level에 따라 사용자를 그룹에 추가할 수 있습니다.
Azure AD (Microsoft Entra ID) Identity Protection은 risk level에 따라 사용자를 그룹에 추가하지 않습니다. Identity Protection의 역할은 risk(사용자 risk 및 sign-in risk)를 탐지하고 계산한 다음, 관리자가 정책과 워크플로를 사용해 대응할 수 있도록 지원하는 것이며—가장 일반적으로 Conditional Access를 통해 수행됩니다. 그룹 멤버십 자동화는 Entra ID dynamic groups(부서, 직함 등과 같은 rule-based attributes) 또는 Identity Governance 기능과 같은 다른 기능에서 처리됩니다. risk level은 사용자를 자동으로 그룹에 배치하기 위한 기본 rule로 사용되지 않으며, Identity Protection은 “사용자를 high-risk group으로 이동”과 같은 작업을 제공하지 않습니다. “예”가 틀린 이유: risk 기반 액세스 적용(Conditional Access 작업: MFA 요구/차단)과 identity lifecycle/governance 기능(그룹 할당)을 혼동한 것입니다. 시험 관점에서 생각하면: Identity Protection = risk 탐지 + Conditional Access에 제공; 그룹 관리 = Entra ID groups/governance.
Azure Active Directory (Azure AD) Identity Protection은 사용자 자격 증명이 공개적으로 유출되었는지 감지할 수 있습니다.
Azure AD (Microsoft Entra ID) Identity Protection은 유출된 자격 증명을 감지할 수 있습니다. 기본 제공 위험 감지 중 하나가 “Leaked credentials”이며, Microsoft는 위협 인텔리전스와 공개적으로 이용 가능한 소스(흔히 public web/dark web로 설명됨)에 대한 모니터링을 사용하여 노출된 사용자 이름/비밀번호 쌍을 찾습니다. 해당 자격 증명이 테넌트의 계정과 일치하면 Identity Protection이 사용자 위험을 발생시킵니다. 이는 단순한 보고 기능이 아니라 감지 기능입니다. 사용자 위험 점수에 반영되며, 수정 조치를 트리거할 수 있습니다(예: 사용자 위험 정책 또는 Conditional Access를 통해 비밀번호 재설정 강제). “아니요”가 틀린 이유: Identity Protection이 비정상적인 로그인(예: 불가능한 이동)만 감지하고 자격 증명 노출은 감지하지 못한다고 의미하게 됩니다. 실제로 leaked credentials는 핵심 Identity Protection 감지 항목이며, 계정 탈취 방지와 연결된 SC-900의 일반적인 개념입니다.
Azure Active Directory (Azure AD) Identity Protection은 사용자의 위험 수준에 따라 Multi-Factor Authentication을 호출하는 데 사용할 수 있습니다.
Azure AD (Microsoft Entra ID) Identity Protection은 Conditional Access와 통합하여 사용자의 위험 수준에 따라 Multi-Factor Authentication을 호출하는 데 사용할 수 있습니다. 실제로는 Identity Protection 위험 신호(사용자 위험 및/또는 로그인 위험)를 조건으로 사용하는 Conditional Access 정책을 구성합니다. 위험이 구성된 임계값(예: 중간 또는 높음)에 도달하면, 해당 정책은 제어로 MFA를 요구할 수 있습니다. 이는 시험에서 중요한 포인트입니다. Identity Protection은 위험 평가를 제공하고, Conditional Access는 대응(예: MFA 요구, 액세스 차단, 암호 변경 요구 등)을 강제합니다. 두 기능을 함께 사용하면 Zero Trust에 맞춘 적응형 액세스를 구현할 수 있습니다. “아니요”가 틀린 이유: 위험 기반 Conditional Access가 Identity Protection 신호를 사용하는 표준 설계 패턴을 간과하기 때문입니다. Identity Protection 자체가 MFA 제공자는 아니지만, 위험에 따라 Conditional Access를 통해 MFA 요구 사항을 트리거하는 데 명시적으로 사용됩니다.
특정 키워드가 포함된 Microsoft SharePoint Online 사이트의 모든 문서를 식별하기 위해 Microsoft 365 compliance center의 어떤 기능을 사용할 수 있습니까?
Microsoft Purview의 Audit는 Microsoft 365 전반의 활동 log(예: 파일 액세스, 삭제, 공유, 권한 변경)를 기록하고 검색할 수 있게 해줍니다. 이는 조사와 책임 추적에 중요한 “누가 무엇을, 언제, 어디서 했는지”에 답합니다. 그러나 Audit는 문서의 전체 텍스트/콘텐츠를 검색하여 특정 키워드가 포함된 파일을 찾지 못하므로 콘텐츠 발견을 위한 올바른 도구가 아닙니다.
Compliance Manager는 assessment, 개선 작업, compliance score를 사용하여 조직이 compliance posture를 평가하고 관리하도록 돕습니다. 이는 control을 추적하고, 요구 사항을 Microsoft 기능에 매핑하며, 증거를 문서화하는 데 사용됩니다. SharePoint Online 문서 전반에서 키워드 검색을 수행하지 않습니다. 거버넌스 및 compliance 계획을 지원하긴 하지만, 콘텐츠를 찾기 위한 discovery/search 기능은 아닙니다.
Microsoft Purview compliance portal의 Content Search는 SharePoint Online site를 포함하여 Microsoft 365 워크로드 전반에서 콘텐츠를 찾도록 설계되었습니다. 특정 SharePoint site를 대상으로 지정하고 키워드/KQL 쿼리를 실행하여 특정 단어 또는 구문이 포함된 문서를 식별할 수 있습니다. 결과를 미리 보고 내보낼 수 있으므로, SharePoint site에서 특정 키워드가 포함된 모든 문서를 찾는 데 올바른 기능입니다.
Microsoft Purview(및 관련 보안/컴플라이언스 솔루션)의 Alerts는 특정 이벤트, 위험 또는 policy match가 발생했을 때(예: DLP policy 트리거, 의심스러운 활동, 컴플라이언스 관련 incident) 관리자가 알림을 받도록 합니다. Alerts는 사후 대응형 알림 및 triage 도구이며, SharePoint Online site의 모든 문서를 대상으로 키워드를 검색하는 메커니즘을 제공하지 않습니다. 이벤트를 가리킬 수는 있지만 콘텐츠 발견을 수행하지는 않습니다.
핵심 개념: 이 문제는 Microsoft Purview(Microsoft 365 compliance)의 eDiscovery 및 검색 기능—특히 키워드를 기반으로 Microsoft 365 위치(예: SharePoint Online) 전반에서 콘텐츠를 찾는 방법—을 평가합니다. Microsoft Purview compliance portal에서 검색 조건과 일치하는 항목을 찾도록 설계된 기능은 Content search입니다. 정답인 이유: Content search를 사용하면 SharePoint Online 사이트(및 Exchange mailbox, OneDrive 같은 다른 워크로드) 전반에서 특정 키워드, 구문 또는 조건이 포함된 항목을 검색할 수 있습니다. 검색 범위를 특정 SharePoint site URL로 지정하고 위치를 선택한 다음, KQL(Keyword Query Language)을 사용하여 대상 용어가 포함된 문서를 식별할 수 있습니다. 결과는 미리 보기, 내보내기할 수 있으며, 추가적인 compliance 워크플로(예: eDiscovery case)의 입력으로 사용할 수 있습니다. 주요 기능 / 사용 방법: - 위치 대상 지정: SharePoint site(특정 site URL)를 선택하고 필요 시 OneDrive를 포함합니다. - 키워드 기반 쿼리: KQL을 사용해 단어/구문을 검색하고 메타데이터(파일 형식, 작성자, 날짜 등)로 세분화합니다. - 결과에 대한 작업: 결과 미리 보기, 내보내기, 보고서 생성—조사, 규제 요청, 내부 감사에 유용합니다. - 거버넌스 정렬: 민감한 콘텐츠를 통제된 방식으로 발견할 수 있게 하여 Azure/Microsoft Well-Architected의 “Security” pillar 원칙(최소 권한, 감사 가능성, 통제된 액세스)을 지원합니다. 일반적인 오해: 많은 사람이 Audit를 검색과 혼동합니다. Audit log는 사용자/관리자 활동(누가 무엇에 액세스했는지, 무엇이 변경되었는지)을 기록하지만, 키워드가 포함된 모든 문서를 열거하지는 않습니다. Compliance Manager는 상태/평가 도구이지 콘텐츠 발견 엔진이 아닙니다. Alerts는 이벤트나 위험을 알려주지만 문서 전반에 대한 키워드 발견을 수행하지는 않습니다. 시험 팁: SC-900에서 작업을 올바른 Purview 기능에 매핑하세요: - “SharePoint/Exchange/OneDrive 전반에서 키워드로 콘텐츠 찾기” = Content search(또는 법적 case의 경우 eDiscovery). - “누가 무엇을 언제 했는지” = Audit. - “compliance score/평가 개선” = Compliance Manager. - “의심/컴플라이언스 이벤트 알림” = Alerts. 질문이 순수하게 키워드가 포함된 문서를 식별하는 것이라면 Content search가 가장 적합합니다.
Azure Multi-Factor Authentication (MFA)에서 사용할 수 있는 인증 방법 세 가지는 무엇입니까? 각 정답은 완전한 솔루션을 나타냅니다. 참고: 각 정답 선택은 1점입니다.
정답입니다. SMS는 사용자에게 등록된 휴대폰 번호로 일회용 코드를 전송하는 Azure MFA 확인 방법입니다. 사용자는 로그인 중 해당 코드를 입력하여 MFA를 완료합니다. 지원되기는 하지만 SIM swapping 및 가로채기 같은 위험 때문에 app 기반 방법보다 약한 것으로 간주되며, 더 강한 보안 체계에서는 종종 대체 수단으로만 허용됩니다.
정답입니다. Microsoft Authenticator app은 Azure MFA의 주요 방법입니다. 푸시 알림(승인/거부)과 시간 기반 일회용 암호(TOTP)를 제공할 수 있습니다. 이 방법은 더 안전하고 신뢰성이 높으며 최신 인증 경험을 지원하므로 일반적으로 SMS/voice보다 권장됩니다. Microsoft Entra ID에서 Conditional Access의 MFA 요구 사항과 함께 흔히 사용됩니다.
오답입니다. Email verification은 Azure MFA 로그인 방법이 아닙니다. 이메일은 일반적으로 Self-Service Password Reset (SSPR) 같은 계정 복구 시나리오나 연락처 정보 확인에 사용되지만, 인증 중 MFA 챌린지를 완료하기 위한 표준 Azure MFA 확인 방법에는 포함되지 않습니다.
정답입니다. Phone call은 사용자가 자동 음성 전화를 받고(예: 키를 눌러) 로그인을 확인하는 Azure MFA 지원 방법입니다. SMS와 마찬가지로 전화망 기반 공격 벡터 및 신뢰성 문제로 인해 app 기반 방법보다 덜 안전한 것으로 간주되지만, 여전히 유효한 Azure MFA 옵션이며 시험 문제에 자주 등장합니다.
오답입니다. Security questions는 Self-Service Password Reset (SSPR)과 관련이 있으며, 추측되거나 사회공학으로 악용될 수 있어 일반적으로 권장되지 않습니다. 이는 로그인용 Azure MFA 인증 방법이 아닙니다. 시험에서 보안 질문은 보통 MFA 확인이 아니라 비밀번호 재설정/복구를 의미합니다.
핵심 개념: 이 문제는 Microsoft Entra ID(이전 Azure AD) Multi-Factor Authentication (MFA)의 인증 방법을 평가합니다. MFA는 계정 탈취 위험을 줄이기 위해 서로 독립적인 요소(알고 있는 것, 가지고 있는 것, 본인 자체) 중 최소 두 가지를 요구합니다. Entra ID에서 MFA 방법은 사용자별(레거시 per-user MFA)로 구성하거나, 더 일반적으로 Conditional Access 정책을 통해 강제합니다. 정답이 맞는 이유: Azure MFA는 여러 가지 2차 인증 방법을 지원합니다. 가장 전형적이고 널리 알려진 Azure MFA 방법 3가지는 다음과 같습니다. 1) 등록된 전화번호로 전송되는 Text message (SMS). 2) Microsoft Authenticator app(푸시 알림 승인 또는 시간 기반 일회용 암호, TOTP). 3) 등록된 전화번호로 걸려오는 Phone call. 이는 선택지 A, B, D에 직접 해당합니다. 주요 기능 및 모범 사례: - Microsoft Authenticator app은 푸시 및 OTP를 지원하고 SMS/voice보다 피싱에 더 강하며 최신 인증 흐름과 잘 통합되므로 일반적으로 선호됩니다. - SMS 및 phone call도 지원되지만 SIM swap/사회공학 및 전화망 신뢰성 문제로 인해 보안성이 낮은 것으로 간주됩니다. Microsoft의 보안 가이드는 가능하면 SMS/voice에서 벗어날 것을 점점 더 권장합니다. - Conditional Access에서는 “multifactor authentication”을 요구할 수 있으며, Authentication methods policy를 통해 사용자가 등록/사용할 수 있는 방법을 제어할 수 있습니다. 또한 더 높은 보증 수준을 위해 MFA를 더 강력한 제어(예: 피싱 저항성 방법인 FIDO2 keys, certificate-based auth)와 결합할 수도 있습니다. 흔한 오해: - Email verification은 종종 self-service password reset (SSPR) 또는 계정 복구에 사용되지만, 로그인용 Azure MFA 인증 방법은 아닙니다. - Security questions 또한 SSPR과 관련이 있으며(보안상 권장되지 않음), MFA 로그인 방법이 아닙니다. 시험 팁: SC-900에서는 “전형적인 Azure MFA 방법”인 Authenticator app, SMS, phone call을 기억하세요. 이메일이나 보안 질문이 보이면 “비밀번호 재설정/복구”를 떠올리고, 로그인용 MFA가 아님을 생각하세요. 또한 Conditional Access는 Entra ID에서 MFA를 요구하는 현대적인 방식이며, Zero Trust 및 Azure Well-Architected 보안 원칙(강력한 ID 제어, 최소 권한, 위험 기반 액세스)과도 정렬됩니다.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택하십시오. 그렇지 않으면 No를 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure Defender는 Azure Storage에 대한 취약점과 위협을 탐지할 수 있습니다.
예. “Azure Defender”(현재 Microsoft Defender for Cloud의 workload protection plans)는 Azure Storage에 대한 보호를 포함합니다. Defender for Storage 플랜은 비정상적인 액세스 패턴, 잠재적인 데이터 유출(data exfiltration), 악성 업로드와 같은 의심스러운 활동에 대한 위협 탐지를 제공하며, Storage account와 관련된 보안 경고를 표시할 수 있습니다. 또한 Defender for Cloud는 posture management recommendations의 일부로 스토리지 구성과 관련된 특정 보안 문제(예: 과도하게 허용적인 액세스 설정)를 식별할 수 있습니다. 왜 아니요가 아닌가: Storage는 전용 Defender 플랜이 있는 핵심 Azure 리소스 유형 중 하나입니다. 시험에서는 Defender for Cloud가 VM에만 국한되지 않으며, Storage, SQL, Kubernetes와 같은 PaaS 서비스도 특정 위협 탐지 기능(CWP)으로 커버한다는 점을 인지하기를 기대하는 경우가 많습니다.
Cloud Security Posture Management (CSPM)은 모든 Azure subscription에서 사용할 수 있습니다.
예. Microsoft Defender for Cloud는 Azure subscription에 대해 Cloud Security Posture Management (CSPM) 기능을 제공하며, 여기에는 secure score, security recommendation, 그리고 resource에 대한 policy-based assessment가 포함됩니다. SC-900 수준에서는 Defender for Cloud가 해당 subscription에 사용되면 Azure subscription 전반에서 이를 사용할 수 있는 것으로 다룹니다. 이 설명은 Azure subscription에 specifically 해당하는 내용이며, advanced multicloud 또는 premium CSPM 기능에 대한 내용이 아닙니다. 따라서 No는 문제에서 평가하는 기본 product capability를 지나치게 복잡하게 해석하므로 올바르지 않습니다.
Azure Security Center는 Azure 또는 온-프레미스에 배포된 워크로드의 보안을 평가할 수 있습니다.
예. Azure Security Center(현재 Microsoft Defender for Cloud)는 Azure의 워크로드 보안을 평가할 수 있으며 온-프레미스 환경까지 확장할 수 있습니다. Azure 리소스의 경우, 기본적으로 보안 상태를 평가하고 권장 사항 및 secure score를 제공할 수 있습니다. 온-프레미스(및 다른 클라우드)의 경우, 에이전트 및/또는 Azure Arc-enabled servers를 사용하여 서버를 온보딩할 수 있으며, 이를 통해 Defender for Cloud가 보안 신호를 수집하고 구성을 평가하며 (적절한 플랜이 있는 경우) 위협 보호를 제공할 수 있습니다. 아니요가 아닌 이유: 시험에서 자주 나오는 개념은 Defender for Cloud가 하이브리드 시나리오를 지원하는 cloud-native 보안 관리 도구라는 점입니다. Azure 전용 워크로드로 제한되지 않으며, 해당 리소스가 연결/온보딩되어 있으면 Azure 및 비-Azure 환경 전반에 걸쳐 통합 보안 관리를 제공할 수 있습니다.
조직 내 두 부서 구성원 간의 커뮤니케이션과 정보 공유를 제한하기 위해 사용할 수 있는 Microsoft 365 기능은 무엇입니까?
Sensitivity label policies(Microsoft Purview Information Protection)는 암호화, 액세스 제어, 시각적 표시를 통해 문서 및 이메일 같은 콘텐츠를 분류하고 보호하는 데 사용됩니다. 이는 정보가 공유되는 방식을 제어하는 데 도움이 되지만(예: “Confidential—internal only”), Teams에서 두 부서가 커뮤니케이션하는 것을 직접적으로 방지하거나 광범위한 협업을 차단하지는 않습니다. Labels는 사용자 세그먼트 기반 커뮤니케이션 차단이 아니라 콘텐츠 중심입니다.
Customer Lockbox는 Microsoft support 엔지니어가 문제 해결을 위해 콘텐츠에 액세스하기 전에 고객의 명시적 승인을 요구하는 Microsoft 365 기능입니다. 이는 부서 간 내부 커뮤니케이션 또는 공유를 제한하기 위한 것이 아니라 Microsoft의 데이터 액세스에 대한 고객 통제를 위한 것입니다. 즉, 사용자 간 협업 제어가 아니라 벤더 액세스 거버넌스를 다룹니다.
Information barriers는 컴플라이언스 요구 사항을 충족하기 위해 정의된 사용자 세그먼트(예: 부서) 간의 커뮤니케이션과 협업을 제한하도록 설계되었습니다. Teams에서 채팅, 통화, 모임, 디렉터리 조회를 방지할 수 있으며, 세그먼트 간 SharePoint 및 OneDrive에서의 공유/협업을 제한할 수 있습니다. 이는 두 부서 간 정보 흐름을 차단하기 위한 직접적이고 목적에 맞게 구축된 기능입니다.
Privileged Access Management (PAM)는 일반적으로 just-in-time 권한 상승과 시간 제한 승인 등을 통해 상승된 administrative access를 제어하고 감사하는 데 중점을 둡니다. 이는 상시 admin 권한을 줄이고 관리자에 대한 least privilege를 지원합니다. 그러나 서로 다른 부서의 일반 사용자 간 일상적인 커뮤니케이션이나 정보 공유를 제어하지는 않습니다.
핵심 개념: 이 문제는 Microsoft Purview Information Barriers (IB)를 평가합니다. IB는 Microsoft 365에서 특정 사용자 또는 그룹 간의 커뮤니케이션이나 협업을 방지하도록 설계된 컴플라이언스 기능입니다. 이는 규제, 법적, 또는 윤리적 분리 요구 사항(예: 부서 간 “Chinese walls”)을 충족하기 위해 일반적으로 사용됩니다. 정답이 맞는 이유: Information barriers는 (두 부서와 같은) 사용자 세그먼트 간의 커뮤니케이션 및 정보 공유를 제한하도록 특별히 구축되었습니다. 구성하면 IB policies는 Microsoft Teams, SharePoint Online, OneDrive for Business(및 구성에 따라 지원되는 기타 환경) 전반에서 세그먼트 간 상호작용을 차단하거나 제한할 수 있습니다. 예를 들어 Sales 부서가 Finance 부서와 채팅, 통화, 파일 공유를 하지 못하도록 하여 이해 상충 또는 부적절한 데이터 흐름의 위험을 줄일 수 있습니다. 주요 기능 / 동작 방식: IB는 “segments”(대개 Microsoft Entra ID의 Department, Group membership, 또는 custom attributes 같은 특성 기반)와 누가 누구와 커뮤니케이션할 수 있는지를 정의하는 policies를 사용합니다. Policies는 양방향(상호 차단)일 수 있으며 특정 workload로 범위를 지정할 수 있습니다. 실무에서는 segments(예: DeptA 및 DeptB)를 정의한 다음, 이들 간 커뮤니케이션을 차단하는 IB policy를 생성합니다. 이는 Microsoft Purview 스택의 컴플라이언스 및 거버넌스 원칙과 정렬되며, least privilege를 강제하고 데이터 유출 경로를 줄임으로써 Azure Well-Architected Framework의 Security pillar를 지원합니다. 흔한 오해: 많은 학습자가 sensitivity labels를 커뮤니케이션 제한과 혼동합니다. Sensitivity labels는 콘텐츠를 분류하고 보호(암호화, 표시, 파일/이메일에 대한 액세스 제한)하지만, 두 부서가 채팅하거나 협업하는 것을 본질적으로 막지는 않습니다. Customer Lockbox는 Microsoft support의 데이터 액세스에 관한 것이지 내부 사용자 간 제한이 아닙니다. PAM은 privileged role elevation에 관한 것이지 부서 간 커뮤니케이션 제어가 아닙니다. 시험 팁: SC-900에서 키워드를 기능에 매핑하세요: - “그룹/부서 간 커뮤니케이션 제한” => Information Barriers. - “문서/이메일 분류/보호” => Sensitivity labels. - “Microsoft support 액세스 승인” => Customer Lockbox. - “Just-in-time admin access” => PAM/PIM. 또한 IB는 주로 identity 또는 admin privilege 도구가 아니라 Microsoft Purview 컴플라이언스 기능의 일부라는 점을 기억하세요.
