CompTIA Data+ DA0-002 · Free study guide

Objective 1.2 — Identify data sources and repositories

An analysis is only as trustworthy as the source behind it. Two systems may contain fields with the same name while representing different events, refresh schedules, or populations. Before joining anything, an analyst should know where the data originated, how it was collected, when it was refreshed, who controls it, and whether it is complete enough for the decision.

This objective separates sources, which produce or expose data, from repositories, which organize data for later use. The same record may begin in an application database, move through an API, land in a lake, and eventually appear in a curated warehouse table.

Operational sources

Databases are common sources because applications record transactions in them. They usually offer clear types and keys, but production access must be controlled. A large analytical query can slow the customer-facing application, and a table built for transactions may omit the business history an analyst expects.

Application programming interfaces, or APIs, expose defined operations and response formats. APIs are useful when direct database access is unavailable or inappropriate. Reliable collection must account for authentication, pagination, rate limits, response errors, and version changes. A successful first response does not prove that every page was collected.

Website data may appear in HTML pages or embedded application responses. It can be public to view without being authorized for automated collection. Terms of service, privacy obligations, and technical stability all matter. A page layout can change without notice and break a scraper that depends on one element name.

Files include exports, spreadsheets, delimited text, documents, and images. They are easy to transfer but often weak on control. An analyst should verify delimiter, encoding, schema, date format, file completeness, and whether the file is a full extract or only a change set.

Logs record events generated by applications, devices, networks, and security systems. Logs are valuable for behavior and troubleshooting because they preserve a sequence of events. They can also be noisy, high-volume, duplicated, or incomplete when logging levels differ between systems.

The source that is easiest to reach is not automatically the source that best answers the question. A dashboard cache may be convenient but stale; an operational table may be current but lack corrected historical records.

Data warehouses and data marts

A data warehouse stores integrated, structured, and curated data for analysis. Data is usually modeled around stable business definitions, historical reporting, and efficient aggregation. A warehouse is the strong choice when users need governed metrics across departments and repeatable reports.

A data mart is a focused analytical repository for one subject area, team, or function, such as finance, marketing, or supply chain. A mart can make access and performance simpler for its audience. It becomes risky when each department creates incompatible definitions and the marts drift away from a shared source of truth.

The distinction is primarily scope. A warehouse aims to integrate broad organizational data; a mart serves a narrower analytical purpose. A mart can be fed by a warehouse or built directly from operational sources.

Data lakes and lakehouses

A data lake holds large amounts of data in native or lightly processed form, commonly in object storage. It can retain structured tables, semi-structured event files, and unstructured media together. The lake applies structure when data is read, which provides flexibility but raises the need for cataloging, ownership, and quality controls.

A lake without usable metadata, lineage, and lifecycle rules can become a data swamp: the files exist, but users cannot determine what they mean or whether they are safe to use.

A data lakehouse adds table management, schema controls, transaction support, and analytical query features over lake-style storage. It seeks to combine the low-cost flexibility of a lake with the reliability and performance conventions associated with a warehouse. A lakehouse is not simply a lake with a new name; the scenario should mention managed tables or warehouse-like guarantees over object data.

Data silos and integration boundaries

A data silo is information isolated within a team, application, format, or access boundary. A silo is not always the result of bad intent. Security requirements, acquisitions, legacy tools, or incompatible identifiers can create legitimate separation. The analytical problem appears when isolated systems describe the same business entities differently and cannot support a unified question.

Integration does not mean copying everything into one unrestricted location. It means establishing controlled relationships, shared definitions, and a way to reconcile keys and timing. Sometimes federation or a governed view is safer than another physical copy.

Evaluating source fit

Use the decision requirement to assess a source across several dimensions.

Freshness describes how recently the source reflects reality. Latency is the delay between an event and its availability. A daily warehouse load may be perfectly fresh for monthly planning and unacceptable for real-time inventory decisions.

Reliability includes more than uptime. It also means consistent definitions, documented changes, known completeness, and predictable delivery. A stable file that silently excludes cancelled orders is reliably incomplete.

Scenario: a customer-retention analysis

A retention team needs current subscription status, support interactions, web activity, and a stable twelve-month revenue history. Subscription status comes from the operational billing database. Support events arrive through an API. Web events are stored as logs in a lake. Audited revenue is available in the warehouse, while marketing maintains its own spreadsheet of campaign labels.

The best design uses each source for what it can prove. The billing database supplies the current state, but extraction should avoid disrupting production. The API collector must follow every page and handle throttling. Lake logs provide detailed behavior only after their event definitions and coverage are checked. The warehouse supplies governed historical revenue. The marketing spreadsheet may enrich the analysis, but it should not silently become the authority for customer identity or revenue.

If teams repeatedly need the same integrated result, a curated warehouse model or governed mart is more defensible than rebuilding the joins in every report.

Exam traps

• Treating a data lake and a data warehouse as interchangeable storage names.
• Choosing a lakehouse when the scenario mentions only raw files and no managed-table guarantees.
• Assuming public website visibility grants permission for automated collection.
• Stopping after the first successful API page.
• Calling every departmental repository a silo without considering whether it is governed and integrated.
• Equating “most current” with “best” when the requirement needs audited history.
• Assuming a copied file remains authoritative after its source continues to change.

Readiness checklist

• I can identify databases, APIs, website data, files, and logs as sources and name their common risks.
• I can distinguish warehouses, marts, lakes, lakehouses, and silos.
• I can choose a repository based on structure, governance, audience, and history.
• I can evaluate source freshness, latency, access, ownership, reliability, and completeness.
• I can explain why integration requires shared definitions as well as technical connectivity.
• I can trace one record from its operational source into an analytical repository.
• I can defend which source should be authoritative for each measure in a mixed-source scenario.