50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
______는 조사에 사용될 수 있는 전자 정보를 식별하고, 보존(홀드)하며, 내보내는 데 사용됩니다.
정답: C. eDiscovery. Microsoft Purview eDiscovery는 내부 조사, 소송, 또는 규제 기관의 요청에 필요할 수 있는 전자적으로 저장된 정보(ESI)를 식별하고, 보존(홀드 설정), 수집, 검토, 및 내보내는 데 사용됩니다. “식별, 홀드, 내보내기”라는 표현은 Microsoft 365 데이터 원본 전반에서의 검색, 삭제/변경을 방지하기 위한 legal hold 적용, 그리고 외부 검토 도구 또는 법률 자문을 위한 결과 내보내기 등 eDiscovery의 핵심 기능과 직접적으로 일치합니다. 다른 선택지가 틀린 이유: - A. Customer Lockbox는 지원 요청 중 Microsoft 지원 인력이 데이터에 접근하는 것을 승인/거부하는 것에 관한 기능이며, 조사/홀드/내보내기 도구가 아닙니다. - B. Data loss prevention (DLP)은 민감한 데이터가 공유되거나 유출(exfiltration)되는 것을 방지(정책 적용)하는 데 초점을 두며, legal hold 및 증거 내보내기와는 관련이 없습니다. - D. A resource lock은 Azure 리소스(예: storage account)의 실수로 인한 삭제/수정을 방지하기 위한 Azure 거버넌스 기능이며, 조사 콘텐츠를 보존하고 내보내기 위한 기능이 아닙니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Azure에서 사용자가 관리 작업을 완료할 수 있도록 2시간의 시간 창을 제공하는 데 무엇을 사용할 수 있습니까?
Azure AD(Microsoft Entra ID) Privileged Identity Management (PIM)은 just-in-time 권한 있는 액세스를 가능하게 합니다. 사용자는 역할에 대해 “eligible”로 할당된 뒤 제한된 기간(예: 2시간) 동안 이를 활성화할 수 있습니다. 활성화 시간 창이 끝나면 역할은 자동으로 제거(비활성화)됩니다. 또한 PIM은 MFA, 정당화, 승인 요구 및 감사 기능을 제공하므로 임시 관리 작업에 이상적입니다.
Azure Multi-Factor Authentication (MFA)은 sign-in 또는 민감한 작업 중에 두 번째 검증 방법을 추가합니다. MFA는 자격 증명 탈취 위험을 줄이고 관리자 작업에 요구될 수 있지만, 사용자에게 오직 2시간 동안만 관리 권한을 부여하는 메커니즘을 제공하지는 않습니다. MFA는 인증을 강화하는 것이지, 시간 제한이 있는 권한 부여/역할 상승을 제공하는 것이 아닙니다.
Azure AD(Microsoft Entra ID) Identity Protection은 ID 관련 위험(예: 유출된 자격 증명, 비정상 이동, risky sign-ins)을 탐지하고 대응합니다. 위험에 따라 MFA 요구 또는 암호 재설정 같은 remediation을 강제할 수 있습니다. 그러나 2시간과 같은 고정된 시간 창 동안 임시로 관리 역할을 활성화하는 데 사용되지는 않습니다.
Conditional Access policies는 조건(사용자/그룹, 위치, 디바이스 준수, 앱, risk 등)에 따라 액세스를 제어하고 MFA 같은 제어를 요구할 수 있습니다. Conditional Access는 기본적으로 just-in-time 역할 상승이나 설정된 기간 이후 관리자 권한의 자동 비활성화를 제공하지 않습니다. 관리자가 언제/어디서 sign-in할 수 있는지는 제한할 수 있지만, 시간 제한이 있는 관리자 권한을 부여하지는 못합니다.
핵심 개념: 이 문제는 Microsoft Entra ID(이전 Azure AD)에서 시간 제한이 있는 권한 있는 액세스를 테스트합니다. 핵심 기능은 필요할 때만, 그리고 제한된 기간 동안만 사용자에게 상승된 권한을 부여하여 상시 관리 권한(주요 보안 위험)을 줄이는 것입니다. 정답이 맞는 이유: Microsoft Entra ID Privileged Identity Management (PIM)은 “just-in-time”(JIT) 권한 있는 액세스를 제공하도록 설계되었습니다. PIM을 사용하면 사용자를 관리 역할(예: Global Administrator, Privileged Role Administrator 또는 Azure 리소스의 Azure RBAC 역할)에 대해 eligible로 만들고, 필요할 때만 해당 역할을 활성화할 수 있습니다. 활성화 시 최대 활성화 기간(예: 2시간)을 강제할 수 있으며, 그 시간이 지나면 역할이 자동으로 비활성화됩니다. 이는 “사용자가 관리 작업을 완료할 수 있도록 2시간의 시간 창을 제공”한다는 요구 사항과 정확히 일치합니다. 주요 기능 및 모범 사례: PIM은 시간 제한 활성화, 승인 워크플로, 활성화 시 MFA, 정당화/티켓팅, 권한 있는 역할 사용에 대한 경고/감사 기능을 지원합니다. 이러한 제어는 Azure Well-Architected Framework 보안 원칙(최소 권한, blast radius 감소, 강력한 거버넌스)과 부합합니다. 실제 운영에서 PIM은 break-glass 감소, 온콜 엔지니어를 위한 통제된 관리자 권한 상승, 변경 창 동안의 액세스 제한에 흔히 사용됩니다. 흔한 오해: MFA와 Conditional Access는 인증을 강화하고 액세스 조건을 제어할 수 있지만, 시간 기반으로 관리자 역할 멤버십을 부여하거나 회수하지는 않습니다. Identity Protection은 위험 탐지 및 sign-in/user risk에 기반한 자동화된 대응에 초점을 두며, 예약된 권한 상승을 위한 기능이 아닙니다. 시험 팁: “temporary admin access”, “time-bound elevation”, “just-in-time”, “eligible vs active role”, “approval to activate a role” 같은 표현이 보이면 PIM을 떠올리세요. MFA 요구, 디바이스 준수, 위치, 앱 제한과 관련된 질문이면 Conditional Access를, risky sign-ins/users에 관한 내용이면 Identity Protection을 생각하세요.
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
Azure DDoS Protection Standard은(는) ______을(를) 보호하는 데 사용할 수 있습니다.
정답: D (virtual networks). Azure DDoS Protection Standard은 Virtual Network (VNet) 수준에서 활성화됩니다. VNet이 보호되면, DDoS Standard는 해당 VNet 내에서 public IP에 노출된(예: Azure Load Balancer, Application Gateway 또는 인터넷에 노출된 VM과 연결된 public IP) 적격 리소스에 대해 향상된 완화 기능을 제공합니다. 이것이 시험에서 기대하는 핵심 범위 개념입니다. DDoS Standard는 ID 객체나 관리 컨테이너가 아니라 VNet에 적용되는 네트워크 보호 서비스입니다. 다른 선택지가 틀린 이유: A (Azure AD applications)는 Azure AD 앱이 ID/애플리케이션 등록이기 때문에 틀립니다. DDoS Standard는 Azure AD 앱 객체에 연결되거나 이를 보호하지 않습니다. B (Azure AD users)는 DDoS가 ID 공격 유형이 아니므로 틀립니다. Azure AD 사용자 보호는 Microsoft Entra ID Protection 및 Conditional Access 같은 서비스로 처리됩니다. C (resource groups)는 resource group이 리소스를 위한 논리적 관리 컨테이너이기 때문에 틀립니다. DDoS Standard는 resource group 범위에서 활성화되지 않습니다. VNet에서 활성화하며, 그 VNet 내의 리소스가 보호의 혜택을 받습니다.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Control은 Microsoft의 핵심 개인정보 보호 원칙입니다.
예. “Control”은 Microsoft의 핵심 개인정보 보호 원칙입니다. Microsoft 개인정보 보호 지침에서 control은 고객과 개인에게 의미 있는 선택권과, 자신의 데이터가 어떻게 수집, 사용, 공유되는지를 관리할 수 있는 능력을 제공하는 것을 의미합니다. 클라우드 맥락에서는 개인정보 보호 설정 구성, 데이터 보존 관리, 데이터 저장 위치 선택(해당되는 경우), 데이터에 접근·내보내기·삭제할 수 있는 도구 사용과 같은 기능으로 나타납니다. 아니요가 아닌 이유: Microsoft는 고객 control을 개인정보 보호의 기반으로 명시적으로 제시합니다. 고객은 자신의 데이터가 어떻게 처리되는지 결정하고 그에 맞게 서비스를 구성할 수 있어야 합니다. 이는 MFA와 같은 보안 control과는 구별되는데, 여기서의 강조점은 위협으로부터의 보호만이 아니라 개인정보 보호 선택과 데이터 처리 방식에 있기 때문입니다.
투명성은 Microsoft의 핵심 개인정보 보호 원칙입니다.
예. “투명성(Transparency)”은 Microsoft의 핵심 개인정보 보호 원칙입니다. 투명성이란 Microsoft가 개인정보 보호 관행—어떤 데이터가 수집되는지, 왜 수집되는지, 어떻게 사용되는지, 얼마나 오래 보관되는지, 누구와 공유될 수 있는지—에 대해 명확하게 커뮤니케이션한다는 의미입니다. 이는 일반적으로 개인정보 처리방침, 제품 문서, 감사/규정 준수 문서, 서비스별 공개 사항을 통해 반영됩니다. 아니요가 아닌 이유: 투명성은 정보에 기반한 의사결정을 가능하게 하고 규정 준수 의무(예: GDPR의 고지 요구사항)를 지원하기 때문에 Microsoft의 개인정보 보호 체계에서 반복적으로 강조됩니다. 시험 관점에서 투명성은 개인정보 보호 원칙인 반면, 위협 보호나 ID 거버넌스 같은 항목은 개인정보 보호 원칙이 아니라 보안/ID 기능입니다.
공유 책임은 Microsoft의 핵심 개인정보 보호 원칙입니다.
아니요. “공유 책임(Shared responsibility)”은 Microsoft의 개인정보 보호 원칙이 아니라, 보안 및 규정 준수에 대한 책임이 Microsoft(클라우드 제공자)와 고객 간에 어떻게 분담되는지를 설명하는 클라우드 서비스 모델 개념(Shared responsibility model)입니다. 예를 들어, Microsoft는 클라우드의 보안(물리적 데이터센터, 핵심 인프라)에 대한 책임이 있는 반면, 고객은 IaaS/PaaS/SaaS에 따라 클라우드 내 보안(Identity 구성, 데이터 분류, 액세스 관리, Endpoint 보안 등)에 대한 책임이 있습니다. 왜 ‘예’가 아닌가: 공유 책임은 개인정보 보호 결과에 강하게 영향을 미치지만(고객이 개인정보 보호 의무를 충족하기 위해 서비스를 적절히 구성해야 함), Microsoft는 “공유 책임”을 개인정보 보호 원칙으로 나열하지 않습니다. 이는 개인정보 보호 약속(예: control 또는 transparency)이라기보다 클라우드 보안/규정 준수 기초에서 다루는 내용입니다.
Azure Active Directory (Azure AD) Password Protection의 목적은 무엇입니까?
오답입니다. 사용자가 비밀번호를 얼마나 자주 변경해야 하는지 제어하는 것은 비밀번호 만료/사용 기간 정책(예: 레거시 password policy settings 또는 AD DS의 domain password policies)과 관련이 있습니다. Entra ID Password Protection은 순환 빈도를 설정하지 않으며, 비밀번호가 생성되거나 변경될 때 금지 목록에 대해 비밀번호 강도를 평가합니다. 또한 현대 모범 사례는 잦은 강제 변경보다 강력한 비밀번호와 MFA를 강조합니다.
오답입니다. MFA 없이 로그인할 수 있는 디바이스를 식별하는 것은 Conditional Access policies, 디바이스 규정 준수(Intune), trusted locations 또는 authentication strengths 같은 개념을 통해 처리됩니다. Password Protection은 디바이스 신뢰 또는 MFA 요구 사항을 평가하지 않으며, 비밀번호 설정/변경 작업 중에 비밀번호 문자열만 검사하여 취약하거나 금지된 비밀번호를 차단합니다.
오답입니다. 비밀번호를 암호화하거나 해싱하는 것은 자격 증명 저장 및 인증 메커니즘(예: salted hashes, secure protocols)의 일부이지, Password Protection의 목표가 아닙니다. Entra ID Password Protection은 애초에 취약한 비밀번호가 선택되지 않도록 하는 데 초점을 둡니다. 전 세계적으로 인정되는 표준을 사용해 “비밀번호를 암호화”하는 사용자 대상 기능을 제공하지 않습니다.
정답입니다. Entra ID Password Protection은 Microsoft의 전역 목록과 조직의 사용자 지정 목록에 있는 금지 용어를 포함하는 비밀번호를 차단하여 사용자가 취약한 비밀번호를 사용하지 못하게 합니다. 여기에는 흔한 단어와 예측 가능한 패턴이 포함되며, 변형을 잡아내기 위해 정규화/fuzzy matching을 사용합니다. 목적은 쉽게 추측 가능한 비밀번호를 제거하여 password spray 및 brute-force 성공을 줄이는 것입니다.
핵심 개념: Azure Active Directory(현재 Microsoft Entra ID) Password Protection은 취약하고 흔히 사용되는 비밀번호를 차단하여 비밀번호 기반 공격을 줄이는 기능입니다. Microsoft가 유지 관리하는 전역 금지 비밀번호 목록과 (선택적으로) 조직이 정의한 사용자 지정 금지 비밀번호 목록에 대해 새로 설정되거나 변경되는 비밀번호를 검사하는 방식으로 동작합니다. 정답인 이유: 주된 목적은 사용자가 특정 금지 용어(예: “Password123”, “Contoso2026!”, 계절 관련 용어, 회사/제품 이름)를 포함하는 비밀번호를 선택하지 못하도록 하는 것입니다. 이는 선택지 D(사용자가 비밀번호에 특정 단어를 사용하는 것을 방지)에 직접적으로 해당합니다. 이 기능은 예측 가능한 비밀번호를 제거함으로써 password spray 및 credential stuffing의 성공률을 낮추도록 설계되었습니다. 주요 기능, 구성 및 모범 사례: - 전역 금지 비밀번호 목록: Microsoft가 선별한 알려진 취약 비밀번호 및 그 변형 목록. - 사용자 지정 금지 비밀번호 목록: 조직별 용어(회사명, 브랜드, 위치, 내부 프로젝트명)를 추가합니다. 또한 시스템은 fuzzy matching/정규화를 수행하여 흔한 치환(예: “P@ssw0rd”)도 탐지합니다. - Smart lockout 통합: 별도의 기능이지만, brute-force 시도를 늦춰 Password Protection을 보완합니다. - Hybrid 지원: Azure AD Password Protection proxy service와 DC agent를 배포하여 동일한 금지 비밀번호 정책을 on-premises Active Directory Domain Services로 확장할 수 있습니다. - Well-Architected 정렬: Security pillar 관점에서 이는 ID 공격 표면을 줄이는 예방적 제어입니다. defense-in-depth를 위해 MFA, Conditional Access, 사용자 교육과 함께 결합하세요. 흔한 오해: 많은 학습자가 Password Protection을 비밀번호 만료/순환 정책(사용자가 비밀번호를 얼마나 자주 변경해야 하는지) 또는 저장된 비밀번호의 암호화/해싱과 혼동합니다. Password Protection은 비밀번호가 생성/변경되는 시점의 비밀번호 품질에 관한 것이지, 비밀번호가 어떻게 저장되는지 또는 얼마나 자주 변경해야 하는지에 관한 것이 아닙니다. 또 다른 혼동은 MFA를 우회할 수 있는 “신뢰할 수 있는 디바이스”를 지정한다고 생각하는 것인데, 이는 Password Protection이 아니라 Conditional Access 및 디바이스 규정 준수에 해당합니다. 시험 팁: “banned passwords”, “weak passwords”, “custom banned list”, “prevent common passwords”가 보이면 Entra ID Password Protection을 떠올리세요. 질문에 MFA 프롬프트, 신뢰할 수 있는 위치/디바이스, sign-in risk가 언급되면 Conditional Access/Identity Protection을 떠올리세요. 비밀번호 만료가 언급되면 password policy settings를 떠올리되(그리고 현대 가이드는 침해 증거가 없는 한 강제적인 주기적 변경을 종종 권장하지 않는다는 점을 참고하세요).
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
______은(는) 온-프레미스 Active Directory 신호를 활용하여 고급 위협을 식별, 탐지 및 조사하는 클라우드 기반 솔루션입니다.
정답: C. Microsoft Defender for Identity. Microsoft Defender for Identity는 온-프레미스 Active Directory(AD)의 신호를 사용하여 고급 위협, 손상된 ID, 악의적인 내부자 행위를 식별하고 탐지하며 조사하는 데 도움을 주도록 특별히 설계된 클라우드 기반 보안 솔루션입니다. 일반적으로 도메인 컨트롤러(Defender for Identity sensors를 통해)에서 텔레메트리를 수집하고 AD 관련 활동을 분석하여 의심스러운 동작과 공격 패턴을 드러냅니다. 다른 선택지가 틀린 이유: - A. Microsoft Defender for Cloud Apps는 SaaS 애플리케이션 검색, shadow IT, 앱 거버넌스, 클라우드 앱 사용 제어/모니터링(CASB 기능)에 중점을 둡니다. 주로 온-프레미스 AD 신호를 다루는 솔루션이 아닙니다. - B. Microsoft Defender for Endpoint는 엔드포인트 디바이스(Windows, macOS, Linux, 모바일)에 대한 EDR, 취약점 관리, 공격 표면 감소에 중점을 두며, AD 도메인 컨트롤러 텔레메트리를 다루는 것이 아닙니다. - D. Microsoft Defender for Office 365는 이메일 및 협업(Exchange, SharePoint, OneDrive, Teams)을 피싱, 멀웨어, business email compromise로부터 보호하며, 온-프레미스 AD 신호 기반의 ID 위협 탐지와는 관련이 없습니다.
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
Microsoft Defender for Identity는 ______ 신호에서 고급 위협을 식별할 수 있습니다.
정답: C (on-premises Active Directory Domain Services (AD DS)). Microsoft Defender for Identity는 on-prem AD DS 환경에서 직접 신호를 수집하고 분석하여 고급 위협을 식별합니다. 이를 위해 domain controller(또는 standalone sensor)에 설치된 Defender for Identity sensor를 사용하여 인증 및 디렉터리 관련 활동을 모니터링합니다. 이러한 on-prem 신호를 통해 의심스러운 로그온, 비정상적인 Kerberos/NTLM 사용, 정찰(reconnaissance), lateral movement, 그리고 domain controller 수준에서 확인 가능한 기타 동작과 같은 ID 중심 공격을 탐지할 수 있습니다. 다른 선택지가 틀린 이유: A (Azure Active Directory/Azure AD, 현재 Microsoft Entra ID)는 주로 Entra ID Protection, Conditional Access, 그리고 sign-in risk/user risk 탐지와 같은 클라우드 ID 보호를 위한 신호 소스입니다. MDI가 클라우드 포털과 통합되기는 하지만, 핵심 텔레메트리는 on-prem AD DS에서 수집됩니다. B (Azure AD Connect)는 AD DS와 Entra ID 간에 ID를 동기화하는 데 사용되는 동기화 구성 요소입니다. 이는 MDI가 고급 위협 탐지에 사용하는 행동/보안 신호를 제공하도록 설계된 것이 아닙니다.
특정 조건에 따라 콘텐츠를 자동으로 암호화하는 데 사용할 수 있는 Microsoft 365 규정 준수 기능은 무엇입니까?
Content Search(Microsoft Purview)는 Microsoft 365 워크로드(Exchange, SharePoint, OneDrive, Teams) 전반에서 키워드, 조건 또는 sensitive info types와 일치하는 콘텐츠를 찾는 데 사용됩니다. 규정 준수 조사 및 데이터 발견을 지원하지만, encryption과 같은 보호 제어를 적용하지는 않습니다. 이는 “찾기 및 내보내기” 기능이지 “자동 보호” 기능이 아닙니다.
Sensitivity labels는 데이터를 분류하고 보호합니다. encryption, 액세스 제한, 시각적 표시를 적용할 수 있습니다. Auto-labeling policies와 함께 사용하면 sensitive information types, 키워드, trainable classifiers와 같은 조건에 따라 레이블을 자동으로 적용할 수 있습니다. Encryption은 레이블의 보호 설정이므로, sensitivity labels는 특정 조건에 따라 자동 암호화를 가능하게 하는 Microsoft 365 기능입니다.
Retention policies는 콘텐츠의 라이프사이클—얼마나 오래 보존되는지와 보존 기간 종료 시 어떤 일이 발생하는지(삭제, 보존, 또는 보존 후 삭제)—를 관리합니다. Retention은 records management 및 규제 요구사항에 관한 것이지, 기밀성 제어가 아닙니다. 일부 시나리오에서 조건 기반일 수는 있지만, 콘텐츠를 암호화하거나 누가 액세스할 수 있는지 제어하지는 않습니다.
eDiscovery(Standard/Premium)는 법적 및 조사 워크플로우를 지원합니다: hold 설정, 데이터 수집, 검토, 증거 내보내기. 콘텐츠를 보존하고 분석하는 데 도움이 되지만, 조건에 따라 콘텐츠를 자동으로 암호화하지는 않습니다. eDiscovery는 검토 중 민감한 콘텐츠를 식별할 수는 있으나, 보호/암호화 강제는 sensitivity labels와 같은 information protection 기능이 처리합니다.
핵심 개념: 이 문제는 Microsoft 365에서 Microsoft Purview Information Protection—특히 조직이 데이터를 분류하고 보호하는 방법—을 평가합니다. 키워드, sensitive info types, 위치와 같은 조건에 따라 자동으로 암호화를 적용할 수 있는 기능은 sensitivity labels입니다. 정답인 이유: Sensitivity labels는 encryption (Azure Rights Management), content marking(머리글/바닥글/워터마크), 액세스 제한과 같은 보호 설정으로 구성할 수 있습니다. Auto-labeling policies와 결합하면, Microsoft 365는 특정 조건이 충족될 때 레이블을 자동으로 적용할 수 있으며—따라서 콘텐츠를 자동으로 암호화할 수 있습니다(예: 신용카드 번호, 국가 ID, 또는 “Confidential” 프로젝트 용어를 감지). 이는 사용자가 파일이나 이메일을 수동으로 암호화하는 데 의존하지 않고도 일관된 보호를 강제하여 규정 준수 목표에 부합합니다. 주요 기능 및 구성 포인트: Sensitivity labels는 Microsoft Purview compliance portal에서 생성합니다. 레이블 범위(Files & emails, Groups & sites 등)와 보호 설정(encrypt, 권한 할당, 만료 설정, 오프라인 액세스 허용)을 정의합니다. Auto-labeling은 라이선스 및 워크로드 지원에 따라 Exchange, SharePoint, OneDrive, Microsoft 365 apps에 적용할 수 있습니다. 이는 사람의 실수를 줄이고 정책 기반 액세스 제어를 통해 least privilege를 적용함으로써 Azure Well-Architected Framework의 security pillar를 지원합니다. 흔한 오해: 사람들은 retention policies를 보호 기능과 혼동하는 경우가 많습니다. Retention은 콘텐츠를 얼마나 오래 보관하거나 삭제할지를 제어하는 것이지, 암호화가 아닙니다. eDiscovery와 Content Search는 조사 목적의 콘텐츠 검색 및 내보내기에 관한 것이며, 암호화를 적용하는 기능이 아닙니다. 민감한 데이터를 드러낼 수는 있지만, 보호를 자동으로 강제하지는 않습니다. 시험 팁: SC-900에서는 “encrypt/classify/protect”는 sensitivity labels(Microsoft Purview Information Protection)에 매핑된다는 점을 기억하세요. “Keep/delete content”는 retention에 매핑됩니다. “Find content”는 Content Search에 매핑됩니다. “Legal case workflow”는 eDiscovery에 매핑됩니다. 질문에 조건에 따른 자동 보호가 언급되면 “auto-labeling + sensitivity labels”를 떠올리세요.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure Policy는 자동 수정(remediation)을 지원합니다.
예. Azure Policy는 DeployIfNotExists 및 Modify와 같은 policy effect를 통해 자동(또는 반자동) 수정(remediation)을 지원합니다. 이러한 policy가 할당되면 managed identity를 사용하여 누락된 구성을 배포하거나 기존 리소스를 수정해 규정 준수 상태가 되도록 하는 remediation task를 생성할 수 있습니다(예: 필수 tag를 자동으로 추가, diagnostic settings 활성화, 또는 누락된 특정 구성을 배포). 중요한 뉘앙스가 있습니다. 모든 policy가 수정(remediate)할 수 있는 것은 아닙니다. Deny가 있는 policy는 비준수 변경을 방지하지만 기존 리소스를 “수정”하지는 않습니다. Audit가 있는 policy는 보고만 합니다. Remediation은 DeployIfNotExists/Modify와 구체적으로 연관되어 있으며 적절한 권한이 필요하고, 종종 managed identity가 필요합니다. 따라서 Azure Policy는 수정(remediation) 메커니즘을 제공하므로, 자동 수정(remediation)을 지원한다는 진술은 참입니다.
Azure Policy는 새 리소스가 기업 표준을 준수하도록 보장하는 데 사용할 수 있습니다.
예. Azure Policy의 주요 사용 사례 중 하나는 새 리소스가 기업 표준을 준수하도록 보장하는 것입니다. 배포 시점에 표준을 강제하는 정책을 할당할 수 있습니다(예: 승인된 지역 외부에서 리소스 생성 Deny, 특정 SKU 요구, 명명/태깅 규칙 강제, 또는 암호화 설정 요구). Deny 정책이 적용되어 있으면 규정을 준수하지 않는 리소스 생성 또는 업데이트가 차단되며, 이는 새 리소스가 조직 요구 사항을 충족하도록 보장하는 직접적인 방법입니다. 이는 Azure의 기본 거버넌스 패턴입니다. 표준을 policy definitions로 정의하고, 적절한 scope(대개 전사 표준의 경우 management group)에 할당하며, initiatives(policy sets)를 사용해 관련 요구 사항을 그룹화합니다. 따라서 Azure Policy는 새 리소스가 기업 표준을 준수하도록 보장하는 데 사용할 수 있습니다.
Azure Policy에서 규정 준수(compliance) 평가는 대상 리소스가 생성되거나 수정될 때에만 발생한다.
아니오. Azure Policy에서 규정 준수(compliance) 평가는 대상 리소스가 생성되거나 수정될 때에만 발생하지 않습니다. Azure Policy는 할당된 정책에 대해 기존 리소스를 평가하기 위해 주기적인 규정 준수 스캔을 수행하며, 이를 통해 리소스에 최근 변경이 없더라도 구성 드리프트(configuration drift) 및 새로 발견된 비규정 준수(non-compliance)를 감지할 수 있습니다. 또한 규정 준수 평가는 필요 시(예: Azure portal 또는 APIs를 통해) 온디맨드로 트리거할 수 있으며, 정책 할당 변경의 영향도 받습니다(새 정책을 할당하면 기존 리소스가 해당 정책에 대해 평가됩니다). 생성/수정 이벤트는 정책이 변경을 deny 또는 audit할 수 있는 중요한 시점이지만, 지속적인 평가(ongoing evaluation)는 연속적인 규정 준수 보고를 위한 핵심 기능입니다. 평가는 연속적/주기적으로 이루어지며 create/modify 이벤트로 엄격히 제한되지 않으므로, 해당 진술은 거짓입니다.
HOTSPOT - 다음 각 진술에 대해 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure subscription에 resource lock을 추가할 수 있습니다.
예. subscription scope에서 resource lock을 추가할 수 있습니다. Azure resource lock은 여러 scope를 지원합니다: management group, subscription, resource group, 그리고 개별 resource. subscription 수준에서 lock을 적용하면 해당 subscription 내의 모든 resource group과 resource에 상속되며, 이는 광범위한 보호(예: 프로덕션 subscription의 모든 resource 삭제 방지)에 유용합니다. 이는 특정 서비스에 종속되지 않는 Azure Resource Manager의 governance 기능입니다. lock은 CanNotDelete 또는 ReadOnly가 될 수 있습니다. 주요 주의사항은 subscription 수준 lock을 적용하면 운영에 광범위한 영향을 줄 수 있으므로, 신중하게 사용해야 하며 일반적으로 RBAC 및 policy와 함께 결합해 사용합니다. 따라서 이 문장은 참입니다.
Azure 리소스에는 리소스 잠금을 하나만 추가할 수 있습니다.
아니요. Azure 리소스에는 둘 이상의 리소스 잠금을 추가할 수 있습니다. Azure는 동일한 범위(예: CanNotDelete 잠금과 ReadOnly 잠금)에서 여러 잠금을 지원하며, 잠금은 상위 범위(리소스 그룹, 구독, 관리 그룹)로부터 상속될 수도 있습니다. 적용되는 모든 잠금의 조합 중 가장 제한적인 제한이 최종적으로 적용됩니다. 예를 들어, 리소스에 직접 잠금이 없더라도 리소스 그룹에 CanNotDelete 잠금이 있으면 해당 리소스는 삭제할 수 없습니다. 이후 리소스에 ReadOnly 잠금을 직접 추가하면 해당 리소스는 읽기 전용도 됩니다. 여러 잠금이 존재할 수 있고 누적/상속될 수 있으므로, “리소스 잠금을 하나만”이라는 진술은 올바르지 않습니다.
리소스 잠금이 있는 리소스를 포함하는 리소스 그룹을 삭제할 수 있습니다.
아니요. 삭제를 방지하는 리소스 잠금이 있는 리소스를 포함하고 있으면 리소스 그룹을 삭제할 수 없습니다. 리소스 그룹 삭제는 포함된 모든 리소스에 대한 일괄 삭제 작업과 사실상 동일합니다. 포함된 리소스 중 하나라도 CanNotDelete 잠금(또는 삭제도 차단하는 ReadOnly 잠금)이 있으면, 잠금을 제거할 때까지 삭제 작업이 실패합니다. 이는 시험에서 흔한 함정입니다. Owner 권한이 있더라도, 먼저 잠금을 제거하지 않으면 잠금이 삭제를 계속 차단합니다(그리고 잠금을 제거할 권한도 있어야 합니다). 실제로는 관리자가 리소스 그룹을 삭제하기 전에 통제된 변경 프로세스의 일부로 잠금을 제거하거나 조정합니다. 따라서 해당 진술은 거짓입니다.
