100% Latest & Updated Microsoft AZ-400 Practice Test Questions, Exam Dumps & Verified Answers!
30 Days Free Updates, Instant Download!
Question 210
A former vendor maintains active write access to private code repositories because access reviews omit outside collaborators. What outcome most clearly explains the business impact?
- Recreating lost work manually can omit required changes or introduce an unreviewed release artifact.
- A library change can unexpectedly break production consumers or leave older copies vulnerable.
- Production can run different code than the reviewed release despite using the same version label.
- An unnecessary collaborator privilege can enable unauthorized source changes or exfiltrate proprietary code.
Explanation
Correct Answer
D:An unnecessary collaborator privilege can enable unauthorized source changes or exfiltrate proprietary code. This is the directly relevant business or security consequence of least-privilege github organization collaborator permissions. Root cause: Repository access is a sensitive software supply-chain boundary, not simply a convenience for team participation.
Incorrect Answers
A:Recreating lost work manually can omit required changes or introduce an unreviewed release artifact. That risk is relevant to recover deleted commits using git reflog safely, but the specific unresolved condition here concerns least-privilege github organization collaborator permissions and has a different direct consequence.
B:A library change can unexpectedly break production consumers or leave older copies vulnerable. That risk is relevant to cross-repository shared code via versioned packages, but the specific unresolved condition here concerns least-privilege github organization collaborator permissions and has a different direct consequence.
C:Production can run different code than the reviewed release despite using the same version label. That risk is relevant to protected release tags and verifiable version references, but the specific unresolved condition here concerns least-privilege github organization collaborator permissions and has a different direct consequence.
Question 211
A build pipeline deploys a mutable latest tag that a developer moved after staging acceptance. What action is MOST appropriate given these constraints?
- Protect critical release tags and pin deployment records to immutable commit IDs and associated artifact digests.
- Publish reusable components under immutable versions and define explicit cross-repository dependency ownership.
- Use reflog or known commit identifiers to recover the intended change, then reapply normal PR and validation rules.
- Use Git LFS or appropriate artifact storage for large binaries while retaining versioned pointer and permission management.
Explanation
Correct Answer
A:Protect critical release tags and pin deployment records to immutable commit IDs and associated artifact digests. A human-friendly release tag is not sufficient evidence when its target may be changed without control. Production can run different code than the reviewed release despite using the same version label.
Incorrect Answers
B:Publish reusable components under immutable versions and define explicit cross-repository dependency ownership. That applies to cross-repository shared code via versioned packages, not protected release tags and verifiable version references.
C:Use reflog or known commit identifiers to recover the intended change, then reapply normal PR and validation rules. That applies to recover deleted commits using git reflog safely, not protected release tags and verifiable version references.
D:Use Git LFS or appropriate artifact storage for large binaries while retaining versioned pointer and permission management. That applies to git lfs for oversized binary assets in version history, not protected release tags and verifiable version references.
Question 212
A build pipeline deploys a mutable latest tag that a developer moved after staging acceptance. Which test MOST directly confirms the solution?
- Locate the original commit hash, compare its diff with the issue, and rerun required tests after recovery.
- Rebuild a prior release using package lock or submodule commit pins and compare retrieved component hashes.
- Compare release tag history, signed commit identity, artifact provenance, and staging-to-production deployment references.
- Clone a test repository with and without LFS access and verify large-object retrieval, revisions, and CI runner storage use.
Explanation
Correct Answer
C:Compare release tag history, signed commit identity, artifact provenance, and staging-to-production deployment references. A human-friendly release tag is not sufficient evidence when its target may be changed without control.
Incorrect Answers
A:Locate the original commit hash, compare its diff with the issue, and rerun required tests after recovery. That applies to recover deleted commits using git reflog safely, not protected release tags and verifiable version references.
B:Rebuild a prior release using package lock or submodule commit pins and compare retrieved component hashes. That applies to cross-repository shared code via versioned packages, not protected release tags and verifiable version references.
D:Clone a test repository with and without LFS access and verify large-object retrieval, revisions, and CI runner storage use. That applies to git lfs for oversized binary assets in version history, not protected release tags and verifiable version references.
Question 213
A build pipeline deploys a mutable latest tag that a developer moved after staging acceptance. Which design distinction is MOST relevant in these conditions?
- Git recovery can recover commit objects, but recovering content does not grant approval to deploy it.
- Repository access is a sensitive software supply-chain boundary, not simply a convenience for team participation.
- Removing a secret from current source does not invalidate leaked credentials or guarantee prior copies disappeared.
- A human-friendly release tag is not sufficient evidence when its target may be changed without control.
Explanation
Correct Answer
D:A human-friendly release tag is not sufficient evidence when its target may be changed without control. Production can run different code than the reviewed release despite using the same version label.
Incorrect Answers
A:Git recovery can recover commit objects, but recovering content does not grant approval to deploy it. That applies to recover deleted commits using git reflog safely, not controlling principle for protected release tags and verifiable version references.
B:Repository access is a sensitive software supply-chain boundary, not simply a convenience for team participation. That applies to least-privilege github organization collaborator permissions, not controlling principle for protected release tags and verifiable version references.
C:Removing a secret from current source does not invalidate leaked credentials or guarantee prior copies disappeared. That applies to removing committed secrets from git and rotating credentials, not controlling principle for protected release tags and verifiable version references.
Question 214
A build pipeline deploys a mutable latest tag that a developer moved after staging acceptance. Which ongoing guardrail would BEST prevent this problem from recurring?
- Document recovery actions and validate branch history and repository permissions before a restored commit is merged.
- Perform periodic collaborator recertification and remove access when contracts and assignments end.
- Restrict tag deletion and modification and monitor unauthorized release reference changes.
- Enforce file-size policies and maintain LFS availability and retention for required revisions.
Explanation
Correct Answer
C:Restrict tag deletion and modification and monitor unauthorized release reference changes. Production can run different code than the reviewed release despite using the same version label.
Incorrect Answers
A:Document recovery actions and validate branch history and repository permissions before a restored commit is merged. This helps sustain a control for recover deleted commits using git reflog safely; it does not directly stop recurrence of protected release tags and verifiable version references described in this case.
B:Perform periodic collaborator recertification and remove access when contracts and assignments end.
D:Enforce file-size policies and maintain LFS availability and retention for required revisions. This helps sustain a control for git lfs for oversized binary assets in version history; it does not directly stop recurrence of protected release tags and verifiable version references described in this case.
Question 215
A build pipeline deploys a mutable latest tag that a developer moved after staging acceptance. Which risk is directly created by the described failure?
- Recreating lost work manually can omit required changes or introduce an unreviewed release artifact.
- A library change can unexpectedly break production consumers or leave older copies vulnerable.
- Production can run different code than the reviewed release despite using the same version label.
- An unnecessary collaborator privilege can enable unauthorized source changes or exfiltrate proprietary code.
Explanation
Correct Answer
C:Production can run different code than the reviewed release despite using the same version label. This is the directly relevant business or security consequence of protected release tags and verifiable version references. Root cause: A human-friendly release tag is not sufficient evidence when its target may be changed without control.
Incorrect Answers
A:Recreating lost work manually can omit required changes or introduce an unreviewed release artifact. That risk is relevant to recover deleted commits using git reflog safely, but the specific unresolved condition here concerns protected release tags and verifiable version references and has a different direct consequence.
B:A library change can unexpectedly break production consumers or leave older copies vulnerable. That risk is relevant to cross-repository shared code via versioned packages, but the specific unresolved condition here concerns protected release tags and verifiable version references and has a different direct consequence.
D:An unnecessary collaborator privilege can enable unauthorized source changes or exfiltrate proprietary code. That risk is relevant to least-privilege github organization collaborator permissions, but the specific unresolved condition here concerns protected release tags and verifiable version references and has a different direct consequence.
Question 216
A GitHub Release is published with a tag name already reused for another commit, undermining audit evidence. What change should the DevOps engineer implement FIRST for the stated Azure DevOps requirement?
- Publish reusable components under immutable versions and define explicit cross-repository dependency ownership.
- Protect critical release tags and pin deployment records to immutable commit IDs and associated artifact digests.
- Use reflog or known commit identifiers to recover the intended change, then reapply normal PR and validation rules.
- Use Git LFS or appropriate artifact storage for large binaries while retaining versioned pointer and permission management.
Explanation
Correct Answer
B:Protect critical release tags and pin deployment records to immutable commit IDs and associated artifact digests. A human-friendly release tag is not sufficient evidence when its target may be changed without control. Production can run different code than the reviewed release despite using the same version label.
Incorrect Answers
A:Publish reusable components under immutable versions and define explicit cross-repository dependency ownership. That applies to cross-repository shared code via versioned packages, not protected release tags and verifiable version references.
C:Use reflog or known commit identifiers to recover the intended change, then reapply normal PR and validation rules. That applies to recover deleted commits using git reflog safely, not protected release tags and verifiable version references.
D:Use Git LFS or appropriate artifact storage for large binaries while retaining versioned pointer and permission management. That applies to git lfs for oversized binary assets in version history, not protected release tags and verifiable version references.
Question 217
A GitHub Release is published with a tag name already reused for another commit, undermining audit evidence. What check would most directly verify this Microsoft DevOps control?
- Compare release tag history, signed commit identity, artifact provenance, and staging-to-production deployment references.
- Rebuild a prior release using package lock or submodule commit pins and compare retrieved component hashes.
- Locate the original commit hash, compare its diff with the issue, and rerun required tests after recovery.
- Clone a test repository with and without LFS access and verify large-object retrieval, revisions, and CI runner storage use.
Explanation
Correct Answer
A:Compare release tag history, signed commit identity, artifact provenance, and staging-to-production deployment references. A human-friendly release tag is not sufficient evidence when its target may be changed without control.
Incorrect Answers
B:Rebuild a prior release using package lock or submodule commit pins and compare retrieved component hashes. That applies to cross-repository shared code via versioned packages, not protected release tags and verifiable version references.
C:Locate the original commit hash, compare its diff with the issue, and rerun required tests after recovery. That applies to recover deleted commits using git reflog safely, not protected release tags and verifiable version references.
D:Clone a test repository with and without LFS access and verify large-object retrieval, revisions, and CI runner storage use. That applies to git lfs for oversized binary assets in version history, not protected release tags and verifiable version references.
Question 218
A GitHub Release is published with a tag name already reused for another commit, undermining audit evidence. Which design distinction is MOST relevant in these conditions?
- Git recovery can recover commit objects, but recovering content does not grant approval to deploy it.
- Repository access is a sensitive software supply-chain boundary, not simply a convenience for team participation.
- Removing a secret from current source does not invalidate leaked credentials or guarantee prior copies disappeared.
- A human-friendly release tag is not sufficient evidence when its target may be changed without control.
Explanation
Correct Answer
D:A human-friendly release tag is not sufficient evidence when its target may be changed without control. Production can run different code than the reviewed release despite using the same version label.
Incorrect Answers
A:Git recovery can recover commit objects, but recovering content does not grant approval to deploy it. That applies to recover deleted commits using git reflog safely, not controlling principle for protected release tags and verifiable version references.
B:Repository access is a sensitive software supply-chain boundary, not simply a convenience for team participation. That applies to least-privilege github organization collaborator permissions, not controlling principle for protected release tags and verifiable version references.
C:Removing a secret from current source does not invalidate leaked credentials or guarantee prior copies disappeared. That applies to removing committed secrets from git and rotating credentials, not controlling principle for protected release tags and verifiable version references.
Question 219
A GitHub Release is published with a tag name already reused for another commit, undermining audit evidence. Which ongoing guardrail would BEST prevent this problem from recurring?
- Apply dependency update automation and retain provenance of shared component versions.
- Enforce secret scanning, tight credential scopes, and training on safe Git history rewriting procedures.
- Enforce file-size policies and maintain LFS availability and retention for required revisions.
- Restrict tag deletion and modification and monitor unauthorized release reference changes.
Explanation
Correct Answer
D:Restrict tag deletion and modification and monitor unauthorized release reference changes. Production can run different code than the reviewed release despite using the same version label.
Incorrect Answers
A:Apply dependency update automation and retain provenance of shared component versions. This helps sustain a control for cross-repository shared code via versioned packages; it does not directly stop recurrence of protected release tags and verifiable version references described in this case.
B:Enforce secret scanning, tight credential scopes, and training on safe Git history rewriting procedures. This helps sustain a control for removing committed secrets from git and rotating credentials; it does not directly stop recurrence of protected release tags and verifiable version references described in this case.
C:Enforce file-size policies and maintain LFS availability and retention for required revisions. This helps sustain a control for git lfs for oversized binary assets in version history; it does not directly stop recurrence of protected release tags and verifiable version references described in this case.
Question 220
A GitHub Release is published with a tag name already reused for another commit, undermining audit evidence. Choose TWO measures that implement and verify an effective Azure DevOps response to this specific situation. (Choose TWO.)
- Compare release tag history, signed commit identity, artifact provenance, and staging-to-production deployment references.
- Dismiss the known risk for protected release tags and verifiable version references and keep no evidence or accountable owner after deployment.
- Declare protected release tags and verifiable version references successful solely from a green pipeline status and skip checking its actual control outcome.
- Protect critical release tags and pin deployment records to immutable commit IDs and associated artifact digests.
- Bypass review and testing for protected release tags and verifiable version references whenever the release deadline is urgent, applying the change to production immediately.
Explanation
Correct Answers
A:Compare release tag history, signed commit identity, artifact provenance, and staging-to-production deployment references. A human-friendly release tag is not sufficient evidence when its target may be changed without control.
D:Protect critical release tags and pin deployment records to immutable commit IDs and associated artifact digests. A human-friendly release tag is not sufficient evidence when its target may be changed without control. Production can run different code than the reviewed release despite using the same version label.
Incorrect Answers
B:Dismiss the known risk for protected release tags and verifiable version references and keep no evidence or accountable owner after deployment. It conflicts with the stated operating condition: A human-friendly release tag is not sufficient evidence when its target may be changed without control.
C:Declare protected release tags and verifiable version references successful solely from a green pipeline status and skip checking its actual control outcome. It conflicts with the stated operating condition: A human-friendly release tag is not sufficient evidence when its target may be changed without control.
E:Bypass review and testing for protected release tags and verifiable version references whenever the release deadline is urgent, applying the change to production immediately. It conflicts with the stated operating condition: A human-friendly release tag is not sufficient evidence when its target may be changed without control.
Designing and Implementing Microsoft DevOps Solutions (AZ-400) Practice Tests
