
50개 문제와 100분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 정답이 둘 이상 있을 수 있고, 다른 문제 세트에는 정답이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 사용자는 Azure Active Directory (Azure AD)의 hybrid 구성을 가지고 있습니다. 사용자는 virtual network에 있는 Azure HDInsight cluster를 가지고 있습니다. 사용자는 on-premises Active Directory 자격 증명을 사용하여 사용자가 cluster에 인증할 수 있도록 허용할 계획입니다. 계획된 인증을 지원하도록 환경을 구성해야 합니다. 솔루션: Azure subscription에 Azure Active Directory Domain Services (Azure AD DS)를 배포합니다. 이것이 목표를 충족합니까?
예가 정답인 이유는 Azure AD DS가 Azure에서 LDAP 및 Kerberos를 지원하는 managed AD DS 호환 domain을 제공하며, 이는 HDInsight Enterprise Security Package (ESP) 인증에 일반적으로 필요하기 때문입니다. hybrid 설정에서는 on-premises AD에서 Azure AD로 동기화된 사용자가 Azure AD DS에 표시될 수 있으므로 기존 on-premises 자격 증명을 사용해 인증할 수 있습니다. Azure AD DS를 subscription에 배포하고 HDInsight cluster와 통합하면(domain join, DNS 구성) domain controller VM을 배포하고 관리하지 않고도 환경이 domain 기반 인증을 지원할 수 있습니다.
아니요는 오답입니다. 요구 사항은 on-premises Active Directory 자격 증명을 사용한 인증을 허용하는 것이며, 이는 Azure AD 전용 로그인이 아니라 domain 기반 인증 메커니즘(예: Kerberos/LDAP)을 의미합니다. Azure AD DS는 Azure에서 이러한 AD DS 프로토콜을 managed service로 제공하도록 특별히 설계되었으며 HDInsight ESP domain integration을 활성화하는 지원되는 접근 방식입니다. 대체 구현(예: Azure VM에 AD DS domain controller 배포)도 있을 수 있지만, 제안된 솔루션은 목표를 충족할 수 있으므로 아니요라고 답하는 것은 Azure AD DS가 요구 사항을 충족할 수 없다고 잘못 가정하는 것입니다.
핵심 개념: 이 문제는 hybrid identity 환경에서 virtual network에 배포된 Azure HDInsight cluster에 대해 domain 기반(on-premises AD) 인증을 활성화하는 방법을 테스트합니다. 정답인 이유: HDInsight는 cluster 인증/권한 부여가 domain(Kerberos/LDAP)과 통합되어 사용자가 domain 자격 증명을 사용해 로그인할 수 있는 Enterprise Security Package (ESP) 시나리오를 지원합니다. Azure Active Directory Domain Services (Azure AD DS)를 배포하면 기존 AD DS 프로토콜(LDAP/Kerberos/NTLM)과 호환되고 Azure VNet의 리소스가 조인할 수 있는 Azure의 managed domain이 제공됩니다. hybrid Azure AD 설정에서는 on-premises AD에서 Azure AD로 동기화된 사용자 identity를 Azure AD DS에서 사용할 수 있으므로, 해당 사용자는 기존 on-premises 자격 증명(동기화된 동일한 username/password)으로 HDInsight cluster에 인증할 수 있습니다. 따라서 Azure AD DS를 배포하는 것은 on-premises AD 자격 증명을 사용하여 HDInsight에 인증해야 한다는 요구 사항을 충족하는 유효한 방법입니다. 주요 기능 / 구성: - Azure AD DS는 LDAP, Kerberos, NTLM, Group Policy 및 domain join과 같은 managed domain services를 제공합니다. - Azure AD DS를 HDInsight cluster와 동일한(또는 peered) VNet에 배포하고 VNet DNS가 Azure AD DS domain controller IP를 가리키도록 구성합니다. - HDInsight Enterprise Security Package (ESP)를 사용하고 cluster를 Azure AD DS managed domain에 domain-join합니다. - 자격 증명이 일관되게 작동하도록 Azure AD Connect가 사용자(그리고 일반적으로 password hash sync)를 동기화하고 있는지 확인합니다. 일반적인 오해: - Azure AD(cloud identity)와 AD DS(domain services)를 혼동하는 것. Azure AD만으로는 많은 HDInsight ESP 통합에 필요한 Kerberos/LDAP domain join을 제공하지 않습니다. - Azure에서 전체 IaaS domain controller를 배포해야 한다고 가정하는 것; Azure AD DS는 managed service로서 domain 요구 사항을 충족할 수 있습니다. - pass-through authentication이 필요하다고 생각하는 것; Azure AD DS에서는 동일한 password로 로그인을 가능하게 하기 위해 일반적으로 password hash synchronization이 사용됩니다. 시험 팁: - 서비스에 Azure에서 LDAP/Kerberos/domain join이 필요하다면 Azure AD DS(managed) 또는 VM의 AD DS를 고려하세요. - domain 기반 인증이 있는 HDInsight의 경우 “Enterprise Security Package (ESP)” + domain integration을 찾으세요. - Azure AD DS를 도입할 때 domain join 및 조회가 작동하도록 VNet DNS 설정을 업데이트해야 한다는 점을 기억하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.


이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Azure SQL database가 있습니다. Always Encrypted를 구현합니다. 애플리케이션 개발자가 database의 데이터를 검색하고 decrypt할 수 있도록 해야 합니다. 개발자에게 어떤 두 가지 정보를 제공해야 합니까? 각 정답은 솔루션의 일부를 나타냅니다. 참고: 각 정답 선택에는 1점이 부여됩니다.
stored access policy는 blob, file, queue 또는 table에 대한 shared access signature를 제어하기 위해 Azure Storage에서 사용됩니다. 이것은 Azure SQL Database Always Encrypted와는 관련이 없습니다. Always Encrypted는 Storage access policy가 아니라 SQL key metadata와 Azure Key Vault 같은 외부 key store에 의존합니다. 따라서 이 옵션은 SQL 데이터 decrypt와 관련이 없습니다.
shared access signature는 Azure Storage 리소스에 대한 delegated access를 부여하며 Azure SQL Database Always Encrypted에서는 사용되지 않습니다. Always Encrypted 데이터의 decryption은 Storage token이 아니라 CEK와 CMK hierarchy에 따라 달라집니다. Azure Key Vault가 관련되어 있더라도 access는 SAS가 아니라 identity와 key permission을 통해 관리됩니다. 따라서 이 시나리오에서 SAS는 관련이 없습니다.
Column Encryption Key는 Always Encrypted column의 데이터를 직접 encrypt하는 key입니다. client driver는 database에서 CEK metadata를 가져와야 특정 column에 어떤 encrypted CEK를 사용해야 하는지 알고, 해당 CEK의 wrapping을 해제한 후 데이터를 decrypt할 수 있습니다. CEK는 encrypted된 상태로 database에 저장되지만, 여전히 decryption process에 관련된 필수 정보 중 하나입니다. CEK 정의와 metadata가 없으면 client는 보호된 column 값을 어떻게 decrypt해야 하는지 판단할 수 없습니다.
user credentials는 개발자 또는 애플리케이션이 Azure SQL Database에 authenticate할 수 있게 해주지만, decryption에 필요한 Always Encrypted의 두 가지 특정 정보 중 하나는 아닙니다. 이 문제는 CEK와 CMK에 의존하는 encryption architecture에 초점을 맞추고 있습니다. client가 필요한 key metadata와 CMK에 대한 access 권한도 가지고 있지 않다면 authentication만으로는 decryption이 가능하지 않습니다. 따라서 credentials는 운영상 필요할 수는 있지만, 이 문제의 의도된 정답은 아닙니다.
Column Master Key는 Column Encryption Key를 보호하거나 wrapping하기 때문에 필요합니다. client driver는 Azure Key Vault와 같은 외부의 신뢰할 수 있는 key store에 있는 CMK를 사용하여 database에서 가져온 encrypted CEK의 wrapping을 해제합니다. CEK의 wrapping이 해제되면 driver는 column 데이터를 로컬에서 decrypt할 수 있습니다. 따라서 CMK는 Always Encrypted column에서 plaintext를 읽어야 하는 모든 애플리케이션에 필수적인 요소입니다.
핵심 개념: Always Encrypted는 Azure SQL Database의 민감한 데이터를 보호하기 위해 2단계 key hierarchy를 사용합니다. Column Encryption Key (CEK)는 실제 column 데이터를 encrypt하고, Column Master Key (CMK)는 CEK를 보호합니다. client application driver는 두 key에 대한 metadata를 사용하여 encrypted 값을 검색하고 이를 로컬에서 decrypt합니다. 정답인 이유: Always Encrypted 데이터를 decrypt하려면 개발자에게 CMK와 CEK에 대한 정보가 필요합니다. CMK는 신뢰할 수 있는 key store 위치와 CEK를 보호하는 데 사용되는 key를 식별하고, CEK metadata는 client driver에 어떤 encrypted CEK가 column 데이터에 적용되는지 알려줍니다. 이 둘을 함께 사용하면 driver가 CEK의 wrapping을 해제하고 client 측에서 column 값을 decrypt할 수 있습니다. 주요 특징: Always Encrypted는 database engine이 아니라 client driver에서 encryption과 decryption을 수행합니다. database는 encrypted column 값과 encrypted CEK를 저장하며, 어떤 key가 사용되는지 설명하는 metadata도 함께 저장합니다. CMK는 외부에 저장되며, 일반적으로 Azure Key Vault 또는 certificate store에 있고, CEK는 database에 정의되며 encrypted column에서 참조됩니다. 일반적인 오해: 흔한 실수는 일반적인 database user credentials가 Always Encrypted에 필요한 정보 중 하나라고 생각하는 것입니다. credentials는 database에 연결하는 데 필요할 수 있지만, 이 문제에서 묻는 Always Encrypted key 정보의 일부는 아닙니다. 또 다른 오해는 SAS 또는 stored access policy와 같은 Azure Storage 개념을 SQL encryption 기능과 혼동하는 것입니다. 시험 팁: Always Encrypted 문제에서는 key hierarchy에 집중하십시오. CMK는 CEK를 보호하고, CEK는 데이터를 보호합니다. decrypt에 무엇이 필요한지 묻는다면, 일반적인 authentication 세부 정보보다 두 수준의 key metadata를 모두 떠올리십시오. SAS와 같은 Storage access 메커니즘은 문제에서 Azure Storage를 명시적으로 언급하지 않는 한 관련이 없습니다.
DRAG DROP - 100개의 virtual machine을 포함하는 Azure subscription이 있습니다. 모든 virtual machine에서 Azure Diagnostics가 활성화되어 있습니다. subscription의 Azure services 모니터링을 계획하고 있습니다. 다음 세부 정보를 검색해야 합니다: ✑ 3주 전에 virtual machine을 삭제한 사용자를 식별합니다. ✑ Windows Server 2016을 실행하는 virtual machine의 security events를 쿼리합니다. Azure Monitor에서 무엇을 사용해야 합니까? 답하려면 적절한 configuration settings를 올바른 세부 정보에 끌어다 놓으십시오. 각 configuration setting은 한 번, 여러 번 또는 전혀 사용되지 않을 수 있습니다. 내용을 보려면 창 사이의 분할 막대를 끌거나 스크롤해야 할 수 있습니다. 참고: 각 정답 선택에는 1점이 부여됩니다. 선택 후 배치:
3주 전에 virtual machine을 삭제한 사용자를 식별하세요: ______
정답: Activity log. VM 삭제는 Azure Resource Manager(control-plane) 작업입니다. Activity log는 생성/업데이트/삭제 작업에 대한 subscription 수준 이벤트를 기록하며, 작업을 시작한 identity(caller)를 포함하므로 3주 전에 VM을 삭제한 사용자를 식별할 수 있습니다(해당 이벤트가 아직 retention window 내에 있거나 더 긴 보존을 위해 workspace/storage로 export된 경우). 다른 선택지가 틀린 이유: - Logs: Azure Monitor Logs(Log Analytics)는 주로 workspace로 전송된 telemetry 및 로그(guest OS 로그, application 로그, diagnostics)를 쿼리하는 데 사용됩니다. Activity log를 workspace로 명시적으로 export하지 않는 한, ARM 삭제 작업에 대한 기본적인 authoritative record는 아닙니다. - Metrics: metrics는 숫자형 시계열(CPU, disk 등)이며, “누가 VM을 삭제했는지”를 기록하지 않습니다. - Service Health: Azure platform incidents 및 maintenance에 대한 정보를 제공하며, 사용자가 시작한 resource 삭제에 대한 정보는 제공하지 않습니다.
Windows Server 2016을 실행하는 virtual machine의 security events를 쿼리합니다: ______
정답: Logs. Windows Server 2016 VM에서 “security events”를 쿼리한다는 것은 Windows Security Event Log 항목(예: Event ID 4624/4625 logons, audit events)을 쿼리하는 것을 의미합니다. 이는 guest OS logs이며, VM이 Security events를 Log Analytics workspace로 전송하도록 구성된 경우(Azure Monitor Agent 또는 legacy agent + data collection rules/settings 사용) Azure Monitor에서 Logs(Log Analytics)와 KQL을 사용하여 쿼리합니다. 다른 선택지가 틀린 이유: - Activity log: VM 시작/중지/삭제와 같은 Azure management operations(ARM)을 캡처하며, guest 내부의 Windows Security events는 캡처하지 않습니다. - Metrics: 상세한 security event records를 제공할 수 없으며, 집계된 숫자 측정값만 제공합니다. - Service Health: VM guest security events와 관련이 없으며, Azure service incidents/advisories/maintenance를 보고합니다.
VNetwork1의 기술 요구 사항을 충족해야 합니다. 가장 먼저 무엇을 해야 합니까?
새 subnet을 만드는 것은 요구 사항이 추가 세분화, 주소 공간 분리 또는 서비스용 전용 subnet(예: AzureFirewallSubnet, GatewaySubnet)을 명시적으로 요구할 때만 적절합니다. 이는 routing/NSG/firewall과 함께 사용되지 않는 한 본질적으로 보안 상태를 개선하지 않습니다. 문제의 원인이 기존 subnet에 NSG가 없다는 것이라면, 새 subnet을 추가하는 것은 불필요하며 즉각적인 제어 요구 사항을 충족하지 못합니다.
Subnet11 및 Subnet13에서 NSG를 제거하면 네트워크 세분화가 줄어들고 최소 권한 원칙을 위반합니다. NSG는 일반적으로 인바운드/아웃바운드 흐름을 제한하고 east-west 트래픽을 제어하는 데 필요합니다. 누군가 NSG가 연결 문제를 일으킨다고 가정하면 이 옵션이 그럴듯해 보일 수 있지만, 질문은 VNetwork1의 기술 요구 사항 충족에 관한 것이며, 이는 일반적으로 제어를 추가/적용하는 것을 의미하지 제거하는 것을 의미하지는 않습니다.
Subnet12에 NSG를 연결하면 VNetwork1 전체에서 일관된 subnet 수준 트래픽 필터링이 보장됩니다. subnet이 보호되지 않거나 요구 사항에서 해당 subnet의 리소스에 대한 트래픽 제어를 지정하는 경우 이것이 올바른 첫 단계입니다. 이는 기본 보호를 위해 subnet 경계에 NSG를 적용하고, 필요한 경우 ASG 또는 NIC 수준 NSG를 통해 더 세분화된 규칙을 허용하는 모범 사례와 일치합니다.
VNetwork1에 대해 DDoS protection(일반적으로 DDoS Network Protection Standard)을 구성하면 대규모 volumetric attack 및 protocol attack을 완화하고 향상된 telemetry와 비용 보호를 제공합니다. 그러나 이는 subnet 간 또는 인터넷으로부터 어떤 port/protocol이 허용되는지를 제어하지 않습니다. 요구 사항이 subnet 보안 규칙 또는 트래픽 제한에 관한 것이라면, DDoS protection은 가장 먼저 또는 주요하게 구현해야 하는 제어가 아닙니다.
핵심 개념: 이 문제는 subnet 수준의 Azure 네트워크 보안 제어, 특히 Network Security Groups (NSGs)를 테스트합니다. Azure에서 NSG는 subnet 및 NIC에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 기본적인 Layer 4 (TCP/UDP) stateful filtering 메커니즘입니다. 일반적인 보안 기준 요구 사항은 워크로드를 호스팅하는 모든 subnet이 NSG(또는 hub-and-spoke 설계의 Azure Firewall과 같은 동등한 제어)로 보호되어야 한다는 것이며, 이는 Azure Well-Architected Framework(Security pillar: 네트워크 세분화 및 최소 권한 구현)와 일치합니다. 정답인 이유: VNetwork1의 기술 요구 사항을 충족하려면, 가장 가능성이 높은 문제는 하나의 subnet(Subnet12)에 NSG 연결이 없고 다른 subnet(Subnet11 및 Subnet13)에는 이미 NSG가 있다는 점입니다. 첫 번째 조치는 Subnet12에 NSG를 연결하여 해당 subnet의 리소스에 대한/로부터의 트래픽을 명시적으로 허용/거부할 수 있도록 하는 것입니다. NSG가 없으면 subnet은 기본 system route 및 상위 제어에만 의존하게 되며, 많은 시험 시나리오에서 이는 "모든 subnet은 NSG로 보호되어야 한다" 또는 "subnet 간 트래픽을 제한해야 한다"와 같은 명시된 요구 사항을 충족하지 못합니다. NSG를 연결하는 것은 올바른 범위에서 정책을 적용하는 최소한의 직접적인 변경입니다. 주요 기능 / 모범 사례: NSG는 기본 규칙과 함께 우선순위, service tag, application security groups (ASGs)를 사용하는 사용자 지정 규칙을 제공하여 확장 가능한 규칙 관리를 지원합니다. subnet 수준 NSG는 subnet의 모든 NIC에 적용됩니다(NIC 수준 NSG에 추가로 적용). 시험 대비를 위해 기억해야 할 점: NSG는 stateful이며, 우선순위에 따라 평가되고, subnet 간 east-west 트래픽을 세분화하는 데 사용할 수 있습니다. 일반적인 오해: NSG를 제거하는 것(옵션 B)은 보안을 약화시키며 "요구 사항 충족"에 거의 부합하지 않습니다. 새 subnet을 만드는 것(옵션 A)은 요구 사항이 추가 세분화를 명시적으로 요구하지 않는 한 누락된 적용을 해결하지 못합니다. DDoS protection(옵션 D)은 가용성 측면에서 유용하지만 NSG 기반 트래픽 필터링을 대체하지는 않습니다. 이는 access rule을 적용하는 것이 아니라 대규모 volumetric attack을 완화합니다. 시험 팁: "VNet/subnet의 기술 요구 사항 충족"이 보이고 옵션에 NSG 연결이 포함되어 있다면, 먼저 필요한 각 subnet에 올바른 NSG가 적용되어 있는지 확인하십시오. DDoS Standard는 공격 완화, telemetry, SLA credit이 요구 사항에 언급될 때 선택하며, 기본적인 subnet 트래픽 제어를 위한 것은 아닙니다.
DRAG DROP - Sub1이라는 Azure subscription이 있고, 여기에는 LAW1이라는 Azure Log Analytics workspace가 포함되어 있습니다. Windows Server 2016을 실행하고 LAW1에 등록된 500개의 Azure virtual machine이 있습니다. LAW1에 System Update Assessment solution을 추가할 계획입니다. 100개의 virtual machine에서만 System Update Assessment 관련 로그가 LAW1에 업로드되도록 해야 합니다. 어떤 세 가지 작업을 순서대로 수행해야 합니까? 답하려면 작업 목록에서 적절한 작업을 답 영역으로 이동하고 올바른 순서로 배열하세요. 선택하여 배치:
아래 이미지에서 정답을 선택하세요.

Pass. System Update Assessment 로그가 100개의 VM에서만 업로드되도록 보장하는 올바른 순서는 다음과 같습니다: 1) computer group을 생성합니다. 2) scope configuration을 생성합니다. 3) scope configuration을 solution에 적용합니다. 이유: Computer Group은 Log Analytics에서 동적 또는 정적 agent/VM 집합(예: 이름, resource group, tag 또는 saved search 기준)을 정의하는 메커니즘입니다. 그런 다음 Scope Configuration은 해당 group을 참조하여 solution의 대상 scope를 정의합니다. 마지막으로 해당 scope configuration을 System Update Assessment solution에 적용하면 group의 멤버만 solution별 데이터를 전송합니다. 다른 선택지가 틀린 이유: 새 workspace를 만드는 것은 불필요하며 설계를 변경하게 됩니다(그리고 100개의 VM만 이동하거나 연결해야 함). data source를 만드는 것은 solution 대상 지정과 관련이 없습니다. 이는 특정 로그/카운터를 수집하는 데 사용되며, solution의 기본 제공 수집을 제한하는 용도가 아닙니다.
다음 표에 표시된 virtual machines를 포함하는 Sub1이라는 Azure subscription이 있습니다.
| Name | Resource group |
|---|---|
| VM1 | RG1 |
| VM2 | RG2 |
| VM3 | RG1 |
| VM4 | RG2 |
RG1의 virtual machines에서 authorized user가 access를 요청할 때까지 Remote Desktop port가 닫혀 있도록 해야 합니다. 무엇을 구성해야 합니까?
Azure AD Privileged Identity Management (PIM)는 Global Administrator 또는 Owner와 같은 Azure AD 및 Azure RBAC의 privileged roles에 대해 just-in-time elevation을 제공합니다. 누가 administrative permissions를 활성화할 수 있는지와 그 기간을 제어하는 데 도움이 되지만, VM에 대한 inbound network access는 관리하지 않습니다. 사용자가 PIM을 통해 privileged role을 활성화하더라도 TCP 3389는 여전히 networking rules를 통해 별도로 제어되어야 합니다. 따라서 PIM은 RDP port의 임시 개방 및 차단이 아니라 identity governance를 다룹니다.
application security group (ASG)은 NSG rules가 해당 groups를 더 쉽게 대상으로 지정할 수 있도록 virtual machine NICs를 논리적으로 그룹화하는 데 사용됩니다. 이는 특히 여러 VMs에 동일한 network policy가 필요할 때 rule 관리를 단순화하지만, 요청 기반 또는 시간 제한 access를 제공하지는 않습니다. ASG를 참조하는 NSG rule을 통해 RDP가 허용되면, 관리자가 rule을 변경할 때까지 해당 access는 계속 유지됩니다. 결과적으로 ASG는 security rules를 구성하는 데는 도움이 되지만, authorized user가 access를 요청할 때까지 RDP를 닫아 두어야 한다는 요구 사항은 충족하지 못합니다.
Azure AD Conditional Access는 MFA, compliant devices 또는 trusted locations 요구와 같이 Azure AD로 인증되는 applications 및 services에 대한 sign-in conditions를 평가합니다. 이는 identity layer에서의 authentication 및 authorization 결정에 초점을 맞추며, VM의 network port로 들어오는 inbound traffic 제어에는 초점을 두지 않습니다. TCP 3389에서의 Remote Desktop 노출은 Conditional Access policies가 아니라 NSGs, Azure Firewall 또는 유사한 network controls에 의해 관리됩니다. 따라서 Conditional Access는 사용자가 temporary access를 요청할 때까지 RDP port가 닫혀 있도록 보장할 수 없습니다.
Just-in-time (JIT) VM access는 RDP (3389) 및 SSH (22)와 같은 management ports의 노출을 줄이도록 특별히 설계된 Azure 기능입니다. 이 기능은 해당 ports를 기본적으로 닫아 두고 authorized user가 정의된 기간 동안, 그리고 선택적으로 특정 source IP address 또는 range에서만 temporary access를 요청할 수 있도록 합니다. Azure에서 JIT는 일반적으로 Microsoft Defender for Cloud를 통해 구성되며 필요 시 NSG 또는 Azure Firewall rules를 수정하여 구현됩니다. 이는 RG1의 virtual machines에서 access가 명시적으로 요청될 때까지 Remote Desktop이 닫혀 있어야 한다는 요구 사항을 직접적으로 충족합니다.
핵심 개념: 이 문제는 Azure VMs에 대한 management-plane access(RDP/SSH)를 제어하기 위해 inbound management ports를 기본적으로 닫아 두고 필요할 때만 여는 방법을 테스트합니다. Azure에서 이를 위한 전용 기능은 Microsoft Defender for Cloud를 통해 제공되고 VM의 network path에 있는 NSG rules(또는 Azure Firewall)를 통해 적용되는 Just-In-Time (JIT) VM access입니다. 정답인 이유: RG1의 VMs에서 authorized user가 access를 요청할 때까지 Remote Desktop port(TCP 3389)가 닫혀 있도록 해야 합니다. JIT VM access는 정확히 이를 수행합니다. management ports에 대한 지속적인 inbound access를 제거/차단하고, 승인된 요청이 있을 때 특정 source IP range와 제한된 시간 동안만 port를 일시적으로 엽니다. 시간이 만료되면 rule이 자동으로 되돌려져 다시 닫힌 상태가 복원됩니다. 이는 least privilege 원칙에 부합하며 brute-force attacks 및 internet scanning에 대한 노출을 줄입니다. 주요 기능 / 구성 포인트: - VM별로(또는 대규모로) 활성화할 수 있으며 RG1의 VMs에 scope를 지정할 수 있습니다. - 3389 (RDP) 및 22 (SSH)와 같은 ports를 제어하며, 허용 ports, source IPs, 최대 요청 기간을 구성할 수 있습니다. - 요청이 있을 때만 access를 열기 위해 NSG rule automation(또는 firewall rules)을 사용합니다. - Azure RBAC와 통합됩니다. 적절한 permissions가 있는 사용자만 JIT access를 요청할 수 있습니다. - 요청 및 access events에 대한 auditing을 지원하여 security operations 및 compliance를 향상시킵니다. 일반적인 오해: - PIM 및 Conditional Access는 Azure resources/apps에 대한 identity 및 access를 관리하지만, VMs에 대한 inbound network ports는 관리하지 않습니다. - Application Security Groups는 NSG 대상을 단순화하는 데 도움이 되지만, 시간 제한이 있는 on-demand port opening을 제공하지는 않습니다. 시험 팁: 요구 사항에 “요청될 때까지 RDP/SSH를 닫아 둔다”, “temporary access”, 또는 “management ports의 attack surface를 줄인다”가 언급되면, 예상 정답은 JIT VM access(Defender for Cloud)입니다. 이를 Azure Well-Architected Framework의 Security pillar와 연결하세요: 노출 최소화, least privilege 적용, auditing 활성화.
귀사에는 contoso.com이라는 이름의 Azure Active Directory (Azure AD) tenant가 있습니다. 귀사는 Azure Monitor를 사용하여 여러 보안 경고를 생성할 계획입니다. 경고를 위해 Azure subscription을 준비해야 합니다. 가장 먼저 무엇을 생성해야 합니까?
Azure Storage account는 일반적으로 로그를 저렴하게 보관하거나 장기 보존 요구 사항을 충족하기 위한 diagnostic 대상에 사용됩니다. 그러나 Azure Monitor alert rules(특히 log query alerts)는 Storage account의 존재를 요구하지 않습니다. Storage는 보존/보관을 위한 선택 사항이며, Azure Monitor에서 보안 alerts를 생성하기 위한 주요 필수 조건이 아닙니다.
Log Analytics workspace는 Azure Monitor Logs의 기반 구성 요소입니다. 대부분의 보안 중심 Azure Monitor alerts는 Log Analytics 데이터에 대해 KQL 쿼리를 실행하는 scheduled query(로그) alerts입니다. workspace를 먼저 생성하면 Azure AD logs, Activity Logs, resource diagnostics를 수집한 다음, 그 중앙 집중식 telemetry를 기반으로 alert rules를 구축할 수 있습니다.
Azure Event Hub는 로그/이벤트를 외부 시스템(예: 타사 SIEM)으로 스트리밍하거나 거의 실시간 event processing에 사용됩니다. diagnostic 대상으로 사용할 수는 있지만, Azure Monitor alerting에는 Event Hubs가 필요하지 않습니다. 이는 통합/스트리밍 선택 사항이지, Azure Monitor 보안 alerts를 위해 Azure subscription을 준비하는 첫 단계가 아닙니다.
Azure Automation account는 runbook, update management(legacy), automation 작업에 사용됩니다. alert action에 의해(예: webhook/logic app를 통해) 호출되어 문제를 수정할 수 있지만, Azure Monitor alerts를 생성하는 데 필요하지는 않습니다. 일반적으로 automation은 alerts가 존재하고 응답 워크플로를 정의한 후에 생성합니다.
핵심 개념: Azure Monitor 경고는 신호(메트릭, 로그, activity log, resource health 등)를 평가하는 규칙 기반 알림입니다. KQL에 의존하는 보안 경고의 경우, Azure Monitor는 데이터 플랫폼으로 Log Analytics를 사용합니다. 많은 AZ-500 시나리오는 암묵적으로 “scheduled query”(로그) 경고를 의미하며, 이는 Log Analytics workspace를 필요로 합니다. 정답이 맞는 이유: Azure Monitor를 사용하여 여러 보안 경고를 생성하려면 일반적으로 보안 관련 telemetry(Azure Activity logs, Azure AD sign-in/audit logs, resource diagnostic logs, VM security events 등)를 Log Analytics workspace로 수집하고 중앙 집중화합니다. Azure Monitor log alerts(Scheduled query rules)는 workspace에 대해(또는 workspace에 연결된 지원되는 resource에 대해) KQL 쿼리를 실행합니다. workspace가 없어도 metric alerts는 생성할 수 있지만, sign-ins, audit events, diagnostic logs를 쿼리하는 일반적인 보안 중심의 로그 기반 탐지는 구축할 수 없습니다. 따라서 이러한 경고를 위해 “subscription을 준비”하는 첫 번째 필수 조건은 Log Analytics workspace를 생성하는 것입니다. 주요 기능 / 모범 사례: - 중앙 집중식 로그 수집 및 보존: 규정 준수 요구 사항과 비용에 따라 보존 기간을 구성합니다(Well-Architected: Cost Optimization + Security). - 주요 resource(Azure AD logs, subscription Activity Log, Key Vault, NSGs, firewalls 등)에서 diagnostic settings를 활성화하여 로그를 workspace로 전송합니다. - 데이터가 흐르기 시작하면 action groups(email/SMS/ITSM/webhook)와 함께 Azure Monitor alert rules를 사용합니다. - workspace region 정렬, RBAC(Log Analytics Reader/Contributor), 데이터 액세스 제어를 고려합니다. 일반적인 오해: - Storage accounts는 diagnostic settings를 통해 로그를 보관/장기 보존하는 데 사용되지만, Azure Monitor alerts를 생성하는 데 필수는 아닙니다. - Event Hubs는 로그를 SIEM 또는 외부 도구로 스트리밍하는 데 사용되며, Azure Monitor alerting에 필수는 아닙니다. - Automation accounts는 응답으로 runbook을 실행할 수 있지만, alerts 생성의 필수 조건은 아닙니다. 시험 팁: 문제에서 “Azure Monitor alerts”와 “security alerts”를 언급하면서 “metric alerts”를 명시하지 않는다면, 로그 기반 탐지를 가정하고 “먼저 Log Analytics workspace”를 떠올리십시오. 또한 일반적인 흐름도 기억하십시오: workspace 생성 -> logs/diagnostics를 workspace로 전송 -> alert rules 생성 -> 응답을 위해 action groups/automation 연결.
contoso.com이라는 Azure Active Directory (Azure AD) 테넌트가 있으며, 이 테넌트에는 User1이라는 사용자가 포함되어 있습니다. 테넌트에 여러 앱을 게시할 계획입니다. 게시된 앱에 대해 User1이 admin consent를 부여할 수 있도록 해야 합니다. 이 목표를 달성하기 위해 User1에게 할당할 수 있는 두 가지 사용자 역할은 무엇입니까? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택에는 1점이 부여됩니다.
Security administrator는 주로 보안 관련 기능(보안 정책, 경고, identity protection 구성, 그리고 범위에 따라 일부 Conditional Access 관련 작업)을 관리합니다. 이 역할은 application lifecycle management를 위한 것이 아니며 일반적으로 application permissions에 대해 테넌트 전체 admin consent를 부여하는 기능을 포함하지 않습니다. 광범위한 권한이 있는 것처럼 들리기 때문에 흔한 오답 유도 선택지이지만, app consent에 필요한 올바른 기능은 아닙니다.
Cloud application administrator는 enterprise applications의 모든 측면을 관리할 수 있으며, 여기에는 app access 및 consent의 구성과 관리가 포함됩니다. 이 역할은 일반적으로 테넌트의 SaaS 앱 및 service principals를 관리하는 데 사용되며, 조직을 대신하여 admin consent를 부여할 수 있습니다. Global Administrator와 비교했을 때 app management에 대해 최소 권한 원칙에 부합하므로 올바른 선택입니다.
Application administrator는 app registrations 및 enterprise applications를 관리할 수 있으며, app permissions에 대해 admin consent를 부여할 수 있는 표준 역할 중 하나입니다. 이 역할은 전체 디렉터리 수준의 관리 권한을 부여하지 않으면서 application management 작업(registration, configuration, permissions/consent operations)을 위해 설계되었습니다. User1이 게시된 앱에 대해 admin consent를 부여할 수 있도록 하는 올바른 역할 할당입니다.
User administrator는 사용자와 그룹을 만들고 관리하며 일부 액세스 관련 작업(예: 암호 재설정 및 사용자 속성)을 처리할 수 있습니다. 그러나 테넌트 수준에서 application consent를 관리하는 데 필요한 권한은 제공하지 않습니다. 관리 역할이기 때문에 그럴듯해 보일 수 있지만, application permission governance보다는 identity objects에 중점을 둡니다.
Application developer(또는 유사한 개발자 중심 권한)는 일반적으로 테넌트 설정(예: 사용자가 애플리케이션을 등록할 수 있는지 여부)에 따라 app registrations를 만들고 관리할 수 있게 합니다. 그러나 권한에 대해 테넌트 전체 admin consent를 제공할 권한은 부여하지 않습니다. 개발자는 권한을 요청할 수는 있지만, 조직에 대해 admin consent를 승인/부여하려면 admin 역할이 필요합니다.
핵심 개념: 이 문제는 Microsoft Entra ID (Azure AD)의 app consent 및 administrative consent를 테스트합니다. 애플리케이션이 테넌트 전체 승인이 필요한 권한(application permissions)을 요청하거나, 사용자가 특정 delegated permissions에 동의할 수 없을 때는 “Admin consent”가 필요합니다. Admin consent를 부여하는 것은 Entra ID 디렉터리 역할에 의해 관리되는 권한 있는 작업입니다. 정답인 이유: User1은 게시된 앱에 대해 admin consent를 부여할 수 있어야 합니다. application permissions에 대해 테넌트 전체 admin consent를 부여할 수 있는 기본 제공 역할은 Application Administrator와 Cloud Application Administrator입니다. 두 역할 모두 app registrations/enterprise applications를 관리하도록 설계되었으며, 조직을 대신하여 admin consent를 부여하는 것을 포함한 consent 관련 작업을 수행할 수 있습니다(테넌트 설정 및 역할 제한 적용). 주요 기능 / 구성 / 모범 사례: - Admin consent는 일반적으로 Enterprise applications(service principals) 또는 App registrations에서 “Grant admin consent for <tenant>”를 사용하여 수행됩니다. - 최소 권한(Azure Well-Architected Framework: Security pillar): 영향 범위를 줄이기 위해 Global Administrator보다 Application Administrator 또는 Cloud Application Administrator를 선호합니다. - 테넌트 전체 “User consent settings” 및 “Admin consent workflow”(Entra ID)를 유의하세요. 이러한 역할이 있더라도 governance 제어(admin consent workflow, Conditional Access, Privileged Identity Management 등)는 consent가 부여되는 방식/시점에 영향을 줄 수 있습니다. - PIM을 사용하여 이러한 역할을 eligible 및 time-bound로 만들고, 로그를 통해 consent 부여를 감사하세요. 일반적인 오해: - Security Administrator는 강력해 보이지만 보안 정책, 경고 및 보안 관련 구성을 중점적으로 다룹니다. 이 역할은 본질적으로 app admin-consent 권한을 부여하지 않습니다. - User Administrator는 사용자/그룹 및 일부 액세스 설정을 관리하지만 app consent는 관리하지 않습니다. - Application Developer는 app registrations를 만들 수는 있지만(설정에 따라) 테넌트 전체 admin consent를 부여할 수는 없습니다. 시험 팁: AZ-500에서는 admin consent가 identity governance 및 application management 기능이라는 점을 기억하세요. enterprise apps 및 app registrations 관리와 가장 직접적으로 연결된 역할(Application Administrator / Cloud Application Administrator)이 정답입니다. Global Administrator가 선택지에 있다면 그것도 가능하지만, 시험에서는 일반적으로 요구 사항을 충족하는 최소 권한 역할을 기대합니다.
네트워크에는 Azure Active Directory (Azure AD)와 동기화되는 adatum.com이라는 이름의 on-premises Active Directory domain이 포함되어 있습니다. Azure AD Connect는 Server1이라는 이름의 domain member server에 설치되어 있습니다. adatum.com domain의 domain administrator가 동기화 옵션을 수정할 수 있도록 해야 합니다. 솔루션은 최소 권한 원칙을 사용해야 합니다. domain administrator에게 어떤 Azure AD role을 할당해야 합니까?
Security administrator는 tenant 전반의 보안 설정, 경고 및 보안 관련 정책을 관리하도록 설계되었습니다. 이 role은 Azure AD Connect 동기화 옵션이나 directory 동기화 동작을 재구성하는 데 필요한 권한을 제공하지 않습니다. 동기화가 보안에 영향을 미치기는 하지만, 이 role의 범위는 hybrid identity 동기화 관리를 위한 것이 아닙니다. 따라서 이 작업에 적절한 role이 아닙니다.
Global administrator는 Azure AD Connect 동기화 옵션을 수정할 수 있는 충분한 권한을 확실히 가지고 있지만, 이 문제에서는 최소 권한 원칙을 위반합니다. 선택지 중 더 낮은 권한의 role이 필요한 작업을 수행할 수 있으므로, Global administrator를 할당하면 tenant 전체에 대한 불필요한 권한을 부여하게 됩니다. Microsoft 시험에서는 더 낮은 권한의 유효한 role이 있으면 일반적으로 그것이 정답입니다. 따라서 여기서 Global administrator는 최선의 답이 아닙니다.
User administrator는 제시된 Azure AD role 중 Azure AD Connect 동기화 옵션 변경에 사용할 수 있는 최소 권한 role입니다. Azure AD Connect 시나리오에서 Microsoft는 구성 작업에 대해 일반적으로 Global administrator 또는 User administrator 자격 증명을 허용하므로, 시험에서 최소 권한을 묻는 경우 User administrator가 선호됩니다. 이 role은 전체 tenant 제어 권한을 부여하지 않고도 관련 directory 수준의 사용자 및 동기화 관련 구성 상호 작용에 충분합니다. 이를 선택하는 것은 관리자가 동기화 옵션을 수정할 수 있도록 하면서도 권한을 최소화해야 한다는 요구 사항에 부합합니다.
핵심 개념: 이 문제는 Azure AD Connect 동기화 옵션을 수정하는 데 필요한 Azure AD 권한에 초점을 맞춥니다. Azure AD Connect는 on-premises에 설치되지만, 특정 구성 변경에는 wizard 또는 재구성 프로세스 중 충분한 directory 권한이 있는 Azure AD 자격 증명이 필요합니다. 정답인 이유: 나열된 role 중에서 User administrator는 Azure AD Connect에서 동기화 옵션을 수정하는 데 사용할 수 있는 최소 권한 role입니다. Azure AD Connect 구성 작업에 대한 Microsoft 문서에서는 특정 동기화 구성 변경에 대해 일반적으로 Global administrator 또는 User administrator 자격 증명을 허용하므로, 요구 사항이 최소 권한을 명시적으로 언급할 때 User administrator가 더 나은 선택입니다. 주요 특징: - Azure AD Connect 구성에는 종종 server에 대한 로컬 administrative 권한과 tenant 측 변경을 위한 Azure AD role이 모두 필요합니다. - Global administrator는 필요한 것보다 더 광범위하므로, 더 낮은 권한의 role로 작업을 완료할 수 있다면 피해야 합니다. - Security administrator는 directory 동기화 구성보다는 보안 정책 및 모니터링에 중점을 둡니다. 일반적인 오해: - 많은 응시자는 Azure AD Connect가 모든 변경에 항상 Global administrator를 요구한다고 가정합니다. Global administrator는 충분한 권한을 가지지만, 항상 최소 권한 옵션은 아닙니다. - 동기화가 identity 보안에 영향을 미치기 때문에 Security administrator가 관련 있어 보일 수 있지만, 이 role은 Azure AD Connect 동기화 설정을 관리하지 않습니다. - User administrator는 작업이 tenant 관련이라는 이유로 간과되기도 하지만, 이 선택지 집합에서는 최소 권한의 유효한 선택입니다. 시험 팁: - 문제에서 최소 권한을 강조하면, 더 낮은 role로 수행할 수 없는 경우가 아니라면 Global administrator는 피하십시오. - 사용자 관리를 담당하는 role, 보안 상태를 관리하는 role, 전체 tenant를 관리하는 role을 구분하십시오. - Azure AD Connect 문제에서는 로컬 server admin 권한이 필요한 작업과 Azure AD directory 권한이 필요한 작업을 주의 깊게 구분하십시오.
Windows Server 2019를 실행하는 VM1 및 VM2라는 두 개의 virtual machine이 포함된 Azure subscription이 있습니다. Azure Automation에서 Update Management를 구현하고 있습니다. Update1이라는 새 update deployment를 만들 계획입니다. Update1이 다음 요구 사항을 충족하도록 해야 합니다. ✑ VM1 및 VM2에 updates를 자동으로 적용합니다. ✑ 새로운 Windows Server 2019 virtual machine을 Update1에 자동으로 추가합니다. Update1에 무엇을 포함해야 합니까?
Assigned membership를 가진 security group은 정적이며 새 virtual machine이 추가될 때마다 수동 관리가 필요합니다. 이는 새로운 Windows Server 2019 virtual machine을 자동으로 추가해야 한다는 요구 사항과 직접적으로 충돌합니다. 또한 Azure Automation Update Management는 deployment targeting 메커니즘으로 Azure AD security group을 사용하지 않습니다. 따라서 이 옵션은 기능적으로도 아키텍처적으로도 적절하지 않습니다.
Dynamic Device membership를 가진 security group은 Azure AD에서 membership를 자동으로 업데이트할 수 있지만, Azure Automation Update Management는 Azure AD device group을 통해 update deployment의 대상을 지정하지 않습니다. group에 VM이 올바르게 포함되어 있더라도 deployment scope는 해당 group에서 결정되지 않습니다. 이는 identity grouping과 operational targeting을 혼동하는 일반적인 사례입니다. 따라서 Update1에 대한 올바른 구성이 아닙니다.
'Dynamic group query'는 이 시나리오에서 Azure Automation Update Management deployment scope를 정의할 때 실제로 사용되는 구성 요소가 아닙니다. 동적 동작은 별도의 'dynamic group query' object를 선택하는 것이 아니라 Kusto query를 기반으로 하는 Log Analytics saved search를 통해 달성됩니다. 표현상 그럴듯하게 들릴 수 있지만, 테스트되는 서비스 기능에 대해서는 부정확합니다. Microsoft 시험에서는 Update Management의 이러한 유형의 동적 포함에 대해 일반적으로 KQL query 옵션이 정답입니다.
Kusto Query Language query는 Log Analytics에서 saved search를 만들어 Azure Automation Update Management deployment를 동적으로 scope 지정하는 데 사용됩니다. Windows Server 2019 machine을 query함으로써 deployment는 즉시 VM1과 VM2를 포함할 수 있고, 향후의 Windows Server 2019 VM도 onboarded된 후 포함할 수 있습니다. 이는 수동 업데이트 없이 현재 대상 지정 요구 사항과 자동 포함 요구 사항을 모두 충족합니다. 또한 machine grouping 및 deployment targeting을 위해 classic Update Management가 Log Analytics와 통합되는 방식과도 일치합니다.
핵심 개념: Azure Automation Update Management는 연결된 Log Analytics workspace에서 Azure, non-Azure 또는 saved search를 사용하여 update deployment의 대상을 지정할 수 있습니다. 운영 체제 버전과 같은 기준에 일치하는 기존 및 미래의 machine을 자동으로 포함하려면 정적 선택이 아니라 query 기반 scope를 사용합니다. 정답인 이유: Kusto Query Language (KQL) query는 Update Management에 등록된 모든 Windows Server 2019 machine을 반환하는 saved search를 정의할 수 있습니다. 이 saved search는 deployment가 실행될 때 평가되므로 현재는 VM1과 VM2가 포함되고, 새로 추가되는 Windows Server 2019 VM도 onboarded되면 자동으로 포함됩니다. 주요 기능: Log Analytics의 KQL 기반 saved search는 OS 세부 정보 및 update management inventory를 포함한 machine 속성에 따라 동적 scoping을 허용합니다. 이를 통해 수동 유지 관리를 피하고 변경되는 server fleet 전반에서 일관된 patching을 지원합니다. 이것은 classic Azure Automation Update Management에서 동적 targeting을 위한 기본 query 메커니즘입니다. 일반적인 오해: Assigned 또는 Dynamic membership 여부와 관계없이 Azure AD security group은 Azure Automation Update Management deployment의 scope를 지정하는 데 사용되지 않습니다. 또 다른 일반적인 실수는 'dynamic group query'가 별도의 지원되는 deployment object라고 생각하는 것입니다. 실제로 동적 scope는 KQL을 사용하는 Log Analytics saved search를 통해 구현됩니다. 시험 팁: 문제에서 Update Management에 미래의 VM을 자동으로 포함하라고 하면 정적 machine 목록이나 Azure AD group이 아니라 query 기반 targeting을 찾으십시오. Azure 시험 문구에서는 Azure Automation Update Management의 동적 포함 시나리오에 대해 saved search와 KQL이 정답인 경우가 많습니다.