ECDE common mistakes
ECDE · Understand the traps and how to avoid them.
Treating DevOps as a toolchain answer: when asked what DevOps is, listing Jenkins, Docker, Kubernetes, and Git as the definition, then failing scenario items that ask why a team's DevOps adoption stalled despite having those tools installed.
Candidates memorize product names from blog posts and vendor marketing instead of the underlying principles (shared ownership, flow, feedback, continuous learning), so they cannot diagnose culture problems described in a scenario.
What to do instead
Learn the CALMS framing and the Three Ways (flow, feedback, continual experimentation) as the primary definition, and practice classifying each tool as an enabler of a principle rather than the principle itself. For any scenario, first ask which principle is missing, then which practice or tool would support it.
Confusing DevOps with DevSecOps by claiming DevOps already includes security, so nothing changes, and then answering DevSecOps items with pure CI/CD answers that omit shifting left, threat modeling, or automated security gates.
The two terms overlap heavily in practice, and candidates collapse them into one concept, missing the exam's focus on how security is embedded rather than bolted on.
What to do instead
Hold the distinction explicitly: DevOps optimizes delivery flow and feedback; DevSecOps adds security as a shared, continuous, automated responsibility across the same flow. For DevSecOps questions, always name the security activity, who owns it, and where in the pipeline it runs.
Answering 'shift left' as simply 'test earlier' and then failing items that ask what shifting security left actually requires, such as threat modeling during design, secure coding standards, pre-commit hooks, and developer security training.
Shift left is repeated so often that candidates stop at the slogan and never learn the concrete practices that make it real, so they cannot map it to plan-stage and code-stage activities.
What to do instead
Build a mental list of shift-left practices per stage: design (threat modeling, security requirements, abuse cases), code (SAST in IDE, secret scanning, peer review checklists), build (SCA, container scanning). When a question asks how to shift left, pick the earliest-stage activity that prevents the defect rather than one that detects it later.
Treating the plan stage as pure project administration and ignoring risk and compliance artifacts, so questions about defining security acceptance criteria, data classification, or regulatory requirements at planning time are answered with scheduling or backlog grooming options.
Candidates associate planning with Agile ceremonies and forget that the plan stage is where security requirements, threat models, and compliance obligations must be captured before any code exists.
What to do instead
Study the plan stage as requirements plus risk: security user stories, acceptance criteria with measurable security thresholds, threat modeling, privacy impact assessment, and definition of done that includes security checks. Practice writing a security requirement that is testable, since exam items often hinge on whether a criterion can be verified.
Recommending secrets be stored in the repository 'but encrypted' or in environment variables committed to a config file, rather than in a secrets manager with rotation and least-privilege access.
Candidates know hardcoded secrets are bad but reach for the nearest familiar workaround, missing that encrypted-in-repo and committed-config patterns still leak through history and lack rotation.
What to do instead
Memorize the correct pattern: dedicated secrets management (vault-style store or cloud secrets service), short-lived credentials or dynamic secrets where possible, automatic rotation, audit logging, and pre-commit plus pipeline secret scanning to catch leaks before merge. When an option keeps the secret in version control in any form, eliminate it.
Choosing 'run a full static analysis scan on every commit with a zero-tolerance block' as the ideal gate, then missing that the scenario's complaint is developer friction and abandoned pipelines.
Candidates equate stricter gates with better security and ignore the feedback-loop and false-positive tradeoffs the scenario is testing.
What to do instead
Learn the gate design tradeoffs: fast, high-signal checks on every commit; heavier scans on pull requests or nightly; severity thresholds that block only on critical findings; triage and suppression workflows for false positives. Match gate strictness to the stage and to the scenario's stated pain point.
Confusing SAST, DAST, SCA, and container image scanning, for example answering a question about vulnerable third-party libraries with a static analysis tool or vice versa.
The acronyms are learned as a list of 'security testing' without attaching each to its input artifact and the class of defect it finds.
What to do instead
Anchor each technique to its artifact and finding type: SAST reads your source code for coding flaws; SCA reads dependency manifests and lockfiles for known vulnerable components and license issues; DAST probes a running application for runtime weaknesses; image scanning inspects OS packages and layers in a built image. Practice classifying a given finding into the tool that would have caught it.
Assuming a green build means a releasable artifact, and answering release-stage questions without artifact versioning, immutable artifacts, provenance, or promotion through environments.
Candidates conflate 'tests passed' with 'this exact binary is what we ship', missing that rebuilds between stages create drift and break traceability.
What to do instead
Study build-once-promote-many: one immutable artifact with a content hash or semantic version, stored in an artifact repository, promoted unchanged through staging to production, with signed provenance or attestations. When a scenario shows different results in staging and production, suspect artifact drift first.
Describing deployment strategies incorrectly, such as calling a canary release a blue-green deployment, or recommending a big-bang cutover when the scenario demands the ability to roll back quickly with minimal blast radius.
The strategies are learned as vocabulary rather than as risk profiles, so candidates cannot match the strategy to the scenario's tolerance for exposure and rollback speed.
What to do instead
Learn each strategy by its exposure and rollback characteristics: blue-green switches traffic between two full environments for instant rollback at double cost; canary routes a small percentage of traffic and expands on health metrics; rolling replaces instances gradually with mixed versions; feature flags decouple release from deploy. Choose based on blast radius tolerance, infrastructure cost, and rollback requirement stated in the scenario.
Treating operate-and-monitor as 'install dashboards and alerting' and failing items on observability, SLOs, error budgets, and blameless postmortems, or proposing to punish the engineer who caused an incident.
Candidates default to tooling answers and to a traditional blame culture, missing that the operate stage tests feedback loops, service level objectives, and learning from failure.
What to do instead
Study the three pillars (logs, metrics, traces) plus the purpose of each, the difference between SLI, SLO, and SLA, how error budgets govern release velocity, and the mechanics of blameless postmortems that produce actionable follow-ups. For any incident scenario, prefer options that restore service first, then investigate causes and improve detection.