Practice Test #4
50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
50문제45분700/1000
50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
프로젝트 지향적인 오프라인 데이터베이스 개발을 지원하는 그래픽 도구를 사용하여 데이터베이스를 설계하고 모델링해야 합니다. 무엇을 사용해야 합니까?
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를 떠올리세요.
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를 떠올리세요.
회사의 컴플라이언스 요구 사항을 충족하기 위해 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를 떠올리세요.
HOTSPOT - 문장을 완성하려면 답안 영역에서 적절한 옵션을 선택하세요. 핫 영역:
관계형 데이터는 서로 다른 테이블 간의 관계를 강제하기 위해 ______를 사용합니다.
정답: C (keys). 관계형 데이터는 서로 다른 테이블 간의 관계를 강제하기 위해 keys를 사용합니다. 구체적으로, primary key는 테이블의 각 row를 고유하게 식별하고, 다른 테이블의 foreign key는 그 primary key를 참조합니다. 데이터베이스 엔진은 이러한 제약 조건을 강제하여 referential integrity를 유지합니다(예: Orders row가 존재하지 않는 Customer를 참조하는 것을 방지). 이는 관계형 데이터베이스의 정의적 특징이며, 테이블 간 join이 동작하는 방식의 핵심입니다. 다른 선택지가 틀린 이유: - A (collections)는 비관계형 개념으로, 문서 데이터베이스(예: Azure Cosmos DB API for MongoDB)에서 흔히 사용되며 관계형 테이블과는 관련이 없습니다. - B (columns)는 테이블 내의 속성/필드를 정의하지만, columns만으로는 관계를 강제하지 못합니다. 관계 강제는 columns에 정의된 key constraints에서 비롯됩니다. - D (partitions)는 성능과 확장성(데이터를 스토리지/컴퓨트 경계로 분할)과 관련이 있습니다. partitioning은 쿼리 성능과 관리성을 개선할 수 있지만, 테이블 간 관계를 본질적으로 강제하지는 않습니다.
다음 테이블이 포함된 재고 관리 데이터베이스가 있습니다. ProductName Quantity Product1 100 Product2 129 Product3 176 SQL 쿼리에서 Product1의 재고 수량을 270으로 변경하려면 어떤 statement를 사용해야 합니까?
INSERT는 테이블에 새 행을 추가합니다. Product1에 INSERT를 사용하면 기존 Quantity 값을 변경하는 대신 추가 행(중복 제품)을 생성하게 됩니다. INSERT는 해당 제품이 아직 존재하지 않고 새 레코드로 추가하려는 경우에 적합합니다. 시험 문제에서 “change” 또는 “modify existing row”는 INSERT가 아니라 UPDATE를 가리킵니다.
MERGE는 source와 target 행을 매칭하여 하나의 statement에서 INSERT/UPDATE(때로는 DELETE) 로직을 결합합니다. 이는 업서트 시나리오(예: staging에서 데이터 로드: 매칭되면 update, 아니면 insert)에 유용합니다. 하지만 여기서는 Product1 행이 이미 존재하고 요구사항이 단순 수정이므로, UPDATE로 처리하는 것이 가장 적절하며 MERGE는 과도합니다.
UPDATE는 테이블의 기존 데이터를 수정하는 올바른 DML statement입니다. SET으로 새 값을 지정하고 WHERE clause로 WHERE ProductName = 'Product1'처럼 올바른 행을 대상으로 지정합니다. 이는 새 행을 만들지 않고 Product1의 Quantity를 100에서 270으로 직접 변경합니다. 표준 SQL에 부합하며 DP-900에서 자주 출제됩니다.
CREATE는 database, table, view, index 같은 데이터베이스 객체를 생성하는 DDL statement입니다. 테이블 내의 기존 데이터를 수정하지 않습니다. 문제가 재고 테이블 구조를 생성하는 것이라면 CREATE TABLE이 관련되겠지만, 기존 행의 값을 변경하는 데에는 CREATE가 해당되지 않습니다.
핵심 개념: 이 문제는 SQL에서 기본적인 관계형 데이터베이스 DML (Data Manipulation Language) 작업, 특히 테이블의 기존 행을 수정하는 방법을 평가합니다. 관계형 데이터베이스(예: Azure SQL Database, Azure VM의 SQL Server, Azure SQL Managed Instance)에서 기존 레코드의 값을 변경할 때는 UPDATE statement를 사용합니다. 정답이 맞는 이유: 이미 Product1에 대해 Quantity = 100인 행이 존재합니다. 요구사항은 해당 기존 값을 270으로 변경하는 것입니다. UPDATE는 이미 존재하는 행의 하나 이상의 컬럼을 수정하도록 설계되어 있으며, 일반적으로 WHERE clause로 올바른 행(들)을 대상으로 제한합니다. 올바른 패턴 예시는 다음과 같습니다: UPDATE Inventory SET Quantity = 270 WHERE ProductName = 'Product1'; WHERE clause는 매우 중요합니다. 이를 생략하면 모든 제품의 수량을 업데이트할 위험이 있으며, 이는 시험과 실무에서 흔한 함정입니다. 주요 특징 / 모범 사례: UPDATE는 관계형 시스템에서 트랜잭션을 지원하므로 commit 또는 rollback이 가능해 데이터 무결성을 지원합니다. 운영 환경에서는 실수로 여러 행이 업데이트되는 것을 방지하기 위해 ProductName이 고유하도록(Primary Key 또는 unique constraint로) 보장하는 것이 일반적입니다. Azure Well-Architected Framework 관점(신뢰성 및 보안)에서는 constraint, 트랜잭션, 최소 권한 접근(적절한 역할에만 UPDATE 권한 부여)을 사용해 위험을 줄입니다. 흔한 오해: INSERT는 기존 행을 수정하는 것이 아니라 새 행을 추가할 때 사용합니다. MERGE는 매칭 여부에 따라 insert/update/delete를 수행하는 “upsert” 로직에 사용할 수 있지만, 행이 존재한다는 것을 알고 있고 단순 변경만 필요할 때는 불필요합니다. CREATE는 테이블 같은 객체를 정의하는 DDL (Data Definition Language)로, 데이터를 변경하는 용도가 아닙니다. 시험 팁: DP-900에서는 CRUD 매핑을 기억하세요: Create=INSERT, Read=SELECT, Update=UPDATE, Delete=DELETE. 문제가 “기존 값을 변경”이라고 하면 UPDATE를 떠올리세요. “새 레코드 추가”라면 INSERT, “테이블/데이터베이스 생성”이라면 CREATE입니다. MERGE는 보통 하나의 statement에서 조건부 insert/update(업서트)가 필요할 때 사용합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
사용자가 Azure SQL database에 연결할 때 multi-factor authentication (MFA)를 사용하도록 보장해야 합니다. 어떤 유형의 authentication을 사용해야 합니까?
Service principal authentication은 Entra ID application identity(app registration)를 사용하며 일반적으로 non-interactive입니다. MFA는 service principal이 아니라 interactive user sign-in을 위해 설계되었습니다. service principal은 secret/certificate로 Entra ID에 authentication할 수 있지만, 동일한 방식으로 “MFA를 요구”하지는 않습니다. 대신 credential hygiene, managed identity, 그리고 해당되는 경우 workload identity를 위한 Conditional Access control로 보안을 강화합니다.
Azure Active Directory (Microsoft Entra ID) authentication은 나열된 옵션 중 Azure SQL Database 연결에 대해 MFA를 직접 강제할 수 있는 유일한 옵션입니다. SQL을 Entra ID identity와 통합하고 MFA 요구를 포함한 Conditional Access 정책을 지원합니다. 사용자는 Entra ID authentication 방법(예: Universal with MFA)을 사용해 연결하며, MFA challenge는 token issuance 과정에서 Entra ID가 처리합니다.
SQL authentication은 SQL engine에서 관리되는 SQL login(username/password)에 의존합니다. authentication이 Entra ID를 거치지 않으므로 MFA 요구 사항과 같은 Entra ID Conditional Access 정책을 적용할 수 없습니다. strong password, rotation, Azure SQL protection으로 보안을 개선할 수는 있지만, SQL authentication에서는 MFA 강제가 불가능합니다.
Certificate authentication은 Azure SQL Database 연결에서 표준 end-user authentication 방법이 아닙니다. certificate는 일반적으로 Entra ID에 application을 authentication하기 위한 용도(service principal의 credential) 또는 TLS encryption에 사용되지만, Azure SQL에 대한 user sign-in에 MFA 메커니즘을 제공하지는 않습니다. MFA 강제는 Entra ID user authentication flow에 연결됩니다.
핵심 개념: 이 문제는 Azure SQL Database 연결에 대해 multi-factor authentication (MFA)를 어떻게 강제하는지 테스트합니다. MFA는 Microsoft Entra ID(이전 Azure Active Directory)에서 제공하는 identity control입니다. Azure SQL Database는 여러 authentication 방법을 지원하지만, Conditional Access 정책(예: MFA 요구 사항 포함)을 직접 활용할 수 있는 것은 Entra ID 기반 sign-in뿐입니다. 정답인 이유: Azure Active Directory (Entra ID) authentication이 정답인 이유는 Azure SQL Database를 Entra ID identity(사용자, 그룹, managed identity)와 통합하고 Conditional Access를 지원하기 때문입니다. Conditional Access를 사용하면 사용자가 database에 authentication할 때 MFA를 요구할 수 있습니다(예: SSMS, Azure Data Studio로 연결하거나 interactive Entra ID authentication을 사용하는 application sign-in flow). SQL authentication은 Entra ID가 아니라 SQL에서 username/password를 저장하고 검증하므로 MFA를 강제할 수 없습니다. 주요 기능 / 강제 방식: 1) Azure SQL logical server에 대해 Entra ID admin을 구성합니다. 2) Entra ID identity에 매핑된 contained database user를 생성합니다(CREATE USER FROM EXTERNAL PROVIDER). 3) Entra ID authentication 방법을 사용합니다(예: SSMS/Azure Data Studio의 “Azure Active Directory - Universal with MFA”). 4) 관련 사용자/앱 및 cloud app(Azure SQL Database)에 대해 MFA를 요구하도록 Entra ID Conditional Access 정책을 적용합니다. 이는 Azure Well-Architected Framework 보안 원칙(centralized identity, strong authentication, conditional access control)과 일치합니다. 흔한 오해: - “Service principal authentication”은 MFA를 지원할 것처럼 보일 수 있지만, service principal은 non-interactive identity입니다. MFA는 interactive user sign-in을 위한 것입니다. workload의 경우 일반적으로 managed identity/certificate/secret을 사용하고, MFA가 아니라 least privilege 및 network control로 액세스를 제한합니다. - “Certificate authentication”은 end user를 위한 주요 Azure SQL Database authentication 모드가 아닙니다. certificate는 Entra ID에 대한 app/service authentication에 더 흔히 사용되며, SQL user MFA를 직접 제공하는 용도가 아닙니다. - “SQL authentication”은 익숙하고 단순하지만 Entra ID Conditional Access로 거버넌스할 수 없으므로 MFA를 요구할 수 없습니다. 시험 팁: 요구 사항이 “MFA를 강제”라면 “Entra ID authentication + Conditional Access”를 떠올리세요. Azure SQL에서 MFA는 SQL login이 아니라 Entra ID sign-in(interactive)을 통해 달성됩니다. 또한 DP-900은 개념적 이해에 초점을 둡니다—MFA를 database-native password가 아니라 identity provider 기능(Entra ID)과 연결하세요.
HOTSPOT - 다음 각 문장에 대해 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure의 Platform as a service (PaaS) 데이터베이스 오퍼링은 기본 제공 고가용성을 제공합니다.
예. Azure PaaS 데이터베이스 오퍼링의 핵심 특징은 서비스에서 기본 제공하는 고가용성(HA)입니다. 예를 들어, Azure SQL Database는 리전 내에서 복제본과 자동 장애 조치를 통해 서비스에서 관리하는 HA를 포함하며, 지원되는 리전/티어 구성에서는 zone redundancy를 추가할 수 있습니다. Azure Cosmos DB는 리전 내에서 데이터를 복제하며 자동 장애 조치가 포함된 다중 리전 복제로 구성할 수 있습니다. Azure Database for PostgreSQL/MySQL (Flexible Server)는 많은 리전에서 zone-redundant HA 옵션을 지원합니다. 중요한 DP-900 포인트는 (IaaS에서처럼) VM을 직접 클러스터링하여 HA를 구축하는 것이 아니라, 관리형 서비스에 통합되어 있고 구성 선택(티어, zone redundancy, geo-replication)을 통해 제공된다는 점입니다. 따라서 이 진술은 참입니다.
Azure의 Platform as a service (PaaS) 데이터베이스 오퍼링은 구성 가능한 스케일링 옵션을 제공합니다.
예. Azure의 PaaS 데이터베이스 오퍼링은 일반적으로 서비스 계층과 컴퓨팅 모델을 통해 구성 가능한 스케일링 옵션을 제공합니다. 예로는 서비스 목표(DTU/vCore)를 변경하여 Azure SQL Database를 스케일링하거나, 컴퓨팅에 대해 serverless 자동 스케일을 사용하거나, 일부 오퍼링에서 readable secondary를 통해 읽기 워크로드를 스케일 아웃하는 방법이 있습니다. Azure Cosmos DB는 처리량(RU/s)을 수동으로 또는 autoscale을 통해 스케일링할 수 있으며, 리전을 추가하여 전역적으로 스케일링할 수도 있습니다. Azure Database for PostgreSQL/MySQL은 컴퓨팅과 스토리지를 스케일링하는 것을 지원합니다(계층/리전에 따라 일부 제약이 있을 수 있음). 정확한 방식은 서비스마다 다르지만, 시험 관점의 핵심 개념은 PaaS가 탄력성을 위해 설계되었다는 점입니다. 즉, VM 크기, 디스크, 또는 클러스터 노드를 직접 관리하지 않고도 용량을 조정할 수 있습니다. 따라서 해당 진술은 참입니다.
Azure의 Platform as a service (PaaS) 데이터베이스 오퍼링은 하드웨어 관리를 위한 관리 오버헤드를 줄여줍니다.
예. PaaS 데이터베이스는 Microsoft가 기본 인프라를 운영하므로 하드웨어 관리를 위한 관리 오버헤드를 줄여줍니다. 물리 서버를 조달, 패치 또는 교체할 필요가 없으며, 일반적으로 guest OS 업데이트, 많은 플랫폼 패치, 그리고 백업/복구 관련 구성 요소의 상당 부분을 관리하는 것도 피할 수 있습니다. 대신 서비스 tier/size를 선택하고 논리적 설정(네트워크 액세스, authentication, encryption, backups/retention)을 구성한 뒤, 데이터와 워크로드 최적화에 집중합니다. 이는 shared responsibility model과 일치합니다. 즉, provider가 하드웨어와 플랫폼의 상당 부분을 관리하므로, 정기적인 유지보수 작업을 줄이고 자동화를 가능하게 하여 Operational Excellence를 향상시킵니다. 반대로 IaaS(Azure VMs에서 SQL Server)에서는 VM sizing, OS patching, storage layout, clustering/HA 설정 등 더 많은 항목을 사용자가 책임져야 합니다. 따라서 해당 진술은 참입니다.
HOTSPOT - 문장을 완성하려면 답변 영역에서 적절한 옵션을 선택하세요. 핫 영역:
대학교의 현재 학생 등록 수와 최대 수용 인원을 비교해 보여주는 시각화는 ______ 분석의 예입니다.
이 시각화는 descriptive analytics의 예입니다. 이는 알려진 기준(최대 수용 인원)에 대비하여 대학교의 등록 현황이라는 현재 상태를 요약하고 제시하기 때문입니다. Descriptive analytics는 기존 데이터를 집계하고 시각화하여(종종 KPI, 대시보드, 보고서 형태로) “무슨 일이 일어났는지”와 “지금 무슨 일이 일어나고 있는지”에 초점을 맞춥니다. 다른 선택지가 틀린 이유: - Cognitive analytics (A)는 자연어 처리, 컴퓨터 비전, 대화형 bot 등과 같이 AI 기반의 이해 또는 추론을 포함합니다. 단순한 등록 수 vs. 수용 인원 차트에는 cognitive 기능이 필요하지 않습니다. - Predictive analytics (C)는 미래 등록 수를 예측합니다(예: 다음 학기의 등록 수 예측 또는 수용 인원 초과 가능성 예측). 문제는 예측이 아니라 현재 등록 현황을 설명합니다. - Prescriptive analytics (D)는 제약과 최적화를 바탕으로 조치를 권고합니다(예: “새 분반 개설”, “수용 인원 확대”, “입학 정원 제한”). 이 시각화 자체는 의사결정을 처방하지 않고 상태를 보고하는 것입니다.
실시간 데이터 처리의 두 가지 특징은 무엇인가요? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택은 1점입니다.
오답입니다. “데이터가 주기적으로 처리된다”는 batch 처리를 설명하며, 데이터가 일정 시간 간격으로 수집된 뒤 스케줄(매시간, 매일 밤 등)에 따라 처리됩니다. 스케줄이 빈번하더라도 이벤트별로 연속 처리되는 것은 아닙니다. DP-900에서는 주기적 처리가 실시간 streaming이 아니라 batch analytics의 핵심 지표입니다.
정답입니다. 실시간 처리는 이벤트 생성과 인사이트/조치 사이의 시간을 최소화하도록 설계됩니다. 대시보드, 경고, 자동화된 응답이 빠르게 반응할 수 있도록 낮은 지연 시간(보통 수 초 이하)이 기대됩니다. 이는 더 긴 지연이 허용되는 batch 워크로드와의 핵심적인 차이점입니다.
오답입니다. 높은 지연 시간이 허용된다는 것은 매일 밤 수행되는 ETL/ELT 작업, 과거 보고, 대규모 변환처럼 즉시성이 필요하지 않은 batch 또는 offline 처리의 특징입니다. 실시간 시스템은 적시에 의사결정과 조치를 지원하기 위해 지연 시간을 줄이는 것을 목표로 합니다.
정답입니다. 실시간(stream) 처리는 batch가 쌓이기를 기다리지 않고, 데이터가 생성되거나 수신되는 대로 지속적으로 처리합니다. 이러한 event-driven 접근 방식은 이벤트가 시스템을 통과하는 동안(예: 사기 탐지 또는 IoT 텔레메트리 모니터링) near-immediate 집계, 필터링, 보강(enrichment), 패턴 탐지를 가능하게 합니다.
핵심 개념: 실시간 데이터 처리(종종 stream processing이라고도 함)는 데이터를 먼저 저장해 두었다가 나중에 batch로 처리하는 것이 아니라, 이벤트가 도착하는 대로 데이터를 지속적으로 처리하는 분석 워크로드 패턴입니다. Azure에서는 일반적으로 수집을 위해 Azure Event Hubs 또는 IoT Hub 같은 서비스에 매핑되고, 처리를 위해 Azure Stream Analytics, Azure Functions, 또는 Azure Databricks/Synapse의 Spark Structured Streaming에 매핑됩니다. 정답이 맞는 이유: 실시간 처리의 두 가지 대표적인 특징은 (1) 데이터가 생성/도착하는 즉시 처리된다(지속적 처리), (2) 낮은 지연 시간이 기대된다(결과가 빠르게 생성되며, 설계에 따라 보통 수 초 또는 sub-seconds)입니다. 따라서 옵션 D와 B가 실시간 처리의 핵심 정의와 일치합니다. 주요 기능 및 모범 사례: 실시간 시스템은 이벤트 스트림, partitions, 확장 가능한 consumers를 중심으로 설계됩니다. 또한 windowing(tumbling/hopping/sliding windows)을 사용해 시간에 따른 이벤트를 집계하고, late/out-of-order 이벤트를 처리하며, 대시보드, 경고(alerting), 이상 탐지(anomaly detection), 운영 자동화를 위한 near-instant 인사이트를 제공합니다. Azure Well-Architected Framework 관점에서는 Reliability(checkpointing, retries, exactly-once/at-least-once semantics), Performance Efficiency(partitioning, autoscale, backpressure handling), Cost Optimization(streaming units/throughput units 및 retention의 적정 sizing)을 고려해 설계합니다. 흔한 오해: 많은 학습자가 “real-time”을 “빠른 batch”로 혼동합니다. batch는 (매 1분처럼) 빈번할 수 있지만 여전히 주기적이며 진정한 event-driven은 아닙니다. 또한 “높은 지연 시간이 허용된다”는 실시간이 아니라 batch/offline 분석을 설명합니다. 시험 팁: DP-900에서는 다음의 단순한 대비를 기억하세요: - Batch analytics: 주기적 처리, 분~시간 단위 지연 시간 허용. - Real-time/stream analytics: 지속적 처리, 낮은 지연 시간 기대. “이벤트가 도착하는 대로(as events arrive)”, “즉각적인 인사이트(immediate insights)”, “alerting”, “low latency” 같은 표현이 보이면 실시간입니다.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure Synapse Analytics는 storage와 compute를 독립적으로 확장합니다
예. Azure Synapse Analytics dedicated SQL pool에서는 compute와 storage가 분리되어 있습니다. Compute는 DWUs (Data Warehouse Units)를 사용하여 프로비저닝 및 확장되며, 데이터는 Azure storage에 영구적으로 저장됩니다. 즉, 기본으로 저장된 데이터를 리사이즈하거나 마이그레이션할 필요 없이 성능 요구에 맞춰 compute를 확장하거나 축소할 수 있습니다. 이 설계는 성능 튜닝(피크 ETL/ELT 또는 보고 시간대에 scale up)과 비용 최적화(수요가 낮을 때 scale down)를 지원하면서도 데이터를 그대로 유지합니다. 반대 선택지(아니요)는 성능을 높이려면 storage도 늘려야 하거나 storage 변경이 compute 변경을 강제한다는 의미인데, 이는 dedicated SQL pool의 설계 방식이 아닙니다. 참고: 이 문장은 dedicated SQL pool 아키텍처와 가장 부합하며, serverless SQL pool도 storage에 있는 데이터에 대해 쿼리당 비용을 지불하므로 본질적으로 분리되어 있습니다.
Azure Synapse Analytics는 compute 비용을 줄이기 위해 일시 중지할 수 있습니다
예. Azure Synapse Analytics의 dedicated SQL pool은 일시 중지할 수 있습니다. 일시 중지하면 compute 리소스가 해제되어 compute(DWU) 요금이 중단되므로, 유휴 기간(예: dev/test 또는 배치 지향 워크로드에서 야간/주말) 동안 비용을 줄이는 데 도움이 됩니다. 중요한 점은, 일시 중지는 데이터를 삭제하지 않는다는 것입니다. storage는 유지되며 storage 요금은 계속 발생합니다. 다시 시작(Resume)하면 compute가 다시 온라인 상태가 되어 쿼리를 다시 실행할 수 있습니다. '아니요'라고 답하는 것은 틀립니다. 일시 중지는 dedicated SQL pool의 잘 알려진 비용 제어 기능이며 시험에서 자주 출제됩니다. 흔한 뉘앙스: 일시 중지는 dedicated SQL pool(프로비저닝된 data warehouse)에 적용됩니다. serverless SQL pool은 일시 중지할 프로비저닝된 compute가 없으므로 'pause'하지 않으며, pay-per-query 방식입니다.
Azure Synapse Analytics 데이터 웨어하우스에는 고정된 스토리지 용량이 있습니다
아니요. Azure Synapse Analytics 데이터 웨어하우스(dedicated SQL pool)는 작고 사전에 할당되며 변경할 수 없는 크기라는 의미에서 고정된 스토리지 용량을 갖지 않습니다. 스토리지는 컴퓨팅과 별도로 관리되며, 더 많은 데이터를 로드함에 따라 서비스 제한 및 조직의 제약(예: 할당량, 거버넌스 정책, 비용 통제)의 범위 내에서 증가할 수 있습니다. 이는 일부 서비스/티어에서 미리 고정된 최대 데이터베이스 크기를 선택하는 방식과 다릅니다. Synapse dedicated SQL pool에서는 주로 컴퓨팅 용량(DWU)을 선택하며 이를 스케일할 수 있고, 스토리지는 유지되면서 데이터에 따라 확장됩니다. 예를 선택하면 확장할 수 없는 고정 스토리지 크기를 미리 정의해야 한다는 의미가 되어, 일반적인 Synapse dedicated SQL pool 모델을 반영하지 못합니다.
Cloud Pass를 다운로드하고 모든 Microsoft DP-900 학습 문제를 무료로 이용하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.