Free CompTIA AT0-001 Practice Questions 2026 - Page 6

Timed Practice Test

Think You're Ready?

Your Final Exam Before the Final Exam.
Dare to Take It?

Automation Coding Concepts

Choose TWO steps to resolve a Git merge conflict.

A. Review and edit conflicting content

B. Publish unresolved conflict markers

C. Delete the remote repository

D. Stage the resolution and commit it

A.   Review and edit conflicting content
D.   Stage the resolution and commit it

Answer Option (Which option is correct) A. Review and edit conflicting content
Answer Option (Which option is correct) D. Stage the resolution and commit it
Explanation:

Option A establishes the intended content by reviewing and editing the conflict. Option D records that resolution by staging it and completing the commit. These actions address both the file contents and Git's record of the resolved merge.

Why the other options are incorrect:

B. Publish unresolved conflict markers:
Unresolved markers are not a completed merge. They leave the conflict text in the file. Publishing them can break the intended code.

C. Delete the remote repository:
Remote deletion removes a collaboration resource. It does not repair the conflicting lines. The merge should be resolved within the source history.

References:

Git: git merge

Git: git push

Git rejects a push as non-fast-forward. What is the safest normal response?

A. Force-push immediately over teammates

B. Fetch and reconcile remote changes before pushing

C. Delete all remote branches

D. Change JSON quotes

B.   Fetch and reconcile remote changes before pushing

Answer Option (Which option is correct) B. Fetch and reconcile remote changes before pushing
Explanation:

A non-fast-forward rejection means the remote reference cannot safely advance to the proposed local history in the normal way. Fetch the remote changes and reconcile the histories through the team's approved workflow. Push after reviewing the resulting history instead of immediately overwriting another contributor's work.

Why the other options are incorrect:

A. Force-push immediately over teammates:
Immediate force-pushing can overwrite others' commits. It skips reconciliation of the diverging histories. Fetching first reveals the remote changes that must be preserved.

C. Delete all remote branches:
Deleting remote branches removes work instead of integrating it. A non-fast-forward rejection does not require that deletion. The shared history should be reconciled.

D. Change JSON quotes:
JSON quotes affect document syntax. They do not resolve Git reference divergence. The rejected push needs source-history handling.

References:

Git: git merge

Git: git push

Choose TWO actions after accidentally committing a live API credential.

A. Encode the existing token

B. Only rename the branch

C. Remove secret material from tracked content and address history exposure

D. Revoke or rotate the exposed credential

C.   Remove secret material from tracked content and address history exposure
D.   Revoke or rotate the exposed credential

Answer Option (Which option is correct) C. Remove secret material from tracked content and address history exposure
Answer Option (Which option is correct) D. Revoke or rotate the exposed credential
Explanation:

Option C removes the secret from tracked content and addresses any continuing exposure through repository history. Option D revokes or rotates the live credential so the disclosed value no longer grants the same access. Repository cleanup and credential invalidation address different parts of the incident, so both are needed.

Why the other options are incorrect:

A. Encode the existing token:
Encoding the token does not invalidate it. Anyone who decodes it can still authenticate. Exposure requires credential lifecycle action as well as cleanup.

B. Only rename the branch:
Renaming a branch changes a reference name. The secret can remain in commits and copies. It also leaves the exposed credential valid.

References:

GitHub Actions: secure use

AWS IAM: security best practices

A program exits successfully despite a failed subprocess. What should be checked?

A. Subprocess exit status

B. DNS TXT record

C. SLA penalty

D. Git branch description

A.   Subprocess exit status

Answer Option (Which option is correct) A. Subprocess exit status
Explanation:

The parent program must inspect the subprocess result rather than equating its own continued execution with child success. A nonzero return code commonly signals failure, and Python subprocess APIs can raise an exception when instructed to check it. Propagate or handle that failure according to the operation's policy.

Why the other options are incorrect:

B. DNS TXT record:
A DNS TXT record contains name-service data. It does not report a subprocess's exit outcome. The parent must inspect the process result.

C. SLA penalty:
An SLA penalty is a service-agreement consequence. It is not a command completion status. Financial terms cannot detect the failed subprocess.

D. Git branch description:
A branch description explains repository work. It does not capture the child process return value. Runtime failure needs direct process-status handling.

References:

Python: subprocess return codes

An operator wants only raw host names from {"hosts":["a","b"]}. Which jq expression fits?

A. .host

B. .hosts[]

C. .hosts.length

D. .status[]

B.   .hosts[]

Answer Option (Which option is correct) B. .hosts[]
Explanation:

B is the supplied source answer because .hosts[] selects the hosts array and emits its elements individually. To produce raw host-name text without JSON quotation marks, the complete command must also enable jq's -r option. The question asks only for an expression and does not specify that output flag, so the raw-output requirement is not fully established by the expression alone. Retain the selected expression while reviewing the stem or adding the required command context.

Why the other options are incorrect:

A. .host:
.host selects a different property name. The supplied document contains hosts rather than host. This expression does not iterate the required array.

C. .hosts.length:
.hosts.length treats length as a property lookup on the hosts value. It is not the array-element iterator. jq uses a separate length filter for counting values.

D. .status[]:
.status[] targets a status value absent from the document. It does not select the hosts array. The iterator must address the actual property.

References:

jq manual: filters and iteration

What does git status primarily show?

A. API latency

B. Remote service uptime

C. Container vulnerability scores

D. Working tree and staging state

D.   Working tree and staging state

Answer Option (Which option is correct) D. Working tree and staging state
Explanation:

git status reports how the working tree and index differ from the relevant repository state. It identifies staged changes, unstaged changes, and untracked files. This helps determine what the next ordinary commit will contain and what edits still remain outside the index.

Why the other options are incorrect:

A. API latency:
API latency is a service performance measure. git status inspects repository state. It does not time remote application requests.

B. Remote service uptime:
Remote uptime measures availability of a service. It is not the working-tree state of a repository. git status does not perform an uptime check.

C. Container vulnerability scores:
Vulnerability scores come from security analysis. git status does not scan container components. It reports file and index changes instead.

References:

Git: git status

A retry loop never increments its attempt counter. What is the likely risk?

A. Certificate renewal

B. Unbounded retries

C. Automatic idempotency

D. A valid SemVer tag

B.   Unbounded retries

Answer Option (Which option is correct) B. Unbounded retries
Explanation:

A bounded retry loop needs progress toward its stopping condition. If the attempt counter never changes, a counter-based maximum may never be reached while failures continue. The loop can therefore repeat indefinitely unless another independent condition stops it.

Why the other options are incorrect:

A. Certificate renewal:
Certificate renewal requires a certificate-management action. Failing to increment an attempt counter does not perform that action. It can instead prevent the retry limit from being reached.

C. Automatic idempotency:
Idempotency concerns repeat effects on state. It does not guarantee a retry loop terminates. The missing counter update is a control-flow issue.

D. A valid SemVer tag:
A SemVer tag identifies a release version. It has no effect on the loop's exit condition. The attempt counter still needs to advance.

References:

Python: functions and control flow

Python: built-in types

A script must handle HTTP errors without printing bearer tokens. Which logging choice fits?

A. Full Authorization header

B. Status code and sanitized request context

C. Private key contents

D. All environment variables

B.   Status code and sanitized request context

Answer Option (Which option is correct) B. Status code and sanitized request context
Explanation:

An HTTP status code and sanitized request context provide useful troubleshooting information without disclosing the bearer token. Redaction must cover the actual secret values, including any sensitive headers or parameters copied into logs. This preserves operational evidence while reducing credential exposure.

Why the other options are incorrect:

A. Full Authorization header:
The Authorization header can contain a usable bearer token. Logging it exposes access credentials. Error diagnosis should use sanitized context.

C. Private key contents:
Private key contents can enable impersonation. They are not needed to interpret an HTTP status. Printing them expands the disclosure risk.

D. All environment variables:
Environment variables may contain unrelated credentials. Dumping all of them defeats selective sanitization. Log only the necessary nonsecret fields.

References:

GitHub Actions: secure use

AWS IAM: security best practices

A dependency update unexpectedly breaks a previously passing build. What best improves reproducibility?

A. Always install newest versions

B. Pin tested dependency versions

C. Remove every dependency file

D. Disable unit tests

B.   Pin tested dependency versions

Answer Option (Which option is correct) B. Pin tested dependency versions
Explanation:

Pinning tested dependency versions limits variation caused by newly released packages. Repeatable installation controls can also include the transitive dependency set and integrity hashes. The pinned set must still be updated deliberately and tested when security or compatibility requires a change.

Why the other options are incorrect:

A. Always install newest versions:
Newest versions can introduce unreviewed dependency changes. That recreates the cause of this unexpected breakage. Tested explicit versions offer more controlled inputs.

C. Remove every dependency file:
Removing dependency files removes the declared installation specification. Runner environments can become inconsistent. Reproducibility needs recorded dependencies rather than their omission.

D. Disable unit tests:
Disabling tests hides the incompatibility. It does not restore the previously working dependency combination. Keep the checks and control the versions.

References:

pip: repeatable installations

A Dockerfile changes only application files frequently. Which arrangement usually improves cache reuse?

A. Install all dependencies after every source change

B. Disable every build cache

C. Install stable dependencies before copying frequently changing code

D. Copy secrets into the base layer

C.   Install stable dependencies before copying frequently changing code

Answer Option (Which option is correct) C. Install stable dependencies before copying frequently changing code
Explanation:

Docker reuses a cached layer when its relevant inputs remain unchanged. Installing stable dependencies before copying frequently edited application files avoids invalidating that dependency layer for every source edit. The arrangement helps only when the dependency inputs themselves have not changed.

Why the other options are incorrect:

A. Install all dependencies after every source change:
Installing after source changes can invalidate dependency-install layers frequently. This wastes the reuse of stable dependency inputs. Place stable steps earlier when practical.

B. Disable every build cache:
Disabling the cache removes reuse entirely. It cannot improve cache effectiveness. The proposed ordering should preserve unchanged layers.

D. Copy secrets into the base layer:
Secrets in image layers can persist in distributed images. They are unrelated to safe dependency-cache ordering. Build credentials should not become retained image content.

References:

Docker: build best practices

pip: repeatable installations

Page 6 out of 22 Pages