Practice Test #3

Windows용 Azure Disk Encryption은 지원되는 Windows Server 버전이 필요하며, Windows Server 2008 R2는 ADE에서 지원되지 않습니다. 따라서 디스크 암호화를 활성화하기 전에 VM1을 지원되는 운영 체제 버전으로 변경해야 합니다. 여기서 결정적인 문제는 티어가 아니며, VM이 지원되는 OS에서 실행되고 필요한 extension을 사용할 수 있는 한 VM size/type 자체가 차단 요인은 아닙니다.

Linux의 Azure Disk Encryption은 특정 승인된 배포판과 이미지들을 지원하며, Ubuntu 16.04-DAILY-LTS는 ADE에서 지원되는 프로덕션 이미지가 아닙니다. 암호화를 활성화하려면 VM2를 공식적으로 지원되는 Ubuntu LTS marketplace image와 같은 지원되는 운영 체제 버전/image로 변경해야 합니다. tier는 이미 Standard이므로 문제가 아니며, 이 시나리오에서 L4s VM type은 ADE의 차단 요인이 아닙니다.

정답: A (통과). 보기에서 허용되는 state 전환을 결정하는 데 필요한 관련 세부 정보를 확인할 수 있습니다. Alerts 목록에는 Alert state 값(New, Acknowledged, Closed)이 표시되고, toolbar에는 “Change state” 작업이 포함되어 있습니다. 이는 특정 alert 인스턴스의 state를 변경할 수 있는지, 그리고 어떤 값으로 변경할 수 있는지에 대한 하위 질문에 답하기에 충분한 정보입니다. 이는 표준 Azure Monitor alerts 관리 시나리오이며(classic alerts와 새 alerts를 혼동하게 만드는 문제가 아님), grid에 여러 state가 존재하고 명시적인 “Change state” 컨트롤이 있다는 점은 portal이 선택한 alerts의 alert state 수정을 지원함을 나타냅니다. 따라서 실패를 선택하기보다 답변을 진행하는 것이 타당합니다. B가 아닌 이유: Fail을 선택한다는 것은 정답을 판단할 수 없다는 의미이지만, screenshot은 질문에 필요한 핵심 필드(Alert state 및 Fired time)를 제공합니다.

11:23:52에 발생한 Alert1 인스턴스는 현재 Acknowledged 상태입니다. Azure Monitor에서 alert processing state는 workflow state이며, acknowledged된 alert는 다시 New로 되돌리거나(처리를 재개/초기화하기 위해) 앞으로 Closed로 변경할 수 있습니다. 따라서 정답은 New 또는 Closed로 변경할 수 있다는 것입니다. 다른 선택지는 alert 상태를 편집할 수 있고, Acknowledged는 다음 상태가 하나로만 제한되지 않기 때문에 올바르지 않습니다.

11:23:24에 발생한 Alert2 인스턴스는 현재 Closed 상태입니다. Azure Monitor에서 closed alert는 terminal 상태가 아니며, New로 변경하여 다시 열거나 누군가가 다시 담당하는 경우 Acknowledged로 변경할 수 있습니다. 따라서 정답은 New 또는 Acknowledged입니다. 다른 선택지는 너무 제한적입니다. Closed alert는 portal에서 workflow state를 계속 업데이트할 수 있기 때문입니다.

예. VM1은 표에 표시된 대로 지원되는 범용 OS(Windows 또는 지원되는 Linux distribution)를 실행하고 있으므로 Update Management를 사용하도록 설정할 수 있습니다. Update Management를 사용하도록 설정하는 것은 주로 온보딩/구성 단계입니다. 즉, VM이 Automation account 및 Log Analytics workspace에 연결되고 필요한 agent/extension이 설치/구성됩니다. VM1이 실행 중이므로 agent 설치를 즉시 완료하고 update compliance 보고를 시작할 수도 있습니다. 대안인 (아니요)는 VM1이 지원되지 않는 OS/image 유형(예: network appliance 또는 필요한 agent/extension을 실행할 수 없는 image)이거나, 시나리오에서 필요한 Azure endpoint에 대한 outbound connectivity가 차단되었다고 명시적으로 언급한 경우에만 정답이 됩니다. 여기서는 VM1에 대해 어느 조건도 적용되지 않습니다.

아니요. VM2는 VM2에 대해 표에 표시된 OS/image 유형이 Azure Update Management (classic)에서 지원되지 않기 때문에 Update Management를 활성화할 수 없습니다. Update Management는 Microsoft Monitoring Agent/Log Analytics agent를 실행할 수 있는 지원되는 Windows/Linux OS(또는 솔루션에서 사용하는 필수 VM extension 경로)를 필요로 하며, Azure Automation/Log Analytics와 통신할 수 있어야 합니다. VM2가 특수한 appliance/잠금된 marketplace image인 경우(이러한 문제에서 흔함), 평가 및 patch orchestration에 필요한 agent/extension 모델을 지원하지 않습니다. VM2가 실행 중이더라도 전원 상태가 OS 지원 요구 사항을 무시하지는 않습니다. 따라서 플랫폼은 지원되지 않는 OS를 Update Management에 온보딩할 수 없으므로 “예”는 올바르지 않습니다.

예. VM3는 중지된 상태이더라도 Update Management를 사용하도록 설정할 수 있습니다. 이것은 자주 출제되는 시험의 미묘한 포인트입니다: Update Management를 활성화/온보딩하는 것은 control-plane 구성으로, 현재 실행 중인지 여부와 관계없이 Azure VM에 적용할 수 있습니다. 중지된 동안 할 수 없는 것은 실시간 평가 완료, agent/extension 설치(아직 없는 경우), 또는 update deployment 실행입니다. 이러한 작업은 VM의 전원이 켜져 있고 Azure endpoints와 outbound 통신이 가능해야 합니다. 표에 있는 VM3의 OS가 지원되는 Windows/Linux OS라면, 사용 설정에 대한 정답은 예입니다. “아니요”가 정답이 되는 경우는 OS가 지원되지 않거나, 질문이 중지된 상태에서 updates를 배포할 수 있는지를 물었을 때뿐입니다.

예. VM4는 표에 따라 지원되는 OS를 실행하고 있으므로 Update Management를 활성화할 수 있습니다. VM이 실행 중인 상태에서는 onboarding이 필요한 agent/extension을 설치/구성하고 update compliance 데이터를 즉시 수집하기 시작할 수 있습니다. Update Management는 지속적인 patch governance 및 reporting을 위해 설계되었으며, 이는 Secure Compute pillar를 지원합니다: OS patch 수준 유지, vulnerability exposure 감소, auditability 제공. “아니요” 옵션은 VM4가 지원되지 않는 OS/appliance image인 경우이거나 prerequisites가 명시적으로 누락된 경우에만 적용됩니다(예: Azure Automation/Log Analytics endpoints에 대한 connectivity 없음, 또는 extension 설치를 방지하는 policy restrictions). 표에서 지원되는 VM OS임을 나타내고 있으므로, Update Management를 활성화하는 것은 유효합니다.

Storage1은 사용할 수 없습니다. Storage1은 올바른 Region(East US)에 있지만, Storage account type이 “Blob”으로 표시되어 있습니다. Azure에서 BlobStorage account(레거시 “Blob” type)는 Azure SQL Database auditing에 대해 지원되는 대상 type이 아닙니다. SQL auditing에는 standard performance의 General-purpose v1 (Storage) 또는 General-purpose v2 (StorageV2)와 같은 지원되는 Azure Storage account type이 필요합니다. Access tier(Cool)는 여기서 결정 요인이 아닙니다. tiering은 blob data lifecycle/cost에 적용되며 그 자체로 auditing을 차단하지는 않습니다. 핵심 문제는 account kind/type입니다. 따라서 올바른 Region과 Resource group이 있더라도 Storage1은 audit log 대상지로 적합하지 않습니다.

Storage2는 사용할 수 있습니다. Storage2는 East US에 있으며, 이는 SQL1의 지역(East US)과 일치합니다. Azure SQL Database auditing에서 Storage로 감사 로그를 보내려면 지역이 일치해야 합니다. 또한 Storage2는 General purpose v1 account이며, 이는 SQL auditing에서 지원되는 storage account 유형입니다. Storage2가 다른 resource group(RG2)에 있다는 사실은 auditing 대상지로 사용하는 것을 막지 않습니다. Auditing 구성은 resource group의 동일 위치 여부가 아니라 권한 및 지원되는 대상지 특성(지역/유형)을 기반으로 합니다. 또한 “Access tier (기본값): 해당 없음”은 GPv1 account에서 예상되는 사항이며 auditing 적격성에 영향을 주지 않습니다. 따라서 Storage2는 유효한 audit log 대상지입니다.

Storage3는 사용할 수 없습니다. Storage3는 General purpose v2 account(지원되는 유형)이지만, West Europe에 있습니다. SQL1은 East US에 있습니다. Azure SQL Database auditing에서 Storage account를 사용하려면, 해당 Storage account는 감사 대상 SQL 리소스와 동일한 region에 있어야 합니다. Storage3가 SQL1과 동일한 Resource group(RG1)에 있더라도, Resource group 일치는 regional requirement를 대체하지 않습니다. SQL auditing에서는 cross-region storage 대상이 지원되지 않으며, 이를 구성하려고 하면 실패하거나 차단됩니다. Access tier(Hot)는 문제가 아닙니다. 문제는 region 불일치입니다. 따라서 Storage3는 적합하지 않습니다.

감사 로그 대상지로는 Storage2만 사용할 수 있습니다. 각 storage account를 두 가지 주요 요구 사항인 지원되는 storage account 유형과 동일한 region 배치 기준으로 평가합니다. - Storage1 (East US)은 account 유형이 “Blob”(BlobStorage)이므로 실패합니다. 이 유형은 Azure SQL auditing 대상지로 지원되지 않습니다. - Storage2 (East US)는 통과합니다. General purpose v1(지원됨)이며 SQL1과 동일한 region에 있습니다. - Storage3는 GPv2이지만 region이 일치하지 않으므로 실패합니다(West Europe vs East US). 따라서 정답은 “Storage2만”입니다.

Analytics1만 사용할 수 있습니다. Analytics1은 이 auditing 구성 시나리오에서 SQL1과 일치하는 Log Analytics workspace입니다. Analytics3는 West Europe에 있으므로 SQL1의 East US 지역과 일치하지 않습니다. Analytics2는 이 문제에서 유효한 대상지로 선택되지 않았으므로, 정답은 Analytics1만입니다.