Microsoft SC-900

정답: C (The Microsoft Cloud Adoption Framework for Azure). Cloud Adoption Framework (CAF)는 Azure에서 워크로드를 채택하고 배포하기 위한 모범 사례, 지침, 도구를 제공하도록 명시적으로 설계되었습니다. 여기에는 구조화된 방법론(Strategy, Plan, Ready, Adopt, Govern, Manage)과 landing zone 지침, 거버넌스 및 관리 모범 사례, 조직 정렬 권장 사항과 같은 실용적인 리소스가 포함됩니다. “Microsoft 직원, 파트너, 고객의 모범 사례”라는 표현은 CAF의 목적과 포지셔닝에 매우 부합합니다. 다른 선택지가 틀린 이유: - A (Azure Blueprints)는 아티팩트(policies, role assignments, templates)를 번들링하여 규정을 준수하는 환경의 배포를 오케스트레이션하고 반복할 수 있도록 돕는 거버넌스/배포 메커니즘입니다. 주로 모범 사례 지침 라이브러리는 아닙니다. - B (Azure Policy)는 리소스에 규칙(audit/deny/modify)을 적용하여 준수 여부를 평가하고 강제하는 서비스입니다. 광범위한 채택 모범 사례를 제공하지는 않습니다. - D (A resource lock)은 리소스의 실수로 인한 삭제 또는 수정을 방지하기 위한 보호 제어이며, 배포 지침이나 모범 사례 프레임워크를 제공하지 않습니다.

Federation은 조직 간에 a trust relationship을(를) 설정하는 데 사용됩니다. federated 구성에서 한 조직(신뢰 당사자/relying party 또는 서비스 제공자/service provider)은 다른 조직의 identity provider가 사용자를 인증하고 security token(claims)을 발급하는 것을 신뢰합니다. 이러한 신뢰를 통해 사용자는 다른 조직의 리소스에 액세스하면서도 자신의 소속 조직 자격 증명을 사용해 로그인할 수 있어, 조직 간 SSO를 가능하게 합니다. 다른 선택지가 틀린 이유: A (MFA): Multi-factor authentication은 identity system 내에서 적용할 수 있는 제어이지만, Federation 자체가 “MFA를 설정”하는 것은 아닙니다. 어느 조직에서든 MFA를 요구할 수는 있으나, Federation의 핵심 목적은 아닙니다. C (user account synchronization): synchronization은 디렉터리 간에 identity object를 복사하거나 정렬합니다(예: Entra Connect가 AD DS에서 동기화). Federation은 token 기반 trust에 의존하므로 password를 동기화할 필요가 없습니다. D (VPN connection): VPN은 네트워크 수준의 연결을 제공합니다. Federation은 identity/authentication 메커니즘이며 VPN과는 독립적으로 동작합니다.

예. “Control”은 Microsoft의 핵심 개인정보 보호 원칙입니다. Microsoft 개인정보 보호 지침에서 control은 고객과 개인에게 의미 있는 선택권과, 자신의 데이터가 어떻게 수집, 사용, 공유되는지를 관리할 수 있는 능력을 제공하는 것을 의미합니다. 클라우드 맥락에서는 개인정보 보호 설정 구성, 데이터 보존 관리, 데이터 저장 위치 선택(해당되는 경우), 데이터에 접근·내보내기·삭제할 수 있는 도구 사용과 같은 기능으로 나타납니다. 아니요가 아닌 이유: Microsoft는 고객 control을 개인정보 보호의 기반으로 명시적으로 제시합니다. 고객은 자신의 데이터가 어떻게 처리되는지 결정하고 그에 맞게 서비스를 구성할 수 있어야 합니다. 이는 MFA와 같은 보안 control과는 구별되는데, 여기서의 강조점은 위협으로부터의 보호만이 아니라 개인정보 보호 선택과 데이터 처리 방식에 있기 때문입니다.

예. “투명성(Transparency)”은 Microsoft의 핵심 개인정보 보호 원칙입니다. 투명성이란 Microsoft가 개인정보 보호 관행—어떤 데이터가 수집되는지, 왜 수집되는지, 어떻게 사용되는지, 얼마나 오래 보관되는지, 누구와 공유될 수 있는지—에 대해 명확하게 커뮤니케이션한다는 의미입니다. 이는 일반적으로 개인정보 처리방침, 제품 문서, 감사/규정 준수 문서, 서비스별 공개 사항을 통해 반영됩니다. 아니요가 아닌 이유: 투명성은 정보에 기반한 의사결정을 가능하게 하고 규정 준수 의무(예: GDPR의 고지 요구사항)를 지원하기 때문에 Microsoft의 개인정보 보호 체계에서 반복적으로 강조됩니다. 시험 관점에서 투명성은 개인정보 보호 원칙인 반면, 위협 보호나 ID 거버넌스 같은 항목은 개인정보 보호 원칙이 아니라 보안/ID 기능입니다.

아니요. “공유 책임(Shared responsibility)”은 Microsoft의 개인정보 보호 원칙이 아니라, 보안 및 규정 준수에 대한 책임이 Microsoft(클라우드 제공자)와 고객 간에 어떻게 분담되는지를 설명하는 클라우드 서비스 모델 개념(Shared responsibility model)입니다. 예를 들어, Microsoft는 클라우드의 보안(물리적 데이터센터, 핵심 인프라)에 대한 책임이 있는 반면, 고객은 IaaS/PaaS/SaaS에 따라 클라우드 내 보안(Identity 구성, 데이터 분류, 액세스 관리, Endpoint 보안 등)에 대한 책임이 있습니다. 왜 ‘예’가 아닌가: 공유 책임은 개인정보 보호 결과에 강하게 영향을 미치지만(고객이 개인정보 보호 의무를 충족하기 위해 서비스를 적절히 구성해야 함), Microsoft는 “공유 책임”을 개인정보 보호 원칙으로 나열하지 않습니다. 이는 개인정보 보호 약속(예: control 또는 transparency)이라기보다 클라우드 보안/규정 준수 기초에서 다루는 내용입니다.

정답: 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을 가리키는 것입니다.

예. 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 (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 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 할당을 확실히 허용한다.

아니요. Azure Active Directory (Azure AD)(현재 Microsoft Entra ID)는 Microsoft가 호스팅하고 운영하는 클라우드 기반 디렉터리 및 ID 서비스입니다. Windows Server Active Directory Domain Services (AD DS)를 도메인 컨트롤러에 배포하는 방식처럼 Azure AD를 온프레미스 환경에 배포하지는 않습니다. 온프레미스에 배포할 수 있는 것은 Microsoft Entra Connect(이전 Azure AD Connect)처럼 온프레미스 AD DS의 ID를 Azure AD로 동기화하는 구성 요소, Pass-through Authentication 에이전트, 또는 페더레이션을 위한 Active Directory Federation Services (AD FS) 등 Azure AD와 통합되는 구성 요소입니다. 이러한 구성 요소는 하이브리드 ID 모델을 가능하게 하지만, Azure AD 자체는 클라우드 서비스로 남아 있습니다. “예”가 틀린 이유: Azure AD를 AD DS와 혼동했기 때문입니다. AD DS는 온프레미스에 설치하고 관리하지만, Azure AD는 Microsoft의 클라우드에서 서비스(SaaS)로 사용합니다.

예. Azure AD (Microsoft Entra ID)는 Microsoft 365 구독의 일부로 제공되는데, Microsoft 365가 테넌트 ID, 인증, 액세스 제어를 위해 Azure AD에 의존하기 때문입니다. 조직이 Microsoft 365에 가입하면 테넌트가 생성되며, 이는 Azure AD 디렉터리에 의해 지원됩니다. 시험에서 중요한 뉘앙스: Azure AD는 포함되지만, 포함되는 기능은 라이선스에 따라 달라집니다. Microsoft 365에는 기본 Azure AD 기능(종종 Entra ID Free로 지칭됨)이 포함됩니다. Conditional Access, Identity Protection, Privileged Identity Management와 같은 더 고급 ID 및 액세스 기능은 Microsoft Entra ID P1/P2 또는 이를 포함하는 제품군이 필요합니다(예: Microsoft 365 E3/E5에는 서로 다른 보안/ID 권한이 포함됨). “아니요”가 틀린 이유: 이는 Microsoft 365가 Azure AD 없이 동작한다는 의미가 되는데, 실제로는 그렇지 않습니다. Azure AD는 Microsoft 365 로그인 및 권한 부여의 기반입니다.

예. Azure Active Directory (Microsoft Entra ID)는 identity and access management (IAM) 서비스입니다. 주요 목적은 identity(사용자, 그룹, service principal)를 관리하고 authentication(사용자가 누구인지 확인) 및 authorization(무엇을 할 수 있는지)을 통해 리소스에 대한 액세스를 제어하는 것입니다. 실무에서 Azure AD는 Microsoft 365, Azure 및 타사 SaaS 앱에 대한 Single Sign-On (SSO), Multi-Factor Authentication (MFA), Conditional Access 정책, application registration 및 OAuth/OpenID Connect/SAML 기반 sign-in, 그리고 device identity 통합과 같은 기능을 제공합니다. 이는 IAM의 핵심 기능입니다. “아니요”가 틀린 이유: Azure AD를 네트워크 보안 도구나 순수한 on-prem directory 같은 것으로 잘못 분류하게 됩니다. on-prem AD DS와 통합할 수는 있지만, Azure AD의 핵심 역할은 cloud IAM이며 least privilege 및 strong authentication 같은 best practice와도 부합합니다.

정답: B. Windows Hello for Business에서는 사용자의 생체 인식 데이터(생체 인식 템플릿)가 로컬 장치에만 저장됩니다. 생체 인식은 암호화 키(일반적으로 TPM으로 보호됨)를 잠금 해제하기 위한 로컬 제스처로 사용됩니다. Azure AD/Entra ID는 생체 인식 템플릿을 수신하거나 저장하지 않으며, 인증을 검증하는 데 필요한 연관된 공개 키 정보만 보유합니다. 다른 선택지가 틀린 이유: A는 WHfB가 표준 모델에서 생체 인식 데이터를 외부 장치에 저장하지 않기 때문에 틀립니다. 템플릿은 등록이 이루어진 장치에 보관됩니다. C는 Azure AD가 생체 인식 템플릿을 저장하지 않기 때문에 틀립니다. 생체 정보를 중앙에 저장하면 프라이버시 및 침해 위험이 증가합니다. D는 생체 인식 템플릿이 사용자의 장치들 간에 복제되지 않기 때문에 틀립니다. 각 장치는 자체 로컬 생체 인식 등록과 자체 키 자료 등록을 가집니다.

정답: A. Multi-factor authentication (MFA). MFA는 사용자 이름과 비밀번호를 넘어서는 추가 검증을 요구합니다. 문제의 예시인 “휴대폰으로 전송되는 인증 코드”는 전형적인 두 번째 요소(소지 기반, something you have)입니다. Microsoft Entra ID에서 MFA는 구성에 따라 SMS 코드, 음성 통화, authenticator app 코드, 푸시 알림, 또는 FIDO2/security key 등으로 충족될 수 있습니다. 목표는 탈취된 비밀번호만으로는 인증이 불가능하도록 하여 password spray, phishing, credential stuffing과 같은 위험을 완화하는 것입니다. 다른 선택지가 틀린 이유: B. Pass-through authentication (PTA)은 agent를 통해 사용자의 비밀번호를 온프레미스 Active Directory에 대해 검증하는 하이브리드 인증 방식입니다. 본질적으로 두 번째 검증 단계를 추가하지는 않습니다. C. Password writeback은 Microsoft Entra ID 기능(일반적으로 SSPR과 함께 사용)으로, 클라우드에서의 비밀번호 변경을 온프레미스 AD로 다시 기록하는 기능이며 “추가 검증” 메커니즘이 아닙니다. D. Single sign-on (SSO)은 기존 세션/token을 재사용하여 로그인 프롬프트 수를 줄입니다. 추가 검증을 요구하는 것과는 반대입니다.

예. Conditional Access 정책은 디바이스 상태를 신호로 사용할 수 있습니다. Microsoft Entra에서 디바이스 관련 조건에는 디바이스 플랫폼(iOS, Android, Windows, macOS)과—“상태”와 더 관련이 큰 것으로—디바이스가 Microsoft Intune에 의해 준수(compliant)로 표시되었는지(디바이스 준수) 여부 및/또는 디바이스가 Hybrid Azure AD joined / Microsoft Entra joined인지 여부가 포함됩니다. Conditional Access는 또한 디바이스 필터(filter for devices)를 사용하여 디바이스 특성에 따라 디바이스를 포함/제외할 수 있습니다. 이러한 디바이스 신호를 통해 “준수 디바이스 필요(Require a compliant device)” 또는 “Hybrid Azure AD joined 디바이스에서만 액세스 허용(Allow access only from Hybrid Azure AD joined devices)”과 같은 정책을 적용할 수 있습니다. 이는 민감한 앱에 대한 액세스를 부여하기 전에 디바이스 상태/건강을 검증하는 일반적인 Zero Trust 패턴입니다. “아니요”는 디바이스 컨텍스트가 액세스 결정을 내리는 데 사용되는 핵심 Conditional Access 입력(신호) 중 하나이므로 틀립니다.

아니오. Conditional Access 정책은 1차 인증이 완료되기 전에 적용되지 않습니다. Conditional Access 평가는 Entra ID가 사용자를 식별하고 로그인 컨텍스트(누가 로그인하는지, 어떤 app/resource에 액세스하는지, 기타 조건)를 이해할 수 있어야 합니다. 이러한 식별은 사용자가 기본 자격 증명(첫 번째 factor)을 제출한 후에 이루어집니다. 첫 번째 factor 이후에 Conditional Access가 평가되며, 그 다음에 MFA 프롬프트, compliant device 요구, 또는 액세스 차단과 같은 추가 요구 사항(controls)을 적용할 수 있습니다. 즉, CA는 사용자가 알려지기 전에 실행되는 pre-authentication 게이트가 아니라, 초기 인증 이후 추가 단계를 요구할 수 있는 로그인 프로세스의 일부입니다. “예”라고 답하면 Conditional Access를 네트워크 계층의 pre-auth controls(일부 VPN/NAC 시나리오 등)와 혼동한 것입니다. Entra에서 CA는 로그인 중에 평가되는 identity 기반 정책이며, 1차 인증 완료 이전에는 적용되지 않습니다.

예. Conditional Access는 사용자가 특정 애플리케이션에 액세스하려고 시도할 때 MFA를 트리거할 수 있습니다. 가장 일반적인 Conditional Access 구성 중 하나는 다음과 같습니다. 정책을 특정 사용자/그룹에 할당하고, 하나 이상의 cloud app(예: Exchange Online, SharePoint Online, Azure Management 또는 특정 enterprise application)을 대상으로 지정한 다음, grant control을 “Require multi-factor authentication”으로 설정합니다. 이를 통해 애플리케이션별 step-up authentication이 가능해집니다. 사용자는 저위험 앱에는 비밀번호만으로 sign in할 수 있지만, 민감한 애플리케이션에 액세스할 때는 Conditional Access가 액세스를 허용(토큰 발급)하기 전에 MFA를 요구합니다. “아니요”라고 답하는 것은 부정확합니다. “Require MFA”는 Conditional Access에 기본 제공되는 grant control이며, 정책 범위를 특정 cloud app으로 지정하는 것은 고가치 리소스를 보호하는 데 사용되는 핵심 기능이기 때문입니다.

정답: 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 위협 탐지와는 관련이 없습니다.