Continuous Delivery Architecture common mistakes
Continuous Delivery Architecture · Understand the traps and how to avoid them.
Treating the deployment pipeline as a single linear path from commit to production and drawing every stage in sequence, even when the scenario describes parallel test suites, fan-out/fan-in, or manual gates on a separate branch of the flow.
Candidates memorize the canonical commit-stage-to-production diagram and then apply it mechanically; the exam often tests whether they can reason about orchestration semantics (parallelism, fan-in, approval gates, promotion criteria) rather than recite the diagram.
What to do instead
Before answering, identify the trigger, the fan-out points, the fan-in/aggregation point, and where promotion decisions happen. Practice sketching pipelines where stages run concurrently and where a manual approval blocks only one branch, then state explicitly which stage gates which downstream stage.
Classifying a whole repository as 'trunk-based' or 'GitFlow' based on branch names alone, without checking integration frequency, branch lifetime, or whether the mainline is always releasable.
Branching-strategy questions look like vocabulary matching, so candidates pattern-match on terms like 'feature branch' or 'release branch' and ignore the behavioural signals the stem provides (short-lived branches, daily merges, release from mainline).
What to do instead
Judge by behaviour: how long branches live, how often they merge back, whether releases are cut from mainline or a stabilization branch, and whether the mainline is continuously integrable. Map the described behaviour to the strategy, not the label.
Assuming dependency version pinning alone guarantees reproducible builds, ignoring transitive dependencies, lockfiles, and the package repository's mutation or availability risk.
Pinning direct dependencies feels like the complete answer, so candidates stop there and miss that unpinned transitive graphs, missing lockfiles, or a mutable upstream registry still break reproducibility.
What to do instead
For reproducibility questions, verify all four: pinned direct versions, a committed lockfile covering the transitive graph, an internal/immutable artifact repository or mirror, and checksum verification. If any is absent, that is the gap the question is probing.
Treating test automation as a coverage percentage target and recommending 'more tests' or 'raise coverage' when the scenario describes slow feedback, flaky suites, or tests that pass locally but fail in the pipeline.
Coverage is the most familiar metric, so it becomes the default remedy; candidates skip the test-pyramid and feedback-latency reasoning the exam is actually testing.
What to do instead
Diagnose by feedback stage: are unit tests fast and isolated, are integration tests environment-dependent, are end-to-end tests overused for logic that unit tests could cover? Recommend rebalancing the suite and quarantining flaky tests rather than adding volume, and tie each recommendation to a pipeline stage.
Describing infrastructure as code as 'write Terraform and commit it' without addressing state management, drift detection, idempotency, or how the same code produces identical environments across stages.
The tool name substitutes for the concept; candidates recall that IaC means declarative provisioning and stop before the operational properties that make it safe (remote state, locking, plan/apply separation, drift reconciliation).
What to do instead
For any IaC question, check for remote shared state with locking, a plan-review step before apply, environment parity via parameterization not copy-paste, and a drift-detection mechanism. If the stem omits one of these, that omission is usually the answer.
Confusing blue-green with canary and recommending the wrong one: proposing blue-green when the requirement is gradual traffic shifting with automatic rollback on error-rate thresholds, or canary when the requirement is instant full cutover with a standby environment.
Both are 'safe release' patterns and share vocabulary (traffic, rollback, old version), so candidates pick whichever they remember first instead of matching the pattern to the stated risk and rollback requirement.
What to do instead
Anchor on the decision criteria: blue-green swaps entire environments and gives instant rollback but doubles infrastructure; canary shifts a percentage of traffic and needs metric-based promotion. Read the stem for 'percentage of users', 'error-rate threshold', or 'instant switch' and choose accordingly.
Storing secrets in the same mechanism as ordinary configuration (config maps, environment variables committed to the repo, or plain CI variables) and calling it 'externalized configuration'.
Externalization and secret management get conflated because both move values out of code; candidates miss the distinct requirements for secrets: encryption at rest, access auditing, rotation, and injection at runtime rather than build time.
What to do instead
Separate the two explicitly: non-sensitive config in versioned parameter stores or config services; secrets in a dedicated vault or secrets manager with short-lived credentials, audit logging, rotation, and runtime injection. When a stem shows secrets in env vars or CI settings, name that as the defect.
Treating database migrations as a deploy-time step that can be rolled back like code, and recommending a single 'migrate then deploy' step without addressing backward compatibility during the transition.
Application rollback intuition is carried over to schema changes, but schemas and data are stateful and often irreversible; candidates overlook the expand/contract (parallel change) approach that keeps old and new code working simultaneously.
What to do instead
For any schema change, apply expand/contract: add the new structure compatibly, deploy code that writes both or reads tolerantly, backfill, then remove the old structure in a later release. Explicitly state that destructive changes are decoupled from the code deploy and are not rolled back by redeploying.
Answering observability questions with 'add logging and monitoring' without distinguishing the three pillars or specifying what signal drives which decision (deployment health, SLO burn, root cause).
Logging and monitoring are the familiar terms; candidates do not separate metrics for alerting and SLOs, traces for latency attribution across services, and logs for detailed diagnosis, so the answer stays generic.
What to do instead
Map signal to purpose: metrics and SLO burn rates for alerting and automated rollback gates; distributed traces for locating latency and failure across service boundaries; structured logs for forensic detail. In pipeline contexts, tie deployment health checks to the specific metric that would trigger rollback.
Treating governance as a manual approval gate inserted before production, and recommending more approvals when the scenario asks how to increase release frequency without losing control.
Approval gates are the visible form of control, so candidates equate governance with sign-off; they miss that automated policy checks, audit trails from the pipeline, and deployment frequency/change-failure metrics provide control without serializing delivery.
What to do instead
Replace manual gates with automated, auditable checks where the decision is rule-based (policy as code, security scans, change records generated by the pipeline), and reserve human approval for genuinely judgment-based risks. Support the recommendation with DORA-style metrics and traceability from commit to deployment.