I85PREP
⌘ K
ECDE study materials
ECDE study resources

ECDE practice questions

One question at a time. Build your ECDE understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Understanding DevOps Culture

In DevOps culture, which practice most directly shortens the feedback loop between detecting a production problem and learning from it?

  1. Running a blameless post-incident review shortly after the event Correct answer.
  2. Freezing all changes for a month after each release
  3. Assigning defects to the team that wrote the oldest code
  4. Requiring sign-off from three managers before any deployment

Explanation

Blameless post-incident reviews bring the people involved together soon after an event to reconstruct the timeline, identify contributing causes, and agree on corrective actions. Holding the review promptly preserves accurate detail and converts failure into shared organizational learning. Sign-off gates and change freezes instead lengthen feedback and hide causes.

Question 2Understanding DevOps Culture

A team adopts the 'you build it, you run it' principle. What change in responsibility does this principle describe?

  1. A separate reliability group owns all production incidents
  2. Developers carry operational responsibility for the services they build Correct answer.
  3. Operations staff write all application code
  4. Product owners approve every production log entry

Explanation

'You build it, you run it' means the team that writes a service also operates and supports it in production. This closes the gap between change and consequence, so developers feel operational pain directly and design for reliability. It does not remove operations specialists; it shifts ownership to the delivery team.

Question 3Understanding DevOps Culture

Which behavior best exemplifies psychological safety on a DevOps team?

  1. A junior engineer reports a risky deploy and is thanked for surfacing it Correct answer.
  2. Engineers avoid raising concerns so that retrospectives stay short
  3. Managers record who caused each failed build for performance reviews
  4. Only senior engineers are permitted to speak in incident calls

Explanation

Psychological safety means people believe they can speak up about risks, mistakes, and uncertainty without punishment. Thanking someone for flagging a risky deploy reinforces that speaking up is valued and keeps problems visible early. Practices that punish or silence reporting suppress the information flow DevOps depends on.

Question 4Understanding DevOps Culture

What is the primary cultural purpose of a blameless postmortem?

  1. To satisfy auditors with a fixed-format report
  2. To document the incident so it can be closed administratively
  3. To determine which individual should be disciplined
  4. To understand systemic causes and prevent recurrence Correct answer.

Explanation

A blameless postmortem assumes people act reasonably given the information and tools available, so it focuses on systemic factors such as design, monitoring, and process. The goal is to identify contributing causes and make durable improvements. Discipline and paperwork are not its purpose.

Question 5Understanding DevOps Culture

Which statement best captures the DevOps cultural shift from 'dev versus ops' to shared goals?

  1. Developers own all goals and operations reports upward
  2. Operations sets targets that developers must meet without discussion
  3. Both groups are measured on delivery speed and service stability together Correct answer.
  4. Each group optimizes its own local metrics independently

Explanation

DevOps replaces competing local objectives with shared outcomes such as deployment frequency and reliability. When both groups are measured on the same delivery and stability metrics, they collaborate instead of trading blame. Independent or one-sided targets recreate the wall DevOps aims to remove.

Question 6Understanding DevOps Culture

An organization wants cross-functional teams that own a service from idea to production. Which structural change aligns with DevOps culture?

  1. Forming product teams with the skills and authority to deliver and operate their service Correct answer.
  2. Outsourcing all operational work to a distant vendor
  3. Adding an approval board between every development stage
  4. Splitting developers and operators into separate buildings with separate budgets

Explanation

Cross-functional teams combine the development, testing, and operational skills needed to deliver a service end to end. Giving them authority over their own service reduces handoffs and waiting, which is central to DevOps culture. Structural separation and added approval layers recreate the silos the change is meant to remove.

Question 7Understanding DevOps Culture

Which is a genuine example of automation supporting DevOps culture rather than merely replacing people?

  1. Automating email approvals for every code review
  2. Automating performance reviews to rank engineers by commit count
  3. Automating a freeze that blocks all releases for a quarter
  4. Automating the deployment pipeline so engineers can release safely and often Correct answer.

Explanation

Automation serves DevOps culture when it removes toil and makes safe, frequent change easier, freeing people for higher-value work. Pipeline automation gives fast feedback and repeatable releases. Automating surveillance, freezes, or approval emails instead adds friction or distrust.

Question 8Understanding DevOps Culture

What distinguishes a DevOps culture from a toolchain-only adoption?

  1. Mandating a single programming language
  2. Changing behaviors, incentives, and collaboration alongside tooling Correct answer.
  3. Renaming the operations department to platform engineering
  4. Buying more continuous integration servers

Explanation

Tools enable practices but do not by themselves change how people collaborate, share accountability, or respond to failure. DevOps culture requires shifts in behavior, incentives, and trust, with tooling as an enabler. Renaming a department or standardizing a language leaves the underlying dynamics untouched.

Question 9Understanding DevOps Culture

A team's retrospectives keep producing the same action items with no follow-through. Which change best addresses the cultural root cause?

  1. Stop recording action items to avoid accountability pressure
  2. Shorten retrospectives to ten minutes to save time
  3. Replace retrospectives with a monthly status meeting
  4. Limit action items to a few with named owners and visible tracking Correct answer.

Explanation

When actions repeat without progress, the issue is usually unclear ownership and lack of visibility rather than the meeting format. Committing to a small number of actions with named owners and tracked status creates accountability and closure. Shortening, replacing, or hiding actions leaves the underlying follow-through gap intact.

Question 10Understanding DevOps Culture

A leader wants to encourage experimentation. Which action best signals that acceptable failures are safe?

  1. Punishing any change that causes a rollback
  2. Running controlled experiments and reviewing outcomes publicly without blame Correct answer.
  3. Requiring perfection before any feature is released
  4. Hiding failed experiments from the wider organization

Explanation

Experimentation culture grows when failures are treated as information and reviewed openly rather than punished. Public, blameless review of controlled experiments shows that calculated risk is expected and that learning is valued. Punishment, perfectionism, or concealment teaches people to avoid risk and hide results.

Question 11Understanding DevOps Culture

A company introduces daily deployments but developers still wait days for operations to provision environments. Which cultural principle is being violated?

  1. Keeping development and operations budgets separate
  2. Maximizing utilization of every operations engineer
  3. Centralizing all decisions with a change advisory board
  4. Removing silos and handoffs so teams can self-serve Correct answer.

Explanation

DevOps culture stresses reducing handoffs and enabling teams to self-serve the resources they need. When developers must queue for operations to provision environments, the silo and its waiting time remain despite faster deployment tooling. Maximizing utilization or centralizing decisions perpetuates the bottleneck.

Question 12Understanding DevOps Culture

In a blameless postmortem, an engineer admits they ran a destructive command on the wrong cluster. What is the most culturally consistent response?

  1. Require the engineer to sign a written warning
  2. Remove the engineer from on-call rotation as a penalty
  3. Examine why the tooling allowed the wrong cluster to be targeted Correct answer.
  4. Record the admission for the next performance cycle

Explanation

Blameless review redirects attention from the individual to the system conditions that made the error easy, such as ambiguous cluster targeting or missing safeguards. Fixing tooling prevents recurrence for everyone. Penalties or records for honest disclosure would discourage reporting and hide risk.

Question 13Understanding DevOps Culture

A manager measures a platform team by the number of tickets it closes. Which outcome is most likely, and how does it conflict with DevOps culture?

  1. The metric aligns everyone on end-to-end delivery
  2. Developers stop filing tickets because service improves
  3. Teams close tickets faster because the metric is clear
  4. The team optimizes ticket volume rather than developer productivity, encouraging local over shared goals Correct answer.

Explanation

Metrics shape behavior, so a ticket-count target invites closing many small tickets rather than improving the developer experience. DevOps culture favors shared outcomes such as flow and reliability over local activity counts. The metric therefore misaligns the platform team from the value it should deliver.

Question 14Understanding DevOps Culture

Which pairing of practices best supports a culture of shared ownership between development and operations?

  1. Operations writes runbooks that developers are forbidden to read
  2. Operations alone decides which features are deployable
  3. Developers hand off releases over a wall to operations
  4. Developers join on-call rotations while operations staff contribute to code reviews Correct answer.

Explanation

Shared ownership grows when each group participates in the other's work: developers experience operational reality through on-call, and operations staff influence design through code review. This mutual participation builds empathy and shared context. Walls, secrecy, and unilateral control preserve the divide.

Question 15Understanding DevOps Culture

A team wants to reduce blame after incidents. Which practice most directly builds the trust needed for honest reporting?

  1. Separating incident review from performance evaluation and stating this policy clearly Correct answer.
  2. Encouraging engineers to resolve incidents quietly without documentation
  3. Requiring incident reporters to justify themselves to senior management
  4. Publishing an incident leaderboard ranked by team

Explanation

People report honestly when they believe disclosure will not affect their evaluations. Explicitly separating incident review from performance management, and saying so, reduces fear and builds trust. Leaderboards, justification demands, and quiet fixes all increase the incentive to conceal.

Question 16Understanding DevOps Culture

Which statement about the relationship between DevOps culture and continuous improvement is most accurate?

  1. Continuous improvement requires a dedicated department to own all changes
  2. Continuous improvement is a one-time transformation project with an end date
  3. Continuous improvement is an ongoing habit of small experiments and learning Correct answer.
  4. Continuous improvement depends mainly on purchasing new tools

Explanation

DevOps culture treats improvement as a continuous, incremental practice driven by feedback and experimentation rather than a finite program. Small, frequent changes compound into lasting gains. One-time projects, a separate owning department, or tool purchases do not sustain the habit.

Question 17Understanding DevOps Culture

A team holds a 'failure party' where engineers present recent mistakes and lessons. What cultural signal does this practice send?

  1. Only dramatic failures deserve attention
  2. Engineers should compete to have the most interesting failure
  3. Mistakes are expected and learning from them is valued Correct answer.
  4. Failures should be celebrated regardless of their impact

Explanation

Openly sharing mistakes and lessons normalizes failure as part of learning and reduces the fear of disclosure. The signal is that errors are expected in complex work and that extracting lessons is valued. It does not imply celebrating harm or ignoring impact.

Question 18Understanding DevOps Culture

Which scenario best demonstrates the DevOps value of 'stop the line' when a quality problem is detected?

  1. An engineer merges despite red tests to meet a sprint goal
  2. A manager disables failing checks to speed up delivery
  3. A developer notices failing integration tests and halts the pipeline to fix them before merging Correct answer.
  4. A team ignores flaky tests to keep the pipeline green

Explanation

'Stop the line' borrows from lean manufacturing: anyone who detects a defect can halt work until it is fixed, preventing defects from flowing downstream. Halting the pipeline on failing tests keeps the main branch healthy. Ignoring, disabling, or bypassing checks lets defects accumulate.

Question 19Understanding DevOps Culture

A leader wants to shift from a blame culture to a learning culture. Which combination of actions is most effective?

  1. Publish individual error rates and tie bonuses to them
  2. Require written explanations from anyone who reports a problem
  3. Model fallibility, ask questions, and reward teams that surface and fix systemic issues Correct answer.
  4. Reduce incident reporting to lower the visible error count

Explanation

Leaders shape culture through what they model and reward. Admitting fallibility, asking genuine questions, and rewarding systemic fixes signal that learning matters more than appearing flawless. Publishing error rates, demanding explanations, or suppressing reports all increase fear and reduce learning.

Question 20Understanding DevOps Culture

An organization claims to value collaboration but rewards individual heroics during incidents. What is the most likely cultural consequence?

  1. Teams will invest in prevention because heroics are discouraged
  2. Incident frequency will fall because heroes respond quickly
  3. Collaboration will improve because heroes share credit
  4. Engineers will optimize for visible firefighting rather than preventing incidents Correct answer.

Explanation

Rewards steer behavior, so celebrating heroic firefighting encourages people to value dramatic saves over quiet prevention. Over time, effort shifts toward being visible during incidents rather than reducing them. Prevention work, which is less visible, gets neglected.

Question 21Understanding DevOps Culture

Two teams share a service. Team A deploys frequently and Team B is measured on minimizing change. Which cultural intervention best resolves the tension?

  1. Give Team B veto power over Team A's deployments
  2. Move Team A to a separate organization
  3. Define shared service-level objectives and joint ownership of the service Correct answer.
  4. Let each team keep its own metric and negotiate ad hoc

Explanation

Conflicting local metrics produce friction that no amount of coordination meetings will fix. Shared service-level objectives and joint ownership align both teams on the same outcome, so frequent safe change and stability support each other. Vetoes or separation preserve the conflict.

Question 22Understanding DevOps Culture

A company adopts DevOps tooling but incident reports still name individuals and managers use them in reviews. Which diagnosis best explains why the culture has not changed?

  1. Underlying norms and incentives still punish disclosure, so behavior reverts to self-protection Correct answer.
  2. The tooling is insufficiently automated
  3. Engineers lack training on the new tools
  4. The deployment pipeline is too fast

Explanation

Culture is shaped by norms and incentives, not tools alone. If reports still assign individual blame and feed performance reviews, people rationally protect themselves by concealing problems, so the old behavior persists. Adding or tuning tools cannot override those incentives.

Question 23Understanding DevOps Culture

An executive asks how to measure cultural health rather than just delivery output. Which set of indicators best reflects DevOps culture?

  1. Total lines of code committed per sprint
  2. Count of deployments per individual engineer
  3. Psychological safety survey results, time to restore service, and share of incidents with completed learning actions Correct answer.
  4. Number of tools purchased and licenses renewed

Explanation

Cultural health shows up in how safe people feel speaking up, how quickly service is restored, and whether incidents produce completed learning actions. These indicators capture trust, resilience, and follow-through. Tool counts, per-person deployment counts, and code volume measure activity or consumption, not culture.

Question 24Understanding DevOps Culture

A team celebrates a successful release but never examines near misses. Why does this weaken DevOps culture?

  1. Celebrating releases always reduces morale
  2. Near misses should only be reviewed by external auditors
  3. Near misses reveal latent weaknesses that, if ignored, tend to reappear as real incidents Correct answer.
  4. Near misses are irrelevant because no harm occurred

Explanation

Near misses expose the same latent conditions that produce incidents, just without the harm, so they are cheap learning opportunities. Ignoring them lets those conditions persist until they cause a real failure. Treating them as irrelevant wastes the safest chance to improve.

Question 25Understanding DevOps Culture

A platform team builds self-service tooling but requires a ticket for every environment change. How does this affect the cultural goal of autonomy?

  1. It has no effect on autonomy because tickets are automated
  2. It fully realizes autonomy because tooling exists
  3. It improves autonomy by centralizing decisions
  4. It preserves a hidden handoff and dependency that limits developer autonomy Correct answer.

Explanation

Autonomy requires that teams can act on their own without waiting for another group's permission. A ticket for every environment change is a handoff that reintroduces dependency and queue time, even if tooling exists. Self-service means the capability is available directly, not gated behind requests.

Question 26Understanding DevOps Culture

In DevOps culture, what does the term 'Westrum organizational culture' primarily describe?

  1. The typology of organizational cultures-pathological, bureaucratic, and generative-and how each shapes information flow Correct answer.
  2. The financial model used to justify platform engineering investments
  3. The maturity ladder that teams climb by increasing deployment frequency
  4. The sequence of tooling layers an organization must adopt to reach continuous delivery

Explanation

Westrum's research classifies organizations by how they handle information: pathological cultures hoard it out of fear, bureaucratic cultures route it through rigid channels, and generative cultures surface it freely. DevOps research later connected generative culture traits to higher software delivery performance, which is why the model is used to diagnose culture rather than tooling.

Question 27Understanding DevOps Culture

A team's manager privately tells one engineer that incident reports should avoid naming anyone so the team looks good in executive reviews. Which cultural problem does this create most directly?

  1. It strengthens shared ownership because the whole team is credited for the incident
  2. It speeds up incident resolution by reducing discussion of individual actions
  3. It improves psychological safety because fewer people are mentioned by name
  4. It converts a learning practice into impression management, so the organization loses accurate risk signals Correct answer.

Explanation

Blameless postmortems exist so that people report what actually happened, including individual actions, without fear of punishment. Suppressing names to protect appearances shifts the purpose from learning to reputation management, and executives then make decisions on sanitized information. That erodes the trust and transparency a generative culture depends on.

Question 28Understanding DevOps Culture

An organization wants to reduce handoffs between development and operations without reorganizing teams. Which cultural practice most directly supports this goal?

  1. Requiring operations to sign off on every production change
  2. Measuring development on feature output and operations on uptime separately
  3. Creating a separate release management group to coordinate deployments
  4. Embedding operations engineers into product teams so they share on-call and delivery goals Correct answer.

Explanation

Handoffs shrink when the people who build a service and the people who run it share the same goals, context, and accountability. Embedding operations expertise in the product team and sharing on-call does that without a full reorganization. The other options add approval steps or split metrics, which reinforce the boundary.

Question 29Understanding DevOps Culture

A leadership team wants to know whether its DevOps culture is genuinely improving. Which evidence set best indicates cultural health rather than only tooling adoption?

  1. The count of approved change requests and the average number of sign-offs per release
  2. The number of pipeline tools deployed and the percentage of repositories with CI configured
  3. Rising deployment frequency alongside rising incident reporting, faster restoration, and staff reporting they can raise concerns without retaliation Correct answer.
  4. Growth in the platform team's headcount and the volume of tickets it resolves per sprint

Explanation

Cultural health shows up in both delivery outcomes and the willingness of people to surface problems. Rising deployment frequency combined with more incident reporting and faster restoration suggests teams are learning rather than hiding failures, and self-reported ability to raise concerns measures psychological safety directly. Tool counts and ticket volumes only show activity, not whether information flows honestly.

Question 30Introduction to DevSecOps

In the DevSecOps model, at which point in the delivery lifecycle should security activities first be introduced?

  1. During requirements and design, before code is written Correct answer.
  2. After production monitoring shows anomalous traffic
  3. After the first penetration test of the release candidate
  4. At the change advisory board review before deployment

Explanation

DevSecOps shifts security left, meaning threat modeling, security requirements, and risk assessment begin during planning and design rather than after code exists. Introducing controls only at test or deployment gates leaves design flaws to be discovered late, when remediation is far more expensive.

Question 31Introduction to DevSecOps

Which practice best describes security as code?

  1. Expressing security controls and checks as versioned, executable artifacts Correct answer.
  2. Hiring a security team that reviews every pull request by hand
  3. Documenting security policy in a wiki that engineers read manually
  4. Running an annual penetration test against the production estate

Explanation

Security as code means policies, guardrails, and compliance checks are defined in machine-readable, version-controlled form and executed automatically in pipelines. This makes controls repeatable, auditable, and reviewable through the same change process as application code.

Question 32Introduction to DevSecOps

A team automates dependency vulnerability scanning so that every pull request fails if a critical CVE is introduced. Which DevSecOps outcome does this primarily demonstrate?

  1. Elimination of the need for any manual security review
  2. Guaranteed compliance with every regulatory framework
  3. Replacement of the incident response process
  4. Reduced mean time to detect through continuous automated checks Correct answer.

Explanation

Automated scanning on every pull request provides continuous, fast feedback so vulnerable components are caught within minutes of introduction. This shortens detection time, which is a core DevSecOps goal of building security feedback into the normal developer workflow.

Question 33Introduction to DevSecOps

What is the primary purpose of a threat model created during design?

  1. To record the results of the last penetration test
  2. To identify plausible threats and agree on mitigations before implementation Correct answer.
  3. To list the credentials stored in the continuous integration system
  4. To enumerate every line of code that handles user input

Explanation

Threat modeling systematically examines a design to find where trust boundaries, data flows, and assets could be attacked, so mitigations can be chosen early. It is an analysis activity, not an inventory of code lines or test results.

Question 34Introduction to DevSecOps

Which statement correctly distinguishes DevSecOps from simply adding a security review stage before release?

  1. DevSecOps integrates security continuously across the whole pipeline and culture Correct answer.
  2. DevSecOps requires freezing code for a security hardening sprint
  3. DevSecOps removes the need for any security specialists on the team
  4. DevSecOps limits security responsibility to a central compliance group

Explanation

DevSecOps distributes security practices throughout planning, coding, building, testing, and operating, supported by shared ownership and automation. A single pre-release review is a gate, not continuous integration of security into the delivery flow.

Question 35Introduction to DevSecOps

In the CALMS framing often used to describe DevOps culture, which element most directly supports DevSecOps adoption?

  1. Sharing of responsibility and knowledge across development, security, and operations Correct answer.
  2. Lean flow of small batches through the delivery pipeline
  3. Measurement of deployment frequency and change failure rate
  4. Automation of every manual approval step

Explanation

CALMS stands for Culture, Automation, Lean, Measurement, and Sharing. The culture and sharing elements underpin DevSecOps because security becomes a shared responsibility rather than an external gatekeeping function.

Question 36Introduction to DevSecOps

A pipeline stores a container registry token as a masked variable in the CI system. Which principle does this most directly satisfy?

  1. Applying immutable infrastructure for build agents
  2. Signing commits with developer GPG keys
  3. Keeping secrets out of source code and build logs Correct answer.
  4. Enforcing least privilege on the artifact repository

Explanation

Storing credentials in a managed secret store with masking keeps them out of repositories and log output, reducing accidental disclosure. Least privilege concerns the scope of permissions granted, which is a related but separate control.

Question 37Introduction to DevSecOps

Which metric is most characteristic of a DevSecOps measurement program?

  1. Count of firewall rules reviewed per quarter
  2. Percentage of pipelines with automated security tests enabled Correct answer.
  3. Total hours spent in annual security awareness training
  4. Number of pages in the security policy document

Explanation

DevSecOps measurement focuses on adoption and effectiveness of automated controls in the delivery flow, such as how many pipelines run security tests. Document length, rule counts, and training hours are activity indicators that do not show whether security is embedded in delivery.

Question 38Introduction to DevSecOps

An organization wants developers to receive vulnerability feedback within minutes of pushing code. Which combination of practices best achieves this?

  1. Nightly full-repository scans reported to the security team by email
  2. Pre-commit and pipeline-integrated scanning with results surfaced in the pull request Correct answer.
  3. Annual red team exercises with executive debriefs
  4. Quarterly third-party assessments with a written report

Explanation

Fast feedback requires checks that run at commit and pipeline time and report directly where developers work, such as the pull request. Nightly, quarterly, and annual activities produce delayed feedback that is disconnected from the change being made.

Question 39Introduction to DevSecOps

A team adopts infrastructure as code for cloud environments. Which security benefit follows most directly?

  1. Encryption keys are automatically rotated by the version control system
  2. Configuration can be reviewed, tested, and scanned before it is applied Correct answer.
  3. Network segmentation is no longer required in the cloud account
  4. Runtime attacks become impossible because infrastructure is declared

Explanation

When infrastructure is declared in code, misconfigurations can be detected by static analysis and peer review before deployment, and changes are auditable. It does not eliminate runtime threats, manage key rotation, or remove the need for segmentation.

Question 40Introduction to DevSecOps

During threat modeling of a web application, the team identifies a trust boundary between the browser and the API gateway. What is the most appropriate next step?

  1. Assume the boundary is secure because TLS is enabled
  2. Defer the analysis until penetration testing begins
  3. Remove the boundary by merging the browser and API into one component
  4. Analyze threats that cross the boundary and define mitigations such as input validation and authentication Correct answer.

Explanation

Trust boundaries are where data crosses between components with different privilege or trust levels, so they concentrate risk. The methodical response is to enumerate threats crossing each boundary and agree on controls like authentication, authorization, and validation.

Question 41Introduction to DevSecOps

A security champion program is being introduced. Which description best matches the role?

  1. An external consultant engaged for annual assessments
  2. A tool administrator who only manages scanner licenses
  3. A developer who advocates secure practices within their team and liaises with security specialists Correct answer.
  4. A dedicated auditor who signs off every release

Explanation

Security champions are embedded practitioners, usually developers, who raise security awareness, review early designs, and act as a bridge to the central security function. They scale security expertise without creating a blocking gate.

Question 42Introduction to DevSecOps

Which control best reduces the risk of a compromised build agent tampering with artifacts?

  1. Disabling build logs to avoid leaking information
  2. Running builds on the developer's laptop
  3. Increasing the build agent's CPU allocation
  4. Signing artifacts and verifying signatures before deployment Correct answer.

Explanation

Artifact signing creates cryptographic evidence of provenance, and verification at deployment rejects anything modified after the trusted build. This directly addresses tampering between build and release.

Question 43Introduction to DevSecOps

A team wants to enforce that no container image with a known critical vulnerability reaches production. Which control implements this most reliably?

  1. A wiki page listing approved base images
  2. A manual checklist completed by the release manager
  3. A weekly report emailed to engineering managers
  4. A policy gate in the deployment pipeline that blocks images failing the vulnerability threshold Correct answer.

Explanation

An automated policy gate evaluates the scan result at deployment time and blocks noncompliant images consistently. Reports, documentation, and manual checklists rely on human follow-through and do not reliably prevent deployment.

Question 44Introduction to DevSecOps

Which situation best illustrates the shared responsibility model relevant to DevSecOps in cloud environments?

  1. The provider secures physical facilities while the customer secures identity and data configuration Correct answer.
  2. The customer is responsible for hypervisor patching in all service models
  3. The provider is responsible for all application vulnerabilities
  4. Both parties share equal responsibility for every layer of the stack

Explanation

Cloud shared responsibility splits duties by layer and service model: providers handle facilities and underlying infrastructure, while customers secure their identities, configurations, and data. DevSecOps practices concentrate on the customer-controlled layers.

Question 45Introduction to DevSecOps

What is the main purpose of running dynamic application security testing against a deployed staging environment?

  1. To confirm that dependency versions match the lock file
  2. To detect runtime behavior such as injection and authentication flaws by exercising the running application Correct answer.
  3. To verify that source code follows naming conventions
  4. To measure code coverage of unit tests

Explanation

Dynamic testing attacks a running instance and observes responses, which reveals exploitable behavior like injection and broken authentication. Static checks and dependency comparison analyze code or metadata rather than runtime behavior.

Question 46Introduction to DevSecOps

A pipeline runs a static analysis tool that reports 400 findings, mostly low severity, and developers stop reading the output. Which adjustment best restores the value of the control?

  1. Tune rules and set a blocking threshold for high-severity findings while triaging the rest Correct answer.
  2. Require every finding to be fixed before any merge
  3. Route all findings to the security team for manual review
  4. Disable the tool to remove noise from the pipeline

Explanation

Alert fatigue undermines a control because real issues get lost in noise. Tuning rules and blocking only on high-severity findings, with a triage process for the remainder, keeps the signal actionable and preserves developer trust.

Question 47Introduction to DevSecOps

Which artifact provides verifiable evidence that a build was produced from a specific source revision by a trusted pipeline?

  1. A signed software bill of materials with provenance attestation Correct answer.
  2. A changelog entry written by the release manager
  3. A tag applied manually to the container image
  4. A screenshot of the successful pipeline run

Explanation

Provenance attestations bind an artifact to its source revision and build process, and signing makes the claim tamper-evident. A software bill of materials adds the component inventory needed to assess what went into the artifact.

Question 48Introduction to DevSecOps

A regulated firm must show auditors that every production change was reviewed and tested. Which DevSecOps capability most directly provides this evidence?

  1. Immutable audit logs of pipeline events tied to commits and approvals Correct answer.
  2. A verbal briefing to the audit committee
  3. An annual self-assessment questionnaire
  4. A screenshot of the team's kanban board

Explanation

Immutable pipeline logs record who approved what, which commit was built, and which tests passed, creating traceable evidence for each change. This turns compliance evidence into a byproduct of normal delivery rather than a separate manual exercise.

Question 49Introduction to DevSecOps

Which approach best balances developer velocity with security assurance when introducing a new scanning tool across many teams?

  1. Deploy the tool only in the security team's own repositories
  2. Let each team decide independently whether to adopt it
  3. Mandate the tool on all repositories on the same day with blocking enabled
  4. Pilot with one team, measure false positives, then roll out with documented thresholds Correct answer.

Explanation

A pilot surfaces false positive rates and workflow friction before the control becomes mandatory, allowing thresholds and guidance to be tuned. This reduces the risk of alert fatigue and resistance during wider adoption.

Question 50Introduction to DevSecOps

A developer bypasses a failing security check by adding an inline suppression comment with no justification. Which control most effectively addresses this behavior?

  1. Requiring suppressions to include a reason, an expiry date, and a named approver Correct answer.
  2. Increasing the severity threshold so checks fail less often
  3. Removing the check from the pipeline for that repository
  4. Sending a monthly reminder email about the policy

Explanation

Structured suppressions create accountability: a reason documents the risk decision, an expiry forces periodic re-evaluation, and an approver ensures a second party accepts the risk. This preserves the control while allowing legitimate exceptions.