Microsoft AZ-400 Practice Test 85

Question 840

An organization trusts every branch of a public repository to obtain a production deployment token. Choose TWO measures that implement and verify an effective Azure DevOps response to this specific situation. (Choose TWO.)

Declare openid connect federation for github actions azure access successful solely from a green pipeline status and skip checking its actual control outcome.
Bypass review and testing for openid connect federation for github actions azure access whenever the release deadline is urgent, applying the change to production immediately.
Dismiss the known risk for openid connect federation for github actions azure access and keep no evidence or accountable owner after deployment.
Test token issuance from the approved deployment job and rejection from an unauthorized branch or fork.
Configure federated identity credentials with restricted repository, branch or environment subject and correct audience.

Explanation

Correct Answers

D:

Test token issuance from the approved deployment job and rejection from an unauthorized branch or fork. OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims.

E:

Configure federated identity credentials with restricted repository, branch or environment subject and correct audience. OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims. Overly broad federated trust can permit unauthorized production access despite using short-lived credentials.

Incorrect Answers

A:

Declare openid connect federation for github actions azure access successful solely from a green pipeline status and skip checking its actual control outcome. It conflicts with the stated operating condition: OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims.

B:

Bypass review and testing for openid connect federation for github actions azure access whenever the release deadline is urgent, applying the change to production immediately. It conflicts with the stated operating condition: OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims.

C:

Dismiss the known risk for openid connect federation for github actions azure access and keep no evidence or accountable owner after deployment. It conflicts with the stated operating condition: OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims.

Question 841

A mobile app release stores a PFX signing certificate directly in a public Git repository. Which solution should be prioritized to resolve the stated failure?

Use secret-aware tasks, masked variables, safe output handling, and controlled artifact content to prevent disclosure.
Configure federated identity credentials with restricted repository, branch or environment subject and correct audience.
Store secrets and certificates in Key Vault and grant the appropriate workload identity narrowly scoped access.
Store signing material in Azure Pipelines secure files with explicit permissions and authorized pipeline use.

Explanation

Correct Answer

D:

Store signing material in Azure Pipelines secure files with explicit permissions and authorized pipeline use. Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access. Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization.

Incorrect Answers

A:

Use secret-aware tasks, masked variables, safe output handling, and controlled artifact content to prevent disclosure. That applies to preventing secret leaks in pipeline logs and artifacts, not secure files protection for mobile signing certificates.

B:

Configure federated identity credentials with restricted repository, branch or environment subject and correct audience. That applies to openid connect federation for github actions azure access, not secure files protection for mobile signing certificates.

C:

Store secrets and certificates in Key Vault and grant the appropriate workload identity narrowly scoped access. That applies to key vault secrets and certificate access from release stages, not secure files protection for mobile signing certificates.

Question 842

A mobile app release stores a PFX signing certificate directly in a public Git repository. Which evidence would BEST demonstrate that the fix operates as intended?

Validate that the intended release identity retrieves only its authorized secret or certificate and the audit log records access.
Run a restricted job and verify access is denied while the approved signer can retrieve and use the file without logging its contents.
Test token issuance from the approved deployment job and rejection from an unauthorized branch or fork.
Search test logs and generated artifacts for safe secret markers and review access to protected outputs.

Explanation

Correct Answer

B:

Run a restricted job and verify access is denied while the approved signer can retrieve and use the file without logging its contents. Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access.

Incorrect Answers

A:

Validate that the intended release identity retrieves only its authorized secret or certificate and the audit log records access. That applies to key vault secrets and certificate access from release stages, not secure files protection for mobile signing certificates.

C:

Test token issuance from the approved deployment job and rejection from an unauthorized branch or fork. That applies to openid connect federation for github actions azure access, not secure files protection for mobile signing certificates.

D:

Search test logs and generated artifacts for safe secret markers and review access to protected outputs. That applies to preventing secret leaks in pipeline logs and artifacts, not secure files protection for mobile signing certificates.

Question 843

A mobile app release stores a PFX signing certificate directly in a public Git repository. Which design distinction is MOST relevant in these conditions?

OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims.
Secret storage alone does not protect credentials if scripts echo them or package them into published artifacts.
A secret vault is effective only when runtime retrieval and key permissions align to workload identity and environment.
Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access.

Explanation

Correct Answer

D:

Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access. Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization.

Incorrect Answers

A:

OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims. That applies to openid connect federation for github actions azure access, not controlling principle for secure files protection for mobile signing certificates.

B:

Secret storage alone does not protect credentials if scripts echo them or package them into published artifacts. That applies to preventing secret leaks in pipeline logs and artifacts, not controlling principle for secure files protection for mobile signing certificates.

C:

A secret vault is effective only when runtime retrieval and key permissions align to workload identity and environment. That applies to key vault secrets and certificate access from release stages, not controlling principle for secure files protection for mobile signing certificates.

Question 844

A mobile app release stores a PFX signing certificate directly in a public Git repository. Which ongoing guardrail would BEST prevent this problem from recurring?

Enable secret scanning in pull requests and rotate any token observed in accessible logs or builds.
Review federation subjects and retire old client secrets after workflow and environment changes.
Rotate exposed values, review certificate expiry, and prevent secret printing in pipeline logs.
Review secure-file permissions and rotate signing material when its authorized custodians change.

Explanation

Correct Answer

D:

Review secure-file permissions and rotate signing material when its authorized custodians change. Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization.

Incorrect Answers

A:

Enable secret scanning in pull requests and rotate any token observed in accessible logs or builds. This helps sustain a control for preventing secret leaks in pipeline logs and artifacts; it does not directly stop recurrence of secure files protection for mobile signing certificates described in this case.

B:

Review federation subjects and retire old client secrets after workflow and environment changes. This helps sustain a control for openid connect federation for github actions azure access; it does not directly stop recurrence of secure files protection for mobile signing certificates described in this case.

C:

Rotate exposed values, review certificate expiry, and prevent secret printing in pipeline logs. This helps sustain a control for key vault secrets and certificate access from release stages; it does not directly stop recurrence of secure files protection for mobile signing certificates described in this case.

Question 845

A mobile app release stores a PFX signing certificate directly in a public Git repository. Which risk is directly created by the described failure?

Overly broad federated trust can permit unauthorized production access despite using short-lived credentials.
A single logged or packaged credential can give unauthorized users access to sensitive services.
Poor secret handling can leak private keys or cause outages when deployed applications cannot access required material.
Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization.

Explanation

Correct Answer

D:

Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization. This is the directly relevant business or security consequence of secure files protection for mobile signing certificates. Root cause: Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access.

Incorrect Answers

A:

Overly broad federated trust can permit unauthorized production access despite using short-lived credentials. That risk is relevant to openid connect federation for github actions azure access, but the specific unresolved condition here concerns secure files protection for mobile signing certificates and has a different direct consequence.

B:

A single logged or packaged credential can give unauthorized users access to sensitive services. That risk is relevant to preventing secret leaks in pipeline logs and artifacts, but the specific unresolved condition here concerns secure files protection for mobile signing certificates and has a different direct consequence.

C:

Poor secret handling can leak private keys or cause outages when deployed applications cannot access required material. That risk is relevant to key vault secrets and certificate access from release stages, but the specific unresolved condition here concerns secure files protection for mobile signing certificates and has a different direct consequence.

Question 846

A release stage downloads a protected signing file but every pipeline in the organization is authorized to use it. Which implementation BEST addresses the operational issue?

Store signing material in Azure Pipelines secure files with explicit permissions and authorized pipeline use.
Store secrets and certificates in Key Vault and grant the appropriate workload identity narrowly scoped access.
Use secret-aware tasks, masked variables, safe output handling, and controlled artifact content to prevent disclosure.
Configure federated identity credentials with restricted repository, branch or environment subject and correct audience.

Explanation

Correct Answer

A:

Store signing material in Azure Pipelines secure files with explicit permissions and authorized pipeline use. Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access. Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization.

Incorrect Answers

B:

Store secrets and certificates in Key Vault and grant the appropriate workload identity narrowly scoped access. That applies to key vault secrets and certificate access from release stages, not secure files protection for mobile signing certificates.

C:

Use secret-aware tasks, masked variables, safe output handling, and controlled artifact content to prevent disclosure. That applies to preventing secret leaks in pipeline logs and artifacts, not secure files protection for mobile signing certificates.

D:

Configure federated identity credentials with restricted repository, branch or environment subject and correct audience. That applies to openid connect federation for github actions azure access, not secure files protection for mobile signing certificates.

Question 847

A release stage downloads a protected signing file but every pipeline in the organization is authorized to use it. How should the team validate the intended result?

Test token issuance from the approved deployment job and rejection from an unauthorized branch or fork.
Run a restricted job and verify access is denied while the approved signer can retrieve and use the file without logging its contents.
Validate that the intended release identity retrieves only its authorized secret or certificate and the audit log records access.
Search test logs and generated artifacts for safe secret markers and review access to protected outputs.

Explanation

Correct Answer

B:

Run a restricted job and verify access is denied while the approved signer can retrieve and use the file without logging its contents. Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access.

Incorrect Answers

A:

Test token issuance from the approved deployment job and rejection from an unauthorized branch or fork. That applies to openid connect federation for github actions azure access, not secure files protection for mobile signing certificates.

C:

Validate that the intended release identity retrieves only its authorized secret or certificate and the audit log records access. That applies to key vault secrets and certificate access from release stages, not secure files protection for mobile signing certificates.

D:

Search test logs and generated artifacts for safe secret markers and review access to protected outputs. That applies to preventing secret leaks in pipeline logs and artifacts, not secure files protection for mobile signing certificates.

Question 848

A release stage downloads a protected signing file but every pipeline in the organization is authorized to use it. Which design distinction is MOST relevant in these conditions?

A secret vault is effective only when runtime retrieval and key permissions align to workload identity and environment.
Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access.
Secret storage alone does not protect credentials if scripts echo them or package them into published artifacts.
OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims.

Explanation

Correct Answer

B:

Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access. Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization.

Incorrect Answers

A:

A secret vault is effective only when runtime retrieval and key permissions align to workload identity and environment. That applies to key vault secrets and certificate access from release stages, not controlling principle for secure files protection for mobile signing certificates.

C:

Secret storage alone does not protect credentials if scripts echo them or package them into published artifacts. That applies to preventing secret leaks in pipeline logs and artifacts, not controlling principle for secure files protection for mobile signing certificates.

D:

OIDC federation replaces standing secrets with short-lived tokens but is safe only with precise trust claims. That applies to openid connect federation for github actions azure access, not controlling principle for secure files protection for mobile signing certificates.

Question 849

A release stage downloads a protected signing file but every pipeline in the organization is authorized to use it. Which ongoing guardrail would BEST prevent this problem from recurring?

Rotate exposed values, review certificate expiry, and prevent secret printing in pipeline logs.
Enable secret scanning in pull requests and rotate any token observed in accessible logs or builds.
Review secure-file permissions and rotate signing material when its authorized custodians change.
Review federation subjects and retire old client secrets after workflow and environment changes.

Explanation

Correct Answer

C:

Review secure-file permissions and rotate signing material when its authorized custodians change. Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization.

Incorrect Answers

A:

Rotate exposed values, review certificate expiry, and prevent secret printing in pipeline logs. This helps sustain a control for key vault secrets and certificate access from release stages; it does not directly stop recurrence of secure files protection for mobile signing certificates described in this case.

B:

Enable secret scanning in pull requests and rotate any token observed in accessible logs or builds. This helps sustain a control for preventing secret leaks in pipeline logs and artifacts; it does not directly stop recurrence of secure files protection for mobile signing certificates described in this case.

D:

Review federation subjects and retire old client secrets after workflow and environment changes. This helps sustain a control for openid connect federation for github actions azure access; it does not directly stop recurrence of secure files protection for mobile signing certificates described in this case.

Question 850

A release stage downloads a protected signing file but every pipeline in the organization is authorized to use it. Which risk is directly created by the described failure?

Overly broad federated trust can permit unauthorized production access despite using short-lived credentials.
A single logged or packaged credential can give unauthorized users access to sensitive services.
Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization.
Poor secret handling can leak private keys or cause outages when deployed applications cannot access required material.

Explanation

Correct Answer

C:

Exposed signing certificates can let attackers publish packages that appear to come from the legitimate organization. This is the directly relevant business or security consequence of secure files protection for mobile signing certificates. Root cause: Sensitive deployment files require separate storage, authorization, and handling controls rather than ordinary repository access.

Incorrect Answers

A:

Overly broad federated trust can permit unauthorized production access despite using short-lived credentials. That risk is relevant to openid connect federation for github actions azure access, but the specific unresolved condition here concerns secure files protection for mobile signing certificates and has a different direct consequence.

B:

A single logged or packaged credential can give unauthorized users access to sensitive services. That risk is relevant to preventing secret leaks in pipeline logs and artifacts, but the specific unresolved condition here concerns secure files protection for mobile signing certificates and has a different direct consequence.

D:

Poor secret handling can leak private keys or cause outages when deployed applications cannot access required material. That risk is relevant to key vault secrets and certificate access from release stages, but the specific unresolved condition here concerns secure files protection for mobile signing certificates and has a different direct consequence.

Microsoft AZ-400 Exam Dumps, Practice Test Questions

Question 840

Explanation

Correct Answers

Incorrect Answers

Question 841

Explanation

Correct Answer

Incorrect Answers

Question 842

Explanation

Correct Answer

Incorrect Answers

Question 843

Explanation

Correct Answer

Incorrect Answers

Question 844

Explanation

Correct Answer

Incorrect Answers

Question 845

Explanation

Correct Answer

Incorrect Answers

Question 846

Explanation

Correct Answer

Incorrect Answers

Question 847

Explanation

Correct Answer

Incorrect Answers

Question 848

Explanation

Correct Answer

Incorrect Answers

Question 849

Explanation

Correct Answer

Incorrect Answers

Question 850

Explanation

Correct Answer

Incorrect Answers