Sample questions
Ds Secrets Pipeline ManagementDifficulty 1
Why is hardcoding a database password directly inside a CI/CD pipeline YAML file considered a bad practice?
- aIt makes the pipeline file larger, which slows down the CI system's YAML parser on every run
- bThe password becomes part of the repository's git history, retrievable by anyone with read access.✓
- cYAML files cannot store string values longer than 64 characters, so long passwords get silently truncated
- dCI/CD platforms reject pipeline files that contain literal string values inside job definitions
Explanation:A secret written directly into a YAML file is committed to git and stays in history forever, even if removed later. Anyone with repo read access, including former employees or a public fork, can recover it. Secrets belong in a dedicated secret store injected at run time, not in version-controlled files.
Ds Secrets Pipeline ManagementDifficulty 1
What is the primary purpose of a pre-commit secret-scanning hook (e.g. a tool that runs before git commit completes)?
- aIt inspects the changes being committed and blocks the commit locally if it detects a pattern that looks like an API key, token, or credential✓
- bIt automatically encrypts every file in the repository so committed content is unreadable without a key
- cIt replaces all environment variables in the code with placeholder values before the commit is created
- dIt compresses the commit diff to reduce the repository's total disk usage over time
Explanation:A pre-commit secret-scanning hook runs on the developer's machine before the commit is finalized, scanning the staged diff for patterns matching known credential formats (AWS keys, private keys, tokens). If a match is found, it blocks the commit locally, stopping the secret from ever reaching the remote repository in the first place.
Ds Secrets Pipeline ManagementDifficulty 1
A developer accidentally commits a .env file containing a real API key. A pre-commit hook was not installed on their machine, so the commit reaches the shared remote repository. What is the most important immediate action?
- aRename the
.env file in a follow-up commit so the original file path no longer exists - bAsk the developer to delete the file from their local working directory only
- cWait until the next scheduled secret-scanning pipeline run to confirm whether the key is actually sensitive
- dTreat the key as compromised and revoke/rotate it immediately.✓
Explanation:Once a secret reaches a shared remote repository's history, it must be treated as compromised, because git history retains it even after a later commit removes or renames the file. The only safe response is to revoke and rotate the credential immediately at the source system; cleaning history is a secondary, best-effort step.
Ds Secrets Pipeline ManagementDifficulty 2
Most CI/CD platforms (GitHub Actions, GitLab CI) automatically mask a registered secret's exact value in build logs. What is a key limitation of this masking?
- aMasking only works for secrets shorter than 8 characters, so longer API keys are always shown in plain text
- bIf the secret value is transformed (e.g. base64-encoded, split across two log lines, or printed in a different case) before being written to the log, the masking may fail to recognize and redact it✓
- cMasking disables the entire pipeline run whenever any secret is referenced in a job step
- dMasking permanently deletes the secret from the CI platform's secret store after its first use in a log line
Explanation:Log masking typically works by exact substring matching against the known secret value. If a script transforms the value before printing it -encoding it, splitting it across lines, or changing case- the masking engine may no longer recognize the pattern, letting the real value leak into the log in plain text.
Ds Secrets Pipeline ManagementDifficulty 1
In a CI/CD pipeline, what does injecting a secret 'as an environment variable at run time' mean, compared to hardcoding it in the source?
- aThe CI system fetches the secret from its secret store right before the job runs and exposes it only inside that job's process environment, never persisting it in the checked-out source files✓
- bThe secret is written into the source code repository but encrypted with a key that only the pipeline knows
- cThe secret is compiled into the application binary as a constant so it never needs to be fetched again
- dThe secret is emailed to the pipeline operator, who manually types it into a terminal during each deployment
Explanation:Injecting a secret as an environment variable means the CI platform retrieves it from its secret store at job start time and makes it available only to that job's running process, as an in-memory environment variable. It never touches the checked-out source tree, unlike a hardcoded value.
Ds Secrets Pipeline ManagementDifficulty 2
Why is it risky to give a CI/CD pipeline's cloud deployment credential the same broad permissions as a human administrator account?
- aBroad permissions make the pipeline run measurably slower because the cloud API has to check more permission rules per request
- bCloud providers charge extra fees for credentials that have administrator-level permissions attached
- cAdministrator credentials expire faster than scoped credentials, forcing more frequent manual rotation
- dIf the pipeline (or any dependency, script, or compromised job step within it) is compromised, an attacker inherits the full blast radius of an administrator, far beyond what the pipeline actually needs to deploy the application✓
Explanation:The pipeline credential should follow least privilege: scoped only to the actions and resources the deployment actually requires. If it instead holds admin-level rights, any compromise of the pipeline (a malicious dependency, a leaked token, a compromised action) gives the attacker admin-level blast radius across the whole cloud account, not just deployment access.