Sample questions
Ci Cd PipelinesDifficulty 3
In a GitOps setup, the desired state of an environment is described declaratively in a Git repository, and an automated controller continuously reconciles the live environment to match what is committed there. Compared to a pipeline that runs deploy commands directly against the environment, what is the key structural difference GitOps introduces?
- aGit becomes the source of truth for desired state, and reconciliation is pulled and enforced continuously, not just at deploy time.✓
- bGitOps removes the need for any pipeline at all, since Git alone can build and test application code.
- cGitOps requires that every environment share a single Git repository with no separation between them.
- dGitOps means deployments can only be triggered manually, since automated reconciliation is disabled by design.
Explanation:The defining shift in GitOps is that Git holds the declared desired state, and a controller continuously pulls and reconciles the live environment toward it, rather than a one-off push happening only when a pipeline runs a deploy command. This also gives continuous drift correction, not just a one-time apply. Option b is false — GitOps still needs a pipeline for build/test, it changes how deployment reconciliation happens, not whether a pipeline exists. Option c invents an unnecessary constraint; environments are commonly still separated (by repo, branch, or directory). Option d contradicts GitOps, which specifically automates reconciliation rather than disabling it.
Ci Cd PipelinesDifficulty 3
Two teams both say their pipeline "deploys to production automatically after tests pass." Team A still requires someone to click a manual approval button before the deploy step runs. Team B has no manual gate at all — a passing pipeline deploys straight to production. Which pair of terms most accurately labels Team A's and Team B's practices, respectively?
- aTeam A practices continuous integration; Team B practices continuous delivery.
- bTeam A practices continuous delivery; Team B practices continuous deployment.✓
- cTeam A practices continuous deployment; Team B practices continuous delivery.
- dTeam A and Team B both practice identical continuous deployment, since both deploy automatically.
Explanation:Continuous delivery keeps every validated change release-ready but leaves the final production release decision to a human (Team A's manual gate). Continuous deployment removes that gate entirely, so every change that passes the pipeline goes live automatically (Team B). Option a mislabels both teams as earlier stages than they actually are. Option c swaps the two definitions. Option d incorrectly claims no distinction exists, ignoring the manual approval difference that separates the two practices.
Ci Cd PipelinesDifficulty 3
During an investigation, an engineer notices that a database password was printed in plain text in the pipeline logs for a job that ran three weeks ago, because a script used echo $DB_PASSWORD for debugging before it was removed. The logs are still retained and viewable by anyone with read access to the pipeline. What is the most appropriate immediate response?
- aDo nothing further, since the debug line printing the password has already been removed from the script.
- bRely on the pipeline's log masking feature to redact the password retroactively in the stored old logs.
- cRotate the exposed credential and treat it as compromised, in addition to having removed the debug line.✓
- dWait until the next scheduled credential rotation cycle, since an unused old log is unlikely to be read.
Explanation:Once a secret has been printed to logs anyone with read access could view, it must be treated as compromised regardless of whether the debug line causing it was later removed — rotating it closes the actual exposure window. Option a only prevents future exposure, it does nothing about the credential already visible in retained logs. Option b is a common misconception: masking is typically applied at print-time going forward, not retroactively to already-stored log content. Option d needlessly delays remediation of a known, already-exposed secret.
Ci Cd PipelinesDifficulty 3
A monorepo contains several independent services. Currently, every push runs the full pipeline for all services, even when a change only touches one service's directory. This makes every run take much longer than necessary. What pipeline design change would best address this?
- aSplit the monorepo into a separate repository per service, since path-based filtering is otherwise impossible.
- bRemove the test stage for services that were not directly touched, but still run their build and deploy stages.
- cConfigure the pipeline to detect changed paths and only run jobs for the services whose directories changed.✓
- dIncrease the number of parallel runner machines so the full pipeline for all services finishes at the same time.
Explanation:Path-based triggering (change detection on directories/files) lets a monorepo pipeline run only the jobs relevant to what actually changed, cutting run time without reducing test coverage where it matters. Option a is an unnecessarily drastic structural change; most CI/CD tools support path filters within a single monorepo. Option b is unsafe — skipping tests while still deploying an untouched-looking service risks deploying based on stale validation. Option d just throws more hardware at the problem instead of avoiding unnecessary work, and doesn't reduce wasted compute.
Ci Cd PipelinesDifficulty 3
A particular integration test fails intermittently across unrelated pull requests, roughly one run in five, with no consistent code change correlating to the failures. Developers have started routinely re-running the pipeline whenever it fails, without investigating further. What is the main long-term risk of leaving this pattern unaddressed?
- aThe team gradually loses trust in pipeline failures and may reflexively re-run past a genuine regression someday.✓
- bThe pipeline tool will eventually refuse to run the same job twice, permanently blocking further re-runs.
- cThe flaky test will automatically be promoted to a required check on every branch, blocking all future merges.
- dBuild caching will silently corrupt because of the repeated re-runs, producing invalid artifacts going forward.
Explanation:A known flaky test that people habitually re-run past, rather than fix or quarantine, erodes trust in the pipeline as a signal — the real danger is that a genuine regression could someday be dismissed as 'probably just the flaky test' and re-run past instead of investigated. Option b, c, and d all invent mechanical failures that pipeline tools don't actually exhibit; the real risk here is a human/process one (eroded trust), not a technical malfunction of the tool itself.
Cloud Architecture ScalingDifficulty 3
A team runs a service whose traffic varies throughout the day, but whose baseline load is predictable and stable over the year. What is the most cost-effective infrastructure strategy?
- aRun all capacity purely on-demand, since committing to reserved capacity always reduces the flexibility needed for a varying workload
- bReserve all capacity needed for the daily peak, since reserved pricing always removes the need to think about autoscaling entirely
- cCover the predictable baseline load with reserved capacity, and handle the variable/peak traffic with on-demand instances added via autoscaling✓
- dDisable autoscaling entirely and run a fixed number of large on-demand instances sized for the peak at all times, to keep the setup simple
Explanation:Mixing reserved capacity for the known, steady baseline with on-demand (often autoscaled) capacity for the unpredictable peak captures the discount on stable usage while keeping flexibility for the variable part. Option b overcommits reserved capacity to cover peak load that doesn't happen most of the day, wasting money. Option d abandons autoscaling and pays peak-level cost around the clock, which is the most expensive option described.