50개 문제와 100분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
Storage Center Update Utility를 사용하여 Storage Center OS를 성공적으로 업데이트하려면 다음 작업 중 어떤 두 가지가 필요합니까? (두 개를 선택하세요.)
필수는 아닙니다. Storage Center Update Utility 사용은 일반적으로 Storage Center settings의 단순한 “enable utility” checkbox에 의해 제한되지 않습니다. 일부 제품에는 feature toggle이 있지만, SCOS 업데이트 workflow는 일반적으로 GUI checkbox보다 올바른 connectivity, credential, 검증된 upgrade path에 의존합니다. 이 옵션은 admin tool에서 “enable feature” 단계가 흔하기 때문에 그럴듯한 distractor입니다.
필수입니다. SCOS pre-upgrade check는 업데이트를 적용하기 전에 system health, compatibility, prerequisite를 검증합니다. SupportAssist(또는 이를 통해 가능한 support workflow)를 사용하는 것은 일반적으로 upgrade path가 지원되는지 확인하고 알려진 문제를 조기에 식별하는 과정의 일부입니다. 이는 업그레이드 실패를 줄이고 통제된 change management를 위한 모범 사례에 부합합니다.
필수입니다. Live Volume replication은 replication session이 끊기거나, resync되거나, failover behavior를 유발할 수 있기 때문에 controller/OS 업데이트 중 민감할 수 있습니다. 업데이트 전에 replication을 일시 중지하면 data consistency를 유지하고 업그레이드 후 replication 관련 conflict 또는 과도한 resynchronization을 방지하는 데 도움이 됩니다. 이는 storage upgrade runbook에서 일반적인 prerequisite입니다.
필수도 아니고 일반적으로도 틀렸습니다. SupportAssist를 비활성화하는 것은 일반적으로 update utility가 Storage Center와 통신하는 데 필요하지 않습니다. 오히려 SupportAssist는 supportability와 diagnostics를 향상시킵니다. 통신 문제는 일반적으로 support tooling을 비활성화하는 것이 아니라 network/proxy/firewall configuration, 올바른 port, credential로 해결합니다.
필수는 아닙니다. Storage Center Update Utility를 사용하기 위해 특별한 license를 적용하는 것은 일반적으로 SCOS 업데이트의 prerequisite가 아닙니다. licensing은 고급 기능(replication, Live Volume 등)에 적용될 수 있지만, system software를 업데이트하는 기능은 일반적으로 추가 license가 아니라 표준 플랫폼 유지 관리 및 support entitlement의 일부입니다.
핵심 개념: 이 문제는 vendor update utility(Storage Center Update Utility for Dell EMC SC Series/SCOS)를 사용하여 플랫폼 업데이트를 안전하게 수행하는 것에 관한 것입니다. SC-200으로 표시되어 있지만 Azure/Microsoft Sentinel 시나리오는 아니며, change management, pre-upgrade validation, replication/availability 고려 사항에 초점을 맞춘 인프라 운영 문제입니다. 정답인 이유: B가 필요한 이유는 SCOS pre-upgrade check가 OS 업데이트를 적용하기 전에 readiness(상태, firmware compatibility, configuration state, 알려진 blocker)를 검증하는 표준 prerequisite이기 때문입니다. 많은 환경에서 이는 SupportAssist(또는 이에 상응하는 support channel tooling)를 통해 시작되거나 검증되므로 Dell이 upgrade path를 확인하고 업데이트 실패나 data availability 위험을 초래할 수 있는 문제를 식별할 수 있습니다. C가 필요한 이유는 Live Volume replication이 시스템 전반에 걸쳐 추가적인 상태와 조정을 수반하기 때문입니다. SCOS 업데이트 중에는 replication link와 Live Volume 관계가 영향을 받을 수 있습니다(planned failover behavior, link interruption, 또는 resync requirement). replication을 일시 중지/중단하는 것은 replication conflict를 방지하고, split-brain condition의 위험을 줄이며, 업데이트 프로세스가 replication 관련 lock 또는 resynchronization storm 없이 진행될 수 있도록 하기 위한 일반적으로 필요한 단계입니다. 주요 기능 / 모범 사례: Pre-upgrade check는 운영 우수성과 reliability 원칙(Azure Well-Architected Framework와 유사함)에 부합합니다: prerequisite를 검증하고, blast radius를 줄이며, rollback planning을 보장합니다. replication pause는 reliability에 부합합니다: data consistency를 보호하고 의도하지 않은 failover/resync를 방지합니다. 일반적인 오해: 옵션 A, D, E는 “활성화” 단계처럼 들리지만, update utility는 일반적으로 OS 업데이트를 수행하기 위해 특별한 checkbox, SupportAssist 비활성화 또는 추가 license를 요구하지 않습니다. SupportAssist를 비활성화하면 일반적으로 도움이 되기보다 supportability가 저하됩니다. 시험 팁: 업데이트/업그레이드 문제에서는 반복적으로 나타나는 두 가지 요구 사항을 찾으세요: (1) pre-check/health validation 및 (2) consistency 유지를 위해 data movement/replication을 안정화하는 작업(pause/suspend). 옵션이 support tooling을 비활성화하라고 제안한다면, 문서화된 network/proxy 제약으로 인해 명시적으로 요구되지 않는 한 일반적으로 위험 신호입니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
기존에 Azure Active Directory (Azure AD) 사용자를 차단하는 데 사용되는 Azure logic app이 있습니다. 이 logic app은 수동으로 트리거됩니다. Azure Sentinel을 배포합니다. 기존 logic app을 Azure Sentinel에서 playbook으로 사용해야 합니다. 가장 먼저 무엇을 해야 합니까?
Scheduled query rule(analytics rule)은 log query에서 alert/incident를 생성합니다. Analytics rule을 automation rule과 함께 사용하여 playbook을 실행할 수는 있지만, 이것은 핵심 문제를 해결하지 못합니다. Logic App은 수동으로 트리거되며 아직 Sentinel playbook trigger와 호환되지 않습니다. 일반적으로 playbook을 사용할 수 있게 만든 후 detection을 생성/조정하며, 이를 변환의 첫 단계로 하지는 않습니다.
Data connector는 data source를 Microsoft Sentinel로 수집하는 데 사용됩니다(예: Entra ID, Microsoft 365 Defender 또는 Azure Activity). Data 수집은 detection 및 investigation에 중요하지만, Logic App이 트리거되는 방식을 변경하지는 않습니다. Connector를 추가해도 수동으로 트리거되는 Logic App을 Sentinel playbook으로 호출 가능하게 만들 수는 없습니다.
Threat Intelligence connector는 Sentinel에서 correlation 및 detection을 위해 TI indicator(STIX/TAXII, platforms 등)를 수집하는 데 사용됩니다. 이는 incident response automation과 관련이 없으며, 기존 Logic App을 playbook으로 사용할 수 있는지 여부에도 영향을 주지 않습니다. 이 선택지는 threat intel 수집과 SOAR 실행 요구 사항을 혼동한 것입니다.
Logic App을 Sentinel playbook으로 사용하려면, Sentinel이 이를 호출하고 incident context를 전달할 수 있도록 Sentinel이 지원하는 trigger(일반적으로 Microsoft Sentinel incident trigger)가 있어야 합니다. 기존 Logic App은 수동으로 트리거되므로, 가장 먼저 필요한 작업은 trigger를 그에 맞게 수정하는 것입니다. 그 후 automation rule을 통해 연결하거나 incident에서 실행할 수 있습니다.
핵심 개념: Microsoft Sentinel playbook은 Sentinel에 의해 호출되는 Azure Logic Apps입니다(일반적으로 automation rule, incident 또는 alert에서 호출됨). Sentinel이 Logic App을 playbook으로 호출하려면, Logic App은 순수한 수동 trigger가 아니라 Sentinel이 지원하는 trigger(예: Microsoft Sentinel incident trigger)를 사용해야 합니다. 정답이 맞는 이유: 기존 Logic App은 수동으로 트리거됩니다. 수동으로 트리거되는 Logic App은 Sentinel이 playbook으로 자동 실행할 수 없습니다. Sentinel은 예상되는 방식으로 호출할 수 있는 trigger endpoint(incident/alert entity context 또는 지원되는 request trigger pattern)가 필요하기 때문입니다. 따라서 첫 번째 단계는 Logic App trigger를 Sentinel playbook trigger(일반적으로 “When a response to a Microsoft Sentinel incident is triggered” / incident trigger)로 수정하는 것입니다. 그 후 automation rule을 통해 incident에 연결하거나 incident에서 수동으로 실행할 수 있습니다. 주요 기능 및 모범 사례: - Playbook은 Sentinel에서 incident response automation (SOAR)에 사용되며 일반적으로 Automation rules에서 실행됩니다. - Logic App은 동일한 tenant에 있어야 하며 Entra ID (Azure AD) 사용자를 차단하는 작업을 수행하기 위한 적절한 권한(managed identity 또는 connections)을 가져야 합니다. - Azure Well-Architected Framework (Security 및 Reliability)를 따르세요: Graph/Entra 작업에는 least privilege를 적용하고, audit logging을 활성화하며, idempotent design을 사용하세요(확인 없이 동일한 사용자를 반복적으로 차단하지 않도록 방지). 일반적인 오해: - Analytics rule(scheduled query rule) 생성은 detection을 위한 것이며, 기존 Logic App을 playbook으로 사용할 수 있게 만드는 작업이 아닙니다. - Data connector는 데이터를 수집하는 역할을 하며, 수동 Logic App을 Sentinel playbook으로 변환하지 않습니다. - Threat Intelligence connector는 response automation 실행과 관련이 없습니다. 시험 팁: 질문이 “기존 Logic App을 Sentinel playbook으로 사용하는 방법”을 묻는다면, 먼저 trigger 유형을 확인하세요. Sentinel playbook은 Sentinel이 incident/alert context를 전달하고 workflow를 호출할 수 있도록 Sentinel 호환 trigger가 필요합니다. Detection 구성(analytics rules)과 수집(data connectors)은 SOAR 활성화와는 별개의 단계입니다.
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 사용자는 Azure Security Center를 사용합니다. Security Center에서 보안 경고를 받습니다. Security Center에서 경고를 해결하기 위한 권장 사항을 확인해야 합니다. 솔루션: Security alerts에서 경고를 선택하고, Take Action을 선택한 다음, Mitigate the threat 섹션을 확장합니다. 이것이 목표를 충족합니까?
이 옵션이 정답인 이유는 Azure Security Center에서 보안 경고를 열고 Take Action 영역을 사용하여 권장 수정 단계를 검토할 수 있기 때문입니다. Mitigate the threat 섹션은 감지된 위협에 대응하고 그 영향을 줄이는 방법에 대한 지침을 제공하도록 특별히 설계되었습니다. 목표가 경고를 해결하기 위한 권장 사항을 확인하는 것이므로, 이 탐색 경로는 요구 사항을 직접 충족합니다. 이는 일반적인 보안 상태 보기가 아니라 경고 중심 워크플로이므로 올바른 선택입니다.
이 옵션은 설명된 솔루션이 실제로 목표를 충족하므로 오답입니다. Azure Security Center에서 보안 경고를 선택한 다음 Take Action 및 Mitigate the threat 섹션을 검토하는 것은 수정 지침을 확인하는 유효한 방법입니다. "아니요"라고 답하는 것은 이 경로가 권장 사항을 제공하지 않는다는 의미가 되지만, 이는 사실이 아닙니다. 이 플랫폼은 정확히 이 위치에서 경고별 완화 단계를 표시하도록 설계되어 있습니다.
핵심 개념: 이 문제는 Azure Security Center(현재는 Microsoft Defender for Cloud의 일부)가 보안 경고에 대한 수정 지침을 어떻게 제공하는지에 대한 지식을 평가합니다. 구체적으로, 감지된 위협을 조사하고 완화할 수 있도록 경고와 관련된 권장 작업을 어디에서 찾는지 알고 있는지를 확인합니다. 정답인 이유: Azure Security Center에서 보안 경고를 열면 Take Action 영역에서 해당 경고에 대한 대응 지침을 제공합니다. Mitigate the threat 섹션을 확장하면 Security Center가 식별한 문제를 해결하는 데 도움이 되는 권장 사항과 수정 단계가 표시됩니다. 이는 경고별 권장 사항을 확인하는 올바른 워크플로이므로, 제안된 솔루션은 제시된 목표를 충족합니다. 주요 기능 / 구성: - Security alerts는 인시던트 세부 정보, 영향을 받는 리소스, 심각도 및 탐지 컨텍스트를 제공합니다. - Take Action 창은 대응자가 조사 및 수정 과정을 진행할 수 있도록 안내하도록 설계되었습니다. - Mitigate the threat 섹션에는 위험을 줄이고 감지된 문제를 수정하기 위한 권장 단계가 포함되어 있습니다. - Azure Security Center / Microsoft Defender for Cloud는 보안 상태 권장 사항과 경고별 대응 지침을 모두 제공합니다. 일반적인 오해: - 응시자는 일반적인 Secure Score 또는 보안 권장 사항과 경고별 완화 지침을 자주 혼동합니다. - 일부는 권장 사항이 Recommendations 블레이드에서만 제공된다고 생각하지만, 경고 수정 지침은 경고에서 직접 액세스할 수도 있습니다. - 또 다른 일부는 Security Center가 경고만 보고하고 대응 작업은 제공하지 않는다고 생각하지만, 이는 사실이 아닙니다. 시험 팁: - 경고 수정 단계를 찾을 때는 일반 권장 사항 페이지가 아니라 특정 보안 경고에서 시작하세요. - Take Action 또는 Mitigate the threat와 같은 작업 중심 섹션을 찾으세요. - 보안 상태 개선 권장 사항과 인시던트/경고 대응 지침을 구분하세요. - Azure 시험 문제에서 "경고를 해결"과 같은 표현은 일반적으로 경고별 완화 지침을 의미합니다.
Microsoft 365 Defender에 다음 advanced hunting query가 있습니다.
DeviceProcessEvents
| where Timestamp > ago (24h)
and InitiatingProcessFileName =~ 'runsll32.exe'
and InitiatingProcessCommandLine !contains " " and InitiatingProcessCommandLine != ""
and FileName in~ ('schtasks.exe')
and ProcessCommandLine has 'Change' and ProcessCommandLine has 'SystemRestore'
and ProcessCommandLine has 'disable'
| project Timestamp, AccountName, ProcessCommandLine
지난 24시간 동안 Microsoft Defender에서 관리되는 디바이스에서 어떤 프로세스든 System Restore를 비활성화하면 alert를 받아야 합니다. 어떤 두 가지 작업을 수행해야 합니까? 각 정답은 솔루션의 일부를 나타냅니다. 참고: 각 정답 선택은 1점의 가치가 있습니다.
정답입니다. Advanced Hunting query에서 alert를 생성하려면 Microsoft 365 Defender에서 Custom detection rule을 만들어야 합니다. 이 rule은 query가 실행되도록 예약하고(24시간과 같은 lookback window 사용), 결과가 반환되면 alert(및 선택적으로 incident)를 생성합니다. Hunting 자체는 alerting이 아니며, detections가 query를 운영화합니다.
오답입니다. suppression rules는 이미 생성되고 있는 alerts(예: 알려진 정상 활동)를 음소거하거나 억제하여 noise를 줄이는 데 사용됩니다. hunting query를 alerting 메커니즘으로 변환하지 않으며, 이 동작에 대한 alerts를 받기 시작하는 데 도움이 되지 않습니다.
오답입니다. order by 절을 추가하는 것은 hunting results grid에서 결과가 표시되는 방식에만 영향을 줍니다. alert 생성 여부는 바뀌지 않습니다. alerting은 detection rule 생성과 entity mapping에 대한 플랫폼 요구 사항 충족에 달려 있으며, 결과 정렬과는 관련이 없습니다.
오답입니다. DeviceNetworkEvents는 network connections 및 관련 telemetry를 캡처합니다. 이 시나리오는 schtasks/rundll32 동작을 통해 프로세스가 System Restore를 비활성화하는 것에 관한 것이며, 이는 DeviceProcessEvents에 캡처됩니다. table을 바꾸면 해당 활동을 놓치고 detection logic이 깨질 가능성이 높습니다.
정답입니다. Custom detections는 실행 가능한 alerts를 생성하고 정확한 event와 device로 다시 연결하기 위해 안정적인 식별자가 필요합니다. projected output에 DeviceId와 ReportId를 포함하면 Microsoft 365 Defender가 detection hit를 올바른 endpoint 및 event record와 연결할 수 있어 alert fidelity와 investigation pivots가 향상됩니다.
핵심 개념: 이 문제는 Microsoft 365 Defender Advanced Hunting (KQL)과 hunting query를 alert로 운영화하는 방법인 Custom detection rules를 테스트합니다. Hunting query는 회고적(retrospective)이며, alert를 생성하려면 해당 로직을 지속적으로 실행되고 alerts/incidents를 생성하는 예약된 detection rule로 변환해야 합니다. 정답인 이유: query가 일치할 때(즉, 프로세스가 System Restore를 비활성화할 때) alert를 받으려면 query를 기반으로 custom detection rule을 생성해야 합니다 (A). 또한 Microsoft 365 Defender custom detections는 플랫폼이 결과를 올바른 device/event에 매핑하고 적절한 entity context로 alert를 생성할 수 있도록 query output에 특정 식별자가 필요합니다. DeviceProcessEvents 기반 detections의 경우 projected output에 DeviceId와 ReportId를 포함해야 합니다 (E). DeviceId는 hit를 특정 endpoint에 연결하고, ReportId는 기본 event record를 고유하게 식별하여 alert enrichment, investigation pivoting, deduplication을 가능하게 합니다. 주요 기능 및 모범 사례: Custom detection rules를 사용하면 schedule (frequency/lookback), severity, category (예: Persistence/Defense evasion), automated actions (예: incident 생성)을 정의할 수 있습니다. Azure Well-Architected Framework의 “Security” pillar에 맞추어 detections가 실행 가능하도록(entity identifiers 포함) 하고, false positives를 최소화하며(조건 강화), investigation을 지원하도록(DeviceName, InitiatingProcess*, FolderPath, SHA1/SHA256 등 관련 필드 project) 해야 합니다. 일반적인 오해: 정렬 추가(C)는 alert를 생성하지 않으며 단지 표시 순서만 변경합니다. suppression rule(B)은 alerts가 이미 존재한 후 alert noise를 줄이는 용도이며, hunting에서 alerts를 생성하지는 않습니다. DeviceNetworkEvents(D)로 전환하는 것은 잘못되었습니다. 이 동작은 network telemetry가 아니라 process execution(schtasks/rundll32)이기 때문입니다. 시험 팁: SC-200에서는 다음을 기억하세요: Advanced Hunting은 query용이고, alerting에는 Custom detection rules가 필요합니다. detections를 만들 때는 필요한 식별자(일반적으로 device tables의 경우 DeviceId와 ReportId)를 포함하고, alert에 표시하려는 entities를 project하세요. 또한 query 시간 필터가 rule의 lookback window와 일치하는지 확인하여 gaps 또는 duplicates를 방지하세요.
HOTSPOT - 임원진 팀 이슈를 조사하기 위해 advanced hunting query를 생성해야 합니다. 쿼리를 어떻게 완성해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:
DeviceFileEvents가 올바른 테이블인 이유는 이 쿼리가 FolderPath, FileName, ActionType으로 그룹화하기 때문이며, 이러한 필드는 Microsoft Defender for Endpoint Advanced Hunting의 file system telemetry를 나타내는 특징적인 필드입니다. DeviceFileEvents는 file created, modified, deleted, renamed 및 기타 file operation과 같은 이벤트를 캡처하며, 관련된 user/account context도 포함할 수 있습니다(예: schema/version에 따라 AccountDisplayName 또는 initiating account field). 다른 선택지가 틀린 이유: - CloudAppEvents는 cloud application activity(예: Microsoft 365, OAuth apps, cloud storage actions)에 초점을 맞추며, 일반적으로 endpoint file-system과 같은 의미에서 FolderPath/FileName을 사용하지 않습니다. - DeviceProcessEvents는 process execution telemetry(process creation, command line, parent/child relationships)를 위한 것입니다. file을 생성한 process를 찾기 위해 table join으로 사용할 수는 있지만, 쿼리가 직접 file path와 file name을 요약하는 경우에는 기본 테이블이 아닙니다.
| summarize activityCount = ______ by FolderPath, FileName, ActionType, AccountDisplayName
count()는 올바른 aggregation function입니다. 이 query는 FolderPath, FileName, ActionType, AccountDisplayName의 각 grouping에 대해 activityCount를 일치하는 event(행)의 수로 계산하기 때문입니다. KQL에서 summarize count()는 어떤 일이 얼마나 자주 발생했는지 정량화하는 표준 방법이며, 이는 hunting에 필수적입니다(예: executive account 또는 특정 sensitive folder에서 비정상적으로 높은 file deletion count를 탐지). 다른 선택지가 틀린 이유: - avg()는 numeric expression/column의 평균을 계산합니다. 이는 “event 수”를 나타내지 않으며, 평균을 낼 numeric metric이 없는 한 의미가 없습니다. - sum()은 지정된 column/expression의 numeric value를 더합니다. event별 수량을 나타내는 numeric field가 없다면, sum()은 occurrence를 세는 데 적절하지 않습니다. 상수 1 column을 만들었다고 해도, event frequency에 대한 더 명확하고 예상되는 시험 답은 여전히 count()입니다.
Azure Security Center에서 생성된 security alerts의 시각적 표현을 제공하는 사용자 지정 Azure Sentinel query를 만들 계획입니다. bar graph를 표시하는 데 사용할 query를 만들어야 합니다. query에 무엇을 포함해야 합니까?
KQL의 extend는 새 columns를 추가하거나 계산하는 데 사용됩니다(예: extend SeverityRank = case(Severity == "High", 3, ...)). 집계 전에 데이터를 보강하는 데는 유용하지만, extend만으로는 rows를 group화하거나 totals를 생성하지 않습니다. bar chart에는 category별 집계된 numeric 값이 필요하므로, extend는 bar graph 출력을 만드는 핵심 요구 사항이 아닙니다.
bin은 연속 값을 buckets로 group화하며, 가장 일반적으로 TimeGenerated를 interval로 나눕니다(예: bin(TimeGenerated, 1h)). 이는 time series charts에 자주 사용되지만, bin 자체만으로는 records 수를 생성하지 않습니다. bar chart가 표시할 수 있는 numeric 값을 생성하려면 여전히 summarize count() by bin(...)이 필요합니다.
count는 일반적으로 summarize와 함께 사용되어 group별 records 수를 반환하는 집계 함수입니다(예: summarize count() by AlertName 또는 by Severity). 이는 bar graph에 필요한 measure(bar 높이)를 생성합니다. Sentinel Workbooks 및 query visualizations에서 count()와 같은 집계 결과는 alert volume을 시각화하는 표준 방법입니다.
workspace는 다른 Log Analytics workspace의 tables를 참조하기 위한 cross-workspace queries에 사용됩니다(예: workspace("<workspace-id>").SecurityAlert). 이는 data scope를 돕는 것이지 visualization을 위한 것이 아닙니다. 여러 workspaces를 query하더라도 chart로 표시 가능한 결과를 생성하려면 여전히 summarize count()(또는 다른 집계)가 필요합니다.
핵심 개념: 이 문제는 Workbooks 또는 Analytics query 결과에서 시각화를 구축하기 위한 Microsoft Sentinel (Azure Sentinel) Kusto Query Language (KQL) 기본 사항을 테스트합니다. security alerts의 bar chart를 렌더링하려면(예: Microsoft Defender for Cloud/Azure Security Center에서 SecurityAlert table로 수집된 alerts), query는 category별 집계된 numeric 값을 반환해야 합니다(예: alert name, severity 또는 time bucket). 정답인 이유: bar graph에는 measure(numeric 값)와 dimension(grouping field)이 필요합니다. KQL에서 measure인 “alerts 수”를 생성하는 가장 일반적인 방법은 summarize와 count()를 사용하는 것입니다. 예시 패턴: SecurityAlert | where ProductName == "Azure Security Center" | summarize AlertCount = count() by AlertName. count() 집계는 visualization engine이 bar 높이로 표시할 수 있는 numeric series를 생성합니다. count()와 같은 집계가 없으면 query는 raw rows를 반환하며, 이는 totals의 bar chart로 직접 표현할 수 없습니다. 주요 기능 및 모범 사례: - chart에 적합한 출력을 만들기 위해 summarize count() by <dimension>을 사용합니다. - x-axis가 time인 경우 bin(TimeGenerated, 1h/1d)와 선택적으로 결합할 수 있습니다. - 스캔되는 데이터를 줄이고 성능/비용을 개선하기 위해 초기에 필터링(where)합니다(Log Analytics 요금은 ingestion 및 query execution patterns와 관련이 있습니다). - Workbooks/dashboards를 위해 query가 작고 집계된 dataset을 반환하도록 합니다(Azure Well-Architected Framework: Performance Efficiency 및 Cost Optimization). 일반적인 오해: - bin은 chart와 자주 연관되지만, 값(일반적으로 time)만 bucket으로 나눌 뿐이며 bucket당 numeric 값을 생성하려면 여전히 count()와 같은 집계가 필요합니다. - extend는 계산된 columns를 추가하지만 집계하지는 않으므로 bars에 필요한 totals를 만들지 못합니다. - workspace는 cross-workspace queries(workspace("id").Table)에 사용되며 chart에 적합한 집계를 생성하는 것과는 관련이 없습니다. 시험 팁: Sentinel 시각화에서는 charts에 summarize가 필요하다는 점을 기억하세요. 문제에서 “bar graph”, “pie chart” 또는 “timechart”를 언급하면 summarize와 집계(count(), dcount(), sum(), avg())를 찾고, time 기반 grouping에는 선택적으로 bin()을 찾으세요. SC-200에서는 SecurityAlert 및 SecurityIncident가 일반적인 tables이며, Defender for Cloud alerts는 일반적으로 관련 product/provider fields와 함께 SecurityAlert에 나타납니다.
Azure Sentinel 데이터를 시각화하고, 침해 지표(IoC)를 식별하기 위해 third-party 데이터 소스를 사용하여 데이터를 보강해야 합니다. 무엇을 사용해야 합니까?
Sentinel notebooks(Jupyter 기반)는 interactive threat hunting 및 조사를 위해 특별히 설계되었습니다. KQL queries와 Python을 결합하여 결과를 시각화하고 third-party 소스(threat intel feeds, REST APIs, WHOIS/GeoIP 등)를 사용해 데이터를 보강합니다. 따라서 보강과 고급 시각적 분석을 통해 IoC를 식별하고 검증하는 데 이상적입니다.
Microsoft Cloud App Security(현재 Microsoft Defender for Cloud Apps)는 SaaS application 검색, 거버넌스, 그리고 session/app controls에 중점을 둡니다. 경고를 생성하고 Sentinel과 통합할 수는 있지만, Sentinel log 데이터를 시각화하고 임의의 third-party 데이터 소스로 보강하여 IoC를 조사하는 기본 도구는 아닙니다.
Azure Monitor는 Sentinel이 사용하는 기본 logging, metrics, 그리고 Log Analytics workspace를 제공합니다. 그러나 Azure Monitor만으로는 보안 특화 시각화 및 보강 워크플로를 위한 Sentinel 조사 경험이 아닙니다. 이 문제는 specifically Sentinel 중심의 시각화와 third-party 보강을 묻고 있으며, 이는 notebooks와 더 잘 부합합니다.
Sentinel의 hunting queries는 KQL을 사용하여 Sentinel 테이블의 데이터를 사전에 검색하고 상관 분석합니다. 탐지 로직과 가설 기반 검색에는 매우 뛰어나지만, 풍부한 시각화와 external enrichment 워크플로를 본질적으로 제공하지는 않습니다. third-party 보강과 고급 시각적 분석에는 notebooks가 더 적합합니다.
핵심 개념: 이 문제는 침해 지표(IoC)를 식별하기 위해 Microsoft Sentinel 데이터를 시각화하고 third-party 데이터 소스로 보강하는 방법을 묻습니다. Sentinel에서는 일반적으로 Notebooks(Azure Monitor Logs/Log Analytics 및 Jupyter 기반)를 사용하여 이를 수행하며, interactive 조사, 시각화, 그리고 external APIs 및 threat intel 소스를 통한 보강을 지원합니다. 정답인 이유: Microsoft Sentinel의 Notebooks는 정적인 KQL 결과를 넘어서는 고급 hunting 및 조사 워크플로를 위해 설계되었습니다. 이를 통해 분석가는 Sentinel 테이블(KQL 사용)을 가져온 다음, third-party intelligence(예: VirusTotal, AbuseIPDB, WHOIS, GeoIP, MISP 또는 custom REST APIs)로 결과를 보강하고, 마지막으로 Python libraries(pandas, matplotlib, plotly) 또는 기본 제공 notebook 시각화를 사용하여 관계와 타임라인을 시각화할 수 있습니다. 이는 “Sentinel 데이터를 시각화”하고 “침해 지표(IoC)를 식별하기 위해 third-party 데이터 소스를 사용하여 데이터를 보강”해야 한다는 요구 사항과 정확히 일치합니다. 주요 기능 / 모범 사례: - Interactive 조사: 반복적인 분석을 위해 KQL queries와 Python을 결합합니다. - 데이터 보강: external services를 안전하게 호출합니다(이상적으로는 Azure Key Vault 기반 secrets, 지원되는 경우 managed identity, 그리고 network controls 사용). - 시각화: 차트, 지도, entity relationship views를 생성하여 패턴을 발견하고 IoC를 검증합니다. - 재사용성: 반복 가능한 조사와 팀 표준화를 위해 notebooks를 playbooks/runbooks로 저장합니다. Azure Well-Architected 관점에서 notebooks는 Operational Excellence(반복 가능한 조사), Security(secrets/APIs에 대한 제어된 액세스), 그리고 Performance Efficiency(수집 시 모든 데이터를 보강하는 대신 대상 데이터를 보강)를 지원합니다. 일반적인 오해: Hunting queries(KQL)는 데이터를 검색하고 상관 분석할 수 있지만, 풍부한 시각화와 external enrichment 워크플로를 본질적으로 제공하지는 않습니다. Azure Monitor는 logs/queries를 위한 기본 플랫폼이지만, threat hunting 및 IoC 보강을 위한 Sentinel 고유의 조사 경험은 아닙니다. Microsoft Cloud App Security(Defender for Cloud Apps)는 SaaS app 가시성과 제어에 중점을 둔 CASB이며, Sentinel 데이터 시각화/보강 도구가 아닙니다. 시험 팁: “visualize”, “enrich”, “Jupyter”, “Python” 또는 “third-party threat intel/API”가 보이면 Sentinel Notebooks를 떠올리십시오. “KQL로 logs 전반을 검색”이 보이면 Hunting queries를 떠올리십시오. “response 자동화”가 보이면 여기에는 없지만 Playbooks(Logic Apps)를 떠올리십시오.
DRAG DROP - 귀하는 귀하의 환경에 영향을 미치는 새로운 common vulnerabilities and exposures (CVE) 취약점에 대한 통지를 받았습니다. 문서화된 활성 exploit가 사용 가능한 경우, 영향을 받는 시스템을 담당하는 팀에 remediation을 요청하기 위해 Microsoft Defender Security Center를 사용해야 합니다. 어떤 세 가지 작업을 순서대로 수행해야 합니까? 답하려면 작업 목록에서 적절한 작업을 답안 영역으로 이동하고 올바른 순서로 배열하십시오. 선택하여 배치:
아래 이미지에서 올바른 답을 선택하세요.
Defender for Endpoint TVM 워크플로에서 올바른 순서의 작업을 식별할 수 있으므로 정답은 Pass입니다. 올바른 순서(3개 작업): 1) Threat & Vulnerability Management에서 Weaknesses를 선택하고 CVE를 검색합니다. 2) Security recommendations를 선택합니다. (CVE/weakness 컨텍스트에서 권장 remediation 가이드와 영향 범위로 이동합니다.) 3) remediation request를 생성합니다. 이것이 올바른 이유: Weaknesses는 특정 CVE를 찾고 평가하며 exploit availability/intelligence를 확인하는 데 사용되는 CVE 중심 보기입니다. Security recommendations는 Defender가 실행 가능한 remediation 가이드를 제공하고 remediation 흐름이 시작되는 위치입니다. remediation request 생성은 해당 remediation을 담당 팀에 전송/할당하는 명시적인 단계입니다. 다른 선택지가 틀린 이유: Device inventory는 주로 device 중심 보기용이며, 표준 CVE triage 시작 지점이 아닙니다. Threat Protection report는 TVM remediation 워크플로가 아닙니다. Advanced hunting은 KQL을 통해 영향을 받는 asset을 찾을 수 있지만, 이 시나리오에서 remediation을 요청하기 위한 의도된 UI 기반 프로세스는 아닙니다.
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. Microsoft Defender for Identity와 Active Directory의 통합을 구성하고 있습니다. Microsoft Defender for Identity portal에서 공격자가 악용할 수 있도록 여러 계정을 구성해야 합니다. 솔루션: Azure AD Identity Protection에서 sign-in risk policy를 구성합니다. 이것이 목표를 충족합니까?
예는 오답입니다. Azure AD Identity Protection과 Microsoft Defender for Identity는 서로 다른 목적을 제공합니다. Identity Protection은 Microsoft Entra ID sign-in에 위험 기반 제어를 적용하지만, honeytoken 스타일 또는 기만용 Active Directory 계정을 구성하지는 않습니다. 목표는 Defender for Identity portal에서 공격자가 악용할 계정을 구체적으로 구성하는 것이므로, 이 솔루션은 목표를 충족하지 않습니다.
아니요가 정답인 이유는 Azure AD Identity Protection에서 sign-in risk policy를 구성하는 것은 Active Directory에서 공격자가 악용하도록 의도된 계정을 생성하거나 관리하지 않기 때문입니다. sign-in risk policy는 위험한 클라우드 인증 시도를 평가하고 MFA 또는 password change와 같은 작업을 적용하도록 설계되었습니다. Microsoft Defender for Identity의 deception 설정은 관련 AD 계정에 대해 MDI 내에서 구성해야 하므로, 제안된 솔루션은 요구 사항을 충족하지 않습니다.
핵심 개념: 이 문제는 Microsoft Defender for Identity (MDI)의 deception 기능, 특히 공격자가 사용하거나 악용하려고 시도할 수 있는 Active Directory의 계정을 구성하는 것에 관한 것입니다. MDI에서는 Microsoft Entra ID Identity Protection 정책을 통해서가 아니라 Defender for Identity 설정에서 직접 honeytoken 또는 sensitive account를 구성하여 이를 수행합니다. 정답인 이유: 제안된 솔루션은 목표를 충족하지 않습니다. Azure AD Identity Protection의 sign-in risk policy는 위험한 클라우드 인증 이벤트를 탐지하고 대응하는 데 사용됩니다. 이는 공격자가 사용할 수 있는 기만용 Active Directory 계정을 생성하거나 구성하지 않으며, MDI의 deception 기능과도 통합되지 않습니다. 따라서 정답은 아니요입니다. 주요 기능: MDI는 관리자가 특정 on-premises Active Directory 계정을 honeytoken으로 표시하거나 고가치 대상으로 모니터링할 수 있도록 하여 deception을 지원합니다. 이러한 계정은 조회되거나, 인증되거나, 의심스럽게 사용될 경우 경고를 트리거하도록 설계됩니다. 반면 Azure AD Identity Protection은 Microsoft Entra ID에서 사용자 및 sign-in risk를 평가하고 conditional access 방식의 수정 조치를 적용합니다. 일반적인 오해: 흔한 실수는 Microsoft Entra ID Identity Protection과 Microsoft Defender for Identity를 혼동하는 것입니다. 둘 다 identity security를 다루기 때문입니다. 그러나 Identity Protection은 클라우드 identity risk 및 정책 적용에 중점을 두는 반면, MDI는 on-premises Active Directory 모니터링, lateral movement 탐지 및 deception 관련 탐지에 중점을 둡니다. 시험 팁: SC-200에서는 Microsoft Entra ID 보호 기능과 Defender for Identity 기능을 구분해야 합니다. 작업이 Active Directory reconnaissance, lateral movement, honeytokens 또는 AD에서의 attacker deception과 관련된 경우 Defender for Identity를 떠올리십시오. 작업이 risky sign-ins, user risk, MFA 또는 클라우드 identity risk를 기반으로 한 password reset과 관련된 경우 Identity Protection을 떠올리십시오.
이미지 파일을 사용하는 잠재적 공격에 대한 security bulletin을 받았습니다. 공격을 방지하기 위해 Microsoft Defender for Endpoint에서 indicator of compromise (IoC)를 만들어야 합니다. 어떤 indicator type을 사용해야 합니까?
오답입니다. Action이 Alert only로 설정된 URL/domain indicator는 방지 없이 탐지만 제공합니다. 요구 사항은 공격을 방지하는 것이므로 “Alert only”는 목표를 충족하지 못합니다. 또한 문제는 이미지 파일 artifact에 초점을 맞추고 있으므로, web destination만 모니터링하는 것보다 file 기반 indicator가 더 적절합니다.
최선의 선택은 아닙니다. Alert and block이 설정된 URL/domain은 알려진 malicious site에 대한 접근을 방지할 수 있지만, 이는 특정 malicious image file이 아니라 전달 infrastructure를 차단합니다. 이미지가 email, removable media 또는 다른 domain/CDN을 통해 전달될 수 있다면 URL/domain 차단만으로는 공격을 막지 못할 수 있습니다. 문제는 이미지 파일을 강조하므로 file hash IoC를 가리킵니다.
정답입니다. Action이 Alert and block으로 설정된 file hash indicator는 알려진 malicious file이 endpoint에서 사용되는 것을 방지하도록 설계되었습니다. 파일이 이미지이더라도 MDE는 알려진 악성 hash를 차단하여 방지와 alerting을 모두 제공합니다. 이는 특정 malicious file sample에 대해 가장 직접적인 IoC type입니다.
이 경우 일반적으로 오답입니다. Certificate indicator는 특정 certificate로 signed된 파일을 차단합니다(손상되었거나 malicious publisher에 유용함). 대부분의 malicious image file은 signed되지 않으며, 설령 signed되었다 하더라도 문제에서 signing certificate를 언급하지 않습니다. 특정 malicious file을 차단할 때 적절한 IoC는 file hash입니다.
핵심 개념: 이 문제는 Microsoft Defender for Endpoint (MDE) Indicators (Indicators of Compromise/Attack)와 알려진 malicious content의 실행을 방지하기 위해 이를 사용하는 방법을 평가합니다. MDE에서는 다양한 artifact type(file hash, URL/domain, IP address, certificate)에 대해 indicator를 만들고 Alert only 또는 Alert and block과 같은 action을 선택할 수 있습니다. 정답이 맞는 이유: bulletin은 이미지 파일을 사용하는 잠재적 공격을 설명합니다. endpoint에서 공격을 방지하려면 malicious file 자체를 차단해야 합니다. 가장 직접적이고 시험에서 자주 다루는 방법은 Action을 Alert and block으로 설정한 file hash indicator입니다. file hash IoC는 정확히 알려진 악성 파일(예: .jpg/.png와 같은 이미지 포함)을 대상으로 하며, 해당 파일이 감지될 때(다운로드되거나, 기록되거나, platform 및 enforcement에 따라 실행/열기 시도될 때) MDE가 이를 차단하도록 지시합니다. 이는 단순히 “detect”하는 것이 아니라 “prevent”하는 요구와 일치합니다. 주요 기능 및 best practice: - File hash indicator는 SHA-256(권장)을 지원하며, portal 환경에 따라 SHA-1/MD5도 지원할 수 있습니다. 시험 관점에서는 SHA-256이 best practice라고 가정하십시오. - “Alert and block”은 enforcement(방지)를 제공하고 SOC 가시성을 위한 alert도 생성합니다. - 특정하게 알려진 malicious sample이 있을 때는 file hash IoC를 사용하고, 전달 infrastructure를 알고 있을 때는 URL/domain IoC를 사용하며, 여러 파일에 걸쳐 signer를 차단해야 할 때는 certificate IoC를 사용합니다. - 이는 Azure Well-Architected Framework의 Security pillar 원칙인 attack surface 축소 및 monitoring과 함께 preventive control 구현에 해당합니다. 일반적인 오해: - 많은 공격이 web link를 통해 전달되므로 URL/domain의 “Alert and block”이 맞아 보일 수 있지만, 문제는 공격이 이미지 파일을 사용한다고 명시합니다. 파일이 여러 채널을 통해 전달되더라도 file hash를 차단하는 것이 더 정확하고 탄력적입니다. - Certificate indicator도 강력하지만 malicious file이 signed된 경우에만 적용됩니다(또는 손상되었거나 악용된 certificate를 차단하려는 경우). 많은 malicious image file은 unsigned입니다. 시험 팁: - 문제에서 “prevent” 또는 “block”이라고 하면, blocking을 지원하고 설명된 artifact와 일치하는 indicator type을 선택하십시오. - artifact가 특정 파일(악용에 사용되는 non-executable 포함)이라면, file hash + Alert and block을 선택하십시오. - enforcement 없이 가시성만 원할 때(예: 테스트, 잠재적 false positive)는 “Alert only”를 사용하십시오.
