McAfee Secure

Microsoft SC-300 Bundle

Exam Code: SC-300

Exam Name Microsoft Identity and Access Administrator

Certification Provider: Microsoft

Corresponding Certification: Microsoft Certified: Identity and Access Administrator Associate

Microsoft SC-300 Bundle $44.99
SC-300 Sample 1 SC-300 Sample 2 SC-300 Sample 3 SC-300 Sample 4 SC-300 Sample 5 SC-300 Sample 6 SC-300 Sample 7 SC-300 Sample 8 SC-300 Sample 9 SC-300 Sample 10

100% Microsoft SC-300 Guaranteed Success With Testking Training Materials

Get Real SC-300 Exam Questions & Expert Verified Answers as Experienced on the Real Exam!

  • Questions & Answers

    SC-300 Questions & Answers

    490 Questions & Answers

    The ultimate exam preparation tool, Questions & Answers mirrors the actual SC-300 exam while allowing you to hone and measure every aspect of your test-taking ability.

  • SC-300 Video Course

    SC-300 Training Course

    43 Video Lectures

    SC-300 Video Course is developed by Microsoft Professionals to help you pass the SC-300 exam.

    Description

    This course will improve your knowledge and skills required to pass Microsoft Identity and Access Administrator exam.
  • Study Guide

    SC-300 Study Guide

    599 PDF Pages

    Developed by industry experts, this 599-page guide spells out in painstaking detail all of the information you need to ace SC-300 exam.

Microsoft Identity and Access Administrator (SC-300) Practice Tests

Satisfaction Guaranteed

Money Back Guarantee

Testking provides hassle-free money back guarantee with our products. That is because we have 100% trust in the abilities of our professional and experience product team, and our record is a proof of that.

99.6% PASS RATE
Total Cost: $194.97
Bundle Price: $149.98

Purchase Individually

  • Questions & Answers

    Questions & Answers

    490 Questions

    $124.99
  • SC-300 Video Course

    Training Course

    43 Video Lectures

    $39.99
  • Study Guide

    Study Guide

    599 PDF Pages

    $29.99

Microsoft SC-300 Practice Test 33

Question 320

An operational review checks whether the change “Use a dedicated service principal or managed identity, grant narrowly scoped resource RBAC, and acquire a token for the resource” meets this need: An application must call an Azure resource using short-lived tokens while following least privilege and avoiding shared administrator credentials. Which finding supports acceptance?

  1. The Function presents its system-assigned identity token and retrieves only its approved vault secret, with no long-lived client password in settings
  2. The unattended job calls the approved Graph endpoint under the application identity without a signed-in employee
  3. The workload reaches only its approved target and authentication logs identify the application principal
  4. The recorded application/service principal ID ties each resource request to the actual workload, not a named human account

Explanation

Correct Answer

C:

Correct acceptance check. The workload reaches only its approved target and authentication logs identify the application principal. This tests the intended access or synchronization boundary instead of merely checking that a setting exists.

Incorrect Answers

A:

Even if enabling a Function system-assigned managed identity succeeds, this does not prove the required identity-control outcome. The decisive check is: The workload reaches only its approved target and authentication logs identify the application principal.

B:

Even if granting narrowly scoped Microsoft Graph application permissions through the application registration succeeds, this does not prove the required identity-control outcome. The decisive check is: The workload reaches only its approved target and authentication logs identify the application principal.

D:

Even if inspecting resource access logs succeeds, this does not prove the required identity-control outcome. The decisive check is: The workload reaches only its approved target and authentication logs identify the application principal.

Question 321

An engineer troubleshoots an identity solution for: An application must call an Azure resource using short-lived tokens while following least privilege and avoiding shared administrator credentials. The pilot result is: Audit logs show a human administrator identity as the workload caller. What is the most likely relevant fault?

  1. The VM app is requesting a token for the wrong resource audience
  2. The app is configured with application permissions instead of delegated permissions for its interactive calls
  3. The application still runs under a personal Global Administrator session
  4. Investigators compare only display names without validating the stable service principal object ID

Explanation

Correct Answer

C:

Correct diagnosis. The application still runs under a personal Global Administrator session. This fault explains the observed failure: Audit logs show a human administrator identity as the workload caller. The intended configuration would instead be: Use a dedicated service principal or managed identity, grant narrowly scoped resource RBAC, and acquire a token for the resource.

Incorrect Answers

A:

The VM app is requesting a token for the wrong resource audience. The reported symptom instead has this cause: The application still runs under a personal Global Administrator session. The corrective action is: Use a dedicated service principal or managed identity, grant narrowly scoped resource RBAC, and acquire a token for the resource.

B:

The app is configured with application permissions instead of delegated permissions for its interactive calls. The reported symptom instead has this cause: The application still runs under a personal Global Administrator session. The corrective action is: Use a dedicated service principal or managed identity, grant narrowly scoped resource RBAC, and acquire a token for the resource.

D:

Investigators compare only display names without validating the stable service principal object ID. The reported symptom instead has this cause: The application still runs under a personal Global Administrator session. The corrective action is: Use a dedicated service principal or managed identity, grant narrowly scoped resource RBAC, and acquire a token for the resource.

Question 322

Select the most appropriate first configuration decision for this scenario: A background Azure job has a user-assigned managed identity but needs to select it explicitly when more than one identity is attached.

  1. Grant the managed identity an appropriate Storage Blob Data Reader or other narrowly necessary Blob data-plane role at the intended container/account scope; do not mistake Azure Reader for blob content access
  2. Register the application for delegated user sign-in and request only the required delegated scopes
  3. Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments
  4. Create a user-assigned managed identity, grant its needed roles, and attach it to each replacement workload

Explanation

Correct Answer

C:

Correct implementation. Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments. It meets the stated requirement: A background Azure job has a user-assigned managed identity but needs to select it explicitly when more than one identity is attached. Acceptance evidence is: The token identifies the selected user-assigned identity and its precisely granted data/resource role, not another attached workload identity.

Incorrect Answers

A:

The identity has management-plane Reader or Contributor access but not the required Azure Storage Blob Data role. That condition is not the problem here: The app selected a default or different attached identity client ID instead of the one granted resource access. The targeted implementation is: Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments.

B:

The app is configured with application permissions instead of delegated permissions for its interactive calls. That condition is not the problem here: The app selected a default or different attached identity client ID instead of the one granted resource access. The targeted implementation is: Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments.

D:

The service used a system-assigned identity whose lifecycle ended with the old compute instance. That condition is not the problem here: The app selected a default or different attached identity client ID instead of the one granted resource access. The targeted implementation is: Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments.

Question 323

After a deployment under this requirement — A background Azure job has a user-assigned managed identity but needs to select it explicitly when more than one identity is attached — administrators claim the following solution is in place: Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments. Which pilot finding supports that claim?

  1. The Function presents its system-assigned identity token and retrieves only its approved vault secret, with no long-lived client password in settings
  2. The VM retrieves only the approved vault object using its identity endpoint without any stored application secret
  3. Deleting the App Service removes the attached system identity lifecycle, and a replacement app cannot inherit the old principal automatically
  4. The token identifies the selected user-assigned identity and its precisely granted data/resource role, not another attached workload identity

Explanation

Correct Answer

D:

Correct acceptance check. The token identifies the selected user-assigned identity and its precisely granted data/resource role, not another attached workload identity. This tests the intended access or synchronization boundary instead of merely checking that a setting exists.

Incorrect Answers

A:

Even if enabling a Function system-assigned managed identity succeeds, this does not prove the required identity-control outcome. The decisive check is: The token identifies the selected user-assigned identity and its precisely granted data/resource role, not another attached workload identity.

B:

Even if enabling an appropriate managed identity on the VM succeeds, this does not prove the required identity-control outcome. The decisive check is: The token identifies the selected user-assigned identity and its precisely granted data/resource role, not another attached workload identity.

C:

Even if enabling a system-assigned managed identity succeeds, this does not prove the required identity-control outcome. The decisive check is: The token identifies the selected user-assigned identity and its precisely granted data/resource role, not another attached workload identity.

Question 324

A change appears correct at a glance, but the requirement is still unmet: A background Azure job has a user-assigned managed identity but needs to select it explicitly when more than one identity is attached. The key observed symptom is: The target resource denies access because the access token belongs to another managed identity. Which cause should be investigated first?

  1. The service used a system-assigned identity whose lifecycle ended with the old compute instance
  2. The app selected a default or different attached identity client ID instead of the one granted resource access
  3. A user-assigned identity was used even though identity lifecycle was meant to be bound to that app
  4. The app is configured with application permissions instead of delegated permissions for its interactive calls

Explanation

Correct Answer

B:

Correct diagnosis. The app selected a default or different attached identity client ID instead of the one granted resource access. This fault explains the observed failure: The target resource denies access because the access token belongs to another managed identity. The intended configuration would instead be: Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments.

Incorrect Answers

A:

The service used a system-assigned identity whose lifecycle ended with the old compute instance. The reported symptom instead has this cause: The app selected a default or different attached identity client ID instead of the one granted resource access. The corrective action is: Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments.

C:

A user-assigned identity was used even though identity lifecycle was meant to be bound to that app. The reported symptom instead has this cause: The app selected a default or different attached identity client ID instead of the one granted resource access. The corrective action is: Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments.

D:

The app is configured with application permissions instead of delegated permissions for its interactive calls. The reported symptom instead has this cause: The app selected a default or different attached identity client ID instead of the one granted resource access. The corrective action is: Select the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector, and separately use its principal object ID for downstream RBAC role assignments.

Question 325

Two teams share the same release window but not the same access policy. Team A needs: A daemon service requires Microsoft Graph app-only authorization and must not depend on a human's delegated sign-in. Team B needs: An Azure deployment pipeline must access a target subscription but cannot keep password credentials in its build variables. Which TWO implementations should be included?

  1. Enable a system-assigned managed identity and scope its downstream permissions to that service identity
  2. Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent
  3. Configure an approved federated workload identity for the deployment principal and assign minimal Azure RBAC at target scope
  4. Inspect resource access logs and service-principal sign-in activity using principal and client IDs
  5. Create an application registration and configure workload identity federation with the trusted external issuer and subject

Explanation

Correct Answers

B:

Correct for task 1. Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent. This directly addresses the first requirement: A daemon service requires Microsoft Graph app-only authorization and must not depend on a human's delegated sign-in. Verify it by checking: The unattended job calls the approved Graph endpoint under the application identity without a signed-in employee.

C:

Correct for task 2. Configure an approved federated workload identity for the deployment principal and assign minimal Azure RBAC at target scope. This addresses the independent second requirement: An Azure deployment pipeline must access a target subscription but cannot keep password credentials in its build variables. Verify it by checking: A trusted pipeline run deploys in the allowed resource group without a client secret; other repositories cannot exchange credentials.

Incorrect Answers

A:

A user-assigned identity was used even though identity lifecycle was meant to be bound to that app. To satisfy task 1, use: Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent. For task 2, use: Configure an approved federated workload identity for the deployment principal and assign minimal Azure RBAC at target scope.

D:

Investigators compare only display names without validating the stable service principal object ID. To satisfy task 1, use: Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent. For task 2, use: Configure an approved federated workload identity for the deployment principal and assign minimal Azure RBAC at target scope.

E:

The federated credential's subject or audience does not match the issued workload token. To satisfy task 1, use: Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent. For task 2, use: Configure an approved federated workload identity for the deployment principal and assign minimal Azure RBAC at target scope.

Question 326

The team implemented the following change: Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent. The acceptance requirement was: A daemon service requires Microsoft Graph app-only authorization and must not depend on a human's delegated sign-in. Which observed outcome most directly proves the change works?

  1. A signed-in user obtains a token reflecting approved delegated permissions and cannot exceed their own authorization
  2. The recorded application/service principal ID ties each resource request to the actual workload, not a named human account
  3. The unattended job calls the approved Graph endpoint under the application identity without a signed-in employee
  4. The identity reads an allowed blob with the Blob data role while another scoped container stays inaccessible despite successful token acquisition

Explanation

Correct Answer

C:

Correct acceptance check. The unattended job calls the approved Graph endpoint under the application identity without a signed-in employee. This tests the intended access or synchronization boundary instead of merely checking that a setting exists.

Incorrect Answers

A:

Even if registering the application for delegated user sign-in succeeds, this does not prove the required identity-control outcome. The decisive check is: The unattended job calls the approved Graph endpoint under the application identity without a signed-in employee.

B:

Even if inspecting resource access logs succeeds, this does not prove the required identity-control outcome. The decisive check is: The unattended job calls the approved Graph endpoint under the application identity without a signed-in employee.

D:

Even if granting the managed identity an appropriate Storage Blob Data Reader or other narrowly necessary Blob data-plane role at the intended container/account scope succeeds, this does not prove the required identity-control outcome. The decisive check is: The unattended job calls the approved Graph endpoint under the application identity without a signed-in employee.

Question 327

The service desk escalates the following unsuccessful identity rollout. Requirement: A daemon service requires Microsoft Graph app-only authorization and must not depend on a human's delegated sign-in. Observed: Daemon token calls succeed but app-only Graph requests return insufficient privileges. Which underlying misconfiguration is most consistent?

  1. The Function identity lacks the Key Vault secret data-plane authorization required by its configured vault permission model
  2. Investigators compare only display names without validating the stable service principal object ID
  3. The app is configured with application permissions instead of delegated permissions for its interactive calls
  4. The app requested only delegated scopes and never received application permission consent

Explanation

Correct Answer

D:

Correct diagnosis. The app requested only delegated scopes and never received application permission consent. This fault explains the observed failure: Daemon token calls succeed but app-only Graph requests return insufficient privileges. The intended configuration would instead be: Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent.

Incorrect Answers

A:

The Function identity lacks the Key Vault secret data-plane authorization required by its configured vault permission model. The reported symptom instead has this cause: The app requested only delegated scopes and never received application permission consent. The corrective action is: Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent.

B:

Investigators compare only display names without validating the stable service principal object ID. The reported symptom instead has this cause: The app requested only delegated scopes and never received application permission consent. The corrective action is: Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent.

C:

The app is configured with application permissions instead of delegated permissions for its interactive calls. The reported symptom instead has this cause: The app requested only delegated scopes and never received application permission consent. The corrective action is: Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent.

Question 328

Which implementation fits the following specific identity problem? Two APIs share a tenant but each must validate access tokens intended for its own audience.

  1. Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate
  2. Register the application for delegated user sign-in and request only the required delegated scopes
  3. Grant narrowly scoped Microsoft Graph application permissions through the application registration and obtain appropriate administrator consent
  4. Create an application registration and configure workload identity federation with the trusted external issuer and subject

Explanation

Correct Answer

A:

Correct implementation. Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate. It meets the stated requirement: Two APIs share a tenant but each must validate access tokens intended for its own audience. Acceptance evidence is: A token minted for API A is accepted by A and rejected when replayed to API B.

Incorrect Answers

B:

The app is configured with application permissions instead of delegated permissions for its interactive calls. That condition is not the problem here: The receiving API does not verify the audience claim. The targeted implementation is: Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate.

C:

The app requested only delegated scopes and never received application permission consent. That condition is not the problem here: The receiving API does not verify the audience claim. The targeted implementation is: Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate.

D:

The federated credential's subject or audience does not match the issued workload token. That condition is not the problem here: The receiving API does not verify the audience claim. The targeted implementation is: Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate.

Question 329

An auditor must verify this deployment decision: Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate. Its purpose was: Two APIs share a tenant but each must validate access tokens intended for its own audience. Which test result is the strongest evidence?

  1. A token minted for API A is accepted by A and rejected when replayed to API B
  2. The token identifies the selected user-assigned identity and its precisely granted data/resource role, not another attached workload identity
  3. A token exchange from the approved external workload succeeds and a different subject fails, with no static secret stored
  4. The identity reads an allowed blob with the Blob data role while another scoped container stays inaccessible despite successful token acquisition

Explanation

Correct Answer

A:

Correct acceptance check. A token minted for API A is accepted by A and rejected when replayed to API B. This tests the intended access or synchronization boundary instead of merely checking that a setting exists.

Incorrect Answers

B:

Even if selecting the intended user-assigned managed identity by its client ID or supported Azure SDK credential selector succeeds, this does not prove the required identity-control outcome. The decisive check is: A token minted for API A is accepted by A and rejected when replayed to API B.

C:

Even if creating an application registration succeeds, this does not prove the required identity-control outcome. The decisive check is: A token minted for API A is accepted by A and rejected when replayed to API B.

D:

Even if granting the managed identity an appropriate Storage Blob Data Reader or other narrowly necessary Blob data-plane role at the intended container/account scope succeeds, this does not prove the required identity-control outcome. The decisive check is: A token minted for API A is accepted by A and rejected when replayed to API B.

Question 330

During post-change review of the requirement “Two APIs share a tenant but each must validate access tokens intended for its own audience,” an auditor observes: API B accepts a validly signed token originally issued for API A. Which root-cause finding would explain that symptom?

  1. The service used a system-assigned identity whose lifecycle ended with the old compute instance
  2. The federated credential's subject or audience does not match the issued workload token
  3. The receiving API does not verify the audience claim
  4. The VM app is requesting a token for the wrong resource audience

Explanation

Correct Answer

C:

Correct diagnosis. The receiving API does not verify the audience claim. This fault explains the observed failure: API B accepts a validly signed token originally issued for API A. The intended configuration would instead be: Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate.

Incorrect Answers

A:

The service used a system-assigned identity whose lifecycle ended with the old compute instance. The reported symptom instead has this cause: The receiving API does not verify the audience claim. The corrective action is: Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate.

B:

The federated credential's subject or audience does not match the issued workload token. The reported symptom instead has this cause: The receiving API does not verify the audience claim. The corrective action is: Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate.

D:

The VM app is requesting a token for the wrong resource audience. The reported symptom instead has this cause: The receiving API does not verify the audience claim. The corrective action is: Configure the API's expected audience/app ID URI and validate issuer, audience, signature and scopes or roles as appropriate.