CompTIA Data+ DA0-002 · Free study guide

Objective 1.3 — Identify infrastructure concepts

Infrastructure determines where analysis runs, how data is stored, and what tradeoffs a team accepts around control, scale, portability, and cost. The exam is not asking you to memorize every cloud product. It is asking you to recognize the infrastructure property a scenario needs and to avoid confusing a deployment model with a storage type.

A useful approach is to separate four decisions: who operates the physical resources, who can use the environment, how bytes are presented to applications, and how the analytical workload is packaged.

Cloud providers and on-premises systems

Amazon Web Services, Microsoft Azure, and Google Cloud are major public cloud providers. All three offer compute, databases, object storage, networking, identity controls, and analytical services. Product names differ, but the underlying requirement often transfers between them. A scenario that needs elastic object storage is testing the concept, not brand loyalty.

In a cloud environment, the provider operates the underlying facilities and exposes resources as services. Teams can provision capacity quickly, scale it, and pay according to the service’s pricing model. Cloud does not remove responsibility: customers still configure identities, permissions, networks, retention, and data protection.

In an on-premises environment, the organization operates systems in facilities it controls. This can provide direct authority over hardware, network boundaries, and specialized configurations. It also means the organization plans capacity, buys equipment, patches platforms, and handles failures. On-premises is not automatically safer; it changes who performs the work and where control resides.

The choice depends on requirements such as regulation, latency, existing investment, skill, scale variability, and recovery needs. A steady workload on owned equipment may be economical, while a short analytical peak may benefit from elastic cloud capacity.

Public, private, and hybrid infrastructure

Public cloud uses services offered by a cloud provider to many customers with logical isolation between tenants. It offers broad service choice and rapid provisioning. “Public” describes the service model; it does not mean that an organization’s data is publicly readable.

Private infrastructure is dedicated to one organization. It may run in the organization’s own facility or be hosted by a provider. The defining property is exclusive use and organizational control, not physical location alone.

Hybrid infrastructure combines environments and coordinates work between them. An organization might retain regulated source data on-premises while sending de-identified aggregates to a cloud analytical platform. A hybrid design is valuable when the boundary serves a requirement. It also adds identity, networking, monitoring, data-movement, and consistency complexity.

Do not choose hybrid merely because a scenario mentions two systems. The systems must operate across meaningfully different infrastructure boundaries.

Storage types

Storage names describe how applications see and access data.

Object storage scales well for large collections and stores metadata with each object, but applications generally do not update a few bytes in place as they would on a disk volume. File storage presents familiar paths and directory permissions. Block storage behaves like a disk volume and is useful when a database needs fine-grained reads and writes.

Local and shared describe reach as much as format. Local storage can be fast but may disappear with a temporary compute instance and is not automatically visible to another worker. Shared storage supports coordination but can introduce network latency or contention.

Durability, backup, replication, and access control are separate properties. Calling storage “shared” does not prove that it is backed up, and placing data in object storage does not make it a governed lake.

Separating storage and compute

Modern analytical platforms often separate persistent storage from the compute engines that query it. The data can remain while compute clusters start, scale, stop, or change independently. This supports bursty workloads and lets different engines analyze the same governed data.

Separation also creates tradeoffs. Remote reads can add latency, repeatedly scanning raw objects can be expensive, and teams must manage compatible formats and permissions. Pre-aggregation, caching, partitioning, and workload scheduling can reduce those costs.

Elasticity means increasing and decreasing resources as demand changes. Scalability means a system can handle growth. A platform may scale to a larger fixed size without automatically scaling back down, so the terms are related but not identical.

Containerization and reproducible environments

A container packages an application with the libraries and runtime configuration it needs. The same image can run on a laptop, a server, or a managed cloud service with fewer “works on my machine” differences. Analysts and engineers use containers to reproduce notebooks, scheduled transformations, APIs, and supporting services.

A container shares the host operating-system kernel; it is not a complete virtual machine. Containers usually start faster and use fewer resources than virtual machines, while virtual machines provide a fuller operating-system boundary.

Containers should be treated as replaceable. Important data belongs in persistent storage outside the container’s temporary writable layer. Rebuilding an image from a controlled definition is safer than manually repairing a running container. Portability also has limits: processor architecture, cloud integrations, credentials, network policies, and external storage still need compatible configuration.

Scenario: month-end reporting

A finance team runs small daily reports but needs ten times the compute for three days at month end. Source records containing regulated identifiers must remain on dedicated infrastructure. Curated, de-identified tables can be analyzed in the cloud, and every scheduled job must run with the same library versions.

A hybrid design fits the boundary: protected source processing remains private, while approved outputs move to public-cloud object storage. Elastic cloud compute can expand for month end and stop afterward without deleting the persistent objects. Container images provide a repeatable job environment. If a database needs low-level, frequently updated storage, block storage is more appropriate than treating object storage as an attached disk. Logs and extracts fit object storage; temporary intermediate files may use local scratch space but cannot be the only copy.

Exam traps

• Assuming public cloud means public access to data.
• Treating private cloud as a synonym for any on-premises server.
• Choosing hybrid without identifying a real boundary or requirement.
• Confusing object storage with a traditional shared file system.
• Assuming local storage survives when temporary compute is replaced.
• Calling replication a backup without considering corruption or retention.
• Saying containers are lightweight virtual machines with their own kernels.
• Storing irreplaceable data only inside a disposable container.

Readiness checklist

• I can identify AWS, Azure, and Google Cloud as providers of comparable infrastructure categories.
• I can compare cloud and on-premises responsibility and cost patterns.
• I can distinguish public, private, and hybrid infrastructure.
• I can match object, file, local, shared, and block storage to a workload.
• I can explain why storage and compute may scale independently.
• I can distinguish elasticity from general scalability.
• I can explain what a container packages, what it shares, and where persistent data belongs.
• I can choose infrastructure by requirement rather than by product name.