CCNA Access Control Configuration Questions

A Control Group Policy is the Vault object that wraps specified paths, requiring authoriser approval before the requesting user's token can read the secret. Creating it defines the approval workflow, satisfying the requirement that a manager authorise each secrets request.

Namespaces partition a single Vault cluster into isolated tenants, each with its own auth methods, secrets engines and policies. This multi-tenancy isolation is Enterprise-only, satisfying the question's requirement for access-control features specific to Vault Enterprise.

token_ttl sets the initial lease duration assigned when the token is issued, after which it expires unless renewed. This satisfies the stem's requirement to control the token's starting lifetime, distinct from token_max_ttl, which caps total renewal.

Vault evaluates deny as an absolute override: any matching deny capability wins regardless of allow elsewhere. A single policy denying the path therefore blocks access, even where another policy grants it, satisfying the stem's conflicting-policy scenario.

Policies are scoped strictly to the namespace where they are written; a root-namespace policy does not cascade into child namespaces. Tokens issued within the child namespace therefore cannot reference it, satisfying the impact that the policy is inaccessible there.

Setting secret_id_num_uses to 1 ensures the secret ID can be used only once, and secret_id_ttl to 24h makes it expire after 24 hours. These parameters directly control the usage limit and lifetime of secret IDs, meeting the requirement for one-time use and expiration. This is the correct configuration for the scenario.

An identity alias maps a name and mount accessor from an external auth method to an existing Vault entity, so multiple credentials resolve to one identity. This linkage is precisely what lets policies and metadata attach to a single entity across auth methods.

Granting 'create', 'read', 'update', 'delete', and 'list' on 'database/roles/*' allows the team to manage roles within the database secrets engine. It does not grant access to the secrets engine's configuration path (e.g., 'database/config') or other engines. This follows the principle of least privilege, providing exactly the permissions needed to manage roles without broader access.

The create capability permits writing new data at a path, letting a policy authorise generating new secrets within a secrets engine. This satisfies the stem's requirement of managing secrets engines, since writing to an engine's path is how secrets are produced.

This approach isolates the subsidiary's resources in a namespace, uses LDAP for authentication, and grants the security team sudo capabilities on the namespace's sys/ path. Sudo on sys/ allows management of policies and auth methods within that namespace only. The root namespace remains inaccessible because namespace boundaries restrict visibility and control. This satisfies all requirements.

Capabilities specify the permitted operations, such as read, list, create, update, delete, sudo and deny, on the paths named in the policy's path stanza. Without them, Vault cannot determine what actions a token may perform, so the policy grants nothing. This satisfies the stem's requirement for an essential ACL policy field.

Tokens issued to an Identity Entity or its group automatically receive the policies attached to that entity, without embedding them in the token request. This inheritance path is a valid assignment mechanism, distinct from specifying policies directly at token creation.

In Vault Enterprise, external groups allow mapping of groups from an external identity provider, such as LDAP, to Vault policies. By creating an external group named 'vault-admins' and attaching the 'admin' policy, any LDAP user who is a member of the 'vault-admins' group will inherit the 'admin' policy upon authentication. This is the correct method for integrating external group memberships with Vault policies.

The AppRole role definition carries secret_id_bound_cidrs and token_bound_cidrs parameters, which restrict issued tokens to specified CIDR blocks. Configuring token_bound_cidrs on the role satisfies the requirement that the resulting token is limited to a specific range.

The root policy is Vault's built-in, non-deletable policy granting full administrative access across all paths and operations, including managing policies, auth methods and mounts. It satisfies the stem by defining the highest privilege level, so it must be tightly restricted.

Sentinel in Vault Enterprise supports both endpoint governing policies, which evaluate requests to Vault endpoints, and role governing policies, which apply to tokens issued to specific roles. Naming both types correctly satisfies the stem's requirement for true statements about Sentinel usage.

The `request` parameter supplies Sentinel with the current request's metadata, including the path being accessed and the operation type, such as read or write. This satisfies the stem's requirement to restrict secret access based on request details, since policies evaluate `request.data` and `request.operation` directly.

The `read` capability grants retrieval of secrets at a specified path, satisfying the requirement for read access to the KV v2 path. It permits GET operations on that path without allowing writes, deletes or list operations, which matches the least-privilege constraint stated in the scenario.

Control Groups only restrict access to the specific paths they protect. The token's other capabilities remain unaffected, so it can read secrets outside the Control Group's scope. This allows users to continue working with other secrets while awaiting approval for the protected path.