8 Software Documentation Online Quiz Questions

True

False

A reference document, because it should list every configuration field.

A how-to guide, because the reader needs to accomplish a specific task.

An architecture decision record, because the reader needs the history of a design choice.

An operational guide, because every configuration task is a recovery procedure.

A tutorial that teaches through a working example.

An explanation that clarifies architecture and trade-offs.

An operational guide that covers deployment and recovery.

A reference that lists interface types and configuration options.

True

False

Store documentation in version control when useful so changes can be reviewed and tracked alongside code.

Review documentation changes alongside related software changes, or explain why no documentation change is needed.

Automate feasible checks such as link, formatting, API-description, and runnable-example validation.

Assign responsibility for important documentation areas.

Revisit high-impact guidance after significant releases and remove obsolete instructions.

Replace human review entirely with automated checks.

Keep operational instructions outside ownership assignments.

The endpoint or method, its purpose, parameters, and required fields.

Authentication and authorization requirements.

Request and response formats, with realistic examples.

Possible errors and their meanings.

Relevant limits, pagination, versioning, and compatibility expectations.

The personal credentials of a developer who tested the API.

The color scheme of the API provider's internal dashboards.

It replaces all tutorials because it explains every task an API user might need.

It can support machine-readable interface understanding, but may need to be paired with focused tutorials and guides.

It is only useful for documenting operational recovery procedures.

It guarantees that API examples agree with the actual contract without further checks.

True

False

Write an ADR for every small implementation detail, whether or not it matters later.

Keep an ADR exhaustive so it can replace current system documentation.

Keep ADRs brief and focused on decisions that are costly, consequential, or difficult to reverse.

Use ADRs only to list the selected option, without recording context or consequences.

A reference page listing every database configuration field

A how-to guide with steps for configuring the connection

An architecture overview explaining why the system uses a database

An operational guide for monitoring the database after deployment

It guarantees that documentation examples will always match the software.

It replaces the need for code review with document formatting checks.

It lets teams review and track documentation changes alongside code.

It ensures every documentation page is exhaustive.

It automatically provides all tutorials and task guides API users need.

It can define an HTTP API in a machine-readable form but does not replace every guide or explanation.

It is primarily a deployment and monitoring tool rather than an interface description.

It removes the need to document errors, request formats, or compatibility expectations.

Keep the earlier record and create a new one explaining what superseded it.

Replace the earlier record so that only the current decision remains.

Delete the earlier record and update the system documentation instead.

Leave the earlier record unchanged and make no record of the new decision.