How Can Automation1 Read Only Secret1 in Vault1?
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?
Community Votes
61% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (14 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.
Related Analysis
Practice All SC-300 Questions
Access 80 questions with complete answers and detailed explanations.
View Full SC-300 Practice Test →