How Can Automation1 Read Only Secret1 in Vault1?

SC-300 By islever Editorial Last updated

Short answer

D Assign Automation1's managed identity a secret-scoped RBAC role, such as Key Vault Secrets User, on Secret1 only.

Question

You have an Azure subscription that contains an Azure Automation account named Automation1 and an Azure key vault named Vault1. Vault1 contains a secret named Secret1. You enable a system-assigned managed identity for Automation1. You need to ensure that Automation1 can read the contents of Secret1. The solution must meet the following requirements: • Prevent Automation1 from accessing other secrets stored in Vault1. • Follow the principle of least privilege. What should you do?
  1. From Vault1, configure the Access control (IAM) settings.
  2. From Automation1, configure the Identity settings.
  3. From Automation1, configure the Run as accounts settings.
  4. From Secret1, configure the Access control (IAM) settings. Correct Answer

Key Takeaways

The exam tests the level at which an RBAC role assignment is scoped — secret-level versus vault-level — and the trap is that vault-wide IAM (option A) is the everyday habit but silently breaks the 'prevent access to other secrets' and least-privilege requirements.

This SC-300 item tests whether you can scope an Azure Key Vault RBAC role assignment down to a single secret so a system-assigned managed identity reads Secret1 and nothing else in Vault1. The correct action is to configure Access control (IAM) on Secret1 itself, not on the vault or on the Automation account's identity blade.

Common mistake: Choosing option A and granting the managed identity a role at the Vault1 scope, because that is the default admin path; it works functionally but the identity can then read every secret in Vault1, violating the stated requirement to block access to all other secrets.

Expert Analysis

Why the Answer Is Correct

A system-assigned managed identity on Automation1 is just a service principal, and Azure Key Vault's recommended permission model (Azure RBAC) allows role assignments at management-group, subscription, resource-group, vault, and — importantly for this scenario — individual secret scope. Option D assigns a least-privileged role such as Key Vault Secrets User directly on Secret1, so the identity's read permission applies to that one secret and cannot be extended to other secrets in Vault1. This is exactly the documented "secret scope role assignment" flow: open the secret, choose Access control (IAM), and add the role assignment there. Because the question explicitly says "prevent Automation1 from accessing other secrets stored in Vault1," the granular per-secret assignment is what satisfies both stated requirements.

Why the Other Options Are Wrong

Option A configures IAM at the Vault1 scope, which gives the managed identity read access to every secret in the vault — functional but a direct violation of the second requirement and of least privilege. Option B configures Automation1's Identity settings, which only manages the managed identity's existence and lifecycle; it grants no data-plane permission on Secret1 whatsoever. Option C refers to Run as accounts, a legacy Automation feature tied to service principals/certificates for runbook authentication, not to scoping RBAC permissions on a vault secret, and it is deprecated guidance for modern design. Only the secret-scoped role assignment isolates permission to the single object named in the requirement.

Community Comment Notes

Consensus on the page leans strongly toward D. Siraf describes it precisely as "Secret scope role assignment" and walks through opening the secret, clicking the Access control (IAM) tab, and adding the role assignment. blanco00555 flags the Microsoft caveat that "Assigning roles on individual keys, secrets and certificates should be avoided" but notes the documented exception applies when one application must be restricted to a specific secret — which is this scenario — and concludes "the exam wants us to answer D." Oskarma confirms hands-on validation: "Tested in my tenant," selecting Azure RBAC in Access configuration makes the IAM blade appear on the secret. klayytech adds an important precondition — with the legacy vault access policy model you cannot find IAM on Secret1, so the vault must be switched to Azure role-based access control. The dissenters (Manny_ez and enklau) argue for A on the grounds that access policies are configured at vault infrastructure and the question never states RBAC is enabled; that is a fair reading of a legacy model, but the stated isolation requirement points to the secret-scoped assignment.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a question says "prevent access to other secrets" or "least privilege" for a single Key Vault object, look for the option that scopes the role assignment at the object level, not the vault level. Remember the hidden precondition: the key vault must use the Azure RBAC permission model for per-secret IAM to exist at all.

Frequently Asked Questions

Why is configuring IAM on Vault1 (option A) wrong when it also grants read access?

Vault-scoped IAM grants the managed identity read permission on every secret in Vault1, which breaks the requirement to prevent Automation1 from accessing other secrets and violates least privilege.

Does option B, configuring Automation1's Identity settings, grant access to Secret1?

No. Identity settings only enable or manage the system-assigned managed identity; the data-plane permission on Secret1 still has to be granted through an RBAC role assignment on the secret.

Can I assign a role on Secret1 if the vault uses access policies instead of Azure RBAC?

No. Per-secret IAM only appears after the key vault is switched to the Azure role-based access control permission model in Access configuration.

More SC-300 FAQ →

Community Votes

D
61%
A
39%

61% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 14 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 14

  1. Manny_ez 👍 9 Answered A
    Correct answer is A. Correct me if I'm wrong though. To achieve the requirements of allowing Automation1 to read the contents of Secret1 while preventing it from accessing other secrets in Vault1 and following the principle of least privilege, this is how you can achieve this as well: Navigate to the Azure portal. Go to the Azure Key Vault (Vault1). Select "Access control (IAM)". Add a role assignment for the Automation1's managed identity with the necessary permissions (e.g., "Get" for secrets). By configuring the access control (IAM) settings at the vault level, you can specifically grant the required permissions to the managed identity of Automation1 for the Secret1, while avoiding unnecessary access to other secrets. So, the correct answer is: A. From Vault1, configure the Access control (IAM) settings.
  2. blanco00555 👍 5
    https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli Note: >Assigning roles on individual keys, secrets and certificates should be avoided. Exceptions to general guidance: >Scenarios where individual secrets must be shared between multiple applications, for example, one application needs to access data from the other application I guess the exam wants us to answer D in this case though. I would select D.
  3. Siraf 👍 5
    Answer is D: Secret scope role assignment: > Open a previously created secret. >Click the Access control(IAM) tab > Select Add > Add role assignment to open the Add role assignment page... https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli.
  4. klayytech 👍 4 Answered D
    D is the corrects, in depend on Permission model if you have. " Vault access policy" we cannot find the IAM role in secret1 you need to change to "Azure role-based access control (recommended)" https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli
  5. KRISTINMERIEANN 👍 4 Answered D
    https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli
Show 9 more comments
  1. jarattdavis 👍 2
    The correct answer is D. From Secret1, configure the Access control (IAM) settings. Explanation: Configuring the Access control (IAM) settings at the level of Secret1 ensures that the permissions are granted only for that specific secret and not for any other secrets stored in Vault1. This approach follows the principle of least privilege by granting the minimum required permissions.
  2. Obi_Wan_Jacoby 👍 1
    Answer D: When asking copilot to consider "the new modernization for Azure Key vault is to use the new RBAC permission model" and to elaborate on why not answer "A", I got the below. Certainly! Here’s why Answer A (configuring the Access control (IAM) settings from Vault1) is not the best choice: Granularity of Permissions: Configuring IAM settings at the vault level (Vault1) would grant permissions to the entire vault, potentially allowing Automation1 to access all secrets within Vault1. This does not adhere to the principle of least privilege, which aims to restrict access to only the necessary resources. Principle of Least Privilege: By configuring IAM settings directly on Secret1 (Answer D), you can ensure that Automation1 has access only to that specific secret and not to any other secrets stored in Vault1. This approach minimizes the risk of unauthorized access and follows best practices for security.
  3. klayytech 👍 1 Answered A
    The best course of action to achieve secure access to Secret1 while adhering to the principle of least privilege is: A. From Vault1, configure the Access control (IAM) settings. Here's why the other options are not ideal: B. From Automation1, configure the Identity settings: While enabling managed identity is a good first step, it doesn't grant specific permissions to access Vault1 resources. C. From Automation1, configure the Run as accounts settings (deprecated): Microsoft is phasing out Run As accounts, and they are considered less secure than managed identities. D. From Secret1, configure the Access control (IAM) settings: Secrets themselves cannot configure access control.
  4. YesPlease 👍 1 Answered D
    Answer D) From Secret1, configure the Access control (IAM) settings. https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-portal#secret-scope-role-assignment
  5. enklau 👍 1 Answered A
    i think that in this case it must be A because the access policy is configured at kv infra & scoped at secret level, & they'r not talking about rbac access ebabled for the kv
  6. Oskarma 👍 1 Answered D
    Tested in my tenant. First, choose Azure RBAC in Access configuration and then you see the IAM in the secret.
  7. bpaccount 👍 1 Answered A
    Co Pilot and ChatGPT are sure it's A.
  8. srysgbvjumozmail 👍 4
    Answer is D Tested
  9. HartMS 👍 4
    Answer is D

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How Long Are Microsoft Entra Risky User Activity Logs Retained?

S-grade

Azure User-Assigned Managed Identity Regional Scope

S-grade

Which role for the Permissions Management service principal?

S-grade

Prerequisite for Microsoft Defender for Cloud Apps Session Policy

S-grade

Practice All SC-300 Questions

Access 80 questions with complete answers and detailed explanations.

View Full SC-300 Practice Test →

← Back to SC-300 Study Guide