
Microsoft
306+ 무료 연습 문제 (AI 검증 답안 포함)
Microsoft Azure Data Fundamentals
AI 기반
모든 Microsoft DP-900 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
귀사는 학생 데이터를 포함할 데이터 저장소를 설계하고 있습니다. 데이터는 다음 형식을 가집니다. StudentNumber | StudentInformation 7634634 First name: Ben Last: Smith Preferred Name: Benjamin 7634634 First Name: Dominik Last Name: Paiha Email Address: dpaiha@contoso.com MCP ID: 931817 7634636 First Name: Reshma Last Name: Patel Phone number: 514-555-1101 7634637 First Name: Yun-Feng Last Name: Peng 어떤 유형의 데이터 저장소를 사용해야 합니까?
graph 데이터베이스는 고도로 연결된 데이터와 관계 traversal(예: 과목에 등록한 학생, 친구 관계, 선수 과목)에 맞게 설계되었습니다. 프롬프트에는 관계가 없고, 가변 속성을 가진 학생 식별자만 있습니다. “공유 수업을 통해 연결된 학생 찾기” 또는 다중 홉 관계 탐색 같은 쿼리가 필요하지 않다면 graph 모델은 이점 없이 복잡성만 추가합니다.
key/value는 StudentNumber가 자연스러운 고유 키이고 StudentInformation을 유연한 값(일반적으로 JSON)으로 저장할 수 있으므로 적합합니다. 각 학생은 스키마 변경 없이 서로 다른 필드를 가질 수 있으며, 주요 액세스 패턴은 키 기반의 효율적인 point lookup입니다. 이는 식별자 기준의 단순하고 확장 가능하며 저지연 조회를 위해 Azure Cosmos DB (NoSQL) 또는 Azure Table Storage 같은 서비스와 일치합니다.
object storage(예: Azure Blob Storage)는 문서, 이미지, 백업, 로그 같은 비정형 파일을 저장하고 제공하는 데 최적화되어 있습니다. 각 학생 프로필을 별도의 blob으로 저장할 수는 있지만, object store는 key/value 또는 document 데이터베이스에 비해 빈번한 레코드 수준 업데이트와 저지연 트랜잭션 액세스 패턴의 키 기반 쿼리에 이상적이지 않습니다.
columnar store(예: Parquet 같은 data warehouse/columnstore 형식)는 대규모 데이터셋을 스캔하고 column 전반에 걸쳐 집계하는 분석 워크로드(보고, BI)에 최적화되어 있습니다. 표시된 학생 데이터는 가변 속성을 가진 운영/프로필 성격의 데이터이며, StudentNumber 기준의 point read가 예상됩니다. columnar storage는 이 트랜잭션 중심의 반정형 사용 사례에 비효율적이고 과도하게 복잡합니다.
핵심 개념: 이 문제는 데이터 형태에 기반하여 적절한 비관계형(NoSQL) 데이터 모델을 선택하는지를 평가합니다. 예시는 StudentNumber가 학생별로 달라질 수 있는 속성 집합과 짝을 이룹니다(어떤 학생은 Email 및 MCP ID가 있고, 다른 학생은 Phone이 있으며, 다른 학생은 이름만 있음). 이는 자연스러운 고유 식별자를 가진 반정형 데이터입니다. 정답이 맞는 이유: key/value 데이터 저장소가 가장 적합합니다. 각 레코드는 단일 키(StudentNumber)로 저장 및 조회할 수 있고, 값은 학생의 속성을 포함하는 불투명한 blob(종종 JSON)일 수 있습니다. 스키마는 학생마다 달라도 되며, 테이블 변경이나 고정된 column이 필요하지 않습니다. 이는 일반적인 NoSQL 패턴(키 기반의 빠른 point read/write, 유연한 스키마, 단순한 액세스 패턴)과 일치합니다. 주요 기능 / Azure 컨텍스트: Azure에서는 이 패턴이 Azure Cosmos DB (NoSQL API) 또는 Azure Table Storage에 잘 매핑되며, StudentNumber를 partition key 및/또는 row key(또는 Cosmos DB item id + partition key)로 사용할 수 있습니다. 모범 사례에는 균등한 분산과 쿼리 패턴을 지원하는 partition key 선택이 포함됩니다(예: 주로 학생별로 액세스한다면 StudentNumber). Azure Well-Architected Framework 관점에서 key/value는 성능 효율성(저지연 point read), 운영 우수성(새로운 선택적 필드에 대해 스키마 마이그레이션 불필요), 신뢰성(관리형, 복제 서비스)을 지원합니다. 일반적인 오해: “학생 정보”가 과목, 교사 등과 연관될 수 있으므로 graph가 그럴듯해 보일 수 있지만, 제공된 데이터에는 관계가 아니라 학생별 속성만 있습니다. object storage는 조회 가능한 레코드라기보다 파일/blob(문서, 이미지)을 위한 것입니다. columnar storage는 많은 row/column에 대한 분석 스캔 및 집계에 최적화되어 있으며, 개별 학생 프로필의 트랜잭션 조회에는 적합하지 않습니다. 시험 팁: “ID -> 가변 속성”을 보고 주요 작업이 해당 ID로 retrieve/update라면 key/value(또는 document)를 떠올리십시오. 선택지에 “document”가 있었다면 그것도 유력하지만, 주어진 선택지에서는 key/value가 가장 가깝습니다. 관계 및 traversal이 핵심일 때만 graph를 선택하고, 대규모 분석 워크로드(BI, 보고)에는 운영 프로필 저장소가 아니라 columnar를 선택하십시오.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.


이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
HOTSPOT - 문장을 완성하려면 답안 영역에서 적절한 옵션을 선택하세요. 핫 영역:
Azure Cosmos DB의 graph database는 ______로 쿼리할 수 있습니다.
정답: D. Azure Cosmos DB의 graph database는 Gremlin 언어를 사용하여 nodes와 edges로 쿼리합니다. Cosmos DB의 graph 기능은 Apache TinkerPop Gremlin traversal language를 구현하는 Gremlin API를 통해 제공됩니다. Gremlin은 graph traversal(예: 관계 탐색, multi-hop 쿼리)을 위해 설계되었으며, 이는 graph database의 핵심 가치입니다. 다른 선택지가 틀린 이유: A는 Cosmos DB Core (SQL) API를 설명합니다. 이는 JSON documents를 저장하고 SQL과 유사한 구문으로 이를 쿼리하며, graph가 아니라 document입니다. B는 Cosmos DB Cassandra API를 설명합니다. 이는 Cassandra Query Language (CQL)로 쿼리되는 wide-column/partitioned row store 모델을 노출하며, graph가 아닙니다. C는 LINQ가 일반적으로 Core (SQL) API SDK와 함께 documents를 쿼리하기 위해 사용되는 client-side 언어 통합 옵션이기 때문에 틀렸습니다. 이는 주요 graph 쿼리 메커니즘이 아니며, Gremlin처럼 nodes/edges로 graph traversal을 표현하지도 않습니다.
데이터 웨어하우스에서 데이터를 읽는 품질 보증 애플리케이션이 있습니다. 애플리케이션은 어떤 유형의 처리를 사용합니까?
OLTP는 일상적인 운영 트랜잭션(많은 소규모 읽기/쓰기, insert/update/delete, 엄격한 동시성, ACID transactions)을 지원합니다. 예로는 주문 입력 또는 은행 시스템이 있습니다. 데이터 웨어하우스는 OLTP에 최적화되어 있지 않고 분석에 최적화되어 있습니다. 애플리케이션이 관계형 운영 데이터베이스에 트랜잭션 레코드를 쓰는 경우라면 OLTP가 맞겠지만, “데이터 웨어하우스에서 읽는다”는 표현은 OLTP와 거리가 있습니다.
배치 처리는 예약된 단위로 작업을 실행하는 것(예: 야간 ETL/ELT 적재, 주기적 데이터 정제, 대용량 파일 처리)을 의미합니다. 데이터 웨어하우스는 종종 배치 작업으로 채워지므로 이 선택지는 그럴듯해 보일 수 있습니다. 그러나 문제는 애플리케이션이 데이터 웨어하우스에서 읽을 때 어떤 유형의 처리를 사용하는지 묻습니다. 분석을 위한 읽기는 OLAP이며, 배치는 데이터가 처리/적재되는 방식에 더 가깝고 쿼리 패턴 자체를 의미하지는 않습니다.
OLAP는 대규모 과거 데이터셋에 대한 분석 쿼리를 위해 설계되며, 이는 데이터 웨어하우스가 제공하는 것과 정확히 일치합니다. OLAP는 통찰(추세, 이상 징후, 품질 지표)을 도출하기 위해 복잡한 쿼리, 집계, 대용량 데이터 스캔을 강조합니다. 데이터 웨어하우스에서 데이터를 읽는 품질 보증 애플리케이션은 일반적으로 분석 쿼리와 보고를 실행하므로, 이는 OLAP 특성과 DP-900의 analytics workload 범주에 직접적으로 부합합니다.
스트림 처리는 Azure Stream Analytics, Event Hubs 또는 Spark Structured Streaming 같은 도구를 사용해 연속적이고 준실시간 데이터(이벤트/telemetry)를 처리합니다. 데이터가 도착하는 즉시(초/분 단위 지연) 처리해야 할 때 사용됩니다. 데이터 웨어하우스는 일반적으로 연속적인 이벤트 단위 처리보다는 과거 분석 및 보고를 위해 쿼리됩니다. 문제가 실시간 이벤트 수집과 연속 계산을 설명하지 않는 한, 스트리밍은 최적의 선택이 아닙니다.
핵심 개념: 이 문제는 데이터가 저장되고 소비되는 방식에 따라 워크로드를 분류하는 능력을 평가합니다. 데이터 웨어하우스는 분석을 위해 설계됩니다. 즉, 쿼리 및 보고를 위해 모델링된(사실/차원, star/snowflake schemas) 대규모의 과거 통합 데이터를 저장합니다. 데이터 웨어하우스를 쿼리하는 것과 일반적으로 연관되는 처리 패턴은 Online Analytical Processing (OLAP)입니다. 정답이 맞는 이유: 데이터 웨어하우스에서 데이터를 읽는 품질 보증(QA) 애플리케이션은 큐레이션된 과거 데이터에 대해 분석 쿼리를 수행하여 추세, 이상 징후, 결함 또는 규정 준수 이슈를 찾습니다. 이것이 OLAP입니다. 즉, 통찰을 얻기 위해 최적화된 읽기 중심의 복잡한 쿼리(집계, group-by, 대규모 테이블 간 join)이며, 개별 트랜잭션을 기록하는 목적이 아닙니다. DP-900 관점에서 “data warehouse”와 “analytics workload”는 OLAP를 강하게 시사하는 단서입니다. 주요 특징 및 모범 사례: OLAP 워크로드는 높은 처리량의 스캔, columnar storage, partitioning, query optimization을 우선시합니다. Azure에서 OLAP/data warehousing에 흔히 사용되는 서비스로는 Azure Synapse Analytics (dedicated SQL pools), data lake에 대한 serverless SQL, 그리고 Delta Lake를 사용하는 Azure Databricks가 있습니다. 모범 사례는 Azure Well-Architected Framework(Performance Efficiency 및 Cost Optimization)와 정렬됩니다. 예를 들어 스캔되는 데이터를 줄이기 위한 partitioning 사용, columnstore/columnar formats(예: Parquet) 활용, 적절한 캐싱, 그리고 보고 시간대에 맞추기 위한 compute의 독립적 확장(예: Synapse DWUs) 등이 있습니다. 흔한 오해: “배치 처리”는 데이터 웨어하우스를 적재(ETL/ELT)하는 데 자주 포함되지만, 문제는 애플리케이션이 웨어하우스를 적재한다고 하지 않고 웨어하우스에서 읽는다고 말합니다. “OLTP”는 운영 시스템(주문, 결제, 재고)에서 빈번한 insert/update와 짧은 트랜잭션을 위한 것입니다. “스트림 처리”는 준실시간 이벤트 수집과 연속 처리를 위한 것으로, 과거 분석을 위해 웨어하우스를 쿼리하는 경우에는 일반적이지 않습니다. 시험 팁: DP-900에서는 키워드를 매핑하세요. “data warehouse, reporting, dashboards, aggregations” => OLAP. “Point-in-time transactions, CRUD, low-latency writes” => OLTP. “Scheduled jobs, nightly loads” => batch. “Telemetry, events, real-time” => streaming. 프롬프트가 분석을 위해 웨어하우스에서 읽는 것을 강조한다면 OLAP를 선택하세요.
Azure SQL managed instance에 데이터를 저장하는 트랜잭션 애플리케이션이 있습니다. 언제 읽기 전용 데이터베이스 replica를 구현해야 합니까?
정답입니다. 읽기 전용 replica는 보고, 대시보드, ad-hoc 쿼리와 같은 read-heavy 워크로드를 primary 트랜잭션 데이터베이스에서 오프로딩하도록 설계되었습니다. 이는 CPU/IO에 대한 경합을 줄이고 장시간 실행되는 SELECT 쿼리가 OLTP 성능을 저하시킬 위험을 최소화합니다. 이는 전형적인 read scale 패턴입니다. 쓰기는 primary에 유지하고 읽기는 replica로 보냅니다.
오답입니다. Auditing은 로그인, 스키마 변경, 데이터 액세스와 같은 이벤트를 추적하는 데 초점을 맞추며, 일반적으로 Azure SQL Auditing, diagnostic logs 또는 보안 도구를 사용합니다. 읽기 전용 replica는 자체적으로 auditing trail을 제공하지 않으며, 단지 읽기 쿼리를 위한 또 다른 복사본을 제공할 뿐입니다. 분석을 위해 replica를 쿼리할 수는 있지만, 적절한 auditing 제어를 대체하지는 않습니다.
오답입니다. 지역적 중단에 대한 고가용성은 auto-failover groups 또는 paired region으로의 geo-replication과 같은 cross-region disaster recovery가 필요합니다. 읽기 전용 replica는 보통 동일 region 내에 있으며 read scale 및 로컬 HA 아키텍처를 위한 것이지, 전체 region 중단 시나리오에서 생존하기 위한 것이 아닙니다.
오답입니다. Recovery Point Objective (RPO)는 허용 가능한 데이터 손실량에 관한 것이며, 주로 backup 빈도, transaction log backups, 그리고 다른 region으로의 DR replication에 의해 영향을 받습니다. read scale을 위한 읽기 전용 replica는 본질적으로 RPO를 개선하지 않으며, geo-DR 또는 backup 전략을 대체하지 않습니다.
핵심 개념: Azure SQL Managed Instance의 읽기 전용 데이터베이스 replica는 기본 read-write instance에서 읽기 워크로드(쿼리)를 오프로딩(offload)하는 데 사용됩니다. 이는 OLTP(트랜잭션) 워크로드를 무거운 읽기/보고 워크로드와 분리하여 트랜잭션의 지연 시간과 처리량을 보호하는 일반적인 패턴과 일치합니다. 정답이 맞는 이유: 트랜잭션 애플리케이션은 장시간 실행되는 SELECT 쿼리, 보고, ad-hoc analytics로 인해 발생하는 경합(CPU, memory, IO, locks/latches)에 민감합니다. 읽기 전용 replica를 구현하면 보고 쿼리를 primary에서 지속적으로 동기화되는 secondary로 보낼 수 있으므로, 보고서 생성이 트랜잭션 워크로드와 경쟁하지 않습니다. 이는 성능 예측 가능성을 개선하고 리소스 경합을 줄이며 primary 워크로드를 안정화함으로써 Azure Well-Architected Framework의 Performance Efficiency 및 Reliability 원칙을 지원합니다. 주요 기능 / 사용 방식: SQL Managed Instance에서 read scale/읽기 전용 replica는 일반적으로 Business Critical 아키텍처(내부적으로 Always On availability groups)와 연관됩니다. 보통 보고/BI 쿼리를 위해 read-only endpoint에 연결하거나(또는 지원되는 경우 application intent=ReadOnly 사용) 합니다. 이 replica는 쓰기용이 아니며 읽기 전용 작업을 위한 것이고, near-real-time 보고에 사용할 수 있습니다. 또한 보고 쿼리를 최적화하고 적절한 isolation levels를 사용하는 것이 일반적인 best practice이지만, 핵심 이점은 워크로드 격리입니다. 흔한 오해: 읽기 전용 replica는 주로 auditing 기능이 아닙니다. Auditing은 SQL Auditing, Microsoft Purview 또는 로그 기반 접근 방식으로 처리합니다. 또한 지역적 중단에 대한 보호의 주요 메커니즘도 아닙니다. 이는 geo-replication, auto-failover groups 또는 cross-region DR 전략으로 해결합니다. 마지막으로 읽기 전용 replica는 본질적으로 RPO를 개선하지 않습니다. RPO는 backup/restore 전략, 다른 region으로의 log shipping/replication, 그리고 DR 구성에 의해 좌우됩니다. 시험 팁: DP-900에서는 “read-only replica/read scale”을 “OLTP에서 reads/reporting 오프로딩”으로 매핑하세요. “regional outage/high availability”는 geo-redundant 설계(failover groups/geo-replication)로, “RPO/RTO”는 backup/restore 및 DR 기능으로 매핑하세요. 트랜잭션에 영향을 주지 않고 보고를 언급한다면, 읽기 전용 replica 선택이 가장 적합합니다.
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 유형에 맞추세요.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Microsoft Power BI 대시보드는 단일 workspace에 연결됩니다.
예. Power BI 서비스에서 대시보드는 특정 workspace 내에서 생성되며(그리고 해당 workspace가 소유합니다). workspace는 대시보드에 대한 조직 및 보안 경계로 작동하며, 누가 이를 보고 편집할 수 있는지도 포함합니다. 대시보드는 사용자에게 workspace 외부로 공유될 수 있지만(tenant 설정, 권한, 공유 방식에 따라 달라짐), 대시보드 자체는 여전히 정확히 하나의 workspace에만 존재합니다. “아니요”가 틀린 이유: 하나의 대시보드가 동시에 여러 workspace에 연결되는 개념은 없습니다. 다른 workspace에서 동일한 대시보드와 유사한 경험이 필요하다면, 일반적으로 이를 다시 만들거나, app을 사용해 콘텐츠를 배포하거나, 공유된 dataset/semantic model을 활용하고 workspace별로 별도의 대시보드를 사용합니다. 이러한 workspace 연결은 거버넌스와 액세스 제어에 중요하므로, DP-900에서는 workspace가 대시보드의 컨테이너임을 인지할 것을 기대합니다.
Microsoft Power BI 대시보드는 단일 dataset의 시각화만 표시할 수 있다.
아니오. Power BI 대시보드는 여러 report에서 고정(pin)한 타일을 포함할 수 있으며, 이러한 report는 서로 다른 dataset(semantic model)을 기반으로 할 수 있습니다. 이는 대시보드의 핵심 목적 중 하나로, 서로 다른 주제 영역 전반에 걸친 통합된 보기를 제공하기 위함입니다(예: 한 dataset의 매출 KPI와 다른 dataset의 지원 티켓 KPI). “예”가 틀린 이유: “단일 dataset” 제한은 특정 report 동작에 더 가깝습니다(일반적으로 report는 한 번에 하나의 dataset을 기반으로 작성되지만, composite model과 DirectQuery를 사용해 여러 source에 연결할 수 있음). 그러나 대시보드는 고정된 시각화/타일을 모아 놓는 집계 계층이며 단일 dataset로 제한되지 않습니다. 시험에서는 다음을 기억하세요: 대시보드 = 한 페이지, 많은 타일, 잠재적으로 많은 dataset.
Microsoft Power BI 대시보드는 Microsoft Excel 통합 문서의 시각화를 표시할 수 있습니다.
예. Power BI는 Excel workbooks를 data source로 사용할 수 있으며, 해당 Excel data로 작성된 visuals는 dashboard에 표시될 수 있습니다. Power BI service에서 dashboard tiles는 일반적으로 reports에서 pin되며, 이러한 reports는 imported Excel data 또는 지원되는 workbook content로부터 생성될 수 있습니다. "No"는 올바르지 않습니다. Excel은 Power BI analytics를 위한 지원되는 source이기 때문입니다. 그러나 dashboard는 임의의 Excel content를 직접 render하지 않으며, 지원되는 방식으로 Power BI에 가져온 경우에만 가능합니다.
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는 적절한 쿼리 도구입니다.
HOTSPOT - 문장을 완성하려면 답안 영역에서 적절한 옵션을 선택하십시오. 핫 영역:
기본적으로 각 Azure SQL database는 ______에 의해 보호됩니다.
정답: B (server-level firewall). Azure SQL Database는 logical SQL server에서 호스팅됩니다. 기본적으로 해당 server의 database에 대한 액세스는 Azure SQL server firewall에 의해 제어됩니다. firewall은 allow rule(서버 수준 및 선택적으로 데이터베이스 수준)을 사용하여 특정 public IP 범위 및/또는 다른 Azure service(해당 설정이 활성화된 경우)로부터의 연결을 허용합니다. 이는 연결을 활성화할 때 가장 먼저 구성하는 기본 보호 메커니즘입니다. 다른 선택지가 틀린 이유: - A (NSG): Network Security Group은 VNet의 subnet 및 network interface에 적용됩니다. Azure SQL Database는 PaaS service이므로 기본적으로 NSG로 직접 보호되지 않습니다(다만 private endpoint를 사용하면 subnet에 NIC가 생성되며, 이는 NSG rule의 적용을 받을 수 있습니다). - C (Azure Firewall): 이는 VNet을 위한 선택적 고객 관리형 network firewall이며, Azure SQL Database 앞단에 자동으로 배치되지 않습니다. - D (Azure Front Door): 이는 HTTP/HTTPS 웹 트래픽용이며 SQL/TDS 연결의 앞단에 둘 수 없습니다.
프로젝트 지향적인 오프라인 데이터베이스 개발을 지원하는 그래픽 도구를 사용하여 데이터베이스를 설계하고 모델링해야 합니다. 무엇을 사용해야 합니까?
SSDT는 프로젝트 지향적인 데이터베이스 개발을 위해 설계되었습니다. SQL Server Database Project에서 데이터베이스 스키마를 오프라인으로 모델링하고 개발할 수 있으며, 스키마를 검증/빌드하고 DACPAC 같은 배포 아티팩트를 생성할 수 있습니다. 소스 제어 및 CI/CD 파이프라인과도 잘 통합되므로, “그래픽 도구”와 “오프라인, 프로젝트 기반” SQL Server 및 Azure SQL용 데이터베이스 개발이라는 요구사항에 가장 부합합니다.
SSMS는 주로 SQL Server 및 Azure SQL을 위한 관리 및 쿼리 도구입니다. T-SQL 쿼리 실행, 보안 구성, 모니터링, 백업, 문제 해결 같은 연결된 작업에 강점이 있습니다. 객체를 스크립팅하고 일부 설계 작업을 할 수는 있지만, 빌드 검증과 DACPAC 기반 배포를 포함한 오프라인 프로젝트 기반 개발에 초점을 맞춘 도구는 아닙니다.
Azure Databricks는 노트북과 분산 처리를 사용하는 분석 워크로드, 데이터 엔지니어링, 머신 러닝을 위한 관리형 Apache Spark 플랫폼입니다. 관계형 데이터베이스 스키마 모델링이나 오프라인 데이터베이스 프로젝트 개발을 목적으로 하지 않습니다. Databricks가 데이터베이스와 상호작용할 수는 있지만, SSDT와 같은 database-project 모델링 경험을 제공하지는 않습니다.
Azure Data Studio는 확장(일부 스키마 및 데이터베이스 도구 포함)을 갖춘 크로스 플랫폼 SQL 편집기 및 관리 도구입니다. 그러나 주로 연결된 방식으로 데이터베이스를 쿼리하고 관리하는 데 사용되며, 오프라인 스키마 빌드/검증 및 DACPAC 중심 배포라는 고전적인 SSDT 스타일의 database project 워크플로를 주된 기능으로 제공하지는 않습니다.
핵심 개념: 이 문제는 프로젝트 지향적인 오프라인 데이터베이스 개발을 지원하는 그래픽 도구를 사용하여 관계형 데이터베이스를 설계하고 모델링하는 것에 관한 것입니다. 이는 스키마 객체(테이블, 뷰, stored procedure)를 소스 제어되는 아티팩트로 취급하고, 라이브 데이터베이스에 지속적으로 연결하지 않고도 개발/검증할 수 있는 “database project” 워크플로를 가리킵니다. 정답이 맞는 이유: Microsoft SQL Server Data Tools (SSDT)는 프로젝트 기반 데이터베이스 개발을 위해 특별히 구축된 Microsoft 도구입니다. SSDT에서는 SQL Server Database Project를 생성하며, 데이터베이스 스키마가 프로젝트 내 파일로 표현됩니다. 디자이너와 T-SQL 스크립트를 사용해 스키마를 설계하고, 빌드 검증(스키마 컴파일)을 수행하며, SQL Server 또는 Azure SQL Database로의 일관된 배포를 위한 배포 아티팩트(예: DACPAC)를 생성할 수 있습니다. 이는 “프로젝트 지향적인 오프라인 데이터베이스 개발”과 정확히 일치합니다. 주요 기능 및 모범 사례: SSDT는 schema compare, data-tier application (DACPAC) 생성, 그리고 배포/게시 프로필을 지원합니다. 이를 통해 DevOps 관행(버전 관리, 반복 가능한 빌드, 자동화된 배포(CI/CD))을 구현할 수 있습니다. Azure Well-Architected Framework 관점에서 이는 구성 드리프트를 줄이고 통제된 릴리스를 가능하게 하여 운영 우수성과 신뢰성을 향상시킵니다. 또한 사전 배포 검증을 지원하여 오류를 조기에 발견(shift-left)할 수 있습니다. 흔한 오해: SSMS와 Azure Data Studio는 훌륭한 대화형 관리/쿼리 도구이지만, 주로 연결된(live) 데이터베이스 중심 도구이며 빌드 검증 및 DACPAC 출력이 포함된 오프라인 프로젝트 기반 모델링에 초점을 맞추지 않습니다. Azure Databricks는 분석 및 데이터 엔지니어링 플랫폼(Spark 기반)으로, 관계형 데이터베이스 모델링 도구가 아닙니다. 시험 팁: “database project”, “offline development”, “schema as code”, “DACPAC”, “project-oriented” 같은 키워드를 보면 SSDT를 떠올리세요. “manage server”, “run queries”, “backup/restore”가 보이면 SSMS를 떠올리세요. “cross-platform editor”, “extensions”, “lightweight management”가 보이면 Azure Data Studio를 떠올리세요. “Spark notebooks”, “big data processing”이 보이면 Databricks를 떠올리세요.
드래그 앤 드롭 - 보안 구성 요소를 적절한 시나리오에 매칭하세요. 답하려면 왼쪽 열의 적절한 구성 요소를 오른쪽의 해당 시나리오로 드래그하세요. 각 구성 요소는 한 번만, 여러 번, 또는 전혀 사용하지 않을 수 있습니다. 참고: 각 올바른 매칭은 1점입니다. 선택 및 배치:
______ 다른 네트워크에서 Azure SQL database에 대한 액세스를 방지합니다.
정답: B. Firewall. 다른 네트워크에서 Azure SQL database에 대한 액세스를 방지하려면 Azure SQL server-level firewall rules(공용 IP 범위 허용/차단) 및/또는 Private Link/Private Endpoint를 사용하는 virtual network rules로 특정 VNet으로 연결을 제한하는 것과 같은 network access controls를 사용합니다. 이러한 제어는 network perimeter에서 동작하며, 특정 source network의 트래픽이 database endpoint에 도달할 수 있는지 여부를 결정합니다. A (Authentication)가 아닌 이유: Authentication은 연결이 설정된 후 누가 로그인할 수 있는지를 제어합니다. 네트워크가 service endpoint에 도달하는 것을 막지는 않으며, 유효하지 않은 identity만 거부합니다. C (Encryption)가 아닌 이유: Encryption은 at rest 또는 in transit 데이터의 기밀성을 보호하지만, network connectivity를 차단하지는 않습니다. firewall/VNet restrictions가 구성되지 않으면 encryption된 database도 다른 네트워크에서 여전히 도달 가능할 수 있습니다.
______는 Azure SQL database에 대한 Azure Active Directory (Azure AD) sign-in을 지원합니다.
정답: A. Authentication. Azure SQL Database에 대한 Azure Active Directory (Azure AD) sign-in을 지원하는 것은 authentication 기능입니다. Azure AD authentication을 사용하면 사용자와 애플리케이션이 SQL login 대신(또는 추가로) Azure AD identity(사용자, 그룹, managed identity, service principal)를 사용하여 authenticate할 수 있습니다. 이는 MFA 및 Conditional Access 같은 최신 보안 기능과 함께 자주 사용되며, identity 보안을 강화하고 best practice에 부합합니다. B (Firewall)가 아닌 이유: firewall은 연결이 어디에서 오는지 제한할 수 있지만, Azure AD sign-in 기능을 제공하지는 않습니다. firewall을 통해 traffic을 허용하더라도, Azure AD authentication이 구성되어 있지 않으면 Azure AD authentication을 지원하지 않습니다. C (Encryption)가 아닌 이유: encryption은 데이터를 보호하지만, 사용자가 어떻게 authenticate하는지를 결정하지는 않습니다. Azure AD sign-in은 데이터 기밀성이 아니라 identity 검증 및 token 기반 authentication에 관한 것입니다.
______ Azure SQL database에서 민감한 데이터가 절대로 plain text로 나타나지 않도록 보장합니다.
정답: C. Encryption. Azure SQL database에서 민감한 데이터가 절대로 plain text로 나타나지 않도록 보장한다는 것은 encryption을 의미합니다. Azure SQL에서는 이는 Always Encrypted와 같은 기술과 가장 밀접하게 연관되며, 민감한 column 데이터를 end-to-end로 암호화하여 SQL engine이 plaintext 값을 절대 보지 않도록 합니다(암호화/복호화는 client driver에서 수행). 보다 일반적으로는 encryption 메커니즘(TDE, TLS)이 data at rest 및 data in transit을 보호하지만, “절대로 plain text로 나타나지 않는다”라는 표현은 Always Encrypted 방식의 보호와 가장 잘 부합합니다. A (Authentication)가 아닌 이유: Authentication은 identity 기반으로 access를 제어하지만, 데이터가 unencrypted로 저장되어 있다면 authenticated user(또는 admin)가 여전히 plaintext 데이터를 볼 수 있습니다. B (Firewall)가 아닌 이유: Firewall은 network access를 제한하지만, access가 허용된 이후 plaintext 저장 또는 노출을 방지하지는 못합니다.
HOTSPOT - 다음 각 문장에 대해, 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. Hot Area:
Azure Table storage는 여러 읽기 복제본을 지원합니다.
아니요. Azure Table storage는 multiple read replicas를 지원하지 않습니다. RA-GRS 또는 RA-GZRS를 사용하면 primary에 추가로 하나의 read-only secondary region을 노출할 수 있지만, 이는 여러 region에 걸쳐 여러 readable replicas를 지원하는 것과는 다릅니다. 여러 region에 대한 read distribution은 Cosmos DB의 기능인 반면, Azure Table storage의 replication은 storage account의 primary/secondary replication model로 제한됩니다.
Azure Table storage는 여러 쓰기 지역을 지원합니다.
아니요. Azure Table storage는 여러 쓰기 지역을 지원하지 않습니다. LRS, ZRS, GRS 또는 GZRS 중 무엇을 선택하든, 쓰기는 기본(primary) 지역에서만 수락됩니다. GRS/GZRS를 사용하면 데이터가 재해 복구를 위해 보조(secondary) 지역으로 비동기적으로 복제되지만, 보조 지역은 쓰기 가능하지 않습니다. RA-GRS/RA-GZRS(보조에 대한 읽기 액세스)를 활성화하더라도, 해당 보조 엔드포인트는 읽기 전용으로 유지됩니다. 이 설계는 Azure Storage의 복제 모델과 일치합니다. 즉, active-active 멀티 마스터 쓰기보다는 내구성과 가용성에 초점을 둡니다. 따라서 Table storage는 동시에 둘 이상의 지역에서 쓰기를 수락할 수 없고, 쓰기는 단일 기본(primary) 구조이므로 해당 문장은 거짓입니다.
Azure Cosmos DB Table API는 여러 개의 읽기 복제본을 지원합니다.
예. Azure Cosmos DB Table API는 Cosmos DB의 글로벌 배포를 통해 여러 개의 읽기 복제본을 지원합니다. Cosmos DB 계정에 여러 Azure region을 추가할 수 있으며, Cosmos DB는 해당 region으로 데이터를 복제합니다. 그러면 애플리케이션은 지연 시간을 줄이기 위해 가장 가까운 region에서 읽을 수 있습니다. Cosmos DB에서는 읽기 확장과 지리적 분산이 기본 기능입니다. 여러 region을 구성하고 자동 failover 및 region 기반 routing과 같은 기능을 사용할 수 있습니다. 이는 Azure Table storage와는 다르며, Azure Table storage에서는 secondary가 주로 DR을 위한 것이고 구성에 따라 읽기 전용일 수 있습니다. Cosmos DB는 여러 region(복제본)에서 동시에 읽기를 제공할 수 있으므로, Table API가 Cosmos DB의 다중 region 읽기 기능을 상속받는다는 점에서 해당 문장은 참입니다.
Azure Cosmos DB Table API는 여러 쓰기 region을 지원합니다.
예. Azure Cosmos DB Table API는 multi-region writes(또는 multi-master)를 활성화하면 여러 쓰기 region을 지원합니다. 이 기능을 통해 Cosmos DB는 둘 이상의 region에서 쓰기를 수락할 수 있어, 전 세계에 분산된 애플리케이션의 쓰기 가용성을 높이고 쓰기 지연 시간을 줄일 수 있습니다. 이 기능은 Azure Table storage와 비교했을 때 고유하며, 시험에서 중요한 차별점입니다. Cosmos DB는 active-active 시나리오를 위해 설계되었습니다. multi-region writes가 활성화되면 Cosmos DB는 내부 메커니즘과 선택한 consistency model에 따라 replication 및 conflict resolution을 처리합니다. 따라서 해당 문장은 참입니다. Cosmos DB Table API는 multi-region writes로 구성할 수 있지만, Azure Table storage는 그렇지 않습니다.
HOTSPOT - 문장을 완성하려면 답안 영역에서 적절한 옵션을 선택하세요. 핫 영역:
관계형 데이터베이스는 ______ 경우에 반드시 사용해야 합니다.
정답: D (강력한 일관성 보장이 필요할 때). 관계형 데이터베이스는 강력한 일관성과 ACID 트랜잭션(Atomicity, Consistency, Isolation, Durability)이 필요할 때 기본 선택입니다. 이러한 기능은 여러 관련 테이블과 행 전반에서 데이터 무결성을 보장하고, 제약 조건(primary/foreign keys)을 강제하며, 읽기 결과가 최신 커밋된 쓰기를 반영해야 하는 트랜잭션 워크로드를 지원하는 데 도움이 됩니다. Azure에서는 Azure SQL Database 같은 서비스가 강력한 일관성과 견고한 트랜잭션 의미론을 제공합니다. 다른 선택지가 틀린 이유: A (동적 스키마가 필요할 때)는 일반적으로 비관계형/문서 데이터베이스(예: Azure Cosmos DB for NoSQL)를 가리키며, 이 경우에는 엄격한 테이블 정의 없이도 스키마를 진화시킬 수 있습니다. B (데이터가 key/value 쌍으로 저장될 때)는 전형적인 key/value 워크로드로, 관계형 엔진보다는 key/value 스토어(예: Cosmos DB key/value patterns, Azure Cache for Redis)에 더 적합합니다. C (대용량 이미지와 비디오를 저장할 때)는 비정형 바이너리 데이터에 최적화되고 대규모 저장을 비용 효율적으로 제공하는 Azure Blob Storage 같은 object storage가 가장 적합합니다.
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입니다.
Azure SQL managed instance에서 데이터베이스를 호스팅하는 것이 Azure SQL database와 비교했을 때 가지는 이점은 무엇인가요?
기본 제공 고가용성은 Azure SQL Managed Instance만의 고유 기능이 아닙니다. Azure SQL Database와 Managed Instance 모두 PaaS 서비스의 일부로 기본 제공 HA(리전 내 복제, 자동 장애 조치 처리, 서비스 관리형 패치)를 포함합니다. 구현 세부 사항은 다를 수 있지만, HA는 공통 이점이므로 이 문제에서 MI의 최선의 비교 우위가 아닙니다.
Azure SQL Managed Instance는 동일한 인스턴스 내에서 여러 데이터베이스를 지원하며, 교차 데이터베이스 쿼리(예: 3부 이름 사용) 및 관련 트랜잭션 패턴에 대해 더 네이티브한 SQL Server 유사 동작을 제공합니다. Azure SQL Database는 주로 단일 데이터베이스 범위로 제한되며, 교차 데이터베이스 쿼리는 같은 방식으로 네이티브 제공되지 않습니다. 이러한 인스턴스 수준의 다중 데이터베이스 기능은 MI의 대표적인 차별화 요소입니다.
시스템에서 시작하는 자동 백업은 Azure SQL Database와 Azure SQL Managed Instance 모두에서 제공됩니다. 두 서비스 모두 백업이 플랫폼에 의해 관리되며(장기 보존 옵션 포함) 보존 기간을 구성할 수 있습니다. 이는 Azure SQL 제품군 전반의 표준 PaaS 기능이므로 Azure SQL Database 대비 Managed Instance의 특정 이점이 아닙니다.
미사용 데이터 암호화는 Azure SQL Database와 Azure SQL Managed Instance 모두에서 지원되며, 일반적으로 Transparent Data Encryption(TDE)이 기본적으로 활성화됩니다. 또한 두 서비스 모두 많은 시나리오에서 customer-managed keys를 위해 Azure Key Vault와 통합됩니다. 미사용 데이터 암호화는 두 제품 모두의 기본 보안 기능이므로 Managed Instance에 유리한 차별화 요소가 아닙니다.
핵심 개념: 이 문제는 Azure SQL Database(단일 데이터베이스 / elastic pool)와 Azure SQL Managed Instance(MI)의 차이를 테스트합니다. 둘 다 SQL Server 엔진을 기반으로 한 PaaS 제품이지만, MI는 온프레미스 SQL Server에서 “lift-and-shift” 마이그레이션을 단순화하기 위해 SQL Server 인스턴스와의 거의 100% 호환성을 목표로 설계되었습니다. 정답이 맞는 이유: Azure SQL Managed Instance가 Azure SQL Database 대비 제공하는 핵심 이점은 동일한 managed instance 내에서 교차 데이터베이스 쿼리 및 트랜잭션을 네이티브로 지원한다는 점입니다. SQL Server와 Managed Instance에서는 하나의 인스턴스에 여러 사용자 데이터베이스를 둘 수 있고, 3부 명명법(database.schema.object) 및 특정 교차 데이터베이스 트랜잭션 패턴을 더 자연스럽게 사용할 수 있습니다. Azure SQL Database는 단일 데이터베이스(또는 격리된 데이터베이스들의 elastic pool) 범위로 제한되며, 동일한 인스턴스 수준의 다중 데이터베이스 동작을 제공하지 않습니다. 교차 데이터베이스 쿼리도 같은 방식으로 네이티브 지원되지 않으며(일반적으로 external data sources, elastic query 패턴, 또는 애플리케이션 수준 조인을 사용합니다). 주요 기능 및 모범 사례: Managed Instance는 SQL Agent, Database Mail, linked servers(제한 있음) 같은 인스턴스 범위 기능과, “인스턴스”에 여러 데이터베이스가 존재한다고 가정하는 애플리케이션의 더 쉬운 마이그레이션을 제공합니다. 이는 Azure Well-Architected Framework 원칙과도 부합하며, 애플리케이션이 인스턴스 수준 기능에 의존하는 경우 운영 효율성을 높이고 마이그레이션 리스크를 줄이는 데(신뢰성 및 운영 우수성) 도움이 될 수 있습니다. 흔한 오해: 기본 제공 고가용성, 자동 백업, 미사용 데이터 암호화는 Azure SQL Database와 Managed Instance 모두의 이점입니다. 이는 Azure SQL 제품군 전반의 핵심 PaaS 기능이므로 차별화 요소가 아닙니다. 시험 팁: DP-900에서는 다음을 기억하세요. Azure SQL Database는 간단한 확장을 갖춘 완전 관리형 단일 데이터베이스가 필요할 때 적합합니다. Azure SQL Managed Instance는 높은 SQL Server 호환성과 인스턴스 수준 기능(특히 교차 데이터베이스 기능을 포함한 다중 데이터베이스)이 필요할 때 적합합니다. “교차 데이터베이스 쿼리/트랜잭션” 또는 “SQL Agent”가 보이면 Managed Instance를 떠올리세요.
귀사는 웹사이트의 세션 데이터를 포함할 데이터베이스를 설계하고 있습니다. 데이터에는 알림, 개인화 속성, 그리고 쇼핑 카트에 추가된 제품이 포함됩니다. 데이터를 검색할 때 가장 낮은 지연 시간을 제공하는 데이터 저장소 유형은 무엇입니까?
key/value 저장소는 단일 키(예: sessionId)를 사용한 매우 빠른 포인트 조회에 최적화되어 있습니다. 이는 애플리케이션이 하나의 세션 레코드를 자주 검색하고 업데이트하는 세션 상태 접근 패턴과 일치합니다. 일반적으로 TTL/만료(세션에 이상적)를 지원하며, in-memory(예: Redis)로 구현할 수 있어 초저지연을 제공하므로 가장 낮은 지연 시간의 검색을 위한 최선의 선택입니다.
Graph 데이터베이스는 엔터티와 관계를 저장하고 연결을 효율적으로 탐색(예: 소셜 네트워크, 추천 엔진)하도록 설계되었습니다. 세션 데이터 검색은 보통 관계 탐색이 아니라 sessionId/userId로 직접 조회합니다. Graph 쿼리는 오버헤드를 추가하며, 단순한 세션 읽기에서는 key/value 저장소보다 가장 낮은 지연 시간을 제공하지 못합니다.
Columnar(컬럼 패밀리/컬럼형 분석) 저장소는 여러 컬럼에 걸친 대량 데이터 읽기와 집계 수행에 최적화되어 분석/OLAP 워크로드에 적합합니다. 세션 데이터는 트랜잭션성이며 키로 접근하고 작은 업데이트가 빈번합니다. Columnar 설계는 불필요한 복잡성을 유발하며 개별 세션 레코드의 최저 지연 시간 포인트 검색에 최적화되어 있지 않습니다.
Document 저장소(JSON 문서)는 쇼핑 카트와 개인화 속성 같은 반정형 데이터에 적합하며 낮은 지연 시간을 제공할 수 있습니다. 그러나 문서 필드에 대한 유연한 쿼리와 인덱싱에 최적화되어 있습니다. 알려진 키로 순수하게 세션을 검색하면서 가능한 가장 낮은 지연 시간(종종 in-memory + TTL)을 원한다면, key/value 저장소가 일반적으로 더 빠르고 접근 패턴에 더 직접적으로 부합합니다.
핵심 개념: 이 문제는 주요 요구 사항이 매우 빠른 읽기/쓰기(가장 낮은 지연 시간)인 세션 상태 워크로드에 대해 가장 적절한 비관계형(NoSQL) 데이터 모델을 선택하는지를 평가합니다. 세션 데이터에는 일반적으로 알림, 개인화 설정, 쇼핑 카트 내용과 같은 사용자/세션별 속성이 포함됩니다. 정답이 맞는 이유: key/value 저장소는 보통 단일의 알려진 키(예: sessionId 또는 userId)로 접근하기 때문에 세션 데이터에 대해 가장 낮은 지연 시간의 검색 패턴을 제공합니다. key/value 데이터베이스는 O(1) 스타일 조회, 최소한의 쿼리 파싱, 단순한 데이터 접근 경로에 최적화되어 있습니다. 흔히 in-memory 또는 메모리 최적화 아키텍처로 구현되며 매우 빠른 포인트 읽기와 업데이트를 지원하므로, 단일 세션 레코드를 자주 읽고/수정하는 세션 상태 및 쇼핑 카트에 이상적입니다. 주요 기능 및 모범 사례: key/value 저장소가 뛰어난 영역: - 키(sessionId) 기반 포인트 읽기/쓰기에서 예측 가능한 성능 - 간단한 확장(키 기반 파티셔닝/샤딩) - TTL/만료 정책(세션 정리에 중요) - 높은 처리량과 낮은 운영 오버헤드 Azure에서는 이 패턴을 초저지연을 위해 Azure Cache for Redis(in-memory key/value)로 구현하는 경우가 많고, 내구성과 전역 분산이 필요할 때는 Azure Cosmos DB에서 key/value에 가까운 NoSQL 접근을 사용합니다. Azure Well-Architected Framework 관점에서 key/value는 Performance Efficiency(낮은 지연 시간), Reliability(복제 옵션), Cost Optimization(필요한 것만 저장하고 자동 만료)과 잘 부합합니다. 흔한 오해: document 저장소도 세션 객체(JSON)를 저장할 수 있고 유연하므로 “알림과 카트 항목”에 가장 적합해 보일 수 있습니다. 하지만 document 데이터베이스는 더 풍부한 쿼리와 인덱싱에 최적화되어 있습니다. 지연 시간이 낮을 수는 있지만, 특히 메모리 기반과 TTL을 결합했을 때 세션 상태에 대해 가장 단순하고 일반적으로 가장 낮은 지연 시간의 검색은 key/value입니다. Graph 저장소는 관계 탐색(친구의 친구, 추천)에 사용됩니다. Columnar 저장소는 분석 및 집계용이며 트랜잭션성 세션 조회에는 적합하지 않습니다. 시험 팁: DP-900에서는 워크로드를 데이터 모델에 매핑하세요: - session 상태, 캐싱, sessionId 기반 쇼핑 카트 => key/value - 쿼리/필터링이 필요한 복잡한 JSON => document - 관계 중심 쿼리 => graph - 대규모 분석/OLAP => columnar 문제가 “검색 시 가장 낮은 지연 시간”을 강조하고 접근 패턴이 단일 식별자 기반이라면 key/value를 선택하세요.
어떤 스토리지 솔루션이 파일 및 폴더 수준에서 역할 기반 액세스 제어(RBAC)를 지원합니까?
Azure Disk Storage는 Azure VM용 블록 수준 스토리지(관리형 디스크)를 제공합니다. Azure가 파일 및 폴더 수준에서 RBAC를 적용할 수 있는 파일시스템 서비스를 노출하지 않습니다. 액세스는 파일/폴더에 대한 데이터 플레인 권한 부여가 아니라 VM 액세스 및 디스크 수준 권한(관리 플레인)으로 제어됩니다. VM 내부에서 디스크를 NTFS/ext4로 포맷할 수는 있지만, 이는 OS 수준 권한이며 Azure Storage RBAC의 파일/폴더 권한이 아닙니다.
Azure Data Lake Storage Gen2는 hierarchical namespace를 통해 실제 디렉터리와 파일을 지원하는 Azure storage service입니다. 이러한 구조 덕분에 디렉터리 및 파일 수준에서 permissions를 적용할 수 있으며, 이는 flat object storage에서는 같은 방식으로는 불가능합니다. 실제로는 더 광범위한 authorization에는 Azure RBAC가 사용되고, 폴더와 파일에 대한 세밀한 제어에는 POSIX-style ACLs가 사용됩니다. 따라서 ADLS Gen2는 세분화된 filesystem-style security가 필요한 storage 시나리오에서 가장 적절하고 기대되는 정답입니다.
Azure Blob storage는 blob 이름에 폴더처럼 보이는 slash-delimited prefixes를 포함할 수 있지만, 기본적으로는 flat namespace를 가진 object store입니다. 이러한 prefixes는 가상 개념이며, 독립적인 file/folder permissions를 가진 진정한 directory objects를 제공하지 않습니다. Azure RBAC는 blob data에 대한 access를 부여할 수 있지만, 여기서 평가하는 filesystem 의미의 진정한 folder-level authorization은 제공하지 않습니다. 세분화된 file 및 directory permission model은 표준 Blob storage가 아니라 ADLS Gen2와 관련이 있습니다.
Azure Queue storage는 메시지를 저장하고 검색하는 메시징 서비스입니다. 파일과 폴더 개념이 없으므로 파일/폴더 수준 RBAC는 적용되지 않습니다. 권한 부여는 일반적으로 스토리지 계정 키, SAS 토큰 또는 큐 작업에 적절한 역할을 가진 Azure AD를 통해 이루어지지만, 여전히 파일시스템 스타일 권한이 아니라 큐/메시지 작업 수준입니다.
핵심 개념: 이 문제는 어떤 Azure storage service가 디렉터리와 파일에 대한 세분화된 authorization을 지원하는지 평가합니다. Azure에서 진정한 file-level 및 folder-level permissions을 구현하려면 flat object storage나 block storage가 아니라 hierarchical filesystem model이 필요합니다. 정답인 이유: Azure Data Lake Storage Gen2는 hierarchical namespace를 지원하며, 이를 통해 실제 디렉터리와 파일이 도입됩니다. 이로 인해 폴더와 파일에 직접 적용할 수 있는 POSIX-style access control lists (ACLs)를 사용할 수 있습니다. Azure RBAC는 더 광범위한 data access roles를 부여하는 데 사용할 수 있지만, file-level 및 folder-level의 세분화 자체는 ADLS Gen2의 ACLs를 통해 제공됩니다. 주요 기능 / 구성 / 모범 사례: - 디렉터리를 인식하는 storage를 위해 hierarchical namespace가 활성화된 Azure Data Lake Storage Gen2를 사용합니다. - 거친 수준의 access에는 Microsoft Entra ID identities와 Azure RBAC를 함께 사용하고, 세밀한 file/folder permissions에는 ACLs를 사용합니다. - 필요한 storage roles만 할당한 뒤 ACLs로 access를 더 제한하여 least-privilege 원칙을 적용합니다. 일반적인 오해: - Azure Blob storage는 blob data access에 대해 Azure RBAC를 지원하지만, ADLS Gen2 hierarchical namespace 기능을 사용하지 않는 한 동일한 방식의 진정한 folder-level security는 제공하지 않습니다. - Azure Disk Storage는 virtual machines에 연결되는 block storage이며, Azure가 강제하는 file/folder permissions를 갖춘 managed filesystem service가 아닙니다. - Queue storage는 메시지용이며 file 또는 folder 구조가 없습니다. 시험 팁: 문제에서 Azure storage의 file-level 또는 folder-level access control을 언급하면 Azure Data Lake Storage Gen2와 ACLs가 있는 hierarchical namespace를 떠올리세요. 문구에 RBAC가 나온다면, 시험에서는 때때로 그 차이를 단순화해서 표현하지만 ADLS Gen2에서의 세분화된 enforcement는 ACLs를 통해 이루어진다는 점을 기억하세요.
회사의 컴플라이언스 요구 사항을 충족하기 위해 Azure Blob storage에 데이터를 7년 동안 저장해야 합니다. 데이터의 검색 시간은 중요하지 않습니다. 솔루션은 스토리지 비용을 최소화해야 합니다. 어떤 storage tier를 사용해야 합니까?
Archive는 데이터가 거의 액세스되지 않고 검색 지연 시간이 수 시간이어도 되는 경우, 장기 보관에서 스토리지 비용을 최소화하기 위한 최선의 선택입니다. GB당 스토리지 가격이 가장 낮지만, 데이터를 읽으려면 Hot/Cool로 rehydrate해야 하며 더 높은 액세스 및 rehydration 비용이 발생합니다. 이는 데이터를 수년간 보관하고 감사(audit)나 조사(investigation) 시에만 검색하는 컴플라이언스 아카이빙 시나리오와 일치합니다.
Hot tier는 자주 액세스하는 데이터에 최적화되어 가장 낮은 지연 시간과 가장 낮은 읽기/액세스 비용을 제공하지만, 지속적인 스토리지 비용이 가장 높습니다. 7년 보관에서 검색 시간이 중요하지 않다면 Hot-tier 스토리지 요금을 지불하는 것은 비용 최소화에 부합하지 않습니다. Hot은 활성 데이터셋, 사용자에게 제공되는 콘텐츠, 또는 애플리케이션이 정기적으로 사용하는 데이터에 적합합니다.
Cool tier는 드물게 액세스하지만 비교적 빠른 액세스(일반적으로 밀리초)가 필요한 데이터를 위해 설계되며, Hot보다 저장 비용이 저렴합니다. 그러나 다년 보관에서는 일반적으로 Archive보다 비용이 더 비싸고, 여전히 가끔의 읽기를 전제로 합니다. 7년 컴플라이언스 아카이브에서 검색 시간이 중요하지 않다면 Cool은 전체적으로 최저 비용 옵션이 아닙니다.
핵심 개념: 이 문제는 Azure Blob Storage access tiers(Hot, Cool, Archive)와 액세스 빈도, 검색 지연 시간, 비용을 기준으로 tier를 선택하는 방법을 평가합니다. Blob access tiers는 스토리지 비용과 액세스(읽기) 비용/지연 시간 간의 트레이드오프를 최적화하도록 설계되었습니다. 정답이 맞는 이유: 컴플라이언스를 위해 데이터를 7년 동안 보관해야 하고, 검색 시간은 중요하지 않으며, 스토리지 비용을 최소화해야 합니다. Archive tier는 거의 액세스하지 않는 데이터를 장기 보관할 때, 수 시간 단위의 검색 시간을 허용할 수 있는 시나리오를 위해 특별히 설계되었습니다. Archive는 tier 중 GB당 스토리지 비용이 가장 낮으며, 이는 수년 보관에서 지배적인 비용 요소입니다. 액세스가 드물고 지연 시간이 중요하지 않으므로 Archive의 더 긴 rehydration(복원) 시간과 더 높은 액세스 비용은 수용 가능합니다. 주요 기능 및 모범 사례: - Archive tier는 blob을 오프라인으로 저장하며, 읽으려면 Hot 또는 Cool로 rehydrate해야 하고 이는 수 시간이 걸릴 수 있습니다. 이는 “검색 시간 중요하지 않음”과 부합합니다. - 비용 모델: Archive는 지속적인 스토리지 비용을 최소화하지만 검색 및 early deletion 비용을 증가시킵니다. 컴플라이언스 아카이브에서는 일반적으로 검색이 드물기 때문에 총비용이 대체로 가장 낮습니다. - Lifecycle management 계획: Azure Blob Lifecycle Management rules를 사용하여 일정 기간 후 blob을 Hot/Cool에서 Archive로 자동 이동하고, 보관 패턴을 강제할 수 있습니다. - 거버넌스 고려: 컴플라이언스에서 변조 방지(tamper resistance)가 필요하다면 immutability policies(WORM) 및 legal holds를 사용하세요. 이는 Blob Storage에서 동작하며 장기 보관과 함께 흔히 사용됩니다. - Azure Well-Architected Framework의 cost optimization 관점에서, 드물게 액세스하는 장수명 데이터를 Archive로 선택하는 것은 지속 지출을 줄이는 주요 수단입니다. 흔한 오해: 많은 사람이 “장기” 스토리지에는 Cool이 최선이라고 생각합니다. Cool은 Hot보다 저렴하지만 여전히 가끔(예: 매월) 액세스하는 데이터를 대상으로 하며 Archive보다 지연 시간이 낮습니다. 7년 보관에 검색 시간이 중요하지 않다면, Cool은 시간이 지날수록 Archive보다 비용이 더 드는 경우가 일반적입니다. 시험 팁: - Hot: 빈번한 액세스, 가장 낮은 액세스 비용, 가장 높은 스토리지 비용. - Cool: 드문 액세스(며칠/몇 주), Hot보다 낮은 스토리지 비용, 더 높은 액세스 비용, 최소 보관 기간. - Archive: 매우 드문 액세스(몇 달/몇 년), 가장 낮은 스토리지 비용, 가장 높은 액세스 비용, 수 시간 단위 rehydration. 문제가 “검색 시간 중요하지 않음”과 “스토리지 비용 최소화”를 말하면 Archive를 떠올리세요.
DRAG DROP - Azure Cosmos DB API를 적절한 데이터 구조에 매칭하세요. 답하려면 왼쪽 열의 적절한 API를 오른쪽의 데이터 구조로 드래그하세요. 각 API는 한 번, 여러 번 또는 전혀 사용하지 않을 수 있습니다. 참고: 각 올바른 매칭은 1점입니다. 선택 및 배치:
아래 이미지에서 올바른 답(들)을 선택하세요.

통과(A)가 적절한 이유는 올바른 매핑이 다음과 같기 때문입니다: - Graph data -> Gremlin API Gremlin은 Apache TinkerPop graph traversal language입니다. Cosmos DB의 Gremlin API는 graph 워크로드(노드/vertices 및 관계/edges)를 위해 목적에 맞게 설계되어, “friends of friends”와 같은 traversal을 효율적으로 수행할 수 있습니다. - JSON documents -> MongoDB API MongoDB는 데이터를 BSON(binary JSON)으로 저장하는 document database입니다. Cosmos DB의 API for MongoDB는 MongoDB semantics와 일관된 document 중심 작업 및 쿼리를 지원합니다. - Key/value data -> Table API Table API는 Azure Table Storage 개념(PartitionKey 및 RowKey)에 부합하며, 일반적으로 key/attribute(key/value 유사) store로 분류됩니다. 여기서 Cassandra API가 아닌 이유: Cassandra는 wide-column/column-family model입니다. 높은 수준에서는 key/value처럼 보일 수 있지만, 시험에서는 key/value에 대해 Table API를 기대하며 Cassandra는(정답 영역 옵션에 나열되어 있지 않은) “wide-column”에 대해 따로 구분합니다.
HOTSPOT - 문장을 완성하려면, 답변 영역에서 적절한 옵션을 선택하세요. 핫 영역:
Batch workloads ______
정답: D. Batch workloads는 시간이 지나면서 데이터를 수집한 뒤 나중에 처리하며, 일반적으로 스케줄(매시간/야간)로 실행되거나 트리거 조건이 충족될 때(예: 스토리지 위치에 파일이 도착함, 시간 윈도우가 닫힘, 또는 파이프라인 트리거가 실행됨) 처리합니다. 이것이 batch의 정의적 특징입니다. 더 높은 지연 시간(latency)을 허용하며, 처리는 개별 실행(run) 단위로 이루어집니다. 다른 선택지가 틀린 이유: - A는 batch analytics를 정의하는 설명이 아닙니다. “메모리에서 데이터를 행 단위로 처리”는 특정 절차적 처리 방식에 더 가깝고, batch와 streaming을 구분하는 특징이 아닙니다. - B는 지나치게 구체적이고 제한적입니다. Batch는 하루에 한 번보다 더 자주(매분/매시간) 실행될 수도 있고 더 드물게 실행될 수도 있으므로, “하루에 최대 한 번”은 일반적으로 사실이 아닙니다. - C는 streaming/real-time processing을 설명합니다. 이 방식은 데이터가 도착하는 즉시 최소한의 지연으로 처리하며, 이는 batch의 반대입니다.










