Exploring Data Transformation with Google Cloud practice questions

Data creates value by revealing trends and by informing strategic decisions, not only by supporting the transaction that produced it.

The question is about what the data can do beyond invoicing. Identifying trends (seasonal volume) and informing strategic decisions (routing and pricing) are both value drawn from analysing the records. Archiving and replicating are tempting because they also handle the records, but they only keep the existing invoicing use cheaper or more reliable. Rehosting the application is an infrastructure change that leaves the data unused.

1. Note that the records are used for one transactional purpose today.
2. Ask which options extract new insight from the same records.
3. Keep trend analysis and evidence-based decision making.
4. Reject options that only store, protect or rehost the existing invoicing use.

Exam tip: Data that only completes transactions is under-used; its larger value comes from trends and better decisions.

Data fuels AI: machine learning models learn their behaviour from large volumes of relevant example data.

A predictive model is only as good as the data it learns from, so relevant historical claims are the essential ingredient. Hand-written rules are tempting because many fraud systems start that way, but ML exists to learn patterns that rules miss. Faster machines and dashboards help elsewhere in the process but do not supply the learning material.

1. Recognise that the insurer wants an ML model, not a report.
2. Recall that ML learns patterns from example data.
3. Pick the option that supplies relevant examples to learn from.
4. Reject compute, rules and reporting as secondary to data.

Exam tip: No relevant data, no useful model: data is the fuel for AI.

AI depends on complete, connected data. Data silos give models a partial picture and weaken the insight AI can produce.

Personalization needs a full view of each customer. Siloed departmental systems mean each model sees only a slice, which lowers accuracy. Collecting more data is the tempting near-miss: it sounds like the cure for weak AI, but more records inside each silo still never join up. The format and single-database options misstate how training works; formats are converted during processing and pipelines read from many sources.

1. Identify the AI goal: personalize offers for each customer.
2. Note the constraint: records are split and not shared.
3. Ask what a model trained on that data would miss.
4. Conclude that silos lead to an incomplete customer view.

Exam tip: Silos starve AI: a model can only learn from the data it can see.

Databases run day-to-day operations: they record transactions as they occur. Warehouses and lakes are for analysis.

Recording each order 'the moment it is placed' and updating stock is transactional work, which is what an operational database does. A warehouse is tempting because it also holds structured data, but it is built for analytical queries over history, not for capturing individual transactions.

1. Identify the workload: individual transactions recorded immediately.
2. Recall that operational databases handle transactions.
3. Recall that warehouses and lakes serve analysis.
4. Choose the operational database.

Exam tip: Run the business in a database; analyse the business in a warehouse.

Data warehouses separate analytics from operations and combine structured data from many sources for complex, historical analysis.

Two needs decide it: analysis must not slow operations, and it must combine data from several systems over years. A warehouse meets both. The read replica is the tempting near-twin because it solves the slowdown, but it still contains only one system's data. A bigger server keeps the conflict, and a lake holds raw rather than analysis-ready data.

1. Note the symptom: analytics on an operational database slow down transactions.
2. Note the scope: five years of data from several systems.
3. Recall that a warehouse consolidates structured data for analysis.
4. Check each alternative against both needs; only the warehouse meets them.

Exam tip: Analysing across systems and years is warehouse work, not a job for the transactional database.

Databases, data warehouses and data lakes each serve a different job: transactions, structured analysis, and raw data of any type kept for later use.

Three facts combine here. Bookings recorded as they happen are transactions, so they belong in a database. Raw device readings and scanned forms are varied, partly unstructured data kept for uses not yet defined, which is what a data lake holds. Monthly cross-clinic reports are structured analysis across sources, which is warehouse work. The tempting mapping keeps bookings in a database but swaps lake and warehouse; it fails because scans are not modelled tables and reports need curated data.

1. Classify each need: transaction, raw data for later use, or structured reporting.
2. Map transactions to a database.
3. Map raw, varied data with unknown future use to a data lake.
4. Map recurring structured reports to a data warehouse.
5. Pick the option that matches all three.

Exam tip: Database = transactions; data lake = raw data of any type; data warehouse = curated data for analysis.