CCNA Compare and configure secrets engines Questions — Page 2 of 2

Multi-Selectmedium

Which TWO of the following are valid use cases for the Transit secrets engine? (Select exactly 2.)

Select 2 answers

A.Signing and verifying data

B.Encrypting data in transit without exposing the encryption key

C.Storing encryption keys

D.Storing encrypted data at rest

E.Managing X.509 certificates

AnswersA, B

Transit supports signing and verification operations.

Why this answer

The Transit secrets engine is designed to perform cryptographic operations on data without exposing the encryption keys to the client. Option A is correct because the engine supports signing and verifying data using HMAC or asymmetric keys, allowing clients to verify integrity and authenticity without handling the private key. Option B is correct because the engine can encrypt data in transit (e.g., via API calls) while the encryption key remains securely stored within Vault, never leaving the server.

Exam trap

HashiCorp often tests the distinction between 'performing cryptographic operations' (Transit) and 'storing secrets or keys' (KV), so the trap here is that candidates confuse the Transit engine's ability to store keys internally with the use case of storing keys for external retrieval.

Practice this question →

MCQeasy

An admin needs to store a configuration value that is unique to each Vault client and must not be shared. Which secrets engine should they use?

A.Cubbyhole

B.AWS

C.KV v2 at a client-specific path

D.Transit

AnswerA

Cubbyhole provides per-token isolated storage.

Why this answer

The Cubbyhole secrets engine creates a private, ephemeral storage space that is scoped to the requesting token. Each token gets its own isolated cubbyhole, and no other client or token can read or write to it, even with root privileges. This makes it the only built-in engine that guarantees a configuration value is unique to each Vault client and cannot be shared.

Exam trap

HashiCorp often tests the misconception that KV v2 with strict ACLs provides the same isolation as Cubbyhole, but the trap is that KV v2 is path-based and policy-dependent, whereas Cubbyhole is inherently token-scoped and cannot be accessed by any other token, even with root privileges.

How to eliminate wrong answers

Option B is wrong because the AWS secrets engine is designed to generate dynamic AWS IAM credentials or manage static AWS secrets, and it has no concept of per-client isolation — any client with the correct policy can access the same path. Option C is wrong because KV v2 at a client-specific path relies on ACL policies to restrict access, but it does not enforce token-scoped isolation; a misconfigured policy or a token with broader permissions could read another client's path, and the data persists even after the token expires. Option D is wrong because the Transit engine handles encryption and decryption operations (e.g., encrypting data in transit or at rest) and does not store configuration values at all; it is a cryptographic operations engine, not a storage engine.

Practice this question →

MCQmedium

Refer to the exhibit. After executing these commands, what is the expected behavior?

A.The key is automatically rotated every 30 days

B.The ciphertext is base64 encoded, and the plaintext is base64 decoded automatically

C.The decryption command requires the key version to be specified

D.The encryption operation will fail because the key type 'aes256-gcm96' is incorrect

AnswerB

Transit expects base64-encoded inputs and outputs base64-encoded results.

Why this answer

Option B is correct because the Vault transit secrets engine, when configured with `auto_decode` enabled, automatically base64-decodes the ciphertext returned from encryption operations and base64-encodes plaintext before decryption. The command `vault write -f transit/keys/my-key/encrypt/orders` with the `auto_decode` parameter set to `true` ensures that the output ciphertext is base64-encoded for safe transport, and the corresponding decryption operation will automatically base64-decode the input ciphertext before processing.

Exam trap

HashiCorp often tests the misconception that key rotation in Vault is time-based by default, when in fact it requires explicit action or configuration, and that the `auto_decode` feature is about automatic encoding/decoding rather than a security property of the ciphertext.

How to eliminate wrong answers

Option A is wrong because key rotation in Vault is not automatic based on time; it requires explicit `vault write -f transit/keys/my-key/rotate` commands or a configured rotation period via `rotation_period`, not a default 30-day auto-rotation. Option C is wrong because the decryption command does not require the key version to be specified; Vault automatically uses the latest key version for decryption unless a specific version is explicitly provided via the `ciphertext` field or the `version` parameter. Option D is wrong because `aes256-gcm96` is a valid key type in Vault's transit secrets engine, representing AES-256 encryption with GCM and a 96-bit nonce, so the encryption operation will succeed.

Practice this question →

Multi-Selecteasy

Which TWO of the following are features of the AWS secrets engine compared to the Azure secrets engine?

Select 2 answers

A.Supports federation via SAML with Azure AD

B.Provides native integration with Azure Key Vault for key management

C.Allows connection to AWS via IAM instance profiles

D.Can generate IAM users with custom policies

E.Can generate STS temporary credentials for cross-account access

AnswersD, E

AWS secrets engine creates IAM users and attaches policies.

Why this answer

Option D is correct because the AWS secrets engine can dynamically generate IAM users with custom policies attached, allowing fine-grained access control for applications. Option E is correct because the engine can generate STS temporary credentials for cross-account access, enabling secure, time-limited access to AWS resources in different accounts.

Exam trap

HashiCorp often tests the distinction between the AWS and Azure secrets engines, and the trap here is confusing the AWS engine's ability to generate IAM users and STS tokens with Azure-specific features like SAML federation or Key Vault integration.

Practice this question →

MCQhard

A Vault administrator configures an AWS secrets engine role with credential_type=iam_user and attaches a policy that allows creating EC2 instances. A developer generates credentials and uses them to launch an EC2 instance. Later the lease expires and Vault revokes the IAM user. What happens to the EC2 instance?

A.The instance continues to run because IAM user revocation does not affect running instances

B.The instance fails with a permission error

C.The instance is immediately terminated

D.The instance is stopped after a grace period

AnswerA

Correct; the instance uses its instance profile.

Why this answer

When Vault revokes an IAM user, it deletes the IAM user credentials, but this does not affect resources already launched by that user. The EC2 instance runs under its own instance profile and is not tied to the IAM user's session after launch. AWS does not retroactively terminate or stop instances based on IAM user revocation; the instance continues to run until explicitly stopped or terminated.

Exam trap

HashiCorp often tests the misconception that revoking IAM credentials will immediately impact running resources, but in AWS, IAM revocation only affects future API calls, not existing instances.

How to eliminate wrong answers

Option B is wrong because the instance does not fail with a permission error — the instance's runtime operations rely on its attached IAM role (if any) or the instance's own metadata, not the original IAM user's credentials. Option C is wrong because AWS does not immediately terminate instances when the launching IAM user is revoked; there is no such lifecycle dependency. Option D is wrong because there is no grace period or automatic stop mechanism triggered by IAM user revocation — the instance remains running indefinitely.

Practice this question →

MCQmedium

A SaaS startup uses Vault to manage secrets for their microservices architecture. They have enabled the KV v2 secrets engine at 'secret/' and the database secrets engine at 'database/'. Developers often need to read application configuration from 'secret/app/config' and database credentials from 'database/creds/app-role'. Recently, the security team mandated that all secrets must be encrypted at rest using Vault's seal mechanism. They configured Vault to use AWS KMS as the seal. After enabling the seal, they noticed that reading from 'secret/app/config' still works, but reading from 'database/creds/app-role' returns an error: 'Error making API request: Code: 500. Errors: * 1 error occurred: * failed to decrypt data'. What is the most likely cause?

A.The database engine requires a separate seal configuration.

B.The database engine configuration is stored in a different location that is not sealed.

C.The AWS KMS key has been rotated and Vault cannot access the old key.

D.The database engine uses a separate encryption key that was not re-wrapped after changing the seal configuration.

AnswerD

The database engine may have its own key for encrypting credentials, which needs re-wrapping.

Why this answer

Option D is correct because when the seal configuration is changed (e.g., from the default Shamir seal to AWS KMS), the database secrets engine's encrypted storage (which includes its own encryption key used to protect dynamic credentials) must be re-wrapped with the new seal. Vault's KV v2 engine stores data encrypted with the same seal, but reading existing static secrets works because they are decrypted on-the-fly using the new seal. However, the database engine's internal key material was encrypted under the old seal and was not re-wrapped, causing decryption failures when Vault attempts to use it to generate credentials.

Exam trap

The trap here is that candidates assume all secrets engines use the same encryption path and will automatically work after a seal change, but Vault requires explicit re-wrapping of engine-specific key material that was encrypted under the previous seal.

How to eliminate wrong answers

Option A is wrong because the database engine does not require a separate seal configuration; all secrets engines in Vault share the same seal mechanism configured at the Vault cluster level. Option B is wrong because the database engine configuration is stored within Vault's encrypted storage (the same backend as KV v2), not in a separate unsealed location; the error is due to key material encrypted under the old seal, not a different storage location. Option C is wrong because rotating the AWS KMS key would cause Vault to be unable to unseal at all (the master key would be lost), but the error occurs only for database credentials while KV reads still work, indicating the seal itself is functional but the database engine's internal key was not re-wrapped.

Practice this question →