Practice Test #3

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

정규화는 테이블 간의 관계를 제거하지 않으며, 일반적으로 명확하게 정의된 관계의 필요성을 더 증가시킵니다. 정규화를 수행하면, 각 테이블이 하나의 주제(엔터티)를 나타내고 각 비키(non-key) 속성이 키에 종속되도록, 넓은 테이블을 여러 테이블로 분리하는 경우가 많습니다. 분리한 후에는 primary key와 foreign key(관계)를 사용해 테이블을 연결하고, join을 통해 데이터의 전체 뷰를 재구성합니다. 예를 들어, 고객 주소 세부 정보를 별도의 Address 테이블로 옮기고 Customer 테이블에서 이를 참조하도록 하면, 관계를 제거하는 것이 아니라 관계를 생성(또는 강화)하는 것입니다. 관계를 제거하는 것은 관계형 설계에 반하는 것이며, 보통 데이터 중복이나 referential integrity의 손실로 이어집니다. 따라서 해당 진술은 거짓이므로, 정답은 아니오입니다.

정규화의 주요 목표 중 하나는 데이터 중복(동일한 사실을 중복 저장하는 것)을 줄이는 것이다. 종속성에 따라 데이터를 별도의 테이블로 구성하면, 많은 행에 걸쳐 동일한 값을 반복해서 저장하는 일을 피할 수 있다. 이는 갱신 이상을 줄여준다. 예를 들어 고객의 전화번호가 여러 곳에 저장되어 있다면, 한 곳에서는 변경했지만 다른 곳에서는 변경하지 않아 불일치가 발생할 수 있다. 정규화된 설계에서는 공유되는 사실을 한 번만 저장하고 키를 통해 참조한다. 예를 들어 Product 테이블에 제품 상세 정보를 저장하고 OrderLine 테이블에서 ProductID로 참조하면, 모든 주문 라인마다 제품명과 설명을 반복해서 저장하지 않아도 된다. 정규화는 테이블과 조인의 수를 늘릴 수 있지만, 일반적으로 중복 데이터 저장을 줄이고 유지보수성을 향상시킨다. 따라서 이 진술은 참이므로 정답은 예이다.

정규화는 일관되지 않거나 유효하지 않은 데이터가 발생할 가능성을 줄여 데이터 무결성을 향상시킵니다. 동일한 사실이 여러 위치에 저장되면(중복, redundancy) 시간이 지나면서 그 사본들이 서로 달라지기 쉬워 일관성이 손상됩니다. 정규화는 각 사실을 한 곳에 중앙화하고 key와 constraint를 사용해 올바른 관계를 강제합니다. 예를 들어, 적절히 정규화된 schema에서는 foreign key constraint가 모든 Order가 유효한 Customer를 참조하도록 보장할 수 있습니다. 이는 referential integrity를 지원합니다. 또한 column을 올바른 entity 및 dependency 규칙(예: 2NF/3NF 원칙)에 맞추면 insert, update, delete 시 실수로 orphaned 또는 모순된 데이터가 생성되는 anomaly를 줄일 수 있습니다. 무결성은 constraint(PK, FK, UNIQUE, CHECK) 구현과 올바른 transaction에도 좌우되지만, 정규화는 무결성을 더 쉽게 강제하고 유지할 수 있게 해주는 기본적인 설계 관행입니다. 따라서 해당 진술은 참이며, 정답은 예입니다.

예. 한 달에 한 번 급여를 지급 처리하는 것은 전형적인 batch workload입니다. 이를 규정하는 특징은 (1) 고정된 스케줄(매월), (2) 처리할 레코드 집합이 한정됨(해당 급여 기간의 모든 직원/급여 변경 사항), (3) 각 개별 payroll 이벤트가 발생하는 즉시 처리할 필요가 없음입니다. Batch 시스템은 낮은 latency보다 신뢰성, 감사 가능성(auditability), 처리량(throughput)을 우선합니다. 실제로 payroll은 종종 예약된 job으로 실행되어 근태(time/attendance)를 집계하고, 공제 및 세금을 적용하며, 하나의 통제된 실행에서 결과물(은행 파일, payslip, 원장(ledger) 엔트리)을 생성합니다. 왜 streaming이 아닌가? Streaming은 payroll 관련 이벤트를 거의 실시간(near real time)으로 지속적으로 처리하는 것을 의미합니다(예: 근무 시간이 기록되는 즉시 급여를 계산). 이는 월급 지급처럼 급여 주기 말에 결과가 필요한 일반적인 비즈니스 요구사항과는 다릅니다.

예. 초당 50개의 센서 측정값을 전송하는 풍력 터빈은 이벤트가 연속적이고 고속으로 흐르는 형태로 생성되기 때문에 streaming workload의 예입니다. 초당 50회라는 빈도는 데이터가 충분히 자주 도착하므로 자연스럽게 event stream으로 모델링되며, 이상 탐지, 예측 유지보수, 운영 대시보드, 알림과 같은 near-real-time use case를 지원하는 경우가 많습니다. Azure 관점에서 이 패턴은 IoT telemetry ingestion(Azure IoT Hub 또는 Event Hubs), real-time processing(Azure Stream Analytics, Databricks/Synapse Spark streaming), 그리고 hot/warm path를 위한 storage/analytics(Azure Data Explorer, Cosmos DB 또는 time-series에 최적화된 store)와 정렬됩니다. 이는 batch가 아닌데, 고장을 빠르게 감지하는 것이 목표라면 터빈 telemetry를 처리하기 위해 보통 몇 시간 또는 며칠을 기다리지 않기 때문입니다. 가치는 low-latency processing에서 나옵니다.

아니오. 하루에 한 번 측정값을 전송하는 가정용 전기 계량기는 streaming이라기보다 batch(또는 주기적) workload로 설명하는 것이 더 적절합니다. 데이터가 전자적으로 전송되더라도, 핵심 요소는 낮은 전송 빈도와 near-real-time 처리 요구사항이 없다는 점입니다. 일일 측정값은 일반적으로 청구, 사용량 요약, 추세 보고에 사용되며, 이러한 사용 사례는 더 높은 latency를 허용하고 보통 예약된 작업으로 처리됩니다. 왜 streaming이 아닌가? Streaming은 이벤트가 발생하는 대로 지속적으로 수집하고 처리하는 것을 의미하며, 보통 seconds-to-minutes 수준의 latency를 전제로 합니다. 하루 1회 telemetry는 연속적인 고속 스트림이 아니라 주기적 스냅샷입니다. Azure에서는 추가 요구사항(예: 즉각적인 정전 감지)으로 인해 더 빈번한 보고가 필요하지 않는 한, real-time stream processing 서비스보다는 예약된 ETL/ELT(예: Data Factory)를 통해 수집 후 처리하는 경우가 많습니다.

정답: A. control flow Azure Data Factory에서 control flow는 파이프라인 내에서 활동 실행 순서와 종속성을 오케스트레이션하는 기능입니다. 종속성 조건(예: 이전 활동이 Succeeds일 때만 활동 실행)과 If Condition, Switch, ForEach, Until, Wait, Execute Pipeline 같은 control activities를 사용하여, 이전 출력 또는 완료 상태에 의존하는 단계들을 조정합니다. 이는 “다른 파이프라인 활동의 출력에 의존하는 파이프라인 활동을 오케스트레이션”한다는 설명과 정확히 일치합니다. 다른 선택지가 틀린 이유: - B. Dataset: 활동에서 사용하는 데이터 구조와 위치(테이블, 파일, 폴더)를 정의하며, 실행 순서를 제어하지 않습니다. - C. Linked service: 데이터 저장소 또는 컴퓨팅에 대한 연결 정보(서버, 인증, 엔드포인트)를 저장하며, 오케스트레이션이 아닙니다. - D. Integration runtime: 데이터 이동 및 변환을 위한 컴퓨팅 인프라(Azure IR, Self-hosted IR)를 제공하며, 작업을 실행하지만 활동 간 종속성 로직을 정의하지는 않습니다.

Customer는 제공된 JSON 스니펫의 맥락에서 루트 객체입니다. 이 스니펫은 "customer"라는 최상위 속성을 보여주며, 그 값은 객체입니다(중괄호 { }를 사용합니다). 다른 이름의 속성 내부에 포함되어 있는 것으로 표시되지 않았기 때문에(예: { "order": { "customer": { ... } } } 같은 더 큰 객체 내부), 이 문서의 최상위/루트 객체로 취급됩니다. A(중첩 배열)가 아닌 이유: "customer"는 대괄호 [ ] 안에 있지 않으므로 배열이 아닙니다. B(중첩 객체)가 아닌 이유: "customer"가 중첩 구조를 포함하고 있기는 하지만, 질문의 의도는 "customer" 자체를 분류하는 것입니다. 이 스니펫에서 이는 설명 대상이 되는 주요/최상위 객체이므로 루트 객체로 분류하는 것이 가장 적절합니다.

Address는 중첩 객체입니다. "customer" 객체 내부에서 "address" 속성의 값은 중괄호 { }로 둘러싸여 있는데, 이는 객체를 나타냅니다. 또한 문서의 최상위 수준이 아니라 "customer" 객체 안에 존재하므로 중첩되어 있습니다. A(중첩 배열)가 아닌 이유: "address"는 대괄호 [ ]로 정의되어 있지 않으며, 여러 요소를 포함하지도 않습니다. "line 1", "line 2", "ZIP code"와 같은 속성을 가진 단일 객체입니다. C(루트 객체)가 아닌 이유: 루트 객체는 JSON 문서의 최상위 객체입니다. "address"는 명확히 "customer" 아래의 자식 속성이므로 루트가 될 수 없습니다.

소셜 미디어는 중첩 배열입니다. "social media" 속성은 대괄호 [ ]를 사용하여 정의되어 있으며, 이는 배열을 의미합니다. 해당 배열의 각 요소는 객체입니다(각 요소는 중괄호 { }를 가지며 "service"와 "handle"을 포함합니다). 또한 이 배열은 "customer" 객체 안에 포함되어 있으므로 중첩되어 있습니다. B(중첩 객체)가 아닌 이유: 배열 내부의 각 항목은 객체이지만, "social media" 속성 자체는 단일 객체가 아니라 객체들의 배열입니다. C(루트 객체)가 아닌 이유: "social media"는 최상위 레벨에 있지 않고 "customer" 내부의 속성이므로 루트 객체가 아닙니다.

정답: A. compute node 전반에 걸쳐 처리를 분산합니다. Azure Synapse Analytics dedicated SQL pool에서 MPP 엔진은 여러 compute node에 걸쳐 병렬로 실행되는 작업으로 업무를 분할하여 쿼리를 실행하도록 설계되었습니다. control node는 클라이언트 쿼리를 수신하고, 구문 분석 및 최적화를 수행한 다음, 쿼리 계획 단계들을 compute node에 분배하여 실행을 조정합니다. 각 compute node는 할당된 data distribution을 병렬로 처리하며, 이것이 대규모 분석 워크로드에서 MPP의 핵심 이점입니다. 다른 선택지가 틀린 이유: - B (control node 전반에 걸쳐 처리를 분산): Synapse는 여러 control node에 걸쳐 처리를 분산하지 않으며, control node는 주로 오케스트레이션을 수행합니다. - C (compute node 전반에 걸쳐 클라이언트 연결을 리디렉션): 클라이언트는 control node 엔드포인트에 연결하며, compute node는 클라이언트 연결 리디렉션에 사용되지 않습니다. - D (control node 전반에 걸쳐 클라이언트 연결을 리디렉션): 이 모델에는 연결 리디렉션을 위한 control node 풀(pool)이 없으며, control node가 조정 지점입니다.