Microsoft DP-900

정답: 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을 표현하지도 않습니다.

예. Power BI 서비스에서 대시보드는 특정 workspace 내에서 생성되며(그리고 해당 workspace가 소유합니다). workspace는 대시보드에 대한 조직 및 보안 경계로 작동하며, 누가 이를 보고 편집할 수 있는지도 포함합니다. 대시보드는 사용자에게 workspace 외부로 공유될 수 있지만(tenant 설정, 권한, 공유 방식에 따라 달라짐), 대시보드 자체는 여전히 정확히 하나의 workspace에만 존재합니다. “아니요”가 틀린 이유: 하나의 대시보드가 동시에 여러 workspace에 연결되는 개념은 없습니다. 다른 workspace에서 동일한 대시보드와 유사한 경험이 필요하다면, 일반적으로 이를 다시 만들거나, app을 사용해 콘텐츠를 배포하거나, 공유된 dataset/semantic model을 활용하고 workspace별로 별도의 대시보드를 사용합니다. 이러한 workspace 연결은 거버넌스와 액세스 제어에 중요하므로, DP-900에서는 workspace가 대시보드의 컨테이너임을 인지할 것을 기대합니다.

아니오. Power BI 대시보드는 여러 report에서 고정(pin)한 타일을 포함할 수 있으며, 이러한 report는 서로 다른 dataset(semantic model)을 기반으로 할 수 있습니다. 이는 대시보드의 핵심 목적 중 하나로, 서로 다른 주제 영역 전반에 걸친 통합된 보기를 제공하기 위함입니다(예: 한 dataset의 매출 KPI와 다른 dataset의 지원 티켓 KPI). “예”가 틀린 이유: “단일 dataset” 제한은 특정 report 동작에 더 가깝습니다(일반적으로 report는 한 번에 하나의 dataset을 기반으로 작성되지만, composite model과 DirectQuery를 사용해 여러 source에 연결할 수 있음). 그러나 대시보드는 고정된 시각화/타일을 모아 놓는 집계 계층이며 단일 dataset로 제한되지 않습니다. 시험에서는 다음을 기억하세요: 대시보드 = 한 페이지, 많은 타일, 잠재적으로 많은 dataset.

예. 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 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 쿼리를 실행하면 됩니다.

예. 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는 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는 적절한 쿼리 도구입니다.

정답: 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 연결의 앞단에 둘 수 없습니다.

정답: 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도 다른 네트워크에서 여전히 도달 가능할 수 있습니다.

정답: 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에 관한 것입니다.

정답: 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 저장 또는 노출을 방지하지는 못합니다.

아니요. 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는 여러 쓰기 지역을 지원하지 않습니다. LRS, ZRS, GRS 또는 GZRS 중 무엇을 선택하든, 쓰기는 기본(primary) 지역에서만 수락됩니다. GRS/GZRS를 사용하면 데이터가 재해 복구를 위해 보조(secondary) 지역으로 비동기적으로 복제되지만, 보조 지역은 쓰기 가능하지 않습니다. RA-GRS/RA-GZRS(보조에 대한 읽기 액세스)를 활성화하더라도, 해당 보조 엔드포인트는 읽기 전용으로 유지됩니다. 이 설계는 Azure Storage의 복제 모델과 일치합니다. 즉, active-active 멀티 마스터 쓰기보다는 내구성과 가용성에 초점을 둡니다. 따라서 Table storage는 동시에 둘 이상의 지역에서 쓰기를 수락할 수 없고, 쓰기는 단일 기본(primary) 구조이므로 해당 문장은 거짓입니다.

예. 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는 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는 그렇지 않습니다.

정답: 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가 가장 적합합니다.

통과(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”에 대해 따로 구분합니다.

정답: D. Batch workloads는 시간이 지나면서 데이터를 수집한 뒤 나중에 처리하며, 일반적으로 스케줄(매시간/야간)로 실행되거나 트리거 조건이 충족될 때(예: 스토리지 위치에 파일이 도착함, 시간 윈도우가 닫힘, 또는 파이프라인 트리거가 실행됨) 처리합니다. 이것이 batch의 정의적 특징입니다. 더 높은 지연 시간(latency)을 허용하며, 처리는 개별 실행(run) 단위로 이루어집니다. 다른 선택지가 틀린 이유: - A는 batch analytics를 정의하는 설명이 아닙니다. “메모리에서 데이터를 행 단위로 처리”는 특정 절차적 처리 방식에 더 가깝고, batch와 streaming을 구분하는 특징이 아닙니다. - B는 지나치게 구체적이고 제한적입니다. Batch는 하루에 한 번보다 더 자주(매분/매시간) 실행될 수도 있고 더 드물게 실행될 수도 있으므로, “하루에 최대 한 번”은 일반적으로 사실이 아닙니다. - C는 streaming/real-time processing을 설명합니다. 이 방식은 데이터가 도착하는 즉시 최소한의 지연으로 처리하며, 이는 batch의 반대입니다.