Microsoft DP900 기출 연습문제 (1)

2026. 1. 26. 09:43·Microsoft Azure

이번 포스팅은 Microsoft Azure의 DP-900 자격증 공부 기록 및 오답노트입니다. Microsoft Azure의 DP900 기출문제를 바탕으로 O/X 퀴즈 및 객관식 문제를 준비했습니다. 

 

■  ( ) 는 본래 엔티티 간의 관계 분석을 지원합니다. 

 

- 컬럼 패밀리 데이터베이스(Column family database)

- 문서 데이터베이스 (Document database)

- 그래프 데이터베이스 (Graph database) - O

- 키-값 저장소 (Key-value stores)

 

해설) NoSQL 데이터베이스의 4가지 유형

 

컬럼 패밀리 데이터베이스 (Column-family Database)는 일반적인 관계형 DB가 '행(Row)' 단위로 데이터를 저장한다면, 여기서는 '열(Column)' 단위로 묶어서 저장합니다. 행마다 서로 다른 컬럼을 가질 수 있으며, 특정 컬럼들을 그룹화(Family)하여 관리합니다.

 

문서 데이터베이스 (Document Database)는 데이터를 JSON, BSON, XML 같은 '문서' 형태로 저장합니다.

 

그래프 데이터베이스 (Graph Database)는 이름 그대로 데이터를 '그래프' 형태로 관리합니다. 데이터는 노드(Node, 엔티티)로, 데이터 간의 관계는 엣지(Edge, 관계)로 표현합니다.

 

키-값 저장소 (Key-Value Store)는 가장 단순한 형태의 NoSQL 데이터베이스입니다.


■  JSON 문서에 있는 각 엔티티를 위해서 필드를 다양화하는 것은 ( ) 의 예입니다. 

 

- 관계형 데이터 (relational data)

- 반구조화된 데이터 (semi-structured data) - O

- 구조화된 데이터 (structured data)

- 비구조화된 데이터 (unstructured data)

 

해설) 데이터의 형식을 분류하는 기준

 

JSON(JavaScript Object Notation)은 데이터를 키-값(Key-Value) 쌍으로 표현합니다. 이때 "필드를 다양화한다"는 것은 같은 종류의 데이터(엔티티)라도 항목마다 가지고 있는 정보의 종류가 다를 수 있음을 의미합니다.

 

관계형 데이터 (Relational Data)는 구조화된 데이터의 대표적인 유형입니다.

반구조화된 데이터 (Semi-structured Data)는 행과 열의 엄격한 구조는 없지만, 데이터 내부에 태그나 키가 있어 데이터 간의 구분이 가능한 형태입니다.

구조화된 데이터 (Structured Data)는 엄격한 규칙(스키마)에 따라 표(Table) 형태로 정리된 데이터입니다.

비구조화된 데이터 (Unstructured Data)는 내부 구조가 전혀 정의되지 않은 데이터입니다.


■  회사에서 애저의 관계형 데이터베이스를 사용하려고 합니다. 지속적인 관리 비용을 최소화하려면 어떤 Azure Service를 사용해야 할까요?

 

- Azure HDInsight

- Azure SQL Database - O

- Azure Cosmos DB

- SQL Server on Azure Virtual Machine

 

해설) IaaS(서비스형 인프라)와 PaaS(서비스형 플랫폼)의 차이

 

Azure SQL Database는 대표적인 PaaS(Platform as a Service) 모델입니다. 데이터베이스 전문가가 수동으로 수행해야 할 관리 업무(Admin Task)가 획기적으로 줄어들기 때문에 지속적인 관리 비용(운영 오버헤드)이 가장 낮습니다.

 

Azure HDInsight는 오픈 소스 분석 프레임워크(Hadoop, Spark, Hive 등)를 실행하기 위한 클라우드 서비스입니다.

Azure SQL Database는 하드웨어나 OS를 신경 쓸 필요 없는 데이터베이스 서비스입니다.

Azure Cosmos DB (NoSQL PaaS)는 전 세계적으로 분산 가능한 NoSQL 데이터베이스 서비스입니다.

SQL Server on Azure Virtual Machine는 Azure 클라우드 위에 가상 머신(VM)을 만들고 그 안에 SQL Server를 직접 설치하는 방식입니다. 관리비용이 가장 높습니다. 사용자가 직접 OS 패치, SQL Server 업데이트, 백업 설정, 보안 설정을 관리해야 합니다. 클라우드에서 제공하는 가장 높은 수준의 제어권을 갖지만, 그만큼 관리 인력과 시간이 많이 듭니다.


■  Azure Resource Manager 템플릿은 언제 사용할까요?

 

- 상호 의존적인 Azure 리소스 그룹의 생성을 자동화하여 반복 가능한 방식으로 수행 - O

- 여러 테넌트에 배포하기 위해 Azure 정책을 적용

- 애저 구독을 프로비저닝

- 관리자나 개발자가 배포할 수 있는 서비스 및 기능을 제어 

 

해설) Azure Resource Manager (ARM) 템플릿의 개념과 목적

 

ARM 템플릿은 코드형 인프라(Infrastructure as Code, IaC)를 실현하는 도구입니다. 예를 들어 '웹 서버'는 '가상 네트워크'가 먼저 있어야 만들어질 수 있습니다. ARM 템플릿은 이런 리소스 간의 순서(의존성)를 스스로 파악하여 올바른 순서로 배포합니다.

 

여러 테넌트에 배포하기 위해 Azure 정책을 적용: 이는 Azure Policy나 Azure Blueprints의 역할에 더 가깝습니다. 정책(Policy)은 리소스가 특정 규칙(예: 한국 리전만 사용 가능)을 준수하는지 강제하는 기능입니다.

애저 구독을 프로비저닝: 구독 자체를 프로비저닝하는 것은 대개 관리 계정 수준의 작업이며, ARM 템플릿은 이미 존재하는 구독 내부에 '리소스(DB, VM 등)'를 배치하는 것이 주 목적입니다.

관리자나 개발자가 배포할 수 있는 서비스 및 기능을 제어: 이는 Azure RBAC(역할 기반 액세스 제어)나 Azure Policy에 해당합니다. 템플릿은 배포를 '실행'하는 도구이지, 권한을 '제한'하는 도구가 아닙니다.


■  Azure SQL Database와 같이 Azure에서 제공하는 PaaS 관계형 데이터베이스의 이점 두 가지는 무엇인가요?

 

- 최신 기능에 대한 액세스 - O

- 백업과 재저장 과정의 완벽한 제어

- 데이터베이스내의 머신러닝 서비스

- 서버 인프라스트럭쳐를 유지하는데 소요되는 관리 비용을 줄임 - O

 

해설) PaaS(서비스형 플랫폼) 모델

 

최신 기능에 대한 액세스 : Azure SQL Database는 소위 '버전이 없는(Versionless)' 데이터베이스 서비스입니다. 클라우드 PaaS는 마이크로소프트가 백그라운드에서 최신 패치와 새로운 기능을 지속적으로 업데이트합니다.

백업과 재저장 과정의 완벽한 제어 : '완벽한 제어'는 사용자가 모든 것을 직접 설정하고 책임지는 IaaS(가상 머신)나 온프레미스의 특징입니다.

데이터베이스 내의 머신러닝 서비스 : 일부 Azure 데이터베이스 서비스(Managed Instance 등)에서 머신러닝 기능을 지원하긴 하지만, 이것이 PaaS 관계형 데이터베이스의 보편적이고 핵심적인 이점이라고 보기는 어렵습니다.

서버 인프라 유지 관리 비용 절감 : 물리적인 서버 하드웨어 구매, 랙 설치, 전력 관리, 운영체제(OS) 설치 및 보안 패치 등 이 모든 것을 관리 오버헤드(Administrative Overhead)라고 부릅니다.


■  Azure SQL 데이터베이스를 생성할 때, 항상 데이터베이스에 연결할 수 있는 계정은 무엇입니까?

 

- 데이터베이스를 생성하는 Microsoft Entra ID(구 Azure AD) account

- 논리적 서버의 server admin login account - O

- Microsoft Entra ID (구 Azure AD) administrator account

- sa account

 

해설)  Azure SQL Database의 보안 및 계정 관리 체계

 

Azure SQL Database를 처음 만들 때 가장 먼저 하는 작업 중 하나가 논리적 서버(Logical Server)를 생성하는 것입니다. 이때 반드시 서버 관리자 이름(Login)과 비밀번호를 설정해야 합니다.

 

Microsoft Entra ID (구 Azure AD) : Entra ID 인증은 Azure SQL Database에서 선택 사항입니다. 서버를 생성할 때 Entra ID 전용 인증을 강제하지 않는 한, Entra ID 계정은 별도로 'Active Directory 관리자'로 지정되어야만 데이터베이스에 연결할 수 있습니다.

sa 계정 (System Administrator) : 온프레미스 SQL Server에서는 sa 계정이 최고의 관리자 계정이지만, Azure SQL Database에서는 sa 계정을 직접 사용할 수 없습니다. 


■  개발팀은 윈도우 10과 우분투 OS를 가지는 데스크탑 컴퓨터를 가지고 있습니다. 개발자들은 그 컴퓨터에서 Azure SQL Database에 연결하고 쿼리해야 합니다. 개발자들은 IntelliSense와 같은 코드 지원 기능이 필요합니다. 개발자들이 어떤 도구를 사용하여 코드 지원을 얻을 수 있을까요?

 

- sqlcmd

- Microsoft SQL Server Management Studio (SSMS)

- Azure Data Studio - O

- Azure Data Explorer

 

해설)  운영체제(OS)의 다양성과 코드 지원(IntelliSense)

 

sqlcmd : sqlcmd는 명령줄 도구(CLI)입니다. 가볍고 빠르지만, 텍스트 기반이므로 IntelliSense 같은 그래픽 기반의 코드 지원 기능이 전혀 없습니다.

Microsoft SQL Server Management Studio (SSMS) : SSMS는 SQL Server와 Azure SQL을 관리하는 가장 강력한 도구 중 하나지만, 오직 Windows 환경에서만 실행됩니다. 문제의 요구사항인 'Ubuntu OS'를 충족하지 못하므로 오답입니다.

Azure Data Studio : 현대적인 데이터 개발자를 위해 만들어진 오픈 소스 기반의 크로스 플랫폼 도구입니다. 문제에서 언급된 Windows 10뿐만 아니라 Ubuntu(Linux), macOS에서도 모두 설치하고 사용할 수 있습니다.

Azure Data Explorer : 이는 특정 서비스(Azure Data Explorer/Kusto)를 위한 전용 웹 UI 및 분석 플랫폼입니다. 일반적인 Azure SQL Database에 연결하여 IntelliSense 기반의 SQL 개발을 하기 위한 주된 도구가 아닙니다.


■  Azure SQL Database에 연결할 때 multi-factor authentication(MFA)를 사용해야 하는데 어떤 유형의 인증을 사용해야 하나요?

 

- Service principal authentication

- Microsoft Entra ID (구 Azure AD) authentication - O

- SQL authentication

- Certifacate autehntication

 

해설)  보안 강화

 

MFA(다단계 인증)는 아이디와 비밀번호 외에 추가적인 인증(전화, 앱 승인 등)을 요구하는 기능인데, 이 기능은 중앙 집중식 ID 관리 서비스인 Microsoft Entra ID를 통해서만 제공됩니다.

 

Service Principal Authentication (서비스 주체 인증) : 서비스 주체는 '사람'이 아닌 애플리케이션'이나 '코드가 데이터베이스에 접속할 때 사용하는 신분증입니다. Entra ID의 일종이긴 하지만, MFA는 보통 '사람'이 로그인할 때 사용하는 개념이므로, 문제에서 묻는 MFA의 직접적인 해결책은 일반적인 Entra ID 사용자 인증입니다.

Microsoft Entra ID(구 Azure AD) : Microsoft Entra ID(구 Azure AD)는 Azure의 통합 신원 관리 시스템입니다.

SQL Authentication (SQL 인증) : 데이터베이스 내부에서 직접 생성한 아이디와 비밀번호를 사용하는 방식입니다. 가장 고전적인 방식이지만, MFA를 기본적으로 지원하지 않습니다.

Certificate Authentication (인증서 인증) : 디지털 인증서 파일을 사용하여 신원을 확인하는 방식입니다. 주로 보안이 엄격한 애플리케이션 간 통신에 쓰이지만, 우리가 흔히 말하는 사용자의 MFA(지문, OTP 등)와는 별개의 개념입니다.


■  Azure SQL Database와 비교할 때 Azure SQL managed instance에 데이터베이스를 호스팅하는 이점은 무엇인가요?

 

- 내장된 고가용성

- 교차 데이터베이스 쿼리 및 트랜잭션에 대한 네이티브 지원 - O

- 시스템이 주도하는 자동 백업

- 저장 중일 때 암호화 지원

 

해설) 인스턴스 수준의 기능 지원 여부

 

Azure SQL Managed Instance는 온프레미스(직접 설치한) SQL Server와 거의 100% 호환되도록 설계된 인스턴스 기반 서비스입니다.

 

내장된 고가용성 (High Availability): 두 서비스 모두 Microsoft가 99.99% 이상의 가용성을 보장하며, 장애 시 자동으로 복구되는 기능을 내장하고 있습니다.

교차 데이터베이스 쿼리 및 트랜잭션에 대한 네이티브 지원  : 하나의 인스턴스 안에 여러 개의 데이터베이스(DB1, DB2)를 만들었을 때, 별도의 복잡한 설정 없이 SELECT * FROM DB1.dbo.Table1 JOIN DB2.dbo.Table2와 같은 쿼리를 바로 실행할 수 있습니다.

시스템이 주도하는 자동 백업: 두 서비스 모두 사용자가 신경 쓰지 않아도 Azure가 자동으로 백업을 수행하고 보관합니다.

저장 중일 때 암호화 지원 (TDE): 데이터가 디스크에 저장될 때 암호화되는 TDE(Transparent Data Encryption) 기능은 Azure SQL 제품군 전체에서 기본적으로 제공됩니다.


■  디폴트로 Azure SQL Database는 ( ) 에 의해 보호됩니다. 

 

- NSG (Network Security Group)

- Server-level firewall - O

- Azure Firewall

- Azure Front Door

 

해설) 방화벽(Firewall)

 

NSG (Network Security Group) : NSG는 Azure 가상 네트워크(VNet) 내부의 서브넷이나 가상 머신(VM) 사이의 트래픽을 제어하는 도구입니다. Azure SQL Database는 기본적으로 공용 서비스(PaaS) 형태로 제공되기 때문에, 별도의 가상 네트워크 설정(Private Link 등)을 하기 전까지는 NSG가 아닌 자체 방화벽으로 보호됩니다.

Server-level firewall : Azure SQL Database를 생성하면 기본적으로 "모든 외부 접근 차단(Deny All)" 상태가 됩니다. 이를 관리하는 것이 바로 방화벽입니다.

Azure Firewall : Azure Firewall은 가상 네트워크 전체를 보호하는 기업용 대규모 네트워크 보안 서비스입니다. 여러 리소스와 구독을 가로질러 복잡한 정책을 관리할 때 쓰입니다.

Azure Front Door : Front Door는 전 세계 사용자를 대상으로 하는 웹 애플리케이션(HTTP/HTTPS) 가속 및 보안 서비스입니다. 데이터베이스 접속(T-SQL 프로토콜)을 보호하는 도구가 아니라, 웹사이트의 성능을 높이고 보안을 강화할 때 사용합니다. 


■  데이터베이스를 설계하고 모델링하기 위해 프로젝트 지향 오프라인 데이터베이스 개발을 지원하는 그래픽 도구를 사용해야 합니다. 무엇을 사용해야 하나요?

 

- Microsoft SQL Server Data Tool (SSDT) - O

- Microsoft SQL Server Management Studio (SSMS)

- Azure Databricks

- Azure Data Studio 

 

해설) 데이터베이스를 관리하는 도구와 개발/설계하는 도구의 차이점

 

Microsoft SQL Server Data Tool (SSDT) : SSDT는 Visual Studio에 통합된 도구 세트로, 데이터베이스를 소프트웨어를 개발하듯이 다룰 수 있게 해줍니다. 테이블 간의 관계를 시각적으로 보여주는 디자이너 기능을 제공하여 복잡한 모델링을 돕습니다.

Microsoft SQL Server Management Studio (SSMS) : 관리(Management)에 특화된 도구입니다.

Azure Databricks : Apache Spark 기반의 빅데이터 분석 및 AI 플랫폼입니다.

Azure Data Studio : 데이터 개발자와 분석가를 위한 가볍고 현대적인 코드 중심 도구입니다.


■  트랜잭션 애플리케이션이 Azure SQL Managed Instance에 데이터를 저장하고 있습니다. 언제 읽기 전용 데이터베이스 복제본을 구현해야 하나요?

 

- 트랜잭션 워크로드에 영향을 주지 않고 보고서를 작성할 때 - O

- 트랜잭션 애플리케이션을 편집할 때

- 지역 장애가 발생할 경우 고가용성을 구현해야 할 때

- 복구 시점 목표(RPO)를 개선해야 할 때 

 

해설) 읽기 스케일 아웃(Read Scale-Out)의 목적

 

왜 '읽기 전용 복제본'을 쓰나요?

트랜잭션 시스템(OLTP)의 주 목적은 데이터를 빠르게 쓰고, 수정하고, 삭제하는 것입니다. 그런데 여기에 복잡한 계산이 필요한 '보고서용 쿼리(대량의 조회)'가 들어오면 보고서 쿼리가 CPU와 메모리를 많이 점유하게 되어, 정작 중요한 결제나 주문 같은 트랜잭션 처리가 느려집니다.

똑같은 데이터를 가진 '복사본' 데이터베이스를 하나 더 만듭니다. 그리고 쓰기 작업(트랜잭션)은 원본에서, 조회 작업(보고서)은 복제본에서 수행하게 하여 서로의 성능에 간섭하지 않도록 분리하는 것입니다.

 

트랜잭션 애플리케이션을 편집할 때 : 애플리케이션의 코드를 수정(편집)하는 것과 데이터베이스의 복제본을 만드는 것은 아무런 상관이 없습니다.

지역 장애가 발생할 경우 고가용성을 구현해야 할 때 : 지역 장애에 대비하는 것은 장애 조치 그룹(Failover Groups)이나 지정학적 복제(Geo-replication)의 역할입니다. 단순히 읽기 전용 복제본을 하나 둔다고 해서 지역 전체의 장애를 해결하는 고가용성이 완성되는 것은 아닙니다.

복구 시점 목표(RPO)를 개선해야 할 때 : RPO(Recovery Point Objective, 복구 시점 목표)는 재난이나 장애가 발생했을 때, "우리가 어느 시점의 데이터까지 살려내야 하는가?"를 결정하는 기준입니다. RPO는 '데이터가 유실될 수 있는 최대 시간'을 의미하며 주로 백업 주기와 관련이 있습니다.


■  Azure SQL Database에 Products라는 테이블을 쿼리해야 합니다. 인터넷을 사용하여 테이블을 쿼리할 때 요구되는 세 가지 사항은 무엇인가요?

 

- 데이터베이스를 포함하는 리소스 그룹에 reader role을 할당해야 한다.

- Products 테이블에 SELECT 문으로 액세스 해야 한다. - O

- 데이터베이스에 사용자를 가져야 한다. - O

- 데이터베이스를 포함하는 리소스 그룹에 Contributor role을 할당해야 한다.

- IP address가 데이터베이스에 연결되도록 해야 한다. - O 

 

해설) Azure SQL Database의 보안 계층

 

쿼리를 하려는 내 컴퓨터의 공용 IP 주소가 방화벽 규칙에 등록되어 있어야 비로소 데이터베이스 서버에 발을 들여놓을 수 있습니다. 방화벽을 통과했다고 해서 끝이 아닙니다. "당신은 누구인가요?"라는 질문에 답할 수 있는 계정이 필요합니다. 우리가 앞서 공부했던 '서버 관리자 계정'이나 'Microsoft Entra ID 계정' 등이 데이터베이스 내부에 등록되어 있어야 로그인이 가능합니다. 로그인을 했더라도 모든 테이블을 볼 수 있는 것은 아닙니다. 데이터베이스 관리자로부터 Products 테이블에 대해 조회(SELECT) 권한을 부여받아야 합니다.

 

리소스 그룹에 Reader/Contributor Role 할당 : 이는 Azure 포털에서 리소스를 관리(데이터베이스를 삭제하거나 설정을 바꾸는 등)하기 위한 권한입니다.


■  ( ) 는 특정 컬럼값에 기반해 테이블 데이터를 물리적으로 정렬합니다.

 

- 뷰 (View)

- 클러스터형 인덱스 (Clustered Index) - O

- 저장된 프로시저 (Stored Procedure)

- 비클러스터형 인덱스 (Nonclustered Index)

 

해설) 데이터베이스의 저장 원리와 인덱스(Index)

 

클러스터형 인덱스의 가장 큰 특징은 데이터 그 자체를 정렬한다는 점입니다. 클러스터형 인덱스를 생성하면 테이블의 실제 데이터 행(Row)들이 인덱스로 지정한 컬럼의 순서에 맞춰 디스크 상에서 물리적으로 다시 정렬되어 저장됩니다.

 

뷰 (View) : 하나 이상의 테이블로부터 유도된 가상의 테이블입니다.

저장된 프로시저 (Stored Procedure) : 자주 사용하는 SQL 문들을 하나로 묶어 서버에 저장해 둔 함수/스크립트입니다.

비클러스터형 인덱스 (Non-clustered Index) : 실제 데이터는 그대로 두고, 데이터의 위치 정보(포인터)만 모아놓은 별도의 인덱스 페이지를 만듭니다.


■  구조화된 데이터로서 각 열이 하나의 데이터 엔티티를 표현하는 것은 어떤 스키마를 사용하나요?

 

- XML

- tabular - O

- blob

- JSON

 

해설) 데이터의 구조

 

Tabular는 우리가 흔히 사용하는 엑셀(Excel)이나 관계형 데이터베이스(SQL)의 '표' 형태를 의미합니다. 각 열은 데이터 엔티티의 속성(Attribute)이나 필드를 정의합니다. 예를 들어, '회원'이라는 엔티티가 있다면 '이름', '나이', '주소'라는 각 열이 그 엔티티의 세부 정보를 표현하게 됩니다.

 

JSON & XML (반구조화된 데이터) : 이들은 행과 열의 고정된 틀 대신 태그(XML)나 키-값 쌍(JSON)을 사용하여 데이터를 표현합니다. '반구조화(Semi-structured)' 데이터라고 부르며, 각 엔티티마다 필드가 다를 수 있는 유연성을 가집니다.

Blob (비구조화된 데이터) : Binary Large Object의 약자로, 이미지, 비디오, 오디오 파일처럼 내부 구조가 정해져 있지 않은 커다란 데이터 덩어리를 말합니다.



■  어떤 Azure 서비스가 2019년 기업 에디션인 Microsoft SQL Server로부터 마이그레이션 된 데이터베이스와 호환성이 가장 높은가요?

 

- Azure SQL Database

- Azure Database for MySQL

- Azure SQL Managed Instance - O

- An Azure SQL Database elastic pool

 

해설) Lift & Shift

 

Azure SQL Managed Instance는 온프레미스 SQL Server(특히 Enterprise Edition)와 거의 100%에 가까운 기능 호환성을 제공하도록 설계된 서비스입니다. 온프레미스 SQL Server의 최신 엔진과 코드를 공유하기 때문에, 마이그레이션 시 코드 수정이 거의 필요 없습니다.

 

인스턴스는 "데이터베이스 파일에 접근하여 메모리와 프로세스를 할당받아 실행 중인 소프트웨어 엔진 상태"를 말합니다.

 

Azure SQL Database : '단일 데이터베이스' 관리에 최적화된 PaaS입니다. 매우 높은 호환성을 갖추고는 있지만, 인스턴스 수준의 기능(예: SQL 에이전트, 교차 데이터베이스 쿼리 등)을 지원하지 않거나 다른 방식으로 구현해야 합니다.

Azure Database for MySQL : 아예 데이터베이스 엔진 자체가 다릅니다(SQL Server vs MySQL). 데이터 구조부터 쿼리 문법까지 대대적인 수정이 필요하므로 호환성이 가장 낮습니다.

An Azure SQL Database elastic pool : 여러 개의 Azure SQL Database가 리소스(CPU, 메모리)를 공유하여 사용하는 자원 관리 방식입니다.


■  Azure Cosmos DB 계정을 생성할 때만 구성할 수 있는 설정은 무엇입니까?

 

- geo-redundancy

- multi-region writes

- production or non-production account type

- API - O

 

해설) Cosmos DB의 구조적 특징

 

Azure Cosmos DB는 하나의 서비스 안에서 다양한 데이터 모델(문서, 그래프, 키-값 등)을 지원하는 멀티 모델 데이터베이스입니다. 계정을 생성할 때 선택하는 API(NoSQL, MongoDB, Cassandra, Gremlin, Table)는 해당 계정이 어떤 '언어'를 사용하고 데이터를 어떤 '형태'로 저장할지를 결정합니다.

 

Geo-redundancy (지리적 중복) : 데이터를 다른 지역(Region)에 복제해둘지 결정하는 옵션입니다. 처음에는 비용 절감을 위해 껐다가도, 나중에 서비스 규모가 커지거나 안정성이 중요해지면 언제든지 켤 수 있습니다.

Multi-region writes (다중 지역 쓰기) : 전 세계 여러 지역에서 동시에 데이터 쓰기를 허용할지 결정합니다. 읽기 전용 복제본만 쓰다가 나중에 쓰기 성능을 높이기 위해 설정을 변경할 수 있습니다.

Production or Non-production (개발/운영 계정 유형) : 주로 할인 혜택(Free Tier) 적용이나 권장 설정을 안내하기 위한 구분입니다. 이 설정 자체가 데이터베이스의 물리적 구조를 바꾸는 것은 아니므로 나중에 조정이 가능합니다.


■ SQL API를 사용하는 Azure Cosmos DB 계정이 있습니다. 컨테이너 레벨에서 구성해야 하는 두 가지 설정은 무엇입니까?

 

- 처리량 - O

- 읽기 지역

- 파티션 키 - O

- API

 

해설) Azure Cosmos DB의 자원 계층 구조(Hierarchy)

 

처리량 (Throughput, RU/s) : 처리량은 "이 컨테이너가 1초에 얼마나 많은 작업을 처리할 것인가"를 결정하는 성능 지표(Request Units)입니다. 처리량은 데이터베이스 전체가 공유할 수도 있지만, 특정 컨테이너의 성능을 보장하기 위해 컨테이너 개별적으로 할당하는 경우가 매우 많습니다.

파티션 키 (Partition Key) : 컨테이너는 데이터를 저장하는 실제 논리적 단위입니다. Cosmos DB가 방대한 데이터를 여러 서버(물리적 파티션)에 나누어 담을 때, 어떤 기준으로 나눌 것인가를 결정하는 것이 바로 파티션 키입니다.

 

읽기 지역 (Read Regions) : 데이터를 전 세계 어디에 복제하고 어디서 읽게 할지는 계정 레벨의 전역 설정입니다. 특정 컨테이너만 한국에서 읽고, 다른 컨테이너는 미국에서 읽게 설정하는 것이 아니라 계정 전체의 가용성을 위해 설정합니다.

API : API(NoSQL, MongoDB 등)는 계정을 생성할 때 딱 한 번 결정합니다. 계정 내의 모든 컨테이너는 이 API를 따라야 합니다.


■ 파일 및 폴더 수준에서 역할 기반 액세스 제어(RBAC)를 지원하는 스토리지 솔루션은 무엇입니까?

 

- Azure Disk Storage

- Azure Data Lake Stroage - O

- Azure Blob Storage

- Azure Queue Storage

 

해설) 계층 구조(파일 및 폴더)와 세밀한 권한 관리

 

Azure Data Lake Storage Gen2의 가장 큰 특징은 Azure Blob Storage의 경제성과 고성능 파일 시스템의 기능을 합쳤다는 점입니다. 일반적인 Blob Storage는 데이터를 평면적으로 저장하지만, ADLS는 실제 컴퓨터의 폴더 구조처럼 데이터를 관리합니다. 이 계층 구조 덕분에 특정 폴더 단위 또는 파일 단위로 "누구는 읽기만 가능", "누구는 수정 가능"과 같은 권한을 부여할 수 있습니다.

 

Azure Disk Storage : 가상 머신(VM)에 연결해서 쓰는 하드디스크(블록 스토리지)입니다. 디스크 자체에 대한 접근 권한은 RBAC로 제어하지만, 그 내부의 파일이나 폴더 권한은 디스크가 연결된 운영체제(Windows, Linux) 내부에서 관리해야 합니다.

Azure Blob Storage : 대규모 비정형 데이터를 저장하는 '객체 스토리지'입니다. 기본적으로 '플랫(Flat)'한 구조입니다. 폴더처럼 보이는 것은 이름표(Prefix)일 뿐, 실제 물리적인 폴더가 아닙니다. 폴더 수준의 세밀한 RBAC나 ACL을 기본적으로 지원하지 않습니다.

Azure Queue Storage : 애플리케이션 간에 메시지를 주고받기 위한 대기열 서비스입니다. 파일이나 폴더를 저장하는 용도가 아닙니다.


■ Azure Table Storage와 비교할 때, Azure Cosmos DB Table API의 장점은 무엇입니까?

 

- Azure 지역이 실패할 경우 복원력을 제공합니다.

- 파티셔닝을 지원합니다.

- 높은 저장 용량을 제공합니다.

- 다중 마스터 모델을 지원합니다. - O

 

해설) Azure Table Storage(기존)와 Azure Cosmos DB Table API(프리미엄)의  기능적 차이

 

Azure Cosmos DB는 전 세계적으로 분산된 데이터베이스 서비스입니다. 그중에서도 다중 마스터(Multi-region writes) 기능은 Cosmos DB만의 강력한 장점입니다. 전 세계 여러 지역(Region)에 복제본을 두고, 어느 지역에서든 데이터를 직접 '쓰기(Write)' 할 수 있는 기능입니다. 예를 들어 한국과 미국에서 동시에 데이터를 입력해도 시스템이 이를 알아서 동기화합니다.

 

나머지 보기들은 두 서비스가 공통으로 가지고 있거나, Cosmos DB만의 '독보적인' 장점이라고 보기에는 부족한 면이 있습니다.

복원력 제공 (Resilience): Azure Table Storage도 GRS(지리적 중복 저장)를 통해 지역 장애 시 복원력을 제공합니다. 따라서 Cosmos DB만의 차별점이라고 하기 어렵습니다.

파티셔닝 지원 (Partitioning): 두 서비스 모두 대규모 데이터를 관리하기 위해 파티션 키(Partition Key)를 사용한 파티셔닝을 지원합니다.

높은 저장 용량: 두 서비스 모두 테라바이트(TB) 급 이상의 대용량 데이터를 저장할 수 있도록 설계되어 있습니다.


■ Windows 서버의 공유 폴더에 데이터를 저장하는 애플리케이션을 관리하고 있습니다. 공유 폴더를 Azure Storage로 이동해야 합니다. 어떤 유형의 Azure Storage를 사용해야 합니까?

 

- Queue

- Blob

- File - O

- table

 

해설) 공용 네트워크 공유 폴더(Shared Folder)

 

Azure Files는 클라우드에서 제공하는 완전 관리형 파일 공유 서비스입니다. Windows 서버의 공유 폴더가 사용하는 표준 프로토콜인 SMB(Server Message Block)를 그대로 지원합니다.

 

Azure Queue Storage : 애플리케이션 간에 메시지를 주고받아 병목 현상을 해결하는 '메시징 서비스'입니다. 파일 저장과는 관련이 없습니다.

Azure Blob Storage : 이미지, 비디오, 로그 같은 비정형 데이터를 대량으로 저장하는 데 특화되어 있습니다. 일반적인 '파일 시스템' 구조가 아니기 때문에, 윈도우 탐색기에서 드라이브로 연결해서 쓰는 등의 작업에는 적합하지 않습니다.

Azure Table Storage : 키-값(Key-Value) 형태의 구조화된 데이터를 저장하는 NoSQL 저장소입니다. '파일'을 저장하는 곳이 아닙니다.


■ 귀사는 웹사이트의 세션 데이터를 포함하는 데이터베이스를 설계하고 있습니다. 데이터에는 알림, 개인화 속성, 쇼핑 카트에 추가된 제품이 포함됩니다. 데이터를 검색하는 데 가장 낮은 지연 시간을 제공하는 데이터 저장소 유형은 무엇입니까?

 

- Key/value - O

- Graph

- Columnar

- Document

 

해설) 매우 빈번하게 발생하고, 가장 빠른 응답 속도(Lowest Latency)를 요구하는 작업

 

Key-Value 저장소는 데이터베이스 유형 중 가장 단순하고 빠른 구조를 가지고 있습니다. 많은 Key-Value 저장소(예: Redis, Azure Cache for Redis)는 데이터를 디스크가 아닌 메모리(RAM)에 저장합니다. 이 덕분에 마이크로초(μs) 단위의 지연 시간을 제공하여 사용자에게 '실시간' 경험을 줄 수 있습니다.

 

Graph (그래프) : "내 친구의 친구가 좋아하는 제품"처럼 데이터 간의 복잡한 관계를 분석하는 데 특화되어 있습니다. 단순한 세션 조회를 하기에는 너무 과하고 속도도 느립니다.

Columnar (열 지향) : 수조 건의 데이터를 합산하고 평균을 내는 분석(OLAP)에 특화되어 있습니다. 개별 사용자의 세션을 빠르게 읽고 쓰는 작업에는 최악의 선택입니다.

Document (문서) : JSON 형태의 복잡한 데이터를 저장하기엔 좋지만, Key-Value 방식에 비해 데이터를 읽고 쓰는 과정에서 발생하는 오버헤드(부하)가 조금 더 큽니다. 초저지연이 최우선인 세션 관리보다는 일반적인 앱 데이터 저장에 더 많이 쓰입니다.


■ Windows에서 실행되며 매핑된 드라이브에 액세스해야 하는 애플리케이션이 있습니다. 어떤 Azure 서비스를 사용해야 합니까?

 

- Azure Files - O

- Azure Blob Storage

- Azure Cosmos DB

- Azure Table Storage 

 

해설) 네트워크 드라이브 연결(Z: 드라이브 등) 기능

 

Azure Files는 클라우드에서 제공하는 파일 공유 서비스로, 우리가 사무실에서 흔히 쓰는 '공용 폴더'나 'NAS'와 똑같은 역할을 합니다. Windows 탐색기에서 '네트워크 드라이브 연결' 메뉴를 통해 클라우드에 있는 저장 공간을 내 컴퓨터의 Z: 드라이브나 S: 드라이브처럼 바로 붙여서 쓸 수 있습니다.

 

Azure Blob Storage : 비정형 데이터를 저장하는 '객체 저장소'입니다. 웹 주소(URL)나 API를 통해 데이터를 주고받기 때문에, Windows 탐색기에서 드라이브 형태로 연결해서 쓰는 '매핑' 방식에는 적합하지 않습니다.

Azure Cosmos DB / Table Storage : 이들은 데이터를 저장하는 데이터베이스(DB)입니다. 파일이나 폴더를 관리하는 시스템이 아니므로 드라이브로 매핑한다는 개념 자체가 성립하지 않습니다.


■ 데이터베이스 정규화하면 쓰기 트랜잭션의 처리량이 증가한다. (X)

→ 정규화가 쓰기 성능(Throughput)을 반드시 향상시키는 것은 아니기 때문입니다.

 

■ 분석 시스템(OLAP) 은 트랜잭션 시스템(OLTP) 보다 더 정규화되어 있다. (X)

→ 데이터베이스의 두 가지 큰 유형인 OLTP와 OLAP의 특징을 반대로 설명하고 있습니다.

 

■ 데이터베이스를 정규화하면 조인이 더 많이 필요한 쿼리가 생성된다. (O)

→ 정규화는 하나의 커다란 테이블(예: 주문+고객+상품 정보가 다 들어있는 테이블)을 주제별로 작은 여러 개의 테이블로 분리하는 과정입니다. 분리된 데이터를 다시 하나의 정보로 합쳐서 보려면 JOIN 연산자를 사용하여 테이블들을 연결해야 합니다.

 

■ 관계형 데이터베이스에서 행은 테이블의 데이터 타입을 가진다. (X)

→ 관계형 데이터베이스에서 데이터 타입(Data Type)은 '행(Row)'이 아니라 '열(Column)'에 정의되기 때문입니다. 각 열은 이름(예: 이름, 나이, 가입일)과 해당 칸에 들어갈 데이터의 형식(Data Type)을 가집니다. 예를 들어 '나이' 열은 반드시 '정수(Integer)'여야 한다는 규칙을 가집니다.

 

■ MySQL Workbench를 사용하여 Azure Database for MariaDB 데이터베이스에 쿼리를 실행할 수 있습니다. (O)

→ MariaDB가 MySQL의 '포크(Fork)' 프로젝트로 시작되었기 때문에 술적으로 매우 높은 호환성을 유지하고 있습니다.

 

■ Azure에서 PaaS 데이터베이스를 사용한다면 데이터베이스 엔진 설치를 해야 한다. (X)

→ Azure 포털에서 "데이터베이스 만들기"를 누르면, 마이크로소프트가 미리 준비해둔 인프라 위에 이미 설치된 데이터베이스 엔진 인스턴스를 즉시 할당해 줍니다.

 

■ 단일 Azure Storage 계정 내의 Azure Table 스토리지는 다른 Azure 지역에서 여러 동시 읽기를 지원합니다. (O)

→ RA-GRS (Read-Access Geo-Redundant Storage) 덕분입니다. Azure Storage에서 GRS(지리적 중복 저장)를 설정하고 '읽기 액세스' 옵션을 켜면, 주 지역(Primary Region)뿐만 아니라 수백 킬로미터 떨어진 보조 지역(Secondary Region)에도 데이터 복제본이 생깁니다.

 

■ 단일 Azure Storage 계정 내의 Azure Table 스토리지는 다른 Azure 지역에서 여러 동시 쓰기를 지원합니다. (X)

→ 일반적인 Azure Storage(Table 포함)는 '단일 마스터' 구조를 가집니다. 데이터의 일관성을 유지하기 위해, 모든 쓰기(Write) 작업은 오직 주 지역(Primary Region) 한 곳에서만 처리됩니다. 보조 지역에 있는 데이터는 주 지역에서 넘어온 데이터를 복제하여 저장하는 '복사본'일 뿐이며, 사용자가 직접 보조 지역에 데이터를 쓸 수는 없습니다.

 

■ Azure Cosmos DB 계정의 각 데이터베이스는 별도로 구성된 Azure Cosmos DB API를 사용합니다. (X)

→ API는 '계정' 수준에서 결정됩니다. Cosmos DB의 API(NoSQL, MongoDB, Gremlin 등)는 Azure Cosmos DB 계정(Account)을 생성할 때 딱 한 번 선택합니다.

 

■ 같은 Azure Cosmos DB 논리적 파티션에 있는 항목들은 다른 파티션 키를 가질 수 있습니다. (X)

→ "같은 파티션 키 값을 가진 항목들의 모임"이 곧 "논리적 파티션"입니다. Azure Cosmos DB에서 데이터를 저장할 때 가장 중요한 기준이 바로 파티션 키(Partition Key)입니다. 논리적 파티션은 동일한 파티션 키 값을 가진 항목(Item)들의 집합입니다.

'Microsoft Azure' 카테고리의 다른 글

Microsoft DP900 기출 연습문제 (2)  (0) 2026.01.27
SQL Server in Docker & Kubernetes  (0) 2026.01.22
SQL Server on Linux 성능 향상  (0) 2026.01.21
SQL Server on Linux 보안 기능  (0) 2026.01.20
SQL Server on Linux 고가용성 그룹(AG) 구성  (0) 2026.01.17
'Microsoft Azure' 카테고리의 다른 글
  • Microsoft DP900 기출 연습문제 (2)
  • SQL Server in Docker & Kubernetes
  • SQL Server on Linux 성능 향상
  • SQL Server on Linux 보안 기능
David0903
David0903
  • David0903
    별별 코딩
    David0903
  • 전체
    오늘
    어제
    • 전체 (92)
      • Microsoft Azure (33)
      • FastAPI (8)
      • YOLO (4)
      • C++ (27)
      • Deep Learning (12)
      • Business Data Analysis (2)
      • Basic Data Analysis (5)
      • Statistics (1)
      • Data Analysis (0)
      • Computer Science (0)
      • InfoSec (0)
  • 블로그 메뉴

    • 홈
  • 링크

    • 블로그
  • 공지사항

  • 인기 글

  • 태그

    operator overloading
    원-핫 인코딩
    ROS
    call by value
    상속
    테스트셋
    경사하강법
    deep learning
    모델
    학습셋
    데이터 다루기
    딥러닝
    k겹 교차
    object
    c++
    call by reference
    생성자
    모델 설계
    deep learing
    Friend
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.6
David0903
Microsoft DP900 기출 연습문제 (1)
상단으로

티스토리툴바