Practice Test #1
Simulate the real exam experience with 50 questions and a 45-minute time limit. Practice with AI-verified answers and detailed explanations.
50Questions45Minutes
Simulate the real exam experience with 50 questions and a 45-minute time limit. Practice with AI-verified answers and detailed explanations.
AI-Powered
Every answer is cross-verified by 3 leading AI models to ensure maximum accuracy. Get detailed per-option explanations and in-depth question analysis.
You manage an application that stores data in a shared folder on a Windows server. You need to move the shared folder to Azure Storage. Which type of Azure Storage should you use?
Azure Queue Storage is a messaging service for storing and retrieving messages between application components. It’s used to decouple services and handle asynchronous processing (e.g., background jobs). It does not provide a hierarchical file system, folders, or SMB/NFS access, so it cannot replace a Windows shared folder.
Azure Blob Storage is object storage for unstructured data such as images, videos, backups, and logs. Although you can store “files” as blobs, access is typically via HTTP/HTTPS and APIs/SDKs, not as an SMB-mapped drive. Using blobs would usually require application changes or an additional layer to emulate file share behavior.
Azure Files provides managed file shares in Azure that can be accessed using standard file protocols (SMB, and NFS in supported premium scenarios). It supports directory structures, file locking semantics, and can be mounted from Windows like a traditional network share. This makes it the correct choice to move a Windows server shared folder to Azure Storage with minimal application changes.
Azure Table Storage is a NoSQL key-value/column-family style store for semi-structured data, optimized for large scale and simple queries by partition and row key. It is not designed for file storage, does not provide folders or file share access, and cannot be used as a replacement for a Windows shared folder.
Core concept: This question tests which Azure Storage service best replaces a Windows server shared folder. A shared folder implies SMB/NFS access, directory/file semantics, and compatibility with existing applications that expect a file share rather than object storage. Why the answer is correct: Azure Files (Azure Storage file service) is designed to provide fully managed file shares in the cloud that can be accessed via the SMB protocol (and NFS for premium file shares in supported scenarios). This makes it the closest cloud equivalent to a Windows file share. You can lift-and-shift applications that read/write files using standard file APIs, map a drive letter from Windows, and preserve folder structures without rewriting the application to use object APIs. Key features and best practices: Azure Files supports SMB 3.x with encryption in transit, integrates with identity for access control (storage account keys/SAS, and for enterprise scenarios, identity-based auth via Active Directory Domain Services or Azure AD DS for SMB access). It also supports snapshots for point-in-time recovery, soft delete, and backup integration. For performance-sensitive workloads, consider Premium file shares (SSD-backed) and choose appropriate provisioned capacity/IOPS. From an Azure Well-Architected perspective, Azure Files improves operational excellence (managed service), reliability (redundant storage options like LRS/ZRS/GRS), and security (network restrictions, private endpoints, encryption). Common misconceptions: Blob storage is often chosen because it stores “files,” but it is object storage accessed via HTTP/SDKs and doesn’t behave like an SMB share without additional tooling. Queues and tables are non-file services used for messaging and NoSQL key-value storage, respectively. Exam tips: When you see “shared folder,” “SMB,” “lift-and-shift file server,” or “map a network drive,” think Azure Files. When you see “unstructured objects,” “HTTP access,” “data lake,” or “static content,” think Blob. Match the access pattern (file share vs object vs message vs NoSQL) to the storage type.
Which command-line tool can you use to query Azure SQL databases?
sqlcmd is the command-line utility designed to connect to SQL Server and Azure SQL Database and execute T-SQL queries or scripts. It supports interactive querying, running .sql files, and returning exit codes for automation. Because Azure SQL Database is T-SQL compatible, sqlcmd is a standard, exam-friendly choice for “querying” from the command line.
bcp (Bulk Copy Program) is a command-line tool for high-performance bulk data import/export between SQL Server/Azure SQL Database and data files. While it can execute a query to define exported rows, its primary purpose is bulk movement of data, not interactive or general-purpose querying. In exam terms, bcp aligns with data loading/unloading rather than querying.
azdata is a command-line tool associated with Azure data services administration scenarios (for example, SQL Managed Instance and Azure Arc-enabled data services) and integrates with some operational workflows. It is not the most common or canonical tool for simply querying Azure SQL Database with T-SQL in DP-900 context, making it a distractor here.
Azure CLI is used to manage Azure resources (provisioning, configuration, networking, identities), such as creating an Azure SQL logical server, configuring firewall rules, or setting policies. It is not a native T-SQL query client for Azure SQL Database. For running SQL queries, you would use tools like sqlcmd or client libraries rather than Azure CLI.
Core concept: This question tests how to interact with Azure SQL Database (a PaaS relational database) from the command line. In DP-900, you’re expected to recognize common tools used to connect to and run T-SQL queries against relational databases on Azure. Why the answer is correct: sqlcmd is the classic Microsoft command-line query utility for SQL Server and Azure SQL Database. It connects using a connection string (server name, database, authentication) and allows you to execute ad-hoc T-SQL statements or run scripts from files. Because Azure SQL Database is SQL Server–compatible at the T-SQL layer, sqlcmd is a direct and widely supported way to query it from terminals and automation pipelines. Key features and best practices: sqlcmd supports interactive sessions, executing .sql files, variable substitution, error handling/exit codes for automation, and output formatting. It works well in CI/CD and operational runbooks (for example, running schema checks or post-deployment validation). For Azure SQL Database, you typically connect to <servername>.database.windows.net and use Azure AD authentication or SQL authentication depending on your security posture. From an Azure Well-Architected Framework perspective (Security and Operational Excellence), prefer Azure AD auth where possible, avoid embedding passwords in scripts, and use managed identities or secure secret stores (for example, Key Vault) when automating. Common misconceptions: bcp is also a SQL Server tool, but it’s primarily for bulk import/export of data, not general querying. azdata is a newer CLI focused on data services scenarios (notably SQL Managed Instance and Azure Arc-enabled data services) and is not the standard “query tool” for Azure SQL Database in fundamentals questions. Azure CLI can manage Azure resources (create servers, set firewall rules), but it is not a T-SQL query client. Exam tips: For DP-900, map tools to their primary purpose: sqlcmd = run T-SQL queries/scripts; bcp = bulk copy data; Azure CLI = manage Azure resources; azdata = data platform administration scenarios. If the verb is “query” a SQL database, sqlcmd is the most direct and expected answer.
HOTSPOT - For each of the following statements, select Yes if the statement is true. Otherwise, select No. NOTE: Each correct selection is worth one point. Hot Area:
You can use Azure Data Studio to query a Microsoft SQL Server big data cluster.
Yes. Azure Data Studio can be used to query a Microsoft SQL Server big data cluster (BDC). A BDC is built on SQL Server and exposes SQL Server endpoints that can be queried using standard SQL Server connectivity. Azure Data Studio supports connecting to SQL Server instances and, historically, provided additional experiences for BDC through extensions (for example, managing and querying components of the cluster). Why “No” is incorrect: ADS is not limited to Azure-only databases; it is a general SQL client for SQL Server-family workloads. As long as you can reach the SQL endpoint (network access, firewall rules, authentication), ADS can run queries against it. In practice, you would configure the connection to the appropriate SQL Server endpoint for the cluster and then run T-SQL queries as you would for SQL Server.
You can use Microsoft SQL Server Management Studio (SSMS) to query an Azure Synapse Analytics data warehouse.
Yes. SQL Server Management Studio (SSMS) can query an Azure Synapse Analytics data warehouse (dedicated SQL pool). Synapse dedicated SQL pools expose a SQL endpoint that uses the Tabular Data Stream (TDS) protocol, which is the same core protocol used by SQL Server. Because of that compatibility, SSMS can connect, authenticate (SQL auth/Azure AD depending on configuration), and execute T-SQL queries. Why “No” is incorrect: While Synapse is not the same product as SQL Server, the dedicated SQL pool is intentionally SQL Server–compatible for many administrative and query operations. The exam expects you to recognize SSMS as a valid client tool for SQL-based Azure services (Azure SQL Database, SQL Managed Instance, and Synapse dedicated SQL pools), assuming networking and permissions are correctly configured.
You can use MySQL Workbench to query Azure Database for MariaDB databases.
Yes. MySQL Workbench can query Azure Database for MariaDB because MariaDB is MySQL-compatible and Azure Database for MariaDB supports standard MySQL client connections. MySQL Workbench uses the MySQL protocol and can connect to MariaDB servers for running queries, managing schemas, and performing basic administration. Why “No” is incorrect: Although MariaDB is a distinct fork of MySQL, it is designed for compatibility with MySQL clients and tools. In Azure, you must still ensure connectivity prerequisites: the server firewall rules allow your client IP, SSL/TLS settings match the server requirements, and you use the correct hostname/port (typically 3306) and credentials. With those in place, Workbench is an appropriate query tool.
You are writing a set of SQL queries that administrators will use to troubleshoot an Azure SQL database. You need to embed documents and query results into a SQL notebook. What should you use?
Microsoft SQL Server Management Studio (SSMS) is a primary administration tool for SQL Server and Azure SQL Database, offering query windows, Object Explorer, and management features. However, SSMS does not provide a native SQL notebook interface that combines Markdown documentation with executable cells and embedded results in a single notebook artifact. It’s great for interactive troubleshooting, but not for notebook-style documentation.
Azure Data Studio is the correct choice because it supports SQL notebooks that mix Markdown documentation with executable T-SQL cells and saved outputs. Administrators can embed query results directly in the notebook, creating repeatable troubleshooting runbooks. It is cross-platform and commonly used for modern data workflows, making it the go-to Microsoft tool when the question explicitly mentions “SQL notebook.”
Azure CLI is primarily used for provisioning and managing Azure resources (e.g., creating servers, configuring firewall rules, managing identities). While it can execute some database-related commands and automate tasks, it is not designed to author SQL notebooks or embed documentation and query results together. It lacks the integrated notebook UI and rich document experience required by the question.
Azure PowerShell is also focused on automation and management of Azure resources through cmdlets. It can help with operational tasks (e.g., configuring Azure SQL settings, exporting data, managing resource properties), but it is not a notebook authoring tool for embedding documents and query results. Although PowerShell can be used in some notebook platforms, the Microsoft SQL notebook feature referenced here is Azure Data Studio.
Core concept: This question tests knowledge of tooling for working with Azure SQL Database, specifically the ability to create and use SQL notebooks that combine narrative documentation (Markdown) with executable query cells and embedded results. In the Azure ecosystem, this capability is associated with notebook-style experiences used for troubleshooting, operational runbooks, and repeatable investigations. Why the answer is correct: Azure Data Studio is the Microsoft tool that provides built-in SQL notebooks. In Azure Data Studio, administrators can create notebooks that include text, images, and code cells (T-SQL, and in some contexts other kernels) and then execute queries against Azure SQL Database to capture and persist results directly in the notebook. This is ideal for troubleshooting because it creates a single, shareable artifact that documents the steps taken, the queries executed, and the outputs observed. Key features and best practices: Azure Data Studio notebooks support Markdown for documentation, parameterized and repeatable query execution, and saving outputs with the notebook. This aligns with operational excellence (Azure Well-Architected Framework) by enabling standardized runbooks, consistent troubleshooting procedures, and easier knowledge transfer. Notebooks can be stored in source control (e.g., Git) to version troubleshooting scripts and evidence. Azure Data Studio also integrates with extensions and supports connecting to Azure SQL Database securely. Common misconceptions: SSMS is a common choice for SQL administration, but it does not provide a native notebook experience for embedding documentation and results in a single notebook file. Azure CLI and Azure PowerShell are excellent for automation and resource management, but they are not notebook authoring tools for embedding query results alongside rich documentation. Exam tips: For DP-900, remember the mapping: SSMS is the traditional GUI for SQL Server/Azure SQL management; Azure Data Studio is the cross-platform tool with notebooks and modern workflows. When you see “SQL notebook,” “Markdown + query cells,” or “embed results,” the expected answer is Azure Data Studio.
HOTSPOT - To complete the sentence, select the appropriate option in the answer area. Hot Area:
Transparent Data Encryption (TDE) encrypts ______
Correct answer: C. TDE encrypts the database to protect data at rest. TDE performs real-time encryption and decryption of the database data and log files as they are written to and read from storage. Its primary purpose is to mitigate the risk of someone obtaining the underlying database files or backups and reading them outside the database engine. This is encryption at rest and is typically enabled per database. Why the others are wrong: - A: Column-level protection is not TDE. That describes approaches like Always Encrypted (client-side) or column-level encryption features. - B: Protecting queries/results in transit is handled by TLS/SSL (Encrypt=True in connection strings), not TDE. - D: TDE is not “server encryption.” While keys/certificates may be managed at the server level (especially in SQL Server), the encryption scope is the database files, not the entire server.
Want to practice all questions on the go?
Download Cloud Pass for free — includes practice tests, progress tracking & more.
Your company is designing an application that will write a high volume of JSON data and will have an application-defined schema. Which type of data store should you use?
Columnar stores (column-family or columnar analytics formats) are optimized for analytical workloads: scanning large datasets, aggregations, and high compression. They are common in data warehouses and OLAP scenarios (for example, Azure Synapse columnstore). They are not typically the best fit for high-volume operational writes of JSON with evolving structure, where low-latency point reads/writes and flexible schema are needed.
Key/value stores excel at very fast reads/writes when access is primarily by a single key (for example, caching, session state, simple lookups). While you can store JSON as a value, querying and indexing inside the JSON is usually limited or absent compared to document databases. For an application that needs to store and query JSON documents with an app-defined schema, document stores are generally the intended model.
Document stores are purpose-built for JSON and other semi-structured data. They support flexible, application-defined schemas, allow documents with varying fields, and provide rich querying and indexing over document properties. They also scale horizontally for high write volumes (for example, Azure Cosmos DB for NoSQL/MongoDB API). This matches the requirement of high-volume JSON writes with schema controlled by the application.
Graph databases are optimized for modeling and querying relationships (nodes/edges) and performing traversals such as “friends of friends” or dependency chains. Although graph databases can store properties that look like JSON, the primary value is relationship-centric querying, not high-volume ingestion of JSON documents as the main workload. Use graph when relationships and traversals dominate the access patterns.
Core concept: This question tests selecting the right non-relational (NoSQL) data model for semi-structured JSON with an application-defined schema. In Azure fundamentals terms, JSON data with flexible fields aligns to a document data store (for example, Azure Cosmos DB for NoSQL or MongoDB API). Why the answer is correct: A document store is designed to persist and query JSON documents efficiently at high write volumes. “Application-defined schema” implies schema-on-read (the app controls what fields exist and how they’re interpreted) rather than a rigid, centrally enforced schema typical of relational systems. Document databases natively store JSON, support indexing on properties, and allow documents in the same collection/container to have different shapes—ideal when the schema evolves. Key features and best practices: In Azure Cosmos DB, you model data as items (documents) in containers, choose a partition key to scale writes horizontally, and provision throughput (RU/s) or use autoscale to handle spikes. Proper partitioning is critical for high-ingest workloads to avoid hot partitions. Cosmos DB also supports configurable consistency levels (strong to eventual) to balance latency and correctness, aligning with Azure Well-Architected Framework performance efficiency and reliability pillars. Indexing policies can be tuned to reduce write cost if you don’t need every field indexed. Common misconceptions: Key/value stores can also handle high throughput, but they typically optimize for simple lookups by key and offer limited querying over nested JSON compared to document stores. Columnar stores are for analytics/OLAP and compression for read-heavy scans, not high-velocity operational writes. Graph stores are for relationship-centric queries (traversals), not primarily for high-volume JSON ingestion. Exam tips: When you see “JSON,” “semi-structured,” “flexible schema,” or “schema defined by the application,” think document database. When you see “relationships and traversals,” think graph. When you see “simple get/put by key,” think key/value. When you see “analytics, aggregations over large datasets,” think columnar/warehouse.
You have an application that runs on Windows and requires access to a mapped drive. Which Azure service should you use?
Azure Files is the correct choice because it provides managed file shares using SMB (and optionally NFS). Windows systems can map an Azure file share to a drive letter, meeting legacy application requirements that expect a traditional network share. It supports encryption in transit, snapshots, and can integrate with AD DS/Azure AD DS for Kerberos authentication, aligning with common enterprise Windows scenarios.
Azure Blob storage is object storage accessed via REST APIs (HTTP/HTTPS) and SDKs, optimized for unstructured data like images, logs, and backups. While you can simulate file access using tools or custom code, it is not a native SMB file share and is not intended to be mapped as a Windows drive for applications that require a mapped drive letter.
Azure Cosmos DB is a globally distributed NoSQL database service for low-latency, scalable data workloads (document, key-value, graph, column-family). It stores structured/semi-structured data and is accessed via database APIs, not as a file system. It cannot be mapped as a network drive and does not provide SMB file share functionality.
Azure Table storage (or Azure Tables in Storage accounts) is a NoSQL key-value store for large volumes of structured, non-relational data. It is accessed via REST APIs/SDKs and is designed for entities and properties, not files. It does not provide SMB shares and cannot satisfy a requirement for a Windows mapped drive.
Core concept: This question tests which Azure storage service supports traditional file shares that Windows apps can access via a mapped drive letter. In Azure, that capability is provided by Azure Files, which exposes SMB (and optionally NFS) file shares. Why the answer is correct: A Windows application that “requires access to a mapped drive” typically expects an SMB file share that can be mapped as a drive (e.g., Z:) using standard Windows networking. Azure Files provides fully managed file shares accessible over SMB 3.x, allowing you to map the share from Windows clients, Windows Server, or Azure VMs using the UNC path (e.g., \\storageaccount.file.core.windows.net\sharename) and credentials (storage account key or Azure AD DS/AD DS integration depending on configuration). This directly matches the requirement. Key features and best practices: Azure Files supports SMB encryption in transit, snapshots, and backup integration. For enterprise identity, Azure Files can integrate with on-prem AD DS or Azure AD DS for Kerberos-based authentication (useful to avoid embedding storage keys). Performance and cost depend on the storage account type/tier (Standard vs Premium FileStorage) and share provisioning. From an Azure Well-Architected Framework perspective, Azure Files improves operational excellence (managed service), reliability (durable storage with redundancy options like LRS/ZRS/GRS), and security (SMB encryption, identity integration). Common misconceptions: Blob storage is sometimes mistaken for “files,” but it’s object storage accessed via HTTP/HTTPS APIs, not a native mapped drive for Windows apps. Cosmos DB and Table storage are NoSQL data stores, not file shares. Exam tips: When you see “mapped drive,” “SMB,” “file share,” “lift-and-shift Windows app,” or “shared folder,” think Azure Files. When you see “unstructured objects,” “HTTP,” “images/videos,” think Blob. When you see “globally distributed NoSQL,” think Cosmos DB. When you see “key-value/NoSQL table,” think Table storage.
When can you use an Azure Resource Manager template?
Correct. ARM templates define Azure resources declaratively and can deploy multiple dependent resources as a single, repeatable deployment. They support dependency management (dependsOn), parameters for environment differences, and idempotent redeployment. This is a core Infrastructure as Code use case: consistently creating the same data platform stack (for example, storage + database + networking) across dev/test/prod.
Incorrect. Applying Azure policies for multi-tenant deployments is a governance scenario handled by Azure Policy (and policy initiatives), management groups, and RBAC. ARM templates can deploy policy definitions/assignments as resources, but the purpose described—applying policies for multi-tenant governance—is not what ARM templates are primarily “used for” in exam wording.
Incorrect. Provisioning Azure subscriptions is generally done through Azure billing/tenant processes, subscription creation APIs, or enterprise enrollment workflows, not via standard ARM template deployments. ARM templates deploy resources within an existing subscription (or at management group/tenant scope for certain resource types), but “provision subscriptions” is not the typical ARM template use case.
Incorrect. Controlling which services and features admins/developers can deploy from the Azure portal is primarily achieved with Azure Policy (deny/allowed SKUs/locations), RBAC, and sometimes management group governance. ARM templates can standardize deployments, but they do not directly restrict portal choices; governance controls do.
Core concept: Azure Resource Manager (ARM) templates are an Infrastructure as Code (IaC) mechanism for defining Azure resources declaratively in JSON. They are deployed through Azure Resource Manager, which is the control plane for creating, updating, and deleting Azure resources. Why the answer is correct: You use an ARM template when you want to automate the creation of an interdependent group of Azure resources in a repeatable, consistent way. A template can define multiple resources (for example, a storage account, a SQL server, a database, networking, and role assignments) and the relationships between them. ARM handles dependency ordering (via implicit dependencies and the dependsOn property) so resources are deployed in the correct sequence. This supports repeatable deployments across environments (dev/test/prod) and aligns with Azure Well-Architected Framework principles such as Operational Excellence (automation, repeatability) and Reliability (consistent configuration reduces drift). Key features and best practices: ARM templates support parameters (environment-specific values), variables (reuse), outputs (return resource IDs/connection strings), conditions (deploy resources only when needed), and modularization via linked templates or template specs. Deployments are idempotent: redeploying the same template converges the environment toward the declared state. Templates integrate with CI/CD (Azure DevOps/GitHub Actions) and can be validated/what-if analyzed before deployment. Common misconceptions: ARM templates are often confused with governance tools. Azure Policy is used to enforce rules and compliance, not to define and deploy full sets of resources. Azure Blueprints (now largely replaced by template specs + policy initiatives and other tooling) packaged governance artifacts, but that is different from ARM’s primary purpose of resource deployment. Also, ARM templates do not “provision subscriptions” in the typical exam sense; subscription creation is handled through Azure billing/tenant processes and management group governance, not standard ARM resource deployment. Exam tips: If the question mentions “repeatable deployments,” “infrastructure as code,” “deploy a set of resources together,” or “automate environment creation,” think ARM templates (or Bicep, which compiles to ARM). If it mentions “restrict what can be deployed” or “enforce standards,” think Azure Policy/RBAC. If it mentions “portal marketplace restrictions,” think Azure Policy/Blueprint-like governance, not ARM templates. Domain note: Although ARM templates are not a data service, DP-900 includes foundational Azure concepts that support data solutions, including how resources are deployed consistently for data workloads.
You need to create an Azure Storage account. Data in the account must replicate outside the Azure region automatically. Which two types of replication can you use for the storage account? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.
Zone-redundant storage (ZRS) replicates data synchronously across multiple availability zones within the same Azure region. It improves resiliency against a zonal outage, but it does not replicate to a different region. Therefore, it does not meet the requirement to replicate outside the Azure region automatically. ZRS is a “within-region” redundancy option, not a geo-replication option.
Read-access geo-redundant storage (RA-GRS) replicates data asynchronously to a secondary region (Azure paired region) and also provides a read-only endpoint in the secondary region. This satisfies the requirement for automatic replication outside the primary region and adds the capability to read from the secondary even during normal operations. It’s commonly used for DR plus read-scale scenarios.
Locally-redundant storage (LRS) replicates data within a single datacenter in a single Azure region (multiple copies, but local only). It protects against local hardware failures but not against datacenter-wide or regional outages. Because it does not replicate to another region, it fails the requirement to replicate outside the Azure region automatically.
Geo-redundant storage (GRS) replicates data asynchronously from the primary region to a secondary region (Azure paired region). This provides protection against regional outages and meets the requirement that data replicate outside the Azure region automatically. Unlike RA-GRS, GRS does not provide read access to the secondary endpoint unless a failover occurs.
Core concept: This question tests Azure Storage redundancy options and specifically which ones replicate data to a secondary Azure region automatically (geo-replication). Azure Storage offers multiple redundancy models: LRS, ZRS, GRS, and RA-GRS (and variants like GZRS/RA-GZRS, not listed here). Only the “geo” options replicate to a paired region. Why the answer is correct: Geo-redundant storage (GRS) and read-access geo-redundant storage (RA-GRS) both asynchronously replicate data from the primary region to a secondary region (typically the Azure paired region). This meets the requirement that data must replicate outside the Azure region automatically. GRS provides cross-region replication for disaster recovery, while RA-GRS adds the ability to read from the secondary endpoint even when the primary region is healthy. Key features, configurations, and best practices: - GRS/RA-GRS use asynchronous replication, so there is a potential RPO (some recent writes might not yet be in the secondary). - The secondary region is not user-selectable; it’s determined by Azure region pairing. - RA-GRS exposes a secondary read-only endpoint, useful for read-heavy workloads and improved read availability. - From an Azure Well-Architected Framework perspective, these options primarily support the Reliability pillar (resiliency and disaster recovery). Use them when business requirements demand regional disaster recovery beyond a single datacenter/zone. Common misconceptions: - ZRS sounds “more redundant,” but it only replicates across availability zones within the same region, not outside the region. - LRS is the default and cheapest, but it only protects against local hardware failures within a single datacenter. Exam tips: If the question says “outside the Azure region” or “to another region,” look for GRS/RA-GRS (or GZRS/RA-GZRS if offered). If it says “within the region across zones,” that’s ZRS. If it says “within a datacenter,” that’s LRS.
DRAG DROP - Your company plans to load data from a customer relationship management (CRM) system to a data warehouse by using an extract, load, and transform (ELT) process. Where does data processing occur for each stage of the ELT process? To answer, drag the appropriate locations to the correct stages. Each location may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content. NOTE: Each correct selection is worth one point. Select and Place:
Extract: ______ Location
Extract in an ELT pipeline means reading data from the source system. Here, the source is the CRM system, so extraction occurs from (and logically “at”) the CRM system. In practice, a connector/service (for example, Azure Data Factory) initiates the read, but the data being extracted originates from the CRM. Why not A (in-memory data integration tool)? That describes where transformations might run in ETL, but extraction is not “performed inside” an in-memory tool; it is a data movement operation that pulls from the source. Why not C (data warehouse)? The warehouse is the destination; it does not contain the CRM data until after the load step. Therefore, the correct location for Extract is the CRM system.
Load: ______ Location
Load in ELT is the step where the extracted data is written into the target analytical store. Since the scenario states the destination is a data warehouse, the load location is the data warehouse. This often means landing raw or minimally processed data into staging/landing tables (or files) inside the warehouse environment. Why not B (CRM system)? The CRM is the source; you do not “load” into the source as part of an ELT pipeline to a warehouse. Why not A (in-memory data integration tool)? An external tool may orchestrate the load, but the data is loaded into the warehouse, not into the tool’s memory as the final destination. In ELT, the warehouse becomes the central place where data is stored and prepared for analytics.
Transform: ______ Location
Transform in ELT occurs after the data is loaded into the destination. Therefore, transformations are performed in the data warehouse using its compute engine (typically SQL-based transformations such as joins, aggregations, cleansing, and creating dimensional models). This is a defining characteristic of ELT: leverage the scalable compute of the warehouse to do the heavy processing. Why not A (in-memory data integration tool)? That aligns with ETL, where an external integration engine transforms data before loading it into the warehouse. The question explicitly states ELT, so transformation is not primarily done in the external tool. Why not B (CRM system)? Source systems are optimized for transactional workloads (OLTP) and should not be burdened with analytical transformations; also, ELT transformation happens after loading into the warehouse. Thus, Transform is in the data warehouse.
Download Cloud Pass and access all Microsoft DP-900 practice questions for free.
Want to practice all questions on the go?
Get the free app
Download Cloud Pass for free — includes practice tests, progress tracking & more.