Cyber Security Quiz: Secrets Management
10 questions · exam conditions
0:00
Secrets ManagementQuestion 1 of 10

A development team removes a database password from application source code. During the container build, the CI system reads the password from a protected variable and writes it into an environment variable in the final image. The image is stored in a private registry, and containers use the variable at runtime.

Which change would BEST address the remaining secrets-management weakness?

Encrypt the private registry and continue embedding the password as an environment variable in each image.
Use a workload identity to retrieve the password from a vault when the container starts.
Obfuscate the environment variable name and restrict access to the container build definition.
Create separate images containing different passwords for development, testing, and production environments.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Secrets Management

Practice Secrets Management in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Secrets Management, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A development team removes a database password from application source code. During the container build, the CI system reads the password from a protected variable and writes it into an environment variable in the final image. The image is stored in a private registry, and containers use the variable at runtime.

Which change would BEST address the remaining secrets-management weakness?

  1. Encrypt the private registry and continue embedding the password as an environment variable in each image.
  2. Use a workload identity to retrieve the password from a vault when the container starts. (correct answer)
  3. Obfuscate the environment variable name and restrict access to the container build definition.
  4. Create separate images containing different passwords for development, testing, and production environments.
Explanation: When you see a secrets-management question in cybersecurity, ask yourself: at what point in the lifecycle is the secret exposed, and how broadly? The core weakness here isn't just where the password lives — it's that baking a secret into an image means anyone who pulls that image (now or in the future) can extract it with a simple docker inspect or printenv. The secret becomes permanently embedded in an artifact. The strongest fix is B: using a workload identity to fetch the password from a vault at container startup. This approach means the secret never touches the image at all. The container authenticates itself (via a platform-assigned identity, like AWS IAM roles or HashiCorp Vault's AppRole) and retrieves the credential dynamically. Even if the image is compromised, there's no secret to steal — and credentials can be rotated without rebuilding anything. A is a trap because encrypting the registry doesn't remove the secret from inside the image. You've added a lock to the door while leaving the valuables in plain sight inside. C mistakes obscurity for security — renaming or hiding a variable doesn't prevent someone with container access from reading its value, and restricting the build definition is an access-control measure, not a secrets-management solution. D seems organized but actually multiplies the problem: now you have more images with hardcoded secrets, increasing your attack surface rather than reducing it. A useful study rule: any solution that still ends with a secret stored inside an image hasn't solved the underlying problem — it's just moved the wrapper around it.

Question 2

A vault rotates a service credential every 12 hours. For performance, an application retrieves the credential only when its process starts and then caches it indefinitely. Application instances commonly run for several weeks.

Which design change would BEST preserve caching while allowing rotation to take effect reliably?

  1. Make the cache lease-aware and refresh the credential before expiration, with controlled handling of refresh failures. (correct answer)
  2. Increase the vault's credential lifetime to match the longest expected application process lifetime.
  3. Schedule every application instance to restart exactly when the vault performs its credential rotation.
  4. Cache both the old and new credentials indefinitely so the application can retry either credential.
Explanation: When designing systems that use rotating secrets, the core challenge is keeping performance high (via caching) without letting stale credentials cause authentication failures. The question is really asking: how do you make a cache smart about expiration rather than just eliminating caching or working around rotation? The best solution, choice A, introduces lease-awareness — the cache tracks when a credential is due to expire and proactively refreshes it before that deadline hits. By handling refresh failures gracefully (retrying, alerting, or falling back), the application stays resilient even if the vault is temporarily unreachable. This preserves the performance benefit of caching while ensuring rotation actually propagates. Choice B eliminates the security benefit of rotation entirely. If you extend credential lifetimes to match multi-week process lifespans, a compromised credential stays valid for weeks — exactly the risk rotation is designed to minimize. You've solved the caching problem by breaking the security model. Choice C creates an operational nightmare. Coordinating restarts across every application instance to align precisely with vault rotation schedules is brittle, hard to automate reliably at scale, and causes unnecessary downtime. It also doesn't handle cases where instances start mid-cycle. Choice D is dangerous because indefinitely caching both credentials means you never actually evict the old one. Over time this becomes unmanageable, and holding a revoked credential in cache defeats the purpose of rotation — an attacker who compromised the old credential still has a working copy. A useful rule of thumb: when a question asks you to preserve caching and support security rotation, look for the answer that adds intelligence to the cache rather than one that removes or ignores either constraint.

Question 3

To avoid storing a plaintext API key, a developer encrypts the key and commits the ciphertext to the application repository. The same repository contains the decryption key so that the application can decrypt the API key without contacting another service.

What is the PRIMARY security problem with this design?

  1. The ciphertext cannot be version-controlled safely because encrypted data changes whenever a repository is cloned.
  2. The application cannot decrypt the API key unless the ciphertext is converted to Base64 before deployment.
  3. An attacker obtaining the repository receives both the protected secret and the means to decrypt it. (correct answer)
  4. The API key will automatically expire whenever the repository's decryption key is used by the application.
Explanation: When a question describes someone "protecting" a secret by encrypting it, your first instinct should be to ask: where does the decryption key live? Encryption only provides security if the key is kept separate from the ciphertext — otherwise you've simply added a thin wrapper around the same vulnerability. That's exactly the trap in this design. The developer encrypts the API key, but then stores the decryption key in the same repository. Anyone who gains access to the repo — whether a malicious insider, a misconfigured public GitHub setting, or an attacker who steals credentials — immediately has both the locked box and the key to open it. The encryption adds no real security because it can be trivially reversed. This is why C is the correct answer: the attacker receives the protected secret and the means to decrypt it simultaneously, making the encryption theater rather than protection. A is wrong because encrypted data does not change during cloning — ciphertext is deterministic and stable in a repository like any other file. This answer fabricates a technical behavior that doesn't exist. B is wrong because Base64 is an encoding scheme, not a security requirement. It has nothing to do with whether decryption succeeds, and converting to Base64 would not fix the fundamental design flaw anyway. D is wrong because decryption key usage does not cause API keys to expire. Expiration is governed by the API provider's policies, not by cryptographic operations on the client side. For your exam, watch for "security theater" scenarios — any design where encryption or hashing is applied but the key or secret is stored alongside the protected data defeats the purpose entirely.

Question 4

A company migrates an application from a hardcoded cloud access key to vault-issued temporary credentials. One week later, a security review discovers that the original hardcoded key is still active, although the current application version no longer uses it.

Which response BEST completes the migration securely?

  1. Leave the original key active as an emergency fallback because the new application does not normally use it.
  2. Rename the original key in the cloud console so attackers cannot associate it with the application.
  3. Move the original key into the vault and retain it indefinitely alongside the temporary credentials.
  4. Revoke the original key promptly and review audit records for use after its possible exposure. (correct answer)
Explanation: When you see a question about credential management during a migration, focus on one core principle: unused credentials that remain active are live attack surfaces, regardless of whether the current application uses them. A stale key sitting in a cloud console is just as exploitable as one in active use — and if it was ever exposed (in source code, logs, or version history), attackers may already have it. That's why D is the correct response. Revoking the original key eliminates the risk immediately. Reviewing audit logs is equally critical: if the key was compromised during its exposure window, there may already be unauthorized activity you need to detect and remediate. Together, these two actions — revoke and investigate — close both the present vulnerability and any ongoing damage. A is tempting because "emergency fallback" sounds prudent, but keeping a potentially exposed key active as a backup directly contradicts the principle of least privilege. An attacker who found the key doesn't care that your application stopped using it. B is a classic security-through-obscurity trap — renaming a credential does nothing to invalidate it. The key's value to an attacker is its secret string, not its display name. C sounds systematic, but storing the original key in the vault indefinitely still leaves a live, exposed credential in your environment. Retention without revocation solves nothing. A useful rule of thumb: when migrating away from a credential, your checklist is always revoke, then review — not archive, rename, or preserve "just in case."

Question 5

A vault contains production payment credentials, test database passwords, and infrastructure administration keys. A payment service needs to read one production payment credential and does not need to enumerate other secrets.

Which access policy BEST applies least privilege?

  1. Permit administrative vault access but restrict the token's network origin to the payment-service subnet.
  2. Permit read and list access to all production paths because the service already runs in production.
  3. Permit read access to the entire payment folder and write access so the service can rotate any credential.
  4. Permit read access to the exact payment-secret path and deny broad listing or administrative operations. (correct answer)
Explanation: When you see a question about vault or secrets management, anchor your thinking to the principle of least privilege: grant only the minimum permissions necessary to perform the specific task — nothing more. The payment service has exactly one job here: read one specific credential. Option D is correct because it grants read access to the exact secret path the service needs and explicitly denies listing and administrative operations. This surgical precision means a compromised token cannot be used to enumerate other secrets, escalate privileges, or discover the vault's structure — limiting blast radius if something goes wrong. Option A fails because "administrative vault access" is wildly overkill regardless of the network restriction. Restricting the source IP is a useful additional control, but it doesn't fix the underlying problem that administrative permissions grant far more capability than reading a single secret. Option B violates least privilege by granting access to all production paths under the rationalization that the service runs in production. Running in production is not a justification for broad access — production services still need scoped permissions. This is a classic "environment-level" thinking trap. Option C compounds the problem by adding write access under the guise of credential rotation. A payment service that only reads credentials has no business rotating them; rotation responsibilities belong to a dedicated secrets-management process, not a consumer service. Study tip: On security exams, watch for answers that bundle a legitimate need with a hidden overpermission — like C pairing "read" with "write for rotation." Always ask: does the stated task actually require each permission listed? If not, the answer violates least privilege.

Question 6

A CI job authenticates to a vault using a short-lived identity and retrieves a signing key only for the duration of the build. During troubleshooting, command tracing is enabled, and the build log prints the command after the key has been substituted into it.

Which control would BEST address the immediate exposure without abandoning centralized secrets management?

  1. Disable secret-bearing command tracing and configure reliable masking while keeping the vault-issued access short-lived and scoped. (correct answer)
  2. Store the signing key in the source repository so the CI system no longer needs to substitute it into commands.
  3. Use a longer-lived vault credential so the signing key needs to be retrieved less frequently during troubleshooting.
  4. Encrypt archived build logs while continuing to display the substituted signing key to all job viewers.
Explanation: When secrets leak through CI/CD pipelines, the instinct is often to overhaul the entire system — but good security design asks you to fix the specific control that failed while preserving the protections already working. Here, the vault-based short-lived credential is doing exactly what it should; the failure is that command tracing exposed the substituted key in the build log. Option A is correct because it surgically addresses the actual exposure point. Disabling tracing for secret-bearing commands (or ensuring reliable log masking) prevents the key from ever appearing in plaintext output, while keeping the short-lived, scoped vault credential preserves the principle of least privilege and minimizes the blast radius if another leak occurs. You fix what broke without discarding what works. Option B is a serious regression — storing the signing key in source control is one of the most dangerous secrets management mistakes you can make. It trades a narrow logging exposure for a broad, persistent one accessible to everyone with repository access, forever baked into git history. Option C actually weakens security. Longer-lived credentials expand the window of exploitation if they're compromised. The short-lived nature of vault credentials is a feature, not a burden to optimize away. Option D addresses log storage in isolation but ignores the real problem: the key is already visible to all current job viewers in real time. Encrypting archives doesn't help if the exposure happens during the live build. Study tip: When a question describes a working security control alongside a specific failure, the best answer almost always preserves the working control while fixing the failure — not replaces or weakens the overall architecture.

Question 7

A team stores application passwords in Kubernetes Secret objects. An engineer argues that the values are secure because the manifest displays them as Base64 text rather than readable plaintext.

Which assessment is MOST accurate?

  1. Base64 provides confidentiality as long as the encoding scheme is not documented in the cluster configuration.
  2. Base64 is only an encoding; proper RBAC, encryption at rest, and secure transport are still required, or secrets should be retrieved from an external vault with centralized policy and audit. (correct answer)
  3. Base64 protects secret values within the cluster, though transport encryption should be disabled to prevent double-encoding conflicts during transmission.
  4. Base64 is functionally equivalent to vault encryption when each namespace uses a distinct Kubernetes service account and network policy.
Explanation: When you see a question about secrets management in Kubernetes — or any system — your first instinct should be to ask: "Does this mechanism actually hide or protect data, or does it just transform it?" That distinction separates security from the illusion of security. Base64 is purely an encoding scheme, not encryption. Anyone who runs echo "dGVzdA==" | base64 --decode instantly recovers the original value. Kubernetes stores Secrets as Base64 in etcd by default, meaning without additional controls, those values are exposed to anyone with etcd access, sufficient RBAC permissions, or an unencrypted API channel. Answer B correctly identifies the full picture: Base64 provides zero confidentiality on its own. Real protection requires encrypting secrets at rest (configuring etcd encryption), locking down access with RBAC, ensuring TLS for API server communication, and ideally externalizing secrets to a dedicated vault like HashiCorp Vault or AWS Secrets Manager, which adds centralized auditing and policy enforcement. Answer A is wrong because Base64 offers no confidentiality regardless of whether it's documented — it's a publicly known, trivially reversible transformation. Secrecy of the encoding algorithm is not a security property. Answer C contains a dangerous fabrication: disabling transport encryption to "prevent double-encoding" is nonsensical and would actively harm security. Answer D is wrong because RBAC and network policies control access, not encryption — they don't make Base64 equivalent to vault-grade cryptographic protection. Your study tip: anytime an exam question mentions encoding (Base64, URL encoding, hex), remind yourself that encoding ≠ encryption. Only encryption with a protected key provides confidentiality.

Question 8

Fifty application instances use one static database account stored in a vault. The password is rotated quarterly, but an attacker who compromises one instance can use the account from another host until the next rotation.

Which vault capability would MOST directly reduce both the credential's useful lifetime and the compromise blast radius?

  1. Version the static password so applications can request either the current or previous database credential.
  2. Generate short-lived database credentials uniquely leased to each authenticated application instance. (correct answer)
  3. Replicate the static password across multiple vault clusters to improve credential retrieval availability.
  4. Require administrators to approve each quarterly password change before applications receive the new value.
Explanation: When evaluating vault capabilities, focus on two distinct threat metrics: credential lifetime (how long a stolen credential remains usable) and blast radius (how many systems are exposed if one credential is compromised). The scenario describes both problems simultaneously — a stolen static password works everywhere and stays valid for months. The most powerful solution is dynamic secrets, which is exactly what B describes. When each application instance requests a credential, the vault generates a unique, short-lived database account tied to that specific lease. If one instance is compromised, the attacker gets a credential that expires in minutes or hours, not months — and it's useless on other instances because each has its own unique account. This directly attacks both problems at once. A is a versioning feature — it lets applications fall back to previous passwords during rotation windows. This is a convenience mechanism, not a security control. It doesn't shorten the credential's lifetime at all; it actually extends the window during which an older credential works. C describes replication for high availability. Spreading the same static password across more clusters increases retrieval reliability but does nothing to limit how long the credential is valid or how broadly it can be used — it may even expand the blast radius. D adds an approval gate to the quarterly rotation process. This slows down rotation and makes credential delivery more controlled, but it keeps the same quarterly rotation cycle, meaning a stolen credential is still valid for months. On exam questions involving credential security, watch for answers that sound protective but only address availability or process, not actual exposure time or scope.

Question 9

An engineer accidentally commits an API key to a Git repository. The engineer immediately replaces the key in the latest commit with a vault reference. The repository is private, but it has been cloned by several developers and CI runners.

What is the MOST appropriate next action?

  1. Rotate or revoke the exposed key, review its use, and remove it from accessible repository history. (correct answer)
  2. Delete the branch containing the latest commit and rely on repository access controls to protect earlier commits.
  3. Move the repository to a new private project and retain the key because it is no longer in the current files.
  4. Add the affected filename to the ignore list and wait for the key's normal expiration date.
Explanation: When a secret is accidentally committed to a Git repository, you need to think beyond the current state of the files. Git preserves complete history, meaning that even if you overwrite a commit or replace the value in the latest version, the original credential still lives in earlier commits — fully visible to anyone who cloned the repo before the fix. This is exactly why A is correct. The three-part response it describes covers every threat surface: rotating or revoking the key neutralizes it immediately (so even if someone found it, it's useless); reviewing its use detects whether it was already exploited; and purging it from repository history eliminates the persistent exposure in git logs. Replacing it with a vault reference in the latest commit alone is a good practice, but it's insufficient on its own. B fails because deleting a branch doesn't erase commit history in Git — those commits remain accessible via other branches, reflog, or clones already distributed to developers and CI runners. C is dangerously wrong: moving to a new repository doesn't help because the compromised key is still valid and the old clones still contain it. Retaining a leaked key is never acceptable. D mistakes .gitignore for a security control — it only prevents future accidental commits of that file; it does nothing to remove already-committed secrets, and waiting for natural expiration leaves the key live and exploitable for potentially weeks or months. A useful rule of thumb: treat any exposed credential as already compromised. Revoke first, investigate second, clean history third — always in that order.

Question 10

A cloud-hosted service must retrieve secrets from a vault. The team proposes storing a long-lived vault access token in the service's configuration file so the service can authenticate after deployment.

Which alternative BEST avoids merely replacing one hardcoded secret with another?

  1. Store the vault token in a separately maintained configuration repository with access limited to administrators.
  2. Encrypt the vault token in the configuration file and package the decryption key with the service.
  3. Use the platform's workload identity to obtain a short-lived, policy-scoped vault authentication token. (correct answer)
  4. Generate a different long-lived vault token for each deployment and place it in that deployment's image.
Explanation: When you see a question about secrets management in cloud environments, ask yourself: does this solution genuinely eliminate the secret, or just relocate it? That framing cuts through most of the distractors here. The core problem with hardcoded secrets is that any static credential must be stored, transmitted, and protected — and every step introduces risk. The modern solution is workload identity: the cloud platform itself vouches for your service's identity (e.g., AWS IAM roles, GCP service accounts, Azure Managed Identities), and the vault issues a short-lived, scoped token in response. No secret ever enters your configuration because authentication is based on what your workload is, not what it knows. This is why C is correct — the platform's workload identity breaks the secret-bootstrapping cycle entirely. A only changes where the long-lived token lives. Restricting access to administrators reduces exposure but the static secret still exists, still can be leaked or stolen, and still must be rotated manually. You've added access control, not eliminated the root problem. B is a classic trap: encrypting the token sounds more secure, but bundling the decryption key with the service means anyone with access to the service can reconstruct the secret. You've just added a layer of obscurity, not genuine protection — one hardcoded secret becomes two. D distributes the problem rather than solving it. Unique tokens per deployment still means long-lived, static credentials baked into images, which can be extracted from the image registry or container filesystem. Study tip: On security exams, watch for answers that protect a secret versus answers that eliminate the need for one — eliminating is almost always the stronger architectural choice.