Overview
Database Deployment follows a new database from planning to go-live. Objective 2.1 covers planning and design: gathering requirements (number of users, storage size, speed and type, objectives and use cases), architecture decisions (asset inventory and gap analysis, cloud versus on-premises, infrastructure, platform or software as a service, logical, physical and view schemas, data sources, system specifications) and design documentation such as the data dictionary, entity relationships and cardinality.
Objective 2.2 covers implementation, testing and deployment: acquiring assets, installing and configuring the engine, provisioning, upgrading and importing data, then making it reachable through DNS, firewalls, IP addressing and the right ports. It ends with testing (data quality, code execution, stress, regression and negative tests) and validation of indexes, data mapping, values, queries, referential integrity and scalability. Domain 3 inherits whatever this phase gets wrong.
How it's tested
Domain 2 questions describe a project at a particular stage and ask what belongs there: which requirement to gather, which service model or schema fits, why a client cannot connect, or which test or validation step confirms a specific outcome. Many items are sequencing questions, so watch for FIRST and NEXT in the stem.
-
Right step, right phase
A project status is described and you choose the activity that should happen first or next, such as gap analysis before purchasing or validation before cutover.
-
Name the test
A testing activity is described in plain words and you identify it as stress, regression, negative or data quality testing, or as a validation check such as referential integrity.
-
Diagnose connectivity
A client fails to reach a new server and you trace the cause to DNS, a firewall rule, a changed dynamic IP address or a wrong port.
A new PostgreSQL server passes local tests, but application servers in another subnet time out when connecting. Options include rebuilding indexes, raising memory, opening TCP 5432 between the subnets, and switching to a PaaS database. The clue is that the database works locally but fails only across the network, so the cause sits in the path: a firewall rule for the engine's port is the targeted fix.
Objectives 2
Official objectives from the CompTIA outline, in outline order.
2.1 Compare and contrast aspects of database planning and design.Requirements gathering, architecture factors such as cloud models and schema types, and design documentation.
- What it means
- Planning starts with requirements: how many users and concurrent sessions, how much storage and how fast (IOPS, latency, solid-state versus spinning disk), and what the database is for. Architecture then weighs asset inventory and gap analysis, cloud versus on-premises, infrastructure as a service (IaaS), platform as a service (PaaS) or software as a service (SaaS), schema types, data sources and system specifications, and the design is captured in a data dictionary, entity relationships, cardinality and system requirements.
- What to understand
- A logical schema models entities, attributes and relationships independent of any product; a physical schema maps them to tables, data types, indexes and storage on a specific engine; a view schema defines what particular users or applications see. Service models shift responsibility: with IaaS you patch the operating system and engine, with PaaS the provider runs the engine and you own schema, data and access, and with SaaS you consume a finished application.
- How it shows up
- A stem gives business constraints (limited staff, regulated data, unpredictable growth) and asks for the deployment model, service model or the design document that answers a question.
- Common confusion
- Calling an entity relationship diagram a physical schema; it is usually logical until data types, indexes and storage details are added.
2.2 Explain database implementation, testing, and deployment phases.Acquisition, installation and configuration, connectivity, testing types and validation checks.
- What it means
- Implementation runs from acquiring hardware or licenses, through installing prerequisites and the engine, provisioning, upgrading, modifying and importing data, to network connectivity: server location, DNS, client/server architecture, firewall and perimeter network rules, static versus dynamic IP addressing, and ports and protocols. Testing then checks data quality, code execution and syntax, stress behavior, alerts, version control, regression and negative cases, and validation confirms indexes, data mapping, values, queries, referential integrity and scalability.
- What to understand
- Know the default ports (SQL Server TCP 1433, MySQL 3306, PostgreSQL 5432, Oracle 1521, MongoDB 27017), why servers need static or reserved addresses and DNS names, and why a database sits on an internal network rather than in the perimeter network. Regression testing reruns existing tests after a change; negative testing feeds invalid input to confirm it is rejected; stress testing pushes load beyond normal peaks.
- How it shows up
- A scenario describes a test, a connection failure or a post-migration check and asks you to name it or choose the next action.
- Common confusion
- Mixing up regression testing with negative testing, or treating data mapping (source field to target field) as the same thing as referential integrity (foreign keys point to existing rows).
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Logical vs. physical vs. view schema
A logical schema describes entities, attributes and relationships without product details; a physical schema adds tables, data types, indexes, partitions and storage for a specific engine; a view schema defines the subset each user group or application sees.
- Remember
- Logical answers what data and how it relates; physical answers how it is stored on this engine.
- Tested as
- Design questions ask which schema level a document or decision belongs to.
- Trap
- Putting index and storage choices into the logical model.
-
IaaS vs. PaaS vs. SaaS
Infrastructure as a service provides virtual machines you manage; platform as a service provides a managed database engine; software as a service provides a complete application.
- Remember
- Moving from IaaS to PaaS hands engine patching, backups and high availability features to the provider, but data, schema and access stay with you.
- Tested as
- Scenarios with small teams and no need for OS-level control point to PaaS.
- Trap
- Assuming PaaS removes the customer's responsibility for access control and data classification.
-
Gap analysis
A gap analysis compares the current asset inventory and capabilities with what the new database requires, revealing missing hardware, licenses, skills or network capacity.
- Remember
- Inventory first, then gap analysis, then acquisition.
- Tested as
- Sequencing questions ask what to do before purchasing or provisioning.
- Trap
- Buying hardware before confirming what existing assets can be reused.
-
Data dictionary
A data dictionary records each table and column with its data type, allowed values, constraints, owner and business meaning.
- Remember
- It answers what a field means and what it may contain.
- Tested as
- Asked as the document that resolves confusion about a column's purpose or format.
- Trap
- Choosing an ERD, which shows relationships but not detailed field definitions.
-
Cardinality
Cardinality states how many rows on one side of a relationship relate to rows on the other: one-to-one, one-to-many or many-to-many.
- Remember
- A many-to-many relationship needs a junction (associative) table in a relational design.
- Tested as
- Design items describe a business rule and ask for the cardinality or table design.
- Trap
- Modeling many-to-many with a single foreign key, which forces duplicate rows.
-
Default database ports
Common defaults are TCP 1433 for SQL Server, 3306 for MySQL, 5432 for PostgreSQL, 1521 for Oracle and 27017 for MongoDB.
- Remember
- Firewall rules must allow the engine's port between the application tier and the database.
- Tested as
- Connectivity troubleshooting stems often hinge on a blocked or nonstandard port.
- Trap
- Opening the port to the internet instead of only to the application subnet.
-
Static vs. dynamic IP addressing
A static or reserved address stays the same, while a dynamic DHCP lease can change after a reboot or lease expiry.
- Remember
- Servers need stable addresses and clients should connect by DNS name.
- Tested as
- Appears when connections break after a server restart.
- Trap
- Hard-coding an IP address in connection strings, which breaks on any change or failover.
-
Perimeter network placement
A perimeter network (screened subnet, formerly DMZ) hosts internet-facing services; databases belong on an internal segment reachable only from approved application servers.
- Remember
- Web tier in the perimeter, database behind a second firewall.
- Tested as
- Design and connectivity items ask where to place the new server.
- Trap
- Placing the database in the perimeter network so the web server can reach it easily.
-
Regression vs. negative vs. stress testing
Regression testing reruns existing tests after a change to confirm nothing broke; negative testing submits invalid or unexpected input to confirm it is rejected safely; stress testing applies load beyond expected peaks to find breaking points.
- Remember
- Changed code plus old tests is regression; bad input is negative; extreme load is stress.
- Tested as
- Test identification is a frequent item shape in this domain.
- Trap
- Calling any test that finds a bug a regression test.
-
Referential integrity
Referential integrity means every foreign key value matches an existing primary key in the parent table, so there are no orphan rows.
- Remember
- Validate it after imports and migrations, especially when constraints were disabled for loading.
- Tested as
- Post-migration validation scenarios.
- Trap
- Assuming row counts that match between source and target prove integrity.
-
Data mapping
Data mapping defines how each source field translates to a target field, including type conversions and transformations.
- Remember
- Validation compares mapped values, not just counts.
- Tested as
- Appears in migration and import validation questions.
- Trap
- Treating data mapping as the same thing as an entity relationship diagram.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Logical vs. physical vs. view schema
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Logical schema | Entities, attributes, relationships and keys | Independent of any product or storage | Adding engine-specific data types and indexes too early |
| Physical schema | Tables, columns with types, indexes, partitions, storage | Specific to one engine and deployment | Skipping it and letting defaults decide storage and indexing |
| View schema | The subset of data a user or application sees | Shapes access and presentation, not storage | Treating it as a security control on its own without permissions |
IaaS vs. PaaS vs. SaaS for databases
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| IaaS | Virtual machines where you install the engine | You manage OS, engine, patches and backups | Choosing it for a team with no capacity for OS administration |
| PaaS | Managed database service | Provider runs engine and patching; you own data, schema and access | Assuming the provider handles user permissions and data classification |
| SaaS | Finished application with its own data store | You configure the application, not the database | Expecting DBA-level control over the underlying database |
Regression vs. negative vs. stress testing
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Regression testing | Rerun existing tests after a change | Protects features that already worked | Running only tests for the new feature |
| Negative testing | Submit invalid or unexpected input | Confirms bad input is rejected safely | Testing only the expected happy path |
| Stress testing | Push load beyond expected peaks | Finds breaking points and failure behavior | Confusing it with a single-user functional test |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Technology before requirements
- What candidates pick
- Choose a cloud PaaS database at the start of the project.
- Why it looks right
- Managed services sound modern and reduce administration.
- Why it's wrong
- Without user counts, storage needs, data residency and use cases, the choice may break a compliance or performance requirement.
Clue to watch for The stem says the project is in its early or planning stage, or requirements are not yet documented.
-
Database in the perimeter network
- What candidates pick
- Place the database server in the perimeter network next to the web servers.
- Why it looks right
- It simplifies connectivity for the web tier.
- Why it's wrong
- The perimeter network is exposed to internet traffic; the database belongs on an internal segment reachable only through specific firewall rules.
Clue to watch for Any mention of internet-facing applications and where to locate the new database.
-
Row counts as validation
- What candidates pick
- Compare row counts between source and target after a migration and declare success.
- Why it looks right
- Matching counts look like proof that everything arrived.
- Why it's wrong
- Counts can match while values are truncated, mapped to the wrong columns or orphaned; data mapping, value checks and referential integrity checks are still needed.
Clue to watch for The requirement says accurate, complete or consistent data, not just all rows.
-
IP address in the connection string
- What candidates pick
- Point the application at the server's current IP address.
- Why it looks right
- It works immediately and avoids DNS lookups.
- Why it's wrong
- Dynamic addresses change and failover moves services; connecting by DNS name keeps clients working when the address changes.
Clue to watch for Connections break after a reboot, migration or failover.
-
Wrong test name
- What candidates pick
- Negative testing for rerunning the full test suite after a patch.
- Why it looks right
- Both are about finding defects.
- Why it's wrong
- Rerunning existing tests after a change is regression testing; negative testing deliberately supplies invalid input.
Clue to watch for The stem says existing functionality, after an update, or previously passing tests.
-
PaaS means no security work
- What candidates pick
- Assume the cloud provider handles permissions on a PaaS database.
- Why it looks right
- The provider patches and runs the engine.
- Why it's wrong
- Shared responsibility leaves identities, permissions, data classification and often encryption key choices with the customer.
Clue to watch for The stem asks who must configure access or protect data in a managed service.
Answer framework
Use this sequence when a Domain 2 question asks what to plan, build, test or check at a given stage of a database deployment.
- Place the scenario in its phase: requirements, architecture and design, acquisition and installation, connectivity, testing, or validation.
- Confirm the prerequisite of that phase is done; if requirements or gap analysis are missing, that is usually the FIRST answer.
- Match the decision to the stated constraint, such as staff capacity for a service model, regulation for location, or growth for storage type and scalability.
- For connection failures, walk the path in order: name resolution, IP address, firewall rule, port and protocol, then authentication.
- Name tests and checks precisely: regression after change, negative for bad input, stress for load, referential integrity for orphans, data mapping for field translation.
Practice question
Want more like this? The CompTIA DataSys+ practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study objective 2.1 first, because the exam expects planning decisions to come before technology choices. Draw a small logical model for a familiar business process, convert it into a physical schema for one engine with data types and indexes, then write a short data dictionary for it. That single exercise covers schema types, cardinality and design documentation.
Next, build a one-page responsibility chart for IaaS, PaaS and SaaS that lists who patches, who backs up, who manages access and who classifies data. Shared responsibility is where scenario questions catch candidates.
For objective 2.2, install a database engine in a virtual machine or container, connect to it from a second machine by DNS name, and break the connection on purpose by closing the port or changing the address. Then write a regression test, a negative test and a simple load test for one stored procedure so the test names stay attached to real activities.
Candidates commonly underestimate validation after imports. Afterward, practice migration scenarios that ask how to prove data is complete and consistent, then move to Domain 3 for running the system.
FAQ
How much of DataSys+ DS0-001 is Database Deployment?
CompTIA weights it at 16% of the exam across two objectives. CompTIA does not publish per-domain question counts, so any number for this domain is an estimate.
Do I need to memorize default port numbers?
The objective lists ports and protocols under connectivity, so knowing the common defaults for SQL Server, MySQL, PostgreSQL, Oracle and MongoDB helps you diagnose connection scenarios quickly.
Is cloud architecture tested in depth?
The objectives name cloud versus on-premises and the IaaS, PaaS and SaaS models. Expect questions on trade-offs and responsibilities rather than specific provider console settings.
What is the difference between a logical and a physical schema?
A logical schema describes entities and relationships independent of technology, while a physical schema specifies tables, data types, indexes and storage on a particular engine.
Which testing types should I know?
The objective lists data quality checks, code execution and syntax checks, stress testing, alerts and notification triggers, version control, regression testing and negative testing. Be able to identify each from a plain description.
Why is this domain only two objectives?
CompTIA groups planning and design into one objective and implementation, testing and deployment into another, so each objective is broad. Study every sub-topic under both.
How does Domain 2 relate to the rest of the exam?
Design documents produced here are maintained in Domain 3, network placement and access decisions are judged in Domain 4, and the architecture choices set up the high availability and backup options in Domain 5.
Other Data & Analytics certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have just walked a database from requirements through design, installation, connectivity, testing and validation. Check whether you can pick the right step and the right test when a scenario describes them in plain words.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the CompTIA DataSys+ AI tutor Get any concept explained your way