Practice Test #2

예. 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에 가져온 경우에만 가능합니다.

정답: 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. hierarchical namespace를 활성화합니다. hierarchical namespace (HNS)를 활성화하면 storage account가 Azure Data Lake Storage Gen2로 전환됩니다. 이를 통해 실제 디렉터리와 파일(단순한 이름 prefix가 아님)을 제공하고, 디렉터리(폴더) 및 파일 수준에 적용할 수 있는 POSIX 스타일 ACL을 지원합니다. 또한 rename 및 move와 같은 atomic 디렉터리 작업을 활성화하며, 이는 partition/폴더를 재구성하는 analytics engine 및 data pipeline에 중요합니다. 다른 선택지가 틀린 이유: - B (Account kind = BlobStorage): 이는 레거시 account 유형이며 HNS, 디렉터리 object, 또는 ACL 기반 폴더 보안을 제공하지 않습니다. - C (Performance = Premium): Premium은 성능 특성과 가격(예: 특정 storage account 유형)을 변경하지만 hierarchical namespace나 폴더 ACL을 추가하지는 않습니다. - D (RA-GRS): Replication은 보조 region에서 내구성과 읽기 가용성을 향상시키지만, namespace 의미를 변경하거나 폴더 수준 보안을 활성화하지는 않습니다.

정답: A. A clustered index. A clustered index는 테이블의 데이터 행이 clustered index 키의 순서대로 물리적으로 저장되는 인덱스 유형입니다. 테이블의 물리적 구성을 결정하므로, 사실상 “키 값에 따라 테이블의 데이터 행을 정렬하고 저장”합니다. Azure SQL Database 및 SQL Server에서 테이블은 데이터의 물리적 정렬 순서가 하나뿐이므로 clustered index는 하나만 가질 수 있습니다. 다른 선택지가 틀린 이유: - B. FileTable: Windows 파일 시스템 의미 체계를 유지하면서 파일과 문서를 저장하고 관계형 액세스를 제공하기 위한 특수 기능이며, 테이블의 행 정렬을 정의하지 않습니다. - C. A foreign key: 자식 테이블과 부모 테이블 간의 참조 무결성을 강제하는 제약 조건이며, 행을 정렬하거나 저장하지 않습니다. - D. A stored procedure: SQL 문과 로직을 포함하는 프로그래밍 가능한 데이터베이스 객체이며, 물리적 행 저장 순서를 제어하지 않습니다.

정답 매칭은 table입니다. table은 데이터를 rows와 columns 형태로 저장하는 데 사용되는 기본 database object이며, relational data를 위한 영구적인 container입니다. view는 일반적으로 기본 데이터를 저장하지 않고 query definition을 저장합니다. index는 database가 데이터를 더 빠르게 찾도록 도와주지만, business data 자체를 저장하는 주요 object는 아닙니다.

정답은 view입니다. view는 하나 이상의 기본 table에 대해 수행되는 SELECT query로 내용이 정의되는 database object입니다. 이는 데이터의 기본 저장 위치로 동작하는 대신 virtual result set을 제공합니다. table은 실제 row를 저장하며, index는 query를 통해 내용을 정의하는 것이 아니라 query 성능을 향상시키는 데 사용됩니다.

정답은 index입니다. index는 row를 찾기 위한 효율적인 구조를 제공하여 data retrieval 속도를 향상시키는 database object입니다. 이는 많은 query에서 full table scan의 필요성을 줄여줍니다. table은 data 자체를 저장하고, view는 data의 query 기반 표현을 정의하므로, 둘 다 retrieval optimization에 가장 적합한 대상은 아닙니다.

정답: B. 단순 조회. 키/값 데이터 저장소는 키를 이미 알고 있을 때 값을 검색하는 데 최적화되어 있습니다(예: get session:12345 또는 get userPref:alice). 데이터 모델은 의도적으로 최소화되어 있으며, 저장소는 일반적으로 값을 불투명한 blob(string/JSON/binary)으로 취급하고, 기본 작업은 키 기반의 빠른 GET/SET입니다. 이러한 설계는 매우 낮은 지연 시간의 액세스와 쉬운 수평 확장을 가능하게 하므로, 키/값 저장소는 캐싱, 세션 상태, 빠른 구성 읽기에 흔히 사용됩니다. 다른 선택지가 틀린 이유: A. 제약 조건 강제 적용은 관계형 데이터베이스의 강점입니다(기본/외래 키, check constraints). 키/값 저장소는 일반적으로 스키마 또는 참조 무결성을 강제하지 않습니다. C. 테이블 조인은 관계형 기능이며, 키/값 저장소는 관련 테이블이 없기 때문에 조인을 지원하지 않습니다. D. 트랜잭션(특히 다중 레코드 ACID 트랜잭션)은 일반적으로 관계형 시스템과 연관됩니다. 일부 키/값 시스템은 제한적인 atomic operations를 제공하지만, DP-900 맥락에서 트랜잭션은 주요 최적화 목표가 아닙니다.

아니요. Azure Cosmos DB에서 API는 데이터베이스별로 별도 구성되는 것이 아니라 Azure Cosmos DB 계정 수준에서 구성됩니다. Cosmos DB 계정을 생성할 때 API(예: Azure Cosmos DB for NoSQL, MongoDB, Cassandra, Gremlin 또는 Table)를 선택합니다. 해당 계정 내에서 생성되는 모든 데이터베이스와 컨테이너는 동일한 API 모델과 endpoint/protocol을 사용합니다. “예”가 틀린 이유: 하나의 계정 안에서 데이터베이스마다 서로 다른 API(예: 한 데이터베이스는 NoSQL, 다른 데이터베이스는 MongoDB)를 사용할 수 있다는 의미가 되기 때문입니다. 시험 관점에서 Cosmos DB는 그런 구조가 아니며, API를 혼합하려면 별도의 Cosmos DB 계정이 필요합니다. 이는 API 선택이 SDK, 쿼리 언어/의미론, 호환성에 영향을 주며 계정의 기본 구성에 포함된다는 점에서 중요한 설계 고려사항입니다.

예. Partition key는 효율적인 라우팅과 분산을 가능하게 함으로써 Azure Cosmos DB에서 쿼리와 작업을 최적화하는 데 사용됩니다. 쿼리에 partition key가 포함되면(일반적으로 partition key 값에 대한 equality predicate), Cosmos DB는 관련 항목이 들어 있는 특정 logical partition을 대상으로 지정할 수 있습니다. 이렇게 하면 여러 partition에 걸친 스캔 또는 fan-out을 피할 수 있어 RU 소비를 줄이고 지연 시간을 개선합니다. 이것이 중요한 이유: partitioning은 주로 확장성과 성능을 위한 것입니다. 데이터와 처리량을 physical partition 전반에 분산하지만, 쿼리 효율성에도 직접적인 영향을 미칩니다. partition key를 지정하지 않는 쿼리는 cross-partition query가 될 수 있으며, 일반적으로 더 많은 RU가 들고 더 느릴 수 있습니다. index도 쿼리를 최적화하지만, partition key는 쿼리 타기팅을 위한 핵심 메커니즘이므로 Cosmos DB 기본 개념의 맥락에서 올바른 설명입니다.

아니요. 동일한 Azure Cosmos DB 논리적 파티션에 포함된 항목은 서로 다른 파티션 키 값을 가질 수 없습니다. 논리적 파티션은 컨테이너 내에서 동일한 파티션 키 값을 공유하는 항목들의 집합으로 정의됩니다. 따라서 두 항목의 파티션 키 값이 다르면 서로 다른 논리적 파티션에 속합니다. “예”가 틀린 이유: 논리적 파티션의 정의와 모순됩니다. Cosmos DB는 파티션 키 값을 사용하여 항목을 그룹화하며, 이러한 그룹화는 (지원되는 경우) 대상 읽기/쓰기와 효율적인 단일 파티션 쿼리/트랜잭션을 가능하게 합니다. 실무적으로 이것이 좋은 파티션 키를 선택하는 것이 중요한 이유입니다. 파티션 키는 항목이 어떻게 그룹화되는지를 결정하고, 데이터 분포(핫 파티션 방지)에 영향을 주며, 일반적인 쿼리와 작업이 단일 논리적 파티션에서 처리될 수 있는지 아니면 크로스 파티션 fan-out이 필요한지에 영향을 줍니다.

통과. 이미지에서의 올바른 매칭은 다음과 같습니다: 1) “JSON documents에 저장된 데이터에 대해 SQL queries를 사용할 수 있도록 함” → Azure Cosmos DB. Cosmos DB (Core/SQL API)는 항목을 JSON documents로 저장하며 SQL-like queries(SELECT, WHERE, documents 내 JOIN 등)를 지원합니다. 이는 DP-900에서 흔히 나오는 연관 관계로, SQL query language를 사용하는 JSON document database입니다. 2) “Server Message Block (SMB) version 3 protocol을 사용하여 사용자가 데이터에 액세스할 수 있도록 함” → Azure Files. Azure Files는 완전 관리형 SMB file shares(SMB 3.x)를 제공하며, 클라이언트 및 VM에서 마운트할 수 있습니다. 다른 선택지가 틀린 이유: Azure Blob storage는 object storage(REST/HTTP)이며 기본 인터페이스로 SMB를 통해 액세스하지 않습니다. Azure Table storage는 NoSQL key-value store(partition/row keys)이며 Cosmos DB처럼 JSON documents에 대해 SQL querying을 제공하지 않습니다.