Practice Test #3

Correct answer: B. Firewall. To prevent access to an Azure SQL database from another network, you use network access controls such as the Azure SQL server-level firewall rules (allow/deny public IP ranges) and/or virtual network rules with Private Link/Private Endpoint to restrict connectivity to a specific VNet. These controls operate at the network perimeter and determine whether traffic from a given source network can reach the database endpoint. Why not A (Authentication): Authentication controls who can log in after a connection is established. It does not stop a network from reaching the service endpoint; it only rejects invalid identities. Why not C (Encryption): Encryption protects confidentiality of data at rest or in transit, but it does not block network connectivity. An encrypted database can still be reachable from other networks unless firewall/VNet restrictions are configured.

Correct answer: A. Authentication. Supporting Azure Active Directory (Azure AD) sign-ins to Azure SQL Database is an authentication capability. Azure AD authentication enables users and applications to authenticate using Azure AD identities (users, groups, managed identities, service principals) instead of (or in addition to) SQL logins. This is commonly paired with modern security features like MFA and Conditional Access, improving identity security and aligning with best practices. Why not B (Firewall): A firewall can restrict where connections come from, but it does not provide Azure AD sign-in capability. You could allow traffic through the firewall and still not support Azure AD authentication if it’s not configured. Why not C (Encryption): Encryption secures data, but it does not determine how users authenticate. Azure AD sign-in is about identity verification and token-based authentication, not data confidentiality.

Correct answer: C. Encryption. Ensuring sensitive data never appears as plain text in an Azure SQL database points to encryption. In Azure SQL, this is most strongly associated with technologies like Always Encrypted, which keeps sensitive column data encrypted end-to-end so that the SQL engine never sees plaintext values (encryption/decryption occurs in the client driver). More generally, encryption mechanisms (TDE, TLS) protect data at rest and in transit, but the “never appears as plain text” wording aligns best with Always Encrypted-style protection. Why not A (Authentication): Authentication controls access by identity, but authenticated users (or admins) could still view plaintext data if it is stored unencrypted. Why not B (Firewall): Firewalls restrict network access but do not prevent plaintext storage or exposure once access is granted.

Normalization does not eliminate relationships between tables; it typically increases the need for well-defined relationships. When you normalize, you often split a wide table into multiple tables so that each table represents a single subject (entity) and each non-key attribute depends on the key. After splitting, you connect the tables using primary keys and foreign keys (relationships) to reconstruct the full view of the data through joins. For example, moving customer address details into a separate Address table and referencing it from a Customer table creates (or reinforces) a relationship rather than removing one. Eliminating relationships would be contrary to relational design and would usually lead to duplicated data or loss of referential integrity. Therefore, the statement is false, so the correct choice is No.

A primary goal of normalization is to reduce data redundancy (duplicate storage of the same facts). By organizing data into separate tables based on dependencies, you avoid repeating the same values across many rows. This reduces update anomalies—for instance, if a customer’s phone number is stored in multiple places, changing it in one place but not another creates inconsistency. In normalized designs, shared facts are stored once and referenced via keys. For example, storing product details in a Product table and referencing ProductID from an OrderLine table prevents repeating product name and description on every order line. While normalization can increase the number of tables and joins, it generally decreases redundant data storage and improves maintainability. Therefore, the statement is true, so the correct choice is Yes.

Normalization improves data integrity by reducing the likelihood of inconsistent or invalid data. When the same fact is stored in multiple locations (redundancy), it’s easy for those copies to diverge over time, harming consistency. Normalization centralizes each fact in one place and uses keys and constraints to enforce correct relationships. For example, with a properly normalized schema, a foreign key constraint can ensure that every Order references a valid Customer. This supports referential integrity. Additionally, by aligning columns with the correct entity and dependency rules (e.g., 2NF/3NF principles), you reduce anomalies where inserts, updates, or deletes accidentally create orphaned or contradictory data. Although integrity also depends on implementing constraints (PK, FK, UNIQUE, CHECK) and correct transactions, normalization is a foundational design practice that makes it easier to enforce and maintain integrity. Therefore, the statement is true, so the correct choice is Yes.

Yes. Processing salary payments once a month is a classic batch workload. The defining characteristics are (1) a fixed schedule (monthly), (2) a bounded set of records to process (all employees/payroll changes for the pay period), and (3) no requirement to process each individual payroll event the moment it occurs. Batch systems prioritize reliability, auditability, and throughput over low latency. In practice, payroll is often run as a scheduled job that aggregates time/attendance, applies deductions and taxes, and produces outputs (bank files, payslips, ledger entries) in one controlled run. Why not streaming? Streaming would imply continuous processing of payroll-related events in near real time (for example, calculating pay instantly as hours are logged). That is not the typical business requirement for monthly salary payments, where results are needed at the end of the pay cycle.

Yes. A wind turbine sending 50 sensor readings per second is an example of a streaming workload because it produces a continuous, high-velocity flow of events. At 50 readings/second, the data arrives frequently enough that it is naturally modeled as an event stream, and it commonly supports near-real-time use cases such as anomaly detection, predictive maintenance, operational dashboards, and alerting. In Azure terms, this pattern aligns with IoT telemetry ingestion (Azure IoT Hub or Event Hubs), real-time processing (Azure Stream Analytics, Databricks/Synapse Spark streaming), and storage/analytics for hot and warm paths (Azure Data Explorer, Cosmos DB, or a time-series optimized store). It’s not batch because you typically wouldn’t wait hours or days to process turbine telemetry if the goal is to detect faults quickly; the value comes from low-latency processing.

No. A home electricity meter that sends readings once a day is better described as a batch (or periodic) workload rather than streaming. Although the data may be transmitted electronically, the key factor is the low frequency and the implied lack of near-real-time processing requirements. Daily readings are typically used for billing, consumption summaries, and trend reporting—use cases that tolerate higher latency and are commonly processed in scheduled jobs. Why not streaming? Streaming implies continuous ingestion and processing of events as they occur, usually with seconds-to-minutes latency. Once-per-day telemetry is not a continuous high-velocity stream; it’s a periodic snapshot. In Azure, this would often be ingested and then processed via scheduled ETL/ELT (for example, Data Factory) rather than real-time stream processing services, unless there are additional requirements (like immediate outage detection) that would necessitate more frequent reporting.

Correct answer: A. a control flow In Azure Data Factory, control flow is the capability within a pipeline that orchestrates activity execution order and dependencies. You use dependency conditions (for example, an activity runs only when a prior activity Succeeds) and control activities such as If Condition, Switch, ForEach, Until, Wait, and Execute Pipeline to coordinate steps that rely on earlier outputs or completion states. This is exactly what “orchestrate pipeline activities that depend on the output of other pipeline activities” describes. Why the others are wrong: - B. Dataset: defines the data structure and location (tables, files, folders) used by activities; it does not control execution order. - C. Linked service: stores connection information (server, authentication, endpoints) to a data store or compute; not orchestration. - D. Integration runtime: provides the compute infrastructure for data movement and transformation (Azure IR, Self-hosted IR); it executes work but does not define dependency logic between activities.

Customer is a root object in the context of the provided JSON snippet. The snippet shows a top-level property named "customer" whose value is an object (it uses curly braces { }). Because it is not shown as being contained inside another named property (for example, inside a larger object like { "order": { "customer": { ... } } }), it is treated as the top-level/root object for this document. Why not A (nested array): "customer" is not in square brackets [ ], so it is not an array. Why not B (nested object): Although "customer" contains nested structures, the question’s intent is to classify "customer" itself. In this snippet, it is the primary/top-level object being described, so it is best classified as the root object.

Address is a nested object. Inside the "customer" object, the "address" property’s value is enclosed in curly braces { }, which indicates an object. Because it exists within the "customer" object rather than at the top level of the document, it is nested. Why not A (nested array): "address" is not defined with square brackets [ ], and it does not contain multiple elements; it is a single object with properties like "line 1", "line 2", and "ZIP code". Why not C (root object): A root object is the top-level object of the JSON document. "address" is clearly a child property under "customer", so it cannot be the root.

Social media is a nested array. The "social media" property is defined using square brackets [ ], which indicates an array. Each element in that array is an object (each has curly braces { } with "service" and "handle"). Because the array is contained within the "customer" object, it is nested. Why not B (nested object): While each item inside the array is an object, the "social media" property itself is an array of objects, not a single object. Why not C (root object): "social media" is not at the top level; it is a property inside "customer", so it is not a root object.

Correct answer: A. distributes processing across compute nodes. In Azure Synapse Analytics dedicated SQL pool, the MPP engine is designed to execute queries by splitting the work into parallel tasks that run across multiple compute nodes. The control node receives the client query, performs parsing and optimization, and then coordinates execution by distributing the query plan steps to the compute nodes. Each compute node processes its assigned data distributions in parallel, which is the core benefit of MPP for large analytics workloads. Why the others are wrong: - B (distributes processing across control nodes): Synapse does not distribute processing across multiple control nodes; the control node primarily orchestrates. - C (redirects client connections across compute nodes): Clients connect to the control node endpoint; compute nodes are not used for client connection redirection. - D (redirects client connections across control nodes): There isn’t a pool of control nodes for connection redirection in this model; the control node is the coordination point.