The Access Control Configuration domain covers how Vault Enterprise authorizes requests: policies, tokens, roles, identity entities and groups, and Sentinel governance. Questions are scenario-based, asking you to pick the correct capability, token TTL behavior, or policy semantics, and to distinguish root policy powers from ordinary policy grants.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member
Be able to write correct HCL policies, choose the right capability for a KV v2 read scenario, and explain token_ttl versus token_max_ttl. The most important thing: grant exactly the capabilities the path needs, including list and metadata where required.
Writing HCL policies with capabilities like read, list, create, update, delete, sudo, and deny on KV v2 paths
Token lifecycle controls including token_ttl, token_max_ttl, periodic tokens, and explicit max TTL on auth roles
Root policy semantics and why it grants unrestricted access across all paths and operations
Sentinel in Vault Enterprise for fine-grained, role-based control beyond standard ACL policies
Watch out for
Common Access Control Configuration exam traps
▸Using read on KV v2 data paths without also granting the required list or metadata capabilities, causing the application to fail.
▸Assuming token_ttl is a hard limit; it is only the initial TTL, and tokens can renew up to token_max_ttl unless explicitly bounded.
▸Confusing root policy with sudo capability; sudo bypasses specific path restrictions but is not global unrestricted access.
Practice set
Access Control Configuration questions
20 questions · select your answer, then reveal the explanation
Listing all ACL policies via GET /sys/policies/acl returns every stored policy name, so you can confirm whether the specific policy exists. It satisfies the scenario's need to verify existence rather than read a policy's rules, which would require appending the policy name to the path.
You are troubleshooting a policy that is not granting the expected permissions. Which tool can help you simulate the policy evaluation for a given path?
Trap 1: vault audit-log
Audit logs show past actions, not simulation.
Trap 2: vault server --debug
This is for server diagnostic logging.
Trap 3: vault read sys/policies/acl
This reads the policy content, not its effective result.
The glob wildcard matches every path beneath the prefix, so secret/data/developers/* grants read on all child paths while excluding the bare prefix itself. This precisely satisfies the requirement to cover all paths starting with secret/data/developers/ using a single policy rule.
Endpoint Governing Policies attach to specific Vault endpoints and paths, evaluating requests against those endpoints rather than the broader token, identity, or role scope. This endpoint-level enforcement is what distinguishes EGP from RGPs, satisfying the question's definition.
An administrator wants to prevent users from listing secrets in a specific path but allow them to read individual secrets. How should the policy be structured?
An AppRole must be bound to an ACL policy that grants the token's permissions once the role authenticates. Without a policy attached, the issued token has no capabilities, so the ACL policy is one of the three required configuration items.
B
Root Token
Why it fails: Root tokens are not used for normal AppRole operations.
C
Role ID
The Role ID identifies which AppRole is being authenticated against, acting as the public half of the credential pair. Vault requires it alongside the Secret ID to complete the AppRole login, making it a mandatory configuration item.
D
Secret ID
The Secret ID is the secret half of the AppRole credential pair, proving the client is authorised to use that Role ID. Vault requires both halves for login, so the Secret ID is one of the three required items.
How can an administrator ensure that a secret is only accessible if the requester has a specific identity group membership?
Trap 1: By adding the group name to the path.
Vault policies bind access to paths, not group names embedded in the path; group membership is checked through identity group aliases and templated policy parameters. It is tempting because path naming conventions feel like access control, which suits scenarios where separate paths genuinely isolate distinct teams' secrets.
Why it fails: Vault policies bind access to paths, not group names embedded in the path; group membership is checked through identity group aliases and templated policy parameters. It is tempting because path naming conventions feel like access control, which suits scenarios where separate paths genuinely isolate distinct teams' secrets.
B
By using a Sentinel policy to validate the entity's group membership.
Sentinel policies evaluate identity metadata, including entity group membership, before granting access, so a policy can deny requests from entities outside the required group. This satisfies the constraint that access depends on specific group membership.
C
By modifying the auth method.
Why it fails: Auth methods don't track groups.
D
By setting a TTL on the group.
Why it fails: TTL does not impact access logic.
E
By creating a new namespace.
Why it fails: Namespaces are for partitioning, not access logic.
Why it fails: Password strength does not affect authorization.
B
The number of active mounts.
Why it fails: Mount count does not affect authorization.
C
Active Sentinel policies.
Sentinel policies act as a secondary authorisation layer, evaluated after ACL policies to restrict or deny access. They cannot grant permissions, only enforce additional constraints such as mandatory MFA or time windows. This satisfies the stem's requirement that effective permissions reflect every policy type applied to the user's token.
D
Policies attached to the identity entity.
Policies attached to the identity entity apply across every token the entity authenticates with, so they form a persistent permission layer. This makes entity policies one of the three factors determining a user's effective permissions in Vault.
E
Policies attached to the token.
Policies attached directly to a token are evaluated at request time and can grant or restrict access for that token's lifetime. They are one of the three factors that combine to produce a user's effective permissions.
Request TTL defines how long an approved Control Group request remains valid before it expires and must be re-initiated. It is a required component of the Control Group configuration, governing the window during which authorisers can approve the pending request.
B
Secret engine path.
Why it fails: The path is the target, not a component of the config.
C
Policy name.
Why it fails: Policies are not part of the control group definition itself.
D
Approver identity group.
An approver identity group defines who must authorise a Control Group request before access is granted, satisfying the requirement that privileged actions need explicit human approval. Control Groups combine this approver set with the required factors, so the group is a genuine configuration component rather than an optional add-on.
E
Auth method name.
Why it fails: Auth methods are not directly part of the group config.
A Vault Enterprise cluster uses namespaces to isolate tenants. A security team wants to enforce that any token issued to the 'payments' namespace can only access secrets under the path 'payments/data/*' and must have a maximum TTL of 1 hour. They also want to prevent any child namespace from overriding these restrictions. Which two configurations must be applied to achieve this? (Choose two.)
Trap 1: Enable the 'payments' namespace as a child of the root namespace…
A global Sentinel policy at the root level would apply to all namespaces, not just 'payments', potentially causing unintended restrictions elsewhere. Moreover, Sentinel policies are scoped to the namespace where they are defined; a root-level policy does not automatically propagate to child namespaces unless explicitly configured. This approach lacks the required granularity.
Trap 2: Use Vault's identity groups to map users from an external identity…
Identity groups and external identity provider mappings control authentication and policy assignment but do not enforce token TTL limits. Policies attached to groups are ACL policies, which cannot set max_ttl. TTL is managed through token roles or auth method role configurations, not through group policies.
Trap 3: Create an ACL policy in the 'payments' namespace that grants read…
ACL policies in Vault control path capabilities but cannot enforce a maximum TTL for tokens. TTL is set at token creation time or via role configuration, not within an ACL policy. While an ACL policy can restrict access to 'payments/data/*', it does not prevent a user from creating a token with a longer TTL, nor does it prevent child namespace overrides.
Configure a token role in the 'payments' namespace with allowed_policies set to the ACL policy and explicit_max_ttl set to 1h.
Token roles in Vault Enterprise allow you to define parameters for tokens created against that role, including explicit_max_ttl. By setting explicit_max_ttl to 1h and allowed_policies to the ACL policy that grants access to 'payments/data/*', you enforce both the path and TTL restrictions. This works in conjunction with Sentinel EGP for comprehensive control.
B
Enable the 'payments' namespace as a child of the root namespace and apply a global Sentinel policy at the root level.
Why it fails: A global Sentinel policy at the root level would apply to all namespaces, not just 'payments', potentially causing unintended restrictions elsewhere. Moreover, Sentinel policies are scoped to the namespace where they are defined; a root-level policy does not automatically propagate to child namespaces unless explicitly configured. This approach lacks the required granularity.
C
Use Vault's identity groups to map users from an external identity provider to a group that has a policy attached with a max_ttl parameter.
Why it fails: Identity groups and external identity provider mappings control authentication and policy assignment but do not enforce token TTL limits. Policies attached to groups are ACL policies, which cannot set max_ttl. TTL is managed through token roles or auth method role configurations, not through group policies.
D
Create an ACL policy in the 'payments' namespace that grants read capabilities on 'payments/data/*' and set a token TTL in the policy.
Why it fails: ACL policies in Vault control path capabilities but cannot enforce a maximum TTL for tokens. TTL is set at token creation time or via role configuration, not within an ACL policy. While an ACL policy can restrict access to 'payments/data/*', it does not prevent a user from creating a token with a longer TTL, nor does it prevent child namespace overrides.
E
Create a Sentinel EGP policy in the 'payments' namespace that restricts token creation based on path and TTL.
An Endpoint Governing Policy (EGP) in Vault Enterprise enforces rules on specific API endpoints. Placing it in the 'payments' namespace ensures that any token creation request within that namespace is evaluated against the policy, allowing you to restrict the token's path and maximum TTL. This is the correct mechanism for centralized enforcement across child namespaces.
An administrator is configuring access control for a Vault Enterprise cluster. They need to grant a team of developers read-only access to all secrets under the 'kv/' secrets engine, but they must also ensure that the developers cannot list the contents of the 'kv/' path itself. Which policy configuration achieves this?
Trap 1: path "kv/" { capabilities = ["read"] }
This policy only applies to the exact path 'kv/' and grants read capability there. It does not grant any access to secrets under 'kv/', such as 'kv/mysecret'. Developers would be unable to read the secrets, which fails the primary requirement. Additionally, 'read' on 'kv/' does not prevent listing; 'list' capability is separate.
The deny capability on 'kv/' would explicitly block any access to that path, including read and list. However, the requirement is to allow reading secrets under 'kv/' while preventing listing of 'kv/'. The deny on 'kv/' would not affect 'kv/*' paths, but it also does not prevent listing of 'kv/' because list is a separate capability. More importantly, the deny on 'kv/' is unnecessary and could interfere with other operations.
This policy grants both read and list capabilities on all paths under 'kv/'. The 'list' capability would allow developers to enumerate the keys under 'kv/', which violates the requirement to prevent listing. Therefore, this configuration is incorrect.
Why it fails: This policy only applies to the exact path 'kv/' and grants read capability there. It does not grant any access to secrets under 'kv/', such as 'kv/mysecret'. Developers would be unable to read the secrets, which fails the primary requirement. Additionally, 'read' on 'kv/' does not prevent listing; 'list' capability is separate.
B
path "kv/*" { capabilities = ["read"] }
This policy grants read capability on all paths under 'kv/', including secrets, but does not grant list capability on 'kv/' itself. In Vault ACL policies, the 'read' capability allows reading a secret at a specific path, while 'list' is required to enumerate keys. Since the policy does not include 'list' on 'kv/' or 'kv/*', developers cannot list the contents, fulfilling the requirement.
Why it fails: The deny capability on 'kv/' would explicitly block any access to that path, including read and list. However, the requirement is to allow reading secrets under 'kv/' while preventing listing of 'kv/'. The deny on 'kv/' would not affect 'kv/*' paths, but it also does not prevent listing of 'kv/' because list is a separate capability. More importantly, the deny on 'kv/' is unnecessary and could interfere with other operations.
D
path "kv/*" { capabilities = ["read", "list"] }
Why it fails: This policy grants both read and list capabilities on all paths under 'kv/'. The 'list' capability would allow developers to enumerate the keys under 'kv/', which violates the requirement to prevent listing. Therefore, this configuration is incorrect.
A Vault Enterprise administrator is configuring a Sentinel RGP policy to enforce that only tokens with a metadata field "department" set to "finance" can read secrets at the path "secret/data/finance/*". The policy must be applied globally across all namespaces. Where should the administrator upload this policy?
Trap 1: To the sys/policies/rgp endpoint of each child namespace…
Applying the policy to each child namespace individually is operationally burdensome and does not enforce it globally across all namespaces, including future ones. This approach lacks centralized management and can lead to inconsistent enforcement. The requirement is for a single global policy, so this option is incorrect.
Trap 2: To the sys/policies/egp endpoint of the root namespace.
The sys/policies/egp endpoint is for Endpoint Governing Policies, which control access to specific API endpoints, not role governing policies that apply to tokens. The requirement is for an RGP policy based on token metadata, so using EGP would not achieve the desired control. This option is incorrect.
Trap 3: To the root namespace's sys/policies/rgp endpoint.
Uploading to the root namespace's sys/policies/rgp endpoint only applies the policy within that namespace. It does not propagate to child namespaces. To apply globally, the policy must be placed at the global level. This option fails because it limits enforcement to the root namespace only.
To the global sys/policies/rgp endpoint using a root token.
The global sys/policies/rgp endpoint is specifically designed for policies that apply across all namespaces in Vault Enterprise. Uploading here with a root token ensures the policy is evaluated globally, satisfying the requirement. This is the correct method for global Sentinel RGP enforcement.
B
To the sys/policies/rgp endpoint of each child namespace individually.
Why it fails: Applying the policy to each child namespace individually is operationally burdensome and does not enforce it globally across all namespaces, including future ones. This approach lacks centralized management and can lead to inconsistent enforcement. The requirement is for a single global policy, so this option is incorrect.
C
To the sys/policies/egp endpoint of the root namespace.
Why it fails: The sys/policies/egp endpoint is for Endpoint Governing Policies, which control access to specific API endpoints, not role governing policies that apply to tokens. The requirement is for an RGP policy based on token metadata, so using EGP would not achieve the desired control. This option is incorrect.
D
To the root namespace's sys/policies/rgp endpoint.
Why it fails: Uploading to the root namespace's sys/policies/rgp endpoint only applies the policy within that namespace. It does not propagate to child namespaces. To apply globally, the policy must be placed at the global level. This option fails because it limits enforcement to the root namespace only.
A Vault Enterprise administrator needs to delegate the ability to create and manage namespaces to a team of operators, but only within a specific parent namespace called "team-a". The operators should not be able to create namespaces at the root level. Which policy should be attached to the operators' tokens?
Trap 1: A policy with path "sys/namespaces/team-a/*" { capabilities =…
This path attempts to manage namespaces under the "team-a" namespace but uses an incorrect path structure. Vault namespace paths are hierarchical, and child namespaces are accessed via the parent namespace's path. The correct path would be "team-a/sys/namespaces/*". This policy would not grant the intended permissions.
Trap 2: A policy with path "sys/namespaces/team-a" { capabilities =…
This policy targets the specific namespace "team-a" itself, not the ability to create or manage child namespaces within it. It would allow operations on the "team-a" namespace object but not on its sub-namespaces. The requirement is to manage namespaces within "team-a", so this is insufficient.
Trap 3: A policy with path "sys/namespaces/*" { capabilities = ["create",…
This policy grants full namespace management capabilities in the root namespace, which would allow operators to create namespaces at the root level. The requirement is to restrict them to the "team-a" namespace only. This policy is too permissive and does not meet the delegation constraints.
A policy with path "sys/namespaces/team-a/*" { capabilities = ["create", "read", "update", "delete", "list"] } in the root namespace.
Why it fails: This path attempts to manage namespaces under the "team-a" namespace but uses an incorrect path structure. Vault namespace paths are hierarchical, and child namespaces are accessed via the parent namespace's path. The correct path would be "team-a/sys/namespaces/*". This policy would not grant the intended permissions.
B
A policy with path "sys/namespaces/team-a" { capabilities = ["create", "read", "update", "delete", "list"] } in the root namespace.
Why it fails: This policy targets the specific namespace "team-a" itself, not the ability to create or manage child namespaces within it. It would allow operations on the "team-a" namespace object but not on its sub-namespaces. The requirement is to manage namespaces within "team-a", so this is insufficient.
C
A policy with path "team-a/sys/namespaces/*" { capabilities = ["create", "read", "update", "delete", "list"] } in the root namespace.
This policy allows management of namespaces under the "team-a" path by specifying the full path including the parent namespace. When attached to tokens, operators can create and manage child namespaces within "team-a" but not at the root. This correctly delegates namespace administration within the specified scope.
D
A policy with path "sys/namespaces/*" { capabilities = ["create", "read", "update", "delete", "list"] } in the root namespace.
Why it fails: This policy grants full namespace management capabilities in the root namespace, which would allow operators to create namespaces at the root level. The requirement is to restrict them to the "team-a" namespace only. This policy is too permissive and does not meet the delegation constraints.
An organization uses Vault Enterprise with Performance Replication. A developer in the secondary cluster has an entity with a specific alias in the primary cluster's identity store. The developer authenticates to the secondary cluster using an auth method that is local to the secondary. The developer must be able to read a secret at 'secret/data/app' that is governed by an ACL policy attached to the entity's group in the primary cluster. However, after authentication, the developer receives a permission denied error. What is the most likely cause?
Trap 1: The ACL policy that grants read on 'secret/data/app' is not…
ACL policies are replicated from primary to secondary in Performance Replication. If the policy is attached to a group in the primary, it should be present in the secondary. The issue is not policy replication but identity alias mapping. Without the correct alias, the entity in the secondary cannot assume the group's policies, leading to permission denied.
Trap 2: The auth method used by the developer is not replicated to the…
Auth methods are not replicated from secondary to primary in Performance Replication; only primary-to-secondary replication of configuration occurs. The developer's local auth method in the secondary cannot create an alias that exists in the primary's identity store. This mismatch means the entity in the primary has no alias for the secondary auth method, so policies attached to that entity's group are not applied.
Trap 3: The entity alias in the primary cluster is not associated with the…
Identity aliases are replicated from primary to secondary, but only for entities and groups that are replicated. However, if the auth method is local to the secondary, the alias created there is not propagated to the primary. The primary's entity lacks a matching alias, so the group membership does not apply. This is a common pitfall when mixing local auth methods with replicated identity groups.
The ACL policy that grants read on 'secret/data/app' is not replicated to the secondary cluster, so the policy cannot be evaluated.
Why it fails: ACL policies are replicated from primary to secondary in Performance Replication. If the policy is attached to a group in the primary, it should be present in the secondary. The issue is not policy replication but identity alias mapping. Without the correct alias, the entity in the secondary cannot assume the group's policies, leading to permission denied.
B
The auth method used by the developer is not replicated to the primary cluster, so the entity alias is not associated with the entity.
Why it fails: Auth methods are not replicated from secondary to primary in Performance Replication; only primary-to-secondary replication of configuration occurs. The developer's local auth method in the secondary cannot create an alias that exists in the primary's identity store. This mismatch means the entity in the primary has no alias for the secondary auth method, so policies attached to that entity's group are not applied.
C
The developer's token was issued by a local auth method in the secondary, but the entity and its group memberships are only in the primary cluster and not replicated to the secondary.
In Performance Replication, identity entities and groups are replicated from primary to secondary, but only if they are associated with replicated auth methods. A local auth method in the secondary creates aliases that are not known to the primary. Thus, the entity in the secondary does not inherit the primary group's policies. The token from the local auth method lacks the necessary ACL permissions, causing permission denied.
D
The entity alias in the primary cluster is not associated with the entity in the secondary cluster because the alias metadata is not replicated in Performance Replication.
Why it fails: Identity aliases are replicated from primary to secondary, but only for entities and groups that are replicated. However, if the auth method is local to the secondary, the alias created there is not propagated to the primary. The primary's entity lacks a matching alias, so the group membership does not apply. This is a common pitfall when mixing local auth methods with replicated identity groups.
An administrator needs to grant a development team read-only access to all secrets under the 'secret/data/dev' path in a Vault Enterprise cluster. The team should also be able to list the contents of that path to discover available secrets. Which policy snippet correctly implements this requirement?
The sudo capability is not required for reading or listing secrets; it is used for privileged operations like managing auth methods or plugins. Including sudo would grant unnecessary power and could lead to privilege escalation. The list capability is missing, so the team could not discover available secrets. This does not meet the requirement.
Granting create capability allows the team to write new secrets, which violates the read-only requirement. The create capability permits creation of new versions of secrets, potentially overwriting existing data. This is excessive privilege. The correct policy should only include read and list to adhere to the principle of least privilege.
This policy only applies to the exact path secret/data/dev, not to any subpaths. Secrets stored under secret/data/dev/app1 or secret/data/dev/db would not be accessible. The requirement is for all secrets under that path, so a wildcard is needed. Thus this policy is too restrictive and fails to grant the intended access.
Why it fails: The sudo capability is not required for reading or listing secrets; it is used for privileged operations like managing auth methods or plugins. Including sudo would grant unnecessary power and could lead to privilege escalation. The list capability is missing, so the team could not discover available secrets. This does not meet the requirement.
This policy grants both read and list capabilities on all secrets under secret/data/dev. The wildcard ensures all subpaths are included, and the capabilities match the requirement to read individual secrets and list the path contents. This is the standard way to allow discovery and retrieval without granting write or delete permissions.
Why it fails: Granting create capability allows the team to write new secrets, which violates the read-only requirement. The create capability permits creation of new versions of secrets, potentially overwriting existing data. This is excessive privilege. The correct policy should only include read and list to adhere to the principle of least privilege.
Why it fails: This policy only applies to the exact path secret/data/dev, not to any subpaths. Secrets stored under secret/data/dev/app1 or secret/data/dev/db would not be accessible. The requirement is for all secrets under that path, so a wildcard is needed. Thus this policy is too restrictive and fails to grant the intended access.
An administrator is configuring a new auth method in Vault Enterprise. They want to ensure that when a user authenticates, the resulting token is automatically associated with an existing entity in the identity store, based on the user's email address. Which configuration is required to achieve this?
Trap 1: Set the 'alias_name_source' parameter on the auth method role to…
The 'alias_name_source' parameter on some auth methods (like LDAP) allows specifying which attribute to use as the alias name. However, this only affects the alias created during authentication; it does not automatically associate the user with an existing entity unless an alias with that name already exists. Without a pre-created alias, a new entity is created. The question requires association with an existing entity, so simply setting the source is insufficient.
Trap 2: Configure the auth method to use the 'entity_id' parameter in its…
There is no 'entity_id' parameter in auth method roles that directly binds all authenticating users to a specific entity. Auth method roles define policies and TTLs, not entity associations. Entities are linked via aliases, which are created automatically or manually. Attempting to use 'entity_id' in a role is not a supported configuration and would not achieve the desired mapping.
Trap 3: Attach a policy to the auth method role that includes the…
Policies grant permissions to access paths; they do not associate tokens with entities. Reading the entity path does not link the token to the entity. The association is done through aliases during authentication. This option confuses authorization with identity mapping. It would not cause the token to inherit the entity's group memberships or metadata.
Set the 'alias_name_source' parameter on the auth method role to 'email'.
Why it fails: The 'alias_name_source' parameter on some auth methods (like LDAP) allows specifying which attribute to use as the alias name. However, this only affects the alias created during authentication; it does not automatically associate the user with an existing entity unless an alias with that name already exists. Without a pre-created alias, a new entity is created. The question requires association with an existing entity, so simply setting the source is insufficient.
B
Configure the auth method to use the 'entity_id' parameter in its role, pointing to the desired entity ID.
Why it fails: There is no 'entity_id' parameter in auth method roles that directly binds all authenticating users to a specific entity. Auth method roles define policies and TTLs, not entity associations. Entities are linked via aliases, which are created automatically or manually. Attempting to use 'entity_id' in a role is not a supported configuration and would not achieve the desired mapping.
C
Attach a policy to the auth method role that includes the 'identity/entity/id/<entity_id>' path with read capabilities.
Why it fails: Policies grant permissions to access paths; they do not associate tokens with entities. Reading the entity path does not link the token to the entity. The association is done through aliases during authentication. This option confuses authorization with identity mapping. It would not cause the token to inherit the entity's group memberships or metadata.
D
Create an identity alias in the entity that maps to the auth method's mount accessor and the user's email as the alias name.
An identity alias links an entity to a specific auth method and a unique identifier (like email). When a user authenticates, Vault looks for an alias with the auth method's mount accessor and the alias name matching the user's identifier. If found, the token is associated with that entity, inheriting its policies and group memberships. This is the standard way to map external identities to entities.
A Vault Enterprise administrator is designing an access control strategy for a multi-namespace environment. They need to ensure that a group of auditors can only read audit logs and cannot perform any write operations, even if they have other policies that grant broader access. Which two mechanisms can be used to achieve this? (Choose two.)
Trap 1: Configure a Control Group on all write paths that requires approval…
Control Groups add an approval workflow but do not deny access outright. If the security team approves a write request, the auditor could still perform the write. This does not meet the requirement of preventing write operations entirely; it only adds a gate. The auditors could potentially get approval, so it is not a strict read-only enforcement.
Trap 2: Assign the auditors a token with the 'default' policy and no other…
The 'default' policy typically grants limited permissions, but it does not explicitly deny write operations. If the auditors have other policies attached (e.g., through group membership), those could grant write access. Simply having only the default policy does not guarantee read-only access; it depends on what the default policy allows and whether other policies are attached. It is not a robust enforcement mechanism.
Trap 3: Use a Sentinel RGP policy that checks the token's policies and…
Sentinel RGP policies are evaluated on the token's role and can restrict actions based on the token's policies. However, denying based on the presence of other policies is not directly related to the HTTP method. It could inadvertently block legitimate read operations if the token has additional policies. Moreover, it does not specifically target write operations; it relies on policy names, which is fragile and not a reliable way to enforce read-only access.
Configure a Control Group on all write paths that requires approval from a security team.
Why it fails: Control Groups add an approval workflow but do not deny access outright. If the security team approves a write request, the auditor could still perform the write. This does not meet the requirement of preventing write operations entirely; it only adds a gate. The auditors could potentially get approval, so it is not a strict read-only enforcement.
B
Assign the auditors a token with the 'default' policy and no other policies.
Why it fails: The 'default' policy typically grants limited permissions, but it does not explicitly deny write operations. If the auditors have other policies attached (e.g., through group membership), those could grant write access. Simply having only the default policy does not guarantee read-only access; it depends on what the default policy allows and whether other policies are attached. It is not a robust enforcement mechanism.
C
Create an ACL policy that includes 'deny' capabilities on all write paths and attach it to the auditors' entity group.
ACL policies support 'deny' capabilities, which take precedence over any 'allow' capabilities. By explicitly denying write operations on all relevant paths, you can ensure that even if other policies grant write access, the deny rule overrides them. This is a direct way to enforce read-only access for the auditors, provided the deny paths cover all possible write actions.
D
Use a Sentinel RGP policy that checks the token's policies and denies if the token has any policy other than 'auditor-read'.
Why it fails: Sentinel RGP policies are evaluated on the token's role and can restrict actions based on the token's policies. However, denying based on the presence of other policies is not directly related to the HTTP method. It could inadvertently block legitimate read operations if the token has additional policies. Moreover, it does not specifically target write operations; it relies on policy names, which is fragile and not a reliable way to enforce read-only access.
E
Use a Sentinel EGP policy that denies any request with an HTTP method other than GET or LIST.
Sentinel EGP policies can inspect the request method and deny non-read operations. By attaching an EGP to the relevant paths, you can block all write methods (POST, PUT, DELETE, PATCH) regardless of ACL policies. This provides a centralized, hard enforcement that cannot be overridden by other policies, making it ideal for ensuring auditors cannot write.
A Vault Enterprise administrator is designing a control group to enforce additional authorization for accessing a highly sensitive secrets engine. The control group should require approval from two members of the security team before a secret can be read. The security team is defined as an identity group named 'security-team'. Which two steps are necessary to configure this control group? (Choose two.)
Trap 1: Create a Sentinel EGP policy that denies access unless two…
While Sentinel EGP policies can enforce custom logic, control groups are a native Vault feature and do not require Sentinel. Using Sentinel would be an alternative approach, but it is not a necessary step for configuring a control group. The question specifically asks for control group configuration, not Sentinel policies.
Trap 2: Enable the control group feature in the Vault Enterprise license.
Control groups are a built-in feature of Vault Enterprise and do not require a separate license enablement step. The feature is available once Vault Enterprise is installed and licensed. No additional activation is needed beyond configuration.
Trap 3: Configure an identity alias for each member of the security team to…
Identity aliases are used to map external identities to Vault entities, but the requirement is to reference an existing identity group. The group 'security-team' must already exist and contain the appropriate members. Creating aliases is not a step specific to control group configuration; it is part of identity management that would be done beforehand.
Create a Sentinel EGP policy that denies access unless two approvals are present.
Why it fails: While Sentinel EGP policies can enforce custom logic, control groups are a native Vault feature and do not require Sentinel. Using Sentinel would be an alternative approach, but it is not a necessary step for configuring a control group. The question specifically asks for control group configuration, not Sentinel policies.
B
Enable the control group feature in the Vault Enterprise license.
Why it fails: Control groups are a built-in feature of Vault Enterprise and do not require a separate license enablement step. The feature is available once Vault Enterprise is installed and licensed. No additional activation is needed beyond configuration.
C
Configure an identity alias for each member of the security team to map to the 'security-team' group.
Why it fails: Identity aliases are used to map external identities to Vault entities, but the requirement is to reference an existing identity group. The group 'security-team' must already exist and contain the appropriate members. Creating aliases is not a step specific to control group configuration; it is part of identity management that would be done beforehand.
D
Create a control group policy that references the identity group 'security-team' and requires two approvals.
The control group policy must specify the required approvers, which can be an identity group, and the number of approvals needed. This policy is attached to the path or role that requires control group authorization. Without this policy, the control group cannot enforce the approval requirement.
E
Attach the control group policy to the secrets engine path or role that requires additional authorization.
The control group policy must be associated with the target path or role (e.g., via the control_group parameter in the path policy or role configuration). This ensures that any request to that path triggers the control group workflow. Without attaching it, the control group would not be enforced for the sensitive secrets.
What does the Vault Enterprise exam test about Access Control Configuration?
Be able to write correct HCL policies, choose the right capability for a KV v2 read scenario, and explain token_ttl versus token_max_ttl. The most important thing: grant exactly the capabilities the path needs, including list and metadata where required.
How should I use these practice questions?
Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Access Control Configuration questions in a focused session?
Yes — the session launcher on this page draws every question from the Access Control Configuration domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other Vault Enterprise topics?
Use the topic links above to move to related areas, or go back to the Vault Enterprise question bank to see all topics.
Are these real exam questions or dumps?
These are original practice questions written to test the same concepts the Vault Enterprise exam covers. They are not copied from any real exam or dump site.