Practice Test #3

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.