Hard Difficulty Questions

sudo

Why it fails: The 'sudo' capability bypasses root-protected API endpoints; it grants no permission to delete data. It is tempting because it sounds like an elevated privilege, but deletion requires 'delete' on the team/ path, which sudo does not confer.

list

Why it fails: 'list' permits enumerating keys under a path, not removing them. It is tempting because listing team/ is a natural precursor to deleting, but the delete operation itself needs the 'delete' capability on the team/ path.

patch

Why it fails: 'patch' permits partial updates to existing data at a path, not removal of secrets. It is tempting because patch is a write-style capability, but deleting keys under team/ requires the 'delete' capability, which patch does not supply.

The system backend is configured with a max_ttl that overrides the mount setting.

Why it fails: max_ttl would cap, not extend.

The mount token_ttl is only applied if the user does not specify a `token_policies` parameter.

Why it fails: token_policies does not affect TTL.

The token was issued with a periodic token and ignores the TTL.

Why it fails: Periodic tokens are for limited use, not common for userpass.

Add a policy that uses the email claim

Why it fails: Policy cannot request scopes.

Modify the OIDC provider's configuration in Vault

Why it fails: Provider config doesn't include scopes.

Create a custom claim mapping in the OIDC auth method

Why it fails: Claim mapping interprets claims but doesn't request missing ones.

The Vault server's AWS credentials are expired

Why it fails: Vault uses its own AWS credentials to verify, not the instance's.

The Vault role for AWS auth is configured with a wrong bound IAM role ARN

Why it fails: If one instance works, the ARN is correct.

The IAM role's trust policy does not allow Vault to assume the role

Why it fails: Trust policy is about Vault assuming the role, not instances authenticating.

AWS IAM authentication

Why it fails: Only works for AWS workloads.

Kubernetes authentication

Why it fails: Only works for Kubernetes workloads.

AppRole authentication

Why it fails: Requires a secret_id that must be distributed, not suitable for all environments without sharing secrets.

accessor

Why it fails: accessor is not an input parameter; it is returned in the response but cannot be set at creation.

max_ttl

Why it fails: max_ttl is not a direct creation parameter; it is derived from the role or mount configuration and cannot be set via the create endpoint.

The key's `min_decryption_version` must be set to 1

Why it fails: Setting to 1 allows all versions, but this is not required; the default (0) allows all versions. More importantly, if the version is archived, it still won't decrypt.

The key must have the `allow_plaintext_backup` setting enabled

Why it fails: This setting is for backing up key material, not for decryption availability.

The key must have a `deletion_allowed` set to false

Why it fails: This prevents deletion of the entire key, but does not affect decryption of existing ciphertext.

The key's `latest_version` must be greater than 0

Why it fails: This is always true if key exists, but doesn't ensure older versions are available.

Increase the TTL of the Vault token to give more time for the secret read.

Why it fails: TTL does not affect permissions.

Add the microservice's service account to the bound_service_account_names of an existing role that works.

Why it fails: The role is already bound correctly; the issue is policy attachment.

Change the authentication method to AppRole for the payment microservice.

Why it fails: Not necessary; Kubernetes auth can work.

role_type

Why it fails: role_type exists on database and cloud secrets roles to pick a creation statement, and the AWS engine does not use it to select an IAM role. The role_arn parameter names the target role for STS AssumeRole, so role_type would matter only where a backend offers multiple credential-generation templates.

credential_type

Why it fails: credential_type selects iam_user versus assumed_role, but the role ARN itself is supplied by the separate role_arn parameter, which Vault needs to call STS AssumeRole. credential_type would be the deciding field when generating static IAM user keys rather than assuming an existing role.

inline_policy

Why it fails: inline_policy attaches an extra policy to generated IAM users; it cannot cause Vault to assume an existing role. Assuming the role requires role_arn plus the STS trust relationship. inline_policy would be correct when issuing IAM user credentials that need scoped-down permissions beyond the base policy.

The token has been renewed too many times, exceeding its TTL

Why it fails: Renewal count does not itself cap renewals; without an explicit max TTL, Vault renews until the token's max TTL, so this is not the trigger. It is tempting because periodic tokens do have renewal limits, which is the correct cause when a max TTL is configured.

The token accessor is invalid

Why it fails: An invalid accessor would prevent lookup of the token entirely, producing a different error, not a renewal refusal. Accessor validation is tempting because it governs token retrieval and revocation, and it would be the cause if the token could not be found or had been revoked.

The token's max TTL has been reached

Why it fails: Max TTL prevents further renewal, but the error message would indicate 'TTL exceeded'.

The 'read' capability is missing.

Why it fails: Encryption against a transit key requires 'update' on the key path, which the policy already grants; 'read' governs key metadata retrieval, not encrypt operations. Read is the missing capability when a workload must inspect key configuration or versions.

The 'delete' capability is missing.

Why it fails: Deleting a transit key removes it entirely and is irrelevant to encrypt calls, which never invoke the 'delete' capability. The policy already supplies 'update', the capability Vault actually checks for encryption; 'delete' would only matter when rotating or destroying key material.

The 'list' capability is missing.

Why it fails: Encryption against a transit key is a read-style operation, so Vault checks the 'update' capability on the key path, which the policy already grants; 'list' only enumerates keys and is not consulted during encrypt calls. It would be required for listing key names, not performing cryptographic operations.

Use the Vault CLI with curl to wrap commands.

Why it fails: This approach is unnecessary; the Vault CLI is not installed, and curl can interact directly with the API without wrapping CLI commands. It adds complexity and does not satisfy the constraint of no binary installation.

Install Vault binary on the server and use CLI.

Why it fails: The scenario explicitly states the Vault binary cannot be installed, so CLI use is impossible; the HTTP API must be called directly. Installing the binary is tempting because CLI commands are the usual rotation method, but that approach suits servers where Vault tooling may be deployed, not this restricted host.

Use Vault Agent to handle rotation.

Why it fails: Vault Agent is a client daemon that requires the Vault binary to be installed, which violates the constraint. Additionally, Agent is typically used for tasks like caching and auto-authentication, not for direct database credential rotation in this scenario.

Restrict network access to the Vault server with a firewall

Why it fails: A firewall limits network reachability but does nothing once an attacker has root on the host, since the unseal key file remains readable locally. It is tempting because network segmentation is a genuine hardening control, and would be correct against remote attackers lacking server access.

Use Shamir's secret sharing to split the key across multiple files

Why it fails: Shamir's secret sharing splits the unseal key into shares, but storing all shares on the same server lets root read every one. It is tempting because Shamir is Vault's default unseal mechanism, and would be correct if each share were held by a separate operator off-host.

Encrypt the unseal key file with a strong password

Why it fails: Password-encrypting the key file still leaves the decryption material on the compromised host, so root access defeats it. It is tempting because encryption at rest is a real control, and would be correct against theft of the disk or backup rather than a live root compromise.

Use a periodic token with a period of 24h

Why it fails: A periodic token's period sets renewal frequency, not an absolute lifetime; the user can renew indefinitely, so it never expires after 24 hours. Periodic tokens are tempting because they do expire and renew, and would suit short-lived credentials, but enforcing a hard cutoff requires an explicit maximum TTL.

Create an orphan token with a TTL of 24h

Why it fails: An orphan token has no parent and cannot be renewed, but its TTL governs only its own lifetime, not the 24-hour ceiling on the user's token chain. Orphan tokens suit delegated, unattended automation where no renewal path should exist at all.

Use a batch token

Why it fails: A batch token is a short-lived, single-use credential for bulk operations such as Microsoft Graph $batch requests, not a session-lifetime control. It cannot cap a user token at 24 hours or block renewal, which requires configuring token lifetime and refresh token maximum inactive time in Microsoft Entra ID.

Set token_num_uses=1 in the role.

Why it fails: token_num_uses=1 limits the issued token to a single use, not the SecretID itself; the SecretID remains valid for further logins. It is tempting because it sounds like one-use enforcement, and would be correct for constraining a token's API calls, not for making each SecretID single-use.

Set bound_cidr_list to a specific IP.

Why it fails: bound_cidr_list restricts the source addresses from which a SecretID may be used; it does not consume or invalidate the SecretID after one login. It is tempting because it tightens AppRole security, and would be correct for limiting logins to known network ranges, not for enforcing single-use SecretIDs.

Set secret_id_ttl=1s in the role.

Why it fails: secret_id_ttl=1s sets an expiry window, not a usage count; a SecretID could still be used repeatedly within that second. It is tempting because short TTLs appear to restrict reuse, and would be correct for time-bounding SecretIDs, not for enforcing exactly one login per SecretID.

Yes, because TTL refreshes to 48h on each renewal.

Why it fails: Renewal resets TTL, but explicit_max_ttl caps total token lifetime at 120 hours regardless of renewals. After 10 days (240 hours) the token is long expired. Tempting because TTL renewal genuinely extends validity in systems lacking a maximum-lifetime ceiling, which is what this option assumes.

Yes, if renewed before TTL expires, it can persist indefinitely.

Why it fails: Indefinite persistence is blocked by explicit_max_ttl=120h, which caps absolute lifetime irrespective of timely renewals. Renewing before TTL expiry cannot bypass that ceiling. Tempting because sliding-expiration tokens without a maximum lifetime do behave this way, which is exactly the configuration this scenario omits.

No, because tokens cannot be renewed more than 5 times.

Why it fails: No renewal-count limit exists in this token model; expiry is governed by explicit_max_ttl, not a fixed number of renewals. The token fails at 120 hours because that ceiling is reached. Tempting because some session systems do cap refresh counts, but that mechanism is absent here.

List secret/data/finance

Why it fails: Denied by the exact path deny on secret/data/finance.

Delete secret/data/finance/budget

Why it fails: The glob deny on secret/data/finance/* denies all operations.

Read secret/data/finance

Why it fails: Exact path deny overrides the glob for secret/data/finance.

72h

Why it fails: A 72h maximum would have invalidated the token at the 72h check, but the stem confirms it was still valid at that point. It is tempting as three periods, and would be correct if renewal stopped extending the token's life after the third period.

48h

Why it fails: A 48h maximum would have invalidated the token at the 48h check, yet the stem states it remained valid then. It is tempting as double the period, and would be correct if the token had been issued without renewal extending its life beyond two periods.

24h

Why it fails: A 24h maximum would have invalidated the token at the first renewal boundary, contradicting its validity at 48h and 72h. It is tempting as the period value, and would be correct if the token were non-renewable and expired after a single period.

JWT auth method

Why it fails: The JWT auth method validates a JWT against a configured public key or JWKS URL, but it does not call the Kubernetes TokenReview API and cannot natively bind a role to a Kubernetes namespace or service account. It would treat the service account token as a generic JWT, losing the Kubernetes-specific validation the team needs.

AppRole auth method

Why it fails: AppRole authenticates using a role ID and secret ID, not a Kubernetes service account token. While it is popular for machine authentication, it does not verify tokens against the Kubernetes API or check pod namespace and service account, so it does not meet the stated requirement.

Cert auth method

Why it fails: The cert auth method authenticates clients by TLS client certificate. Kubernetes pods would need to present a trusted certificate rather than a service account token, and Vault would not perform TokenReview or namespace checks, so this method does not satisfy the scenario.

vault kv list kv-v2/secret

Why it fails: This lists keys under the path, but not the secret content.

vault read kv-v2/data/secret

Why it fails: The correct path is 'kv-v2/data/secret' but the command syntax is 'vault kv get', not 'vault read' directly for KV v2.

vault kv metadata get kv-v2/secret

Why it fails: This shows metadata, not the secret data.