Free CompTIA AT0-001 Practice Questions 2026 - Page 4

Answer Option (Which option is correct) D. 2.4.2
Explanation:

A backward-compatible bug fix increments the patch component when it does not introduce a new incompatible API or a new public feature. The major and minor components remain unchanged. The next patch after 2.4.1 is 2.4.2.

Why the other options are incorrect:

A. 2.5.0:
A minor increment communicates new compatible functionality. The question specifies only a bug fix. The patch component is the relevant one.

B. 2.3.9:
2.3.9 returns to an older minor line. It is not the next patch after the supplied release. The current minor number should remain unchanged.

C. 3.0.0:
A major increment would signal incompatible changes. The fix is explicitly backward-compatible. A patch release communicates the stated change more accurately.

References:

Semantic Versioning 2.0.0

Answer Option (Which option is correct) B. 1.2.0-rc.1
Explanation:

SemVer denotes a prerelease by adding a hyphen followed by prerelease identifiers to the normal version. The rc.1 suffix identifies a release-candidate prerelease of 1.2.0. It has lower precedence than the corresponding final 1.2.0 release.

Why the other options are incorrect:

A. 1.2:
1.2 lacks the full major-minor-patch form. It also contains no prerelease identifier. It is not the specified SemVer prerelease syntax.

C. 1_2_0:
Underscore-separated numbers do not use SemVer's required dot separators. They also omit a hyphenated prerelease suffix. This spelling is not a valid example.

D. release_one:
release_one is a free-form label. It contains no SemVer numeric core. It cannot serve as the requested standards-compliant prerelease version.

References:

Semantic Versioning 2.0.0

Answer Option (Which option is correct) C. Feature branch
Explanation:

A feature branch lets the developer commit unfinished work without placing those commits directly on main. The work can be reviewed and tested before integration. Branch isolation supports this workflow, although branch protection and review policy still determine how changes enter the main branch.

Why the other options are incorrect:

A. Detached HEAD with no saved branch:
A detached HEAD has no active branch reference for new commits. Work may be harder to retain and share deliberately. A named feature branch better meets the isolation requirement.

B. Delete the repository:
Deleting the repository removes the normal working context. It does not create an isolated line of feature development. The team needs controlled history rather than deletion.

D. Direct unreviewed commits to main:
Direct commits to main mix unfinished changes into the shared branch. That removes the requested isolation. Review and integration should follow feature development.

References:

Git: branching workflows

Answer Option (Which option is correct) D. Release branch
Explanation:

A release branch can carry fixes for a shipped version while the main development line continues toward later releases. That separates maintenance work from unrelated changes under development. Fixes should be coordinated between the relevant branches to avoid losing required corrections.

Why the other options are incorrect:

A. A secret token:
A secret token is an access credential. It does not maintain a separate release history. Using it cannot isolate maintenance fixes.

B. A local log file:
A local log file records observations or output. It does not create a maintained branch of source commits. Release work requires source-control structure.

C. An untracked directory:
An untracked directory is outside the recorded repository content. It offers no branch-based maintenance history by itself. Fixes should remain versioned and reviewable.

References:

Git: branching workflows

Answer Option (Which option is correct) A. Run formatting checks
Answer Option (Which option is correct) D. Detect staged secrets
Explanation:

Option A uses a pre-commit check to evaluate formatting before a proposed commit is recorded. Option D checks the staged content for secret material at the same early point. Local checks help catch mistakes, but they can be bypassed and should be complemented by appropriate server-side controls.

Why the other options are incorrect:

B. Guarantee production uptime:
Guaranteed uptime cannot follow from local checks alone. Runtime dependencies and infrastructure can still fail. Pre-commit automation validates content rather than guaranteeing service availability.

C. Replace all server-side access controls:
Server-side controls protect centrally enforced permissions and policies. A local hook can be bypassed or absent. Pre-commit checks complement those controls rather than replacing them.

References:

Git: hooks

GitHub Actions: secure use

Answer Option (Which option is correct) A. Pre-commit hook
Explanation:

Git runs a pre-commit hook before completing an ordinary local commit. The hook can invoke formatting validation and return a failure status to stop that commit. This matches the requested timing, while repository-wide enforcement still requires controls beyond the developer's local hook.

Why the other options are incorrect:

B. Load balancer:
A load balancer distributes service traffic. It does not execute checks during a local commit. Formatting belongs in the source workflow.

C. Artifact digest:
An artifact digest identifies built content. It does not invoke a formatting tool before commit creation. Identity and validation timing are different functions.

D. Post-deployment DNS change:
A post-deployment DNS change affects service resolution after release. The question requires a local pre-commit check. This action happens at the wrong stage.

References:

Git: hooks

Answer Option (Which option is correct) C. Remove the token and revoke or rotate it if exposed
Explanation:

Remove the real token from the proposed content before committing it. If it has been disclosed or may have been exposed, revoke or rotate it through the credential issuer. Editing the file stops that copy from being committed, but only invalidating the compromised credential addresses continued unauthorized use.

Why the other options are incorrect:

A. Disable the scanner:
Disabling the scanner suppresses the warning. It does not remove the credential or invalidate exposure. The staged secret remains a risk.

B. Add a comment saying ignore:
An ignore comment may silence a detection. The actual token can still be used if exposed. Documentation is not credential remediation.

D. Encode it in Base64:
Base64 encoding is reversible representation. It is not revocation or secure removal. The same credential remains usable after decoding.

References:

GitHub Actions: secure use

AWS IAM: security best practices

Answer Option (Which option is correct) A. Linter
Explanation:

A linter inspects source code for configured error patterns and style violations without running the application's workload. It can identify suspicious constructs early in development. Linting complements execution tests because it does not establish that all runtime behavior is correct.

Why the other options are incorrect:

B. DNS resolver:
A DNS resolver answers name-resolution requests. It does not inspect source patterns for style defects. Static code analysis requires a different tool.

C. Load tester:
A load tester exercises workload behavior under traffic. It executes tests rather than performing only the stated static checks. Its purpose differs from linting.

D. Package registry:
A package registry stores and distributes dependencies. Storage alone does not inspect the workload's source patterns. A linter performs the requested analysis.

References:

Ruff: Python linting

Answer Option (Which option is correct) B. Why the workaround is needed
Explanation:

A useful comment records the reason an unusual workaround exists. The code already shows what it does, while the comment can explain the constraint or failure that made the workaround necessary. That context helps maintainers decide whether changing or removing it is safe.

Why the other options are incorrect:

A. An unrelated deployment schedule:
An unrelated schedule does not explain the workaround. Readers still cannot assess its necessity. The comment should describe the relevant technical constraint.

C. The access token value:
An access token is sensitive operational data. Putting its value in a comment creates exposure. It also does not explain why the workaround exists.

D. Every obvious assignment:
Obvious assignments are already visible in the code. Restating them adds little context about the unusual behavior. The useful comment explains the non-obvious reason.

References:

Python: PEP 8 comments

Answer Option (Which option is correct) C. Reusability
Explanation:

Inputs such as region and instance size allow the same module implementation to serve different environments. Callers supply configuration values instead of duplicating the module for each environment. That illustrates reuse while retaining a common implementation for review and maintenance.

Why the other options are incorrect:

A. Mutable history:
Mutable history concerns changing recorded history. Parameterized infrastructure modules concern repeated use of implementation. The concepts do not describe the same benefit.

B. Manual drift:
Manual drift is divergence from managed configuration. Module inputs deliberately vary approved settings. That variation is not uncontrolled drift.

D. Global credentials:
Global credentials concern shared authentication material. Region and size parameters are configuration inputs. Their reuse does not require broad shared access.

References:

Terraform: reusable modules