Practice Test #2

정답 매칭은 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을 제공하지 않습니다.