50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
Windows 서버의 공유 폴더에 데이터를 저장하는 애플리케이션을 관리하고 있습니다. 공유 폴더를 Azure Storage로 이동해야 합니다. 어떤 유형의 Azure Storage를 사용해야 합니까?
Azure Queue Storage는 애플리케이션 구성 요소 간에 메시지를 저장하고 검색하기 위한 메시징 서비스입니다. 서비스 간 결합을 낮추고 비동기 처리를 처리하는 데 사용됩니다(예: background jobs). 계층적 파일 시스템, 폴더, SMB/NFS 액세스를 제공하지 않으므로 Windows 공유 폴더를 대체할 수 없습니다.
Azure Blob Storage는 이미지, 비디오, 백업, 로그와 같은 비정형 데이터를 위한 object storage입니다. “파일”을 blob으로 저장할 수는 있지만, 액세스는 일반적으로 HTTP/HTTPS 및 APIs/SDK를 통해 이루어지며 SMB로 매핑된 드라이브 형태가 아닙니다. Blob을 사용하려면 보통 애플리케이션 변경 또는 file share 동작을 에뮬레이션하기 위한 추가 계층이 필요합니다.
Azure Files는 표준 파일 프로토콜(SMB, 그리고 지원되는 premium 시나리오에서 NFS)을 사용해 액세스할 수 있는 Azure의 managed file share를 제공합니다. 디렉터리 구조, 파일 잠금 시맨틱을 지원하며, Windows에서 기존 네트워크 공유처럼 마운트할 수 있습니다. 따라서 애플리케이션 변경을 최소화하면서 Windows 서버의 공유 폴더를 Azure Storage로 이동하는 데 올바른 선택입니다.
Azure Table Storage는 반정형 데이터를 위한 NoSQL key-value/column-family 스타일 저장소로, 대규모와 partition 및 row key 기반의 단순 쿼리에 최적화되어 있습니다. 파일 저장용으로 설계되지 않았고, 폴더나 file share 액세스를 제공하지 않으며, Windows 공유 폴더의 대체로 사용할 수 없습니다.
핵심 개념: 이 문제는 Windows 서버의 공유 폴더를 가장 잘 대체하는 Azure Storage 서비스를 묻습니다. 공유 폴더는 SMB/NFS 액세스, 디렉터리/파일 형태의 시맨틱, 그리고 object storage가 아니라 file share를 기대하는 기존 애플리케이션과의 호환성을 의미합니다. 정답이 맞는 이유: Azure Files(Azure Storage file service)는 클라우드에서 완전 관리형 file share를 제공하도록 설계되었으며, SMB 프로토콜(그리고 지원되는 시나리오에서 premium file share의 경우 NFS)로 액세스할 수 있습니다. 따라서 Windows file share에 가장 가까운 클라우드 동등물입니다. 표준 file API를 사용해 파일을 읽고/쓰는 애플리케이션을 lift-and-shift할 수 있고, Windows에서 드라이브 문자를 매핑하며, object API를 사용하도록 애플리케이션을 재작성하지 않고도 폴더 구조를 유지할 수 있습니다. 주요 기능 및 모범 사례: Azure Files는 전송 중 암호화를 포함한 SMB 3.x를 지원하고, 액세스 제어를 위해 identity와 통합됩니다(storage account keys/SAS, 그리고 엔터프라이즈 시나리오에서는 SMB 액세스를 위한 Active Directory Domain Services 또는 Azure AD DS를 통한 identity-based auth). 또한 point-in-time 복구를 위한 snapshots, soft delete, backup 통합을 지원합니다. 성능에 민감한 워크로드의 경우 Premium file shares(SSD 기반)를 고려하고, 적절한 provisioned capacity/IOPS를 선택하세요. Azure Well-Architected 관점에서 Azure Files는 운영 우수성(managed service), 신뢰성(LRS/ZRS/GRS 같은 redundant storage 옵션), 보안(network restrictions, private endpoints, encryption)을 향상시킵니다. 흔한 오해: Blob storage는 “파일”을 저장하기 때문에 자주 선택되지만, 이는 HTTP/SDK를 통해 액세스하는 object storage이며 추가 도구 없이는 SMB share처럼 동작하지 않습니다. Queues와 tables는 각각 메시징과 NoSQL key-value 저장에 사용되는 비파일 서비스입니다. 시험 팁: “shared folder”, “SMB”, “lift-and-shift file server”, “map a network drive”가 보이면 Azure Files를 떠올리세요. “unstructured objects”, “HTTP access”, “data lake”, “static content”가 보이면 Blob을 떠올리세요. 액세스 패턴(file share vs object vs message vs NoSQL)을 storage 유형에 맞추세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Azure SQL 데이터베이스를 쿼리하는 데 사용할 수 있는 명령줄 도구는 무엇입니까?
sqlcmd는 SQL Server 및 Azure SQL Database에 연결하여 T-SQL 쿼리 또는 스크립트를 실행하도록 설계된 명령줄 유틸리티입니다. 대화형 쿼리, .sql 파일 실행, 자동화를 위한 종료 코드 반환을 지원합니다. Azure SQL Database는 T-SQL과 호환되므로, 명령줄에서 “쿼리”하는 표준적이고 시험에 적합한 선택지입니다.
bcp(Bulk Copy Program)는 SQL Server/Azure SQL Database와 데이터 파일 간에 고성능 대량 데이터 가져오기/내보내기를 수행하는 명령줄 도구입니다. 내보낼 행을 정의하기 위해 쿼리를 실행할 수는 있지만, 주된 목적은 대화형 또는 범용 쿼리가 아니라 데이터의 대량 이동입니다. 시험 관점에서 bcp는 쿼리보다는 데이터 로딩/언로딩에 해당합니다.
azdata는 Azure 데이터 서비스 관리 시나리오(예: SQL Managed Instance 및 Azure Arc-enabled data services)와 연관된 명령줄 도구이며 일부 운영 워크플로와 통합됩니다. DP-900 맥락에서 Azure SQL Database를 T-SQL로 단순히 쿼리하는 가장 일반적이거나 정석적인 도구는 아니므로, 여기서는 오답 유도 선택지입니다.
Azure CLI는 Azure SQL 논리 서버 생성, 방화벽 규칙 구성, 정책 설정 등 프로비저닝/구성/네트워킹/ID 같은 Azure 리소스를 관리하는 데 사용됩니다. Azure SQL Database를 위한 기본 T-SQL 쿼리 클라이언트는 아닙니다. SQL 쿼리를 실행하려면 Azure CLI보다는 sqlcmd 같은 도구나 클라이언트 라이브러리를 사용합니다.
핵심 개념: 이 문제는 명령줄에서 Azure SQL Database(관리형 PaaS 관계형 데이터베이스)와 상호작용하는 방법을 평가합니다. DP-900에서는 Azure의 관계형 데이터베이스에 연결하고 T-SQL 쿼리를 실행하는 데 사용되는 일반적인 도구를 식별할 수 있어야 합니다. 정답이 맞는 이유: sqlcmd는 SQL Server 및 Azure SQL Database를 위한 Microsoft의 대표적인 명령줄 쿼리 유틸리티입니다. 연결 문자열(서버 이름, 데이터베이스, 인증)을 사용해 연결하며, 임시 T-SQL 문을 실행하거나 파일의 스크립트를 실행할 수 있습니다. Azure SQL Database는 T-SQL 계층에서 SQL Server와 호환되므로, sqlcmd는 터미널과 자동화 파이프라인에서 이를 쿼리하는 직접적이고 널리 지원되는 방법입니다. 주요 기능 및 모범 사례: sqlcmd는 대화형 세션, .sql 파일 실행, 변수 치환, 자동화를 위한 오류 처리/종료 코드, 출력 형식을 지원합니다. CI/CD 및 운영 런북(예: 스키마 검사 또는 배포 후 검증 실행)에 적합합니다. Azure SQL Database의 경우 일반적으로 <servername>.database.windows.net에 연결하며, 보안 정책에 따라 Azure AD 인증 또는 SQL 인증을 사용합니다. Azure Well-Architected Framework 관점(보안 및 운영 우수성)에서는 가능하면 Azure AD 인증을 선호하고, 스크립트에 비밀번호를 포함하지 않으며, 자동화 시 managed identities 또는 안전한 비밀 저장소(예: Key Vault)를 사용하는 것이 좋습니다. 흔한 오해: bcp도 SQL Server 도구이지만, 주로 데이터의 대량 가져오기/내보내기를 위한 도구이며 일반적인 쿼리 용도가 아닙니다. azdata는 데이터 서비스 시나리오(특히 SQL Managed Instance 및 Azure Arc-enabled data services)에 초점을 둔 비교적 새로운 CLI로, 기초 문제에서 Azure SQL Database의 표준 “쿼리 도구”로 보지는 않습니다. Azure CLI는 Azure 리소스를 관리(서버 생성, 방화벽 규칙 설정)할 수 있지만, T-SQL 쿼리 클라이언트는 아닙니다. 시험 팁: DP-900에서는 도구를 주요 목적에 매핑하세요: sqlcmd = T-SQL 쿼리/스크립트 실행; bcp = 대량 데이터 복사; Azure CLI = Azure 리소스 관리; azdata = 데이터 플랫폼 관리 시나리오. 동사가 “query”로 SQL 데이터베이스를 묻는다면, sqlcmd가 가장 직접적이고 기대되는 정답입니다.
HOTSPOT - 다음 각 문장에 대해 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure Data Studio를 사용하여 Microsoft SQL Server big data cluster를 쿼리할 수 있습니다.
예. Azure Data Studio는 Microsoft SQL Server big data cluster(BDC)를 쿼리하는 데 사용할 수 있습니다. BDC는 SQL Server를 기반으로 구축되며, 표준 SQL Server 연결을 사용해 쿼리할 수 있는 SQL Server endpoint를 노출합니다. Azure Data Studio는 SQL Server instance에 연결하는 것을 지원하며, 과거에는 extension을 통해 BDC에 대한 추가 경험(예: cluster 구성 요소 관리 및 쿼리)을 제공하기도 했습니다. “아니요”가 틀린 이유: ADS는 Azure 전용 database로만 제한되지 않으며, SQL Server 계열 workload를 위한 범용 SQL client입니다. SQL endpoint에 도달할 수만 있다면(네트워크 액세스, firewall 규칙, authentication), ADS로 해당 endpoint에 대해 쿼리를 실행할 수 있습니다. 실제로는 cluster에 적절한 SQL Server endpoint로의 연결을 구성한 다음, SQL Server에서처럼 T-SQL 쿼리를 실행하면 됩니다.
Microsoft SQL Server Management Studio (SSMS)를 사용하여 Azure Synapse Analytics 데이터 웨어하우스를 쿼리할 수 있습니다.
예. SQL Server Management Studio (SSMS)는 Azure Synapse Analytics 데이터 웨어하우스(dedicated SQL pool)를 쿼리할 수 있습니다. Synapse dedicated SQL pool은 Tabular Data Stream (TDS) 프로토콜을 사용하는 SQL endpoint를 노출하며, 이는 SQL Server에서 사용하는 핵심 프로토콜과 동일합니다. 이러한 호환성 때문에 SSMS는 연결, 인증(구성에 따라 SQL auth/Azure AD), 그리고 T-SQL 쿼리 실행이 가능합니다. “아니요”가 틀린 이유: Synapse는 SQL Server와 동일한 제품은 아니지만, dedicated SQL pool은 많은 관리 및 쿼리 작업에서 SQL Server와의 호환성을 의도적으로 제공합니다. 시험에서는 네트워킹과 권한이 올바르게 구성되어 있다는 전제하에, SSMS를 SQL 기반 Azure 서비스(Azure SQL Database, SQL Managed Instance, Synapse dedicated SQL pool)에 사용할 수 있는 유효한 클라이언트 도구로 인지하는지를 묻습니다.
MySQL Workbench를 사용하여 Azure Database for MariaDB 데이터베이스에 대해 쿼리를 실행할 수 있습니다.
예. MySQL Workbench는 MariaDB가 MySQL과 호환되며 Azure Database for MariaDB가 표준 MySQL 클라이언트 연결을 지원하므로 Azure Database for MariaDB에 대해 쿼리를 실행할 수 있습니다. MySQL Workbench는 MySQL protocol을 사용하며, 쿼리 실행, 스키마 관리, 기본 관리 작업을 위해 MariaDB 서버에 연결할 수 있습니다. “아니요”가 틀린 이유: MariaDB는 MySQL의 별도 포크이지만, MySQL 클라이언트 및 도구와의 호환성을 목표로 설계되었습니다. Azure에서는 여전히 연결을 위한 사전 요구 사항을 충족해야 합니다. 즉, 서버 firewall rules에서 클라이언트 IP를 허용하고, SSL/TLS 설정이 서버 요구 사항과 일치하며, 올바른 hostname/port(일반적으로 3306) 및 자격 증명을 사용해야 합니다. 이러한 조건이 갖춰지면 Workbench는 적절한 쿼리 도구입니다.
Azure SQL database를 문제 해결하기 위해 관리자가 사용할 SQL 쿼리 세트를 작성하고 있습니다. SQL notebook에 문서와 쿼리 결과를 포함해야 합니다. 무엇을 사용해야 합니까?
Microsoft SQL Server Management Studio (SSMS)는 SQL Server 및 Azure SQL Database의 주요 관리 도구로, 쿼리 창, Object Explorer, 관리 기능을 제공합니다. 그러나 SSMS는 Markdown 문서와 실행 가능한 셀 및 포함된 결과를 단일 notebook 아티팩트로 결합하는 기본 SQL notebook 인터페이스를 제공하지 않습니다. 대화형 문제 해결에는 훌륭하지만 notebook 스타일 문서화에는 적합하지 않습니다.
Azure Data Studio는 Markdown 문서와 실행 가능한 T-SQL 셀 및 저장된 출력을 혼합하는 SQL notebooks를 지원하므로 정답입니다. 관리자는 쿼리 결과를 notebook에 직접 포함하여 반복 가능한 문제 해결 runbook을 만들 수 있습니다. 크로스 플랫폼이며 현대적 데이터 워크플로에 일반적으로 사용되므로, 문제에서 명시적으로 “SQL notebook”을 언급할 때 Microsoft의 대표 도구입니다.
Azure CLI는 주로 Azure 리소스를 프로비저닝하고 관리하는 데 사용됩니다(예: 서버 생성, firewall rules 구성, identity 관리). 일부 데이터베이스 관련 명령을 실행하고 작업을 자동화할 수는 있지만, SQL notebooks를 작성하거나 문서와 쿼리 결과를 함께 포함하도록 설계되지 않았습니다. 문제에서 요구하는 통합 notebook UI와 풍부한 문서 경험이 없습니다.
Azure PowerShell도 cmdlets를 통해 Azure 리소스를 자동화하고 관리하는 데 초점이 맞춰져 있습니다. 운영 작업(예: Azure SQL 설정 구성, 데이터 내보내기, 리소스 속성 관리)에 도움이 될 수 있지만, 문서와 쿼리 결과를 포함하는 notebook 작성 도구는 아닙니다. PowerShell은 일부 notebook 플랫폼에서 사용할 수 있지만, 여기서 언급된 Microsoft SQL notebook 기능은 Azure Data Studio를 의미합니다.
핵심 개념: 이 문제는 Azure SQL Database로 작업하기 위한 도구에 대한 지식을 평가하며, 특히 서술형 문서(Markdown)와 실행 가능한 쿼리 셀 및 포함된 결과를 결합하는 SQL notebook을 만들고 사용하는 능력을 묻습니다. Azure 환경에서 이러한 기능은 문제 해결, 운영 runbook, 반복 가능한 조사에 사용되는 notebook 스타일 경험과 연관됩니다. 정답인 이유: Azure Data Studio는 기본 제공 SQL notebooks를 제공하는 Microsoft 도구입니다. Azure Data Studio에서 관리자는 텍스트, 이미지, 코드 셀(T-SQL, 그리고 일부 컨텍스트에서는 다른 kernel)을 포함하는 notebook을 만들고 Azure SQL Database에 대해 쿼리를 실행하여 결과를 notebook에 직접 캡처하고 저장할 수 있습니다. 이는 수행한 단계, 실행한 쿼리, 관찰한 출력이 문서화된 단일 공유 아티팩트를 만들기 때문에 문제 해결에 이상적입니다. 주요 기능 및 모범 사례: Azure Data Studio notebooks는 문서화를 위한 Markdown, 매개변수화되고 반복 가능한 쿼리 실행, 그리고 notebook과 함께 출력 저장을 지원합니다. 이는 표준화된 runbook, 일관된 문제 해결 절차, 더 쉬운 지식 이전을 가능하게 하여 운영 우수성(Azure Well-Architected Framework)과 부합합니다. Notebooks는 source control(예: Git)에 저장하여 문제 해결 스크립트와 증거를 버전 관리할 수 있습니다. Azure Data Studio는 확장과의 통합도 제공하며 Azure SQL Database에 안전하게 연결하는 것도 지원합니다. 흔한 오해: SSMS는 SQL 관리에 흔히 사용되지만, 문서와 결과를 단일 notebook 파일에 포함하는 기본 notebook 경험을 제공하지 않습니다. Azure CLI와 Azure PowerShell은 자동화 및 리소스 관리에 매우 유용하지만, 풍부한 문서와 함께 쿼리 결과를 포함하는 notebook 작성 도구는 아닙니다. 시험 팁: DP-900에서는 다음 매핑을 기억하세요: SSMS는 SQL Server/Azure SQL 관리용 전통적인 GUI이고, Azure Data Studio는 notebooks와 현대적 워크플로를 제공하는 크로스 플랫폼 도구입니다. “SQL notebook”, “Markdown + query cells”, “embed results”를 보면 기대 정답은 Azure Data Studio입니다.
HOTSPOT - 문장을 완성하려면 답안 영역에서 적절한 옵션을 선택하세요. 핫 영역:
Transparent Data Encryption (TDE)는 ______을(를) 암호화합니다.
정답: C. TDE는 저장 중 데이터를 보호하기 위해 database를 암호화합니다. TDE는 database data 및 log files가 storage에 기록되고 storage에서 읽힐 때 실시간 암호화 및 복호화를 수행합니다. 주요 목적은 누군가가 기본 database files 또는 backups를 획득하여 database engine 외부에서 이를 읽는 위험을 완화하는 것입니다. 이는 encryption at rest이며 일반적으로 database별로 활성화됩니다. 다른 선택지가 틀린 이유: - A: Column-level 보호는 TDE가 아닙니다. 이는 Always Encrypted (client-side) 또는 column-level encryption 기능과 같은 접근 방식을 설명합니다. - B: 전송 중 queries/results 보호는 TDE가 아니라 TLS/SSL (connection strings에서 Encrypt=True)로 처리됩니다. - D: TDE는 “server encryption”이 아닙니다. keys/certificates는 server 수준에서 관리될 수 있지만(특히 SQL Server에서), 암호화 범위는 전체 server가 아니라 database files입니다.
귀사는 대량의 JSON 데이터를 기록할 애플리케이션을 설계하고 있으며, 애플리케이션에서 정의한 스키마를 사용할 예정입니다. 어떤 유형의 데이터 저장소를 사용해야 합니까?
Columnar store(column-family 또는 columnar analytics format)는 분석 워크로드에 최적화되어 있습니다. 대규모 데이터셋 스캔, 집계, 높은 압축에 적합합니다. 데이터 웨어하우스 및 OLAP 시나리오(예: Azure Synapse columnstore)에서 흔합니다. 구조가 진화하는 JSON을 대량으로 운영 환경에서 쓰는 경우에는 일반적으로 최적의 선택이 아니며, 이 경우에는 낮은 지연의 point read/write와 유연한 스키마가 필요합니다.
Key/value store는 접근이 주로 단일 key로 이루어질 때 매우 빠른 read/write에 강점이 있습니다(예: caching, session state, 단순 조회). JSON을 value로 저장할 수는 있지만, JSON 내부에 대한 querying 및 indexing은 보통 document database에 비해 제한적이거나 없을 수 있습니다. 애플리케이션 정의 스키마로 JSON document를 저장하고 쿼리해야 하는 애플리케이션이라면, 일반적으로 document store가 의도된 모델입니다.
Document store는 JSON 및 기타 반정형 데이터에 맞게 목적에 맞게 설계되었습니다. 유연한 애플리케이션 정의 스키마를 지원하고, 필드가 서로 다른 document를 허용하며, document 속성에 대한 풍부한 쿼리 및 indexing을 제공합니다. 또한 높은 쓰기 볼륨을 위해 수평 확장이 가능합니다(예: Azure Cosmos DB for NoSQL/MongoDB API). 이는 애플리케이션이 제어하는 스키마로 대량의 JSON 쓰기가 필요하다는 요구 사항과 일치합니다.
Graph database는 관계(nodes/edges)를 모델링하고 “friends of friends” 또는 dependency chain과 같은 traversal을 수행하는 관계 쿼리에 최적화되어 있습니다. graph database도 JSON처럼 보이는 속성을 저장할 수는 있지만, 핵심 가치는 관계 중심 querying이며, 주요 워크로드가 대량의 JSON document ingest인 경우에는 적합하지 않습니다. 접근 패턴에서 관계와 traversal이 지배적일 때 graph를 사용하세요.
핵심 개념: 이 문제는 반정형 JSON과 애플리케이션에서 정의한 스키마에 적합한 비관계형(NoSQL) 데이터 모델을 선택하는지를 평가합니다. Azure fundamentals 관점에서, 유연한 필드를 가진 JSON 데이터는 document 데이터 저장소(예: Azure Cosmos DB for NoSQL 또는 MongoDB API)에 부합합니다. 정답이 맞는 이유: document store는 높은 쓰기 볼륨에서 JSON document를 효율적으로 저장하고 쿼리하도록 설계되었습니다. “애플리케이션에서 정의한 스키마”는 관계형 시스템에서 흔한 엄격하고 중앙에서 강제되는 스키마보다는 schema-on-read(앱이 어떤 필드가 존재하는지와 해석 방식을 제어)를 의미합니다. document database는 JSON을 네이티브로 저장하고, 속성에 대한 indexing을 지원하며, 동일한 collection/container 내의 document가 서로 다른 형태를 가질 수 있어 스키마가 진화하는 경우에 이상적입니다. 주요 기능 및 모범 사례: Azure Cosmos DB에서는 container에 items(document)로 데이터를 모델링하고, partition key를 선택해 쓰기를 수평 확장하며, throughput(RU/s)을 프로비저닝하거나 autoscale을 사용해 스파이크를 처리합니다. 높은 ingest 워크로드에서는 hot partition을 피하기 위해 적절한 partitioning이 중요합니다. Cosmos DB는 또한 strong부터 eventual까지 구성 가능한 consistency level을 지원하여 지연 시간과 정확성의 균형을 맞출 수 있으며, 이는 Azure Well-Architected Framework의 performance efficiency 및 reliability pillar와 정렬됩니다. 모든 필드를 indexing할 필요가 없다면 indexing policy를 조정해 write cost를 줄일 수 있습니다. 흔한 오해: key/value store도 높은 처리량을 처리할 수 있지만, 일반적으로 key 기반의 단순 조회에 최적화되어 있으며 document store에 비해 중첩된 JSON에 대한 쿼리 기능이 제한적입니다. columnar store는 분석/OLAP 및 읽기 중심 스캔을 위한 압축에 적합하며, 고속 운영 쓰기에는 적합하지 않습니다. graph store는 관계 중심 쿼리(탐색)에 적합하며, 주로 대량 JSON ingest를 위한 것은 아닙니다. 시험 팁: “JSON”, “semi-structured”, “flexible schema”, “schema defined by the application”을 보면 document database를 떠올리세요. “relationships and traversals”를 보면 graph를 떠올리세요. “simple get/put by key”를 보면 key/value를 떠올리세요. “analytics, aggregations over large datasets”를 보면 columnar/warehouse를 떠올리세요.
Windows에서 실행되며 매핑된 드라이브에 대한 액세스가 필요한 애플리케이션이 있습니다. 어떤 Azure 서비스를 사용해야 합니까?
Azure Files가 정답인 이유는 SMB(및 선택적으로 NFS)를 사용한 관리형 파일 공유를 제공하기 때문입니다. Windows 시스템은 Azure 파일 공유를 드라이브 문자로 매핑할 수 있어, 기존 네트워크 공유를 기대하는 레거시 애플리케이션 요구 사항을 충족합니다. 전송 중 암호화, 스냅샷을 지원하며 AD DS/Azure AD DS와 통합해 Kerberos 인증을 사용할 수 있어, 일반적인 엔터프라이즈 Windows 시나리오에 부합합니다.
Azure Blob storage는 REST API(HTTP/HTTPS) 및 SDK를 통해 액세스하는 오브젝트 스토리지로, 이미지, 로그, 백업 같은 비정형 데이터에 최적화되어 있습니다. 도구나 사용자 지정 코드를 사용해 파일 액세스를 흉내 낼 수는 있지만, 네이티브 SMB 파일 공유가 아니며 매핑된 드라이브 문자가 필요한 애플리케이션을 위해 Windows 드라이브로 매핑하도록 설계되지 않았습니다.
Azure Cosmos DB는 지연 시간이 짧고 확장 가능한 데이터 워크로드(문서, 키-값, 그래프, 컬럼 패밀리)를 위한 전 세계 분산 NoSQL 데이터베이스 서비스입니다. 구조화/반구조화 데이터를 저장하며 데이터베이스 API를 통해 액세스하지, 파일 시스템으로 액세스하지 않습니다. 네트워크 드라이브로 매핑할 수 없고 SMB 파일 공유 기능을 제공하지 않습니다.
Azure Table storage(또는 Storage accounts의 Azure Tables)는 대규모 구조화된 비관계형 데이터를 위한 NoSQL 키-값 저장소입니다. REST API/SDK를 통해 액세스하며 엔터티와 속성을 위해 설계되었지 파일을 위한 것이 아닙니다. SMB 공유를 제공하지 않으며 Windows 매핑 드라이브 요구 사항을 충족할 수 없습니다.
핵심 개념: 이 문제는 Windows 앱이 매핑된 드라이브 문자로 액세스할 수 있는 기존 파일 공유를 지원하는 Azure 스토리지 서비스를 묻습니다. Azure에서 해당 기능은 SMB(및 선택적으로 NFS) 파일 공유를 노출하는 Azure Files에서 제공합니다. 정답인 이유: “매핑된 드라이브에 대한 액세스가 필요”한 Windows 애플리케이션은 일반적으로 표준 Windows 네트워킹을 사용해 드라이브(예: Z:)로 매핑할 수 있는 SMB 파일 공유를 기대합니다. Azure Files는 SMB 3.x를 통해 액세스 가능한 완전 관리형 파일 공유를 제공하므로, Windows 클라이언트, Windows Server 또는 Azure VM에서 UNC 경로(예: \\storageaccount.file.core.windows.net\sharename)와 자격 증명(스토리지 계정 키 또는 구성에 따라 Azure AD DS/AD DS 통합)을 사용해 공유를 매핑할 수 있습니다. 이는 요구 사항과 직접적으로 일치합니다. 주요 기능 및 모범 사례: Azure Files는 전송 중 SMB 암호화, 스냅샷, 백업 통합을 지원합니다. 엔터프라이즈 ID의 경우 Azure Files는 Kerberos 기반 인증을 위해 온-프레미스 AD DS 또는 Azure AD DS와 통합할 수 있습니다(스토리지 키를 포함하지 않기 위해 유용). 성능과 비용은 스토리지 계정 유형/티어(Standard vs Premium FileStorage) 및 공유 프로비저닝에 따라 달라집니다. Azure Well-Architected Framework 관점에서 Azure Files는 운영 우수성(관리형 서비스), 안정성(LRS/ZRS/GRS 같은 중복 옵션을 갖춘 내구성 있는 스토리지), 보안(SMB 암호화, ID 통합)을 향상시킵니다. 흔한 오해: Blob storage는 종종 “파일”로 오해되지만, 이는 HTTP/HTTPS API로 액세스하는 오브젝트 스토리지이며 Windows 앱을 위한 네이티브 매핑 드라이브가 아닙니다. Cosmos DB와 Table storage는 NoSQL 데이터 저장소이지 파일 공유가 아닙니다. 시험 팁: “mapped drive”, “SMB”, “file share”, “lift-and-shift Windows app”, “shared folder”가 보이면 Azure Files를 떠올리세요. “unstructured objects”, “HTTP”, “images/videos”가 보이면 Blob을 떠올리세요. “globally distributed NoSQL”이 보이면 Cosmos DB를 떠올리세요. “key-value/NoSQL table”이 보이면 Table storage를 떠올리세요.
언제 Azure Resource Manager 템플릿을 사용할 수 있나요?
정답입니다. ARM templates는 Azure 리소스를 선언적으로 정의하며, 여러 종속 리소스를 하나의 반복 가능한 배포로 배포할 수 있습니다. dependency 관리(dependsOn), 환경 차이를 위한 parameters, idempotent 재배포를 지원합니다. 이는 핵심 Infrastructure as Code 사용 사례로, dev/test/prod 전반에서 동일한 데이터 플랫폼 스택(예: storage + database + networking)을 일관되게 생성하는 데 해당합니다.
오답입니다. 멀티 테넌트 배포를 위한 Azure 정책 적용은 Azure Policy(및 policy initiatives), management groups, RBAC로 처리되는 governance 시나리오입니다. ARM templates로 policy definitions/assignments를 리소스로 배포할 수는 있지만, 설명된 목적(멀티 테넌트 governance를 위한 정책 적용)은 시험 문맥에서 ARM templates를 주로 “사용하는” 용도가 아닙니다.
오답입니다. Azure 구독 프로비저닝은 일반적으로 Azure billing/tenant 프로세스, subscription creation APIs, 또는 enterprise enrollment 워크플로를 통해 수행되며, 표준 ARM template 배포로 수행되지 않습니다. ARM templates는 기존 구독 내에서 리소스를 배포합니다(또는 특정 리소스 유형에 대해 management group/tenant scope에서 배포 가능). 하지만 “구독을 프로비저닝”하는 것은 전형적인 ARM template 사용 사례가 아닙니다.
오답입니다. Azure portal에서 관리자/개발자가 배포할 수 있는 서비스와 기능을 제어하는 것은 주로 Azure Policy(deny/allowed SKUs/locations), RBAC, 그리고 때로는 management group governance로 달성합니다. ARM templates는 배포를 표준화할 수는 있지만, portal 선택지를 직접 제한하지는 않으며, 그 역할은 governance 제어가 수행합니다.
핵심 개념: Azure Resource Manager (ARM) templates는 JSON에서 Azure 리소스를 선언적으로 정의하는 Infrastructure as Code (IaC) 메커니즘입니다. 이는 Azure Resource Manager를 통해 배포되며, Azure Resource Manager는 Azure 리소스를 생성, 업데이트, 삭제하기 위한 control plane입니다. 정답이 맞는 이유: ARM template은 상호 의존적인 Azure 리소스 그룹을 반복 가능하고 일관된 방식으로 자동 생성하려는 경우에 사용합니다. 템플릿은 여러 리소스(예: storage account, SQL server, database, networking, role assignments)와 그들 간의 관계를 정의할 수 있습니다. ARM은 dependency ordering(implicit dependencies 및 dependsOn 속성)을 처리하여 리소스가 올바른 순서로 배포되도록 합니다. 이는 환경(dev/test/prod) 전반에서 반복 가능한 배포를 지원하며, Operational Excellence(자동화, 반복 가능성) 및 Reliability(일관된 구성은 drift를 줄임) 같은 Azure Well-Architected Framework 원칙과도 부합합니다. 주요 기능 및 모범 사례: ARM templates는 parameters(환경별 값), variables(재사용), outputs(리소스 ID/connection strings 반환), conditions(필요할 때만 리소스 배포), linked templates 또는 template specs를 통한 모듈화를 지원합니다. 배포는 idempotent합니다. 즉, 동일한 템플릿을 다시 배포하면 환경이 선언된 상태로 수렴합니다. 템플릿은 CI/CD(Azure DevOps/GitHub Actions)와 통합되며, 배포 전에 validate/what-if 분석을 수행할 수 있습니다. 흔한 오해: ARM templates는 종종 governance 도구와 혼동됩니다. Azure Policy는 전체 리소스 세트를 정의하고 배포하는 것이 아니라 규칙과 컴플라이언스를 강제하는 데 사용됩니다. Azure Blueprints(현재는 대체로 template specs + policy initiatives 및 기타 도구로 대체됨)는 governance 아티팩트를 패키징했지만, 이는 ARM의 주요 목적(리소스 배포)과는 다릅니다. 또한 ARM templates는 시험에서 말하는 일반적인 의미로 “구독을 프로비저닝”하지 않습니다. 구독 생성은 Azure billing/tenant 프로세스 및 management group governance를 통해 처리되며, 표준 ARM 리소스 배포가 아닙니다. 시험 팁: 문제에 “repeatable deployments”, “infrastructure as code”, “리소스 세트를 함께 배포”, “환경 생성 자동화”가 언급되면 ARM templates(또는 ARM으로 컴파일되는 Bicep)를 떠올리세요. “배포 가능한 항목 제한” 또는 “표준 강제”가 언급되면 Azure Policy/RBAC를 떠올리세요. “portal marketplace 제한”이 언급되면 ARM templates가 아니라 Azure Policy/Blueprint 유사 governance를 떠올리세요. 도메인 참고: ARM templates는 데이터 서비스는 아니지만, DP-900에는 데이터 솔루션을 지원하는 기초 Azure 개념(데이터 워크로드를 위해 리소스를 일관되게 배포하는 방법 포함)이 포함됩니다.
Azure Storage account를 생성해야 합니다. account의 데이터는 Azure region 외부로 자동으로 복제되어야 합니다. storage account에 사용할 수 있는 복제 유형 두 가지는 무엇입니까? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택은 1점입니다.
zone-redundant storage (ZRS)는 동일한 Azure region 내 여러 availability zone에 걸쳐 데이터를 동기적으로 복제합니다. zonal outage에 대한 복원력을 향상시키지만, 다른 region으로 복제하지는 않습니다. 따라서 Azure region 외부로 자동 복제해야 한다는 요구 사항을 충족하지 않습니다. ZRS는 geo-replication 옵션이 아니라 “region 내” 중복성 옵션입니다.
read-access geo-redundant storage (RA-GRS)는 데이터를 secondary region(Azure paired region)으로 비동기적으로 복제하며, secondary region에 read-only endpoint도 제공합니다. 이는 primary region 외부로의 자동 복제 요구 사항을 충족하고, 정상 운영 중에도 secondary에서 읽을 수 있는 기능을 추가합니다. 일반적으로 DR과 read-scale 시나리오에 사용됩니다.
locally-redundant storage (LRS)는 단일 Azure region의 단일 datacenter 내에서 데이터를 복제합니다(여러 사본이지만 로컬에 한정). 로컬 하드웨어 장애로부터는 보호하지만 datacenter 전체 또는 regional outage로부터는 보호하지 못합니다. 다른 region으로 복제하지 않으므로 Azure region 외부로 자동 복제해야 한다는 요구 사항을 충족하지 못합니다.
geo-redundant storage (GRS)는 primary region에서 secondary region(Azure paired region)으로 데이터를 비동기적으로 복제합니다. 이는 regional outage에 대한 보호를 제공하며, 데이터가 Azure region 외부로 자동 복제되어야 한다는 요구 사항을 충족합니다. RA-GRS와 달리 GRS는 failover가 발생하지 않는 한 secondary endpoint에 대한 read access를 제공하지 않습니다.
핵심 개념: 이 문제는 Azure Storage 중복성 옵션, 특히 데이터를 보조 Azure region으로 자동 복제(geo-replication)하는 옵션을 묻습니다. Azure Storage는 LRS, ZRS, GRS, RA-GRS(그리고 여기에는 나열되지 않은 GZRS/RA-GZRS 같은 변형) 등 여러 중복성 모델을 제공합니다. 이 중 “geo” 옵션만 paired region으로 복제합니다. 정답이 맞는 이유: geo-redundant storage (GRS)와 read-access geo-redundant storage (RA-GRS)는 모두 primary region의 데이터를 secondary region(일반적으로 Azure paired region)으로 비동기적으로 복제합니다. 이는 데이터가 Azure region 외부로 자동 복제되어야 한다는 요구 사항을 충족합니다. GRS는 재해 복구를 위한 cross-region 복제를 제공하고, RA-GRS는 primary region이 정상인 경우에도 secondary endpoint에서 읽을 수 있는 기능을 추가로 제공합니다. 주요 기능, 구성 및 모범 사례: - GRS/RA-GRS는 비동기 복제를 사용하므로 잠재적인 RPO가 존재합니다(일부 최신 쓰기 작업이 아직 secondary에 없을 수 있음). - secondary region은 사용자가 선택할 수 없으며 Azure region pairing에 의해 결정됩니다. - RA-GRS는 secondary read-only endpoint를 노출하며, read-heavy workload 및 향상된 read availability에 유용합니다. - Azure Well-Architected Framework 관점에서 이러한 옵션은 주로 Reliability pillar(복원력 및 재해 복구)를 지원합니다. 단일 datacenter/zone을 넘어서는 regional 재해 복구가 비즈니스 요구 사항인 경우 사용합니다. 흔한 오해: - ZRS는 “더 중복적”으로 들리지만, 동일 region 내 availability zone 간에만 복제하며 region 외부로는 복제하지 않습니다. - LRS는 기본값이자 가장 저렴하지만, 단일 datacenter 내의 로컬 하드웨어 장애에 대해서만 보호합니다. 시험 팁: 문제에서 “Azure region 외부” 또는 “다른 region으로”라고 하면 GRS/RA-GRS(또는 선택지에 있으면 GZRS/RA-GZRS)를 찾으십시오. “동일 region 내에서 zone 간”이라고 하면 ZRS입니다. “datacenter 내”라고 하면 LRS입니다.
DRAG DROP - 회사에서 extract, load, transform(ELT) 프로세스를 사용하여 customer relationship management(CRM) 시스템의 데이터를 data warehouse로 로드할 계획입니다. ELT 프로세스의 각 단계에서 데이터 처리는 어디에서 발생합니까? 답하려면 적절한 위치를 올바른 단계로 끌어다 놓으십시오. 각 위치는 한 번, 여러 번 또는 전혀 사용하지 않을 수 있습니다. 콘텐츠를 보려면 창 사이의 분할 막대를 끌거나 스크롤해야 할 수 있습니다. 참고: 각 정답 선택은 1점입니다. 선택 및 배치:
Extract: ______ 위치
ELT 파이프라인에서 Extract는 소스 시스템에서 데이터를 읽는 것을 의미합니다. 여기서 소스는 CRM 시스템이므로, 추출은 CRM 시스템에서(그리고 논리적으로 “CRM 시스템에서”) 발생합니다. 실제로는 커넥터/서비스(예: Azure Data Factory)가 읽기를 시작하지만, 추출되는 데이터는 CRM에서 비롯됩니다. A(인메모리 데이터 통합 도구)가 아닌 이유: 이는 ETL에서 변환이 실행될 수 있는 위치를 설명하지만, 추출은 인메모리 도구 “내부에서 수행”되는 것이 아니라 소스에서 끌어오는 데이터 이동 작업입니다. C(데이터 웨어하우스)가 아닌 이유: 웨어하우스는 목적지이며, Load 단계 이후에야 CRM 데이터가 포함됩니다. 따라서 Extract의 올바른 위치는 CRM 시스템입니다.
Load: ______ 위치
ELT에서 Load는 추출된 데이터가 대상 분석 스토어에 기록되는 단계입니다. 시나리오에서 목적지가 데이터 웨어하우스라고 명시되어 있으므로, load 위치는 데이터 웨어하우스입니다. 이는 종종 웨어하우스 환경 내부의 staging/landing 테이블(또는 파일)에 원시 데이터 또는 최소한으로 처리된 데이터를 적재하는 것을 의미합니다. 왜 B (CRM 시스템)가 아닌가? CRM은 소스이며, 웨어하우스로 가는 ELT 파이프라인의 일부로 소스에 “load”하지 않습니다. 왜 A (인메모리 데이터 통합 도구)가 아닌가? 외부 도구가 load를 오케스트레이션할 수는 있지만, 데이터는 최종 목적지로서 도구의 메모리에 적재되는 것이 아니라 데이터 웨어하우스에 적재됩니다. ELT에서는 웨어하우스가 데이터가 저장되고 분석을 위해 준비되는 중심 장소가 됩니다.
Transform: ______ 위치
ELT에서 Transform은 데이터가 대상에 로드된 이후에 발생합니다. 따라서 변환은 데이터 웨어하우스에서 해당 컴퓨팅 엔진(일반적으로 조인, 집계, 정제, 차원 모델 생성과 같은 SQL 기반 변환)을 사용하여 수행됩니다. 이는 ELT의 정의적 특징입니다. 즉, 웨어하우스의 확장 가능한 컴퓨팅을 활용해 무거운 처리를 수행합니다. 왜 A(인메모리 데이터 통합 도구)가 아닌가? 이는 ETL과 더 부합합니다. ETL에서는 외부 통합 엔진이 데이터를 웨어하우스에 로드하기 전에 변환합니다. 문제에서 ELT를 명시하고 있으므로, 변환은 주로 외부 도구에서 수행되지 않습니다. 왜 B(CRM 시스템)가 아닌가? 소스 시스템은 트랜잭션 워크로드(OLTP)에 최적화되어 있으며 분석 변환으로 부담을 주면 안 됩니다. 또한 ELT의 변환은 웨어하우스에 로드된 이후에 발생합니다. 따라서 Transform은 데이터 웨어하우스에서 수행됩니다.
