14. Applied DevOps Capstone ImplementationIntroduction and ContextA DevOps capstone is not merely a software project with a deployment pipeline attached to it. It is an integrated demonstration that a team can convert a business need into a reliable, secure, observable, and maintainable digital service. The capstone brings together requirements engineering, architecture, version control, automated testing, continuous integration and delivery, infrastructure automation, deployment, monitoring, security, documentation, and evidence-based improvement. In earlier study, these capabilities may be examined separately. Industry practice, however, evaluates them as a system. A technically elegant application may still fail if it cannot be deployed repeatedly. A fast pipeline may be unacceptable if it releases insecure code. A cloud environment may be well provisioned but operationally weak if no one can detect or diagnose failure. The capstone therefore tests both technical competence and professional judgment. This chapter presents a practical framework for designing and executing such a project. The discussion uses an illustrative case: a university service-request platform through which students submit requests, staff manage them, and administrators review service performance. The example is fictional, but the design principles apply to commercial, public-sector, and internal enterprise systems. Learning ObjectivesBy the end of this chapter, students should be able to: 1. Translate stakeholder needs into measurable requirements and acceptance criteria. 2. Design an architecture that balances delivery speed, reliability, security, cost, and maintainability. 3. Establish repository, branching, testing, and code-quality practices suitable for collaborative development. 4. Build a CI/CD workflow with appropriate quality and security gates. 5. Provision infrastructure as code and deploy an application using controlled, reversible methods. 6. Design observability around service-level indicators, operational diagnosis, and user impact. 7. Produce evidence that demonstrates improvement rather than merely claiming success. 8. Evaluate risks, governance obligations, ethical concerns, and trade-offs in a capstone implementation. From Business Need to an Executable ProductThe first capstone decision is defining what will be delivered. Teams often begin with technologies—containers, Kubernetes, a cloud provider, or a particular pipeline tool—before establishing the problem. This reverses the proper sequence. Technology should implement a service objective, not become the objective itself. A useful project charter identifies the users, business problem, intended outcome, scope, constraints, assumptions, and measures of success. For the service-request platform, the product objective might be: “Enable students to submit and track service requests while allowing staff to manage requests within agreed response targets.” The objective is more useful than a statement such as “build a web application,” because it creates a basis for prioritization and evaluation. Requirements should be expressed as outcomes and testable behaviours. A functional requirement may state that a student can submit a request with a category, description, and attachment. A non-functional requirement may specify that 95 percent of normal requests receive an initial response within two seconds under the defined test load. Acceptance criteria convert broad requirements into observable conditions. For example, a request is accepted only when mandatory fields are valid, the requester is authenticated, the request receives a unique identifier, and the user receives confirmation. The distinction between a minimum viable product and an expanded product is important. A capstone should have a deliberately limited first release. Authentication, request submission, staff status updates, audit history, and basic reporting may constitute the minimum viable product. Sophisticated analytics, mobile applications, or automated classification can remain later increments. Limiting scope improves the credibility of the delivery evidence. A product backlog should contain small vertical slices rather than technical fragments alone. “Create database table” is a technical task; “staff can change a request from open to in progress and the requester can see the change” is a user-visible increment. Each item should include acceptance criteria, dependencies, risk, and a definition of done. The definition of done may include peer review, automated tests, security checks, documentation, and deployment to a test environment. Architecture as a Set of Explicit DecisionsArchitecture is the arrangement of components and the reasoning behind their relationships. A capstone architecture should be simple enough to operate and sophisticated enough to demonstrate sound engineering. For the illustrative platform, a modular web application may contain a browser client, an application API, a relational database, object storage for attachments, an identity provider, and an observability stack. A reverse proxy or managed load balancer can terminate TLS and route traffic to the application. A modular monolith is often a rational capstone choice. It allows independent domain modules, such as identity, requests, notifications, and reporting, while avoiding the operational overhead of multiple microservices. Microservices become defensible when independent scaling, deployment autonomy, team boundaries, or technology requirements justify them. Splitting a small application into services merely to appear advanced increases network failure modes, deployment complexity, and diagnostic effort. Architecture decisions should be recorded in concise architecture decision records. An ADR states the context, decision, alternatives considered, consequences, and conditions for revisiting the decision. For example, an ADR may select PostgreSQL rather than a document database because the domain requires relationships, transactional status changes, and reporting queries. The decision is not universally correct; it is correct relative to the requirements and operating constraints. A useful design review considers several quality attributes: - Reliability: Can the service continue or recover when a component fails?
- Security: Are identity, authorization, secrets, data protection, and auditability addressed?
- Performance: Are latency, throughput, and resource limits understood?
- Maintainability: Can another team understand, test, change, and operate the system?
- Scalability: Can capacity increase without disproportionate redesign?
- Cost efficiency: Is the architecture proportionate to expected value and usage?
Architecture diagrams should show users, trust boundaries, data flows, deployment units, and external dependencies. They should be supported by a deployment diagram and a data model. A diagram without explanatory decisions is decoration; a decision without a diagram is difficult to communicate. Repositories, Collaboration, and the Traceability ChainThe repository is the primary record of how the product was built. A professional capstone normally separates application source code, infrastructure code, and operational documentation, either into distinct repositories or clearly governed directories. The choice should reflect team scale and release coupling. A single repository can be effective for a small product if ownership, pipeline boundaries, and directory conventions are clear. The repository should contain source code, tests, configuration templates, database migration scripts, container definitions, infrastructure modules, pipeline definitions, runbooks, ADRs, and a meaningful README. Secrets must never be committed. Environment-specific values should be injected through a secret manager or protected pipeline variables, while safe example configuration is documented separately. Branching strategy should reduce integration delay. Trunk-based development with short-lived branches and frequent pull requests is often suitable for a capstone. Protected main branches, mandatory reviews, automated checks, and signed or traceable releases create useful controls. A branch model is not a substitute for integration discipline: long-lived branches conceal conflicts and postpone testing. Traceability connects a requirement to a backlog item, code change, test, deployment, and operational result. Issue identifiers in pull requests and commits make this chain visible. Traceability is valuable in regulated settings, but it also helps a student team prove what changed and why. The objective is not bureaucratic record keeping; it is recoverable reasoning. Testing as a Risk-Based Design ActivityTesting should be planned according to failure consequences, not simply divided into arbitrary percentages. Unit tests examine isolated logic and should be fast enough to run on every change. Integration tests verify boundaries such as the API and database. Contract tests help ensure that a client and service agree on request and response formats. End-to-end tests validate critical user journeys, but they are more expensive and potentially less stable. For the service-request platform, a sensible test portfolio might verify request validation at unit level, persistence and authorization at integration level, and the complete submission-and-status journey at end-to-end level. Negative tests are essential: unauthorized access, malformed input, duplicate submissions, oversized attachments, and invalid status transitions should be considered explicitly. Quality is broader than functional correctness. Static analysis can detect code smells and insecure patterns. Dependency scanning identifies vulnerable libraries, while secret scanning helps prevent credential exposure. Container image scanning and infrastructure configuration analysis extend testing beyond application code. These tools produce signals rather than absolute proof; teams must define severity thresholds and an exception process. Test data must be repeatable and safe. Production personal information should not be copied into development environments without lawful justification, controls, and masking. Database migrations should be tested from a clean state and, where relevant, from a representative prior version. Flaky tests should be investigated rather than routinely retried until they pass, because silent retries reduce trust in the pipeline. Constructing the Delivery PipelineContinuous integration begins when a change is submitted. A representative pipeline sequence is: 1. Validate formatting and repository policy. 2. Install dependencies from controlled sources. 3. Run unit tests and static analysis. 4. Build a versioned artifact or container image. 5. Execute dependency, secret, and image security scans. 6. Run integration tests using ephemeral or isolated services. 7. Publish the immutable artifact to a registry. 8. Deploy the same artifact to a test or staging environment. 9. Run smoke, contract, and selected end-to-end tests. 10. Obtain approval or satisfy an automated release policy for production. The principle of artifact promotion is important. The artifact tested in staging should be the artifact deployed to production; rebuilding from the same source later can produce a different result because dependencies, base images, or build tools may have changed. Version identifiers should be visible in the application and deployment records. Continuous delivery means the system is kept in a releasable state. Continuous deployment goes further by automatically releasing changes that pass policy. Neither is inherently superior. A low-risk service with strong automated tests may use automatic production deployment, whereas a system involving sensitive records may require human approval, scheduled release windows, or additional evidence. Pipeline stages should fail for meaningful reasons. A pipeline that blocks every minor warning will be bypassed; one that ignores critical vulnerabilities creates false confidence. Policies should specify which findings are blocking, who may approve exceptions, how long exceptions remain valid, and what compensating controls apply. Deployment credentials should be short-lived and scoped to the required environment. Pipeline logs must avoid printing secrets. Infrastructure and Deployment EngineeringInfrastructure as code expresses environments in version-controlled, reviewable configuration. It can provision networks, identity roles, databases, compute resources, storage, DNS, monitoring, and policies. Declarative tools provide a desired-state model, but they do not remove the need to understand dependencies, state management, drift, and destructive changes. A safe infrastructure workflow separates planning from application. A pull request should display the proposed infrastructure changes before approval. State should be protected against accidental deletion and concurrent modification. Production access should be restricted, and the pipeline identity should have only the permissions required for its actions. Environment consistency is a major concern. Development, test, and production need not have identical size or cost, but they should share relevant configuration patterns and deployment mechanisms. Configuration should be externalized, validated, and classified. Feature flags can separate code deployment from feature activation, allowing a capability to be tested or withdrawn without reverting the entire release. Deployment strategy is a risk decision. A rolling deployment updates instances gradually and is efficient for compatible releases. Blue-green deployment maintains two environments and switches traffic between them, enabling rapid rollback but requiring additional capacity. Canary deployment exposes a small proportion of users to the new version and uses health and business signals to decide whether to continue. Database changes require special care: backward-compatible expansion followed by migration and later cleanup is safer than changing schema and application assumptions simultaneously. Rollback must be designed before release. It may involve restoring the previous application image, reversing a feature flag, switching traffic, or restoring data from a verified backup. Data rollback is often more difficult than code rollback, so destructive migrations and irreversible transformations deserve explicit review. Observability and Operational ReadinessObservability enables engineers to infer internal system behaviour from outputs. It is commonly organized around logs, metrics, traces, and events. Logs should be structured, timestamped, correlated with a request identifier, and free from unnecessary personal or secret data. Metrics should represent availability, latency, traffic, errors, saturation, and important business outcomes. Traces help follow a request across application and external boundaries. Monitoring asks whether a known condition has occurred; observability supports investigation of an unfamiliar condition. Both are necessary. A dashboard with dozens of charts is not automatically useful. Each alert should identify a meaningful user or service risk, include context, and have an owner and response procedure. Service-level indicators (SLIs) are measurements such as successful request proportion or latency. A service-level objective (SLO) defines the desired level over a period. An error budget represents the amount of unreliability permitted by the SLO. If a team has consumed its budget, it may pause risky feature work and prioritize reliability. The exact thresholds should be justified by user expectations and business impact rather than copied from another organization. Operational readiness includes a runbook, escalation path, dependency list, backup policy, recovery objectives, and known failure modes. Mean time to detect and mean time to restore can be useful improvement measures, but they should not encourage premature closure or conceal recurring defects. Post-incident reviews should be blameless and focus on system conditions, decision quality, and preventive action. Security, Governance, and Responsible DeliverySecurity is a lifecycle property, not a final inspection. Threat modelling can identify trust boundaries, valuable assets, abuse cases, and mitigations before implementation. For the platform, threats include account takeover, unauthorized access to requests, malicious attachments, injection, exposed credentials, and excessive staff privileges. Identity verification and authorization must be distinguished. Authentication establishes who a user is; authorization determines what that user may do. A student should access only permitted requests, while a staff member may need access limited by department. Authorization should be enforced server-side and tested with both permitted and forbidden cases. Administrative actions should be auditable without recording unnecessary sensitive content. Secure defaults include TLS, input validation, parameterized database access, dependency maintenance, rate limiting where appropriate, safe error messages, secure headers, encrypted backups, and controlled retention. Secrets should be rotated and access should be logged. Security exceptions should have an owner, expiry date, and documented rationale. Governance includes privacy, accessibility, records management, licensing, and separation of duties. A team must know what personal data it collects, why it is needed, how long it is retained, and who can access it. Accessibility should be evaluated in design and testing rather than treated as a late cosmetic adjustment. Open-source licenses must be respected, and third-party services should be assessed for contractual and operational risk. Ethical practice extends beyond compliance. A request-classification model, for example, may reproduce bias or incorrectly prioritize vulnerable users. Automated decisions should be explainable, reviewable, and overrideable when their consequences affect people. The capstone report should identify these concerns and show how they influenced design. Evidence, Measurement, and Continuous ImprovementA capstone is assessed more convincingly through evidence than through screenshots of a successful deployment. Useful evidence includes architecture decisions, commit and review history, automated test results, security scan outcomes, deployment records, infrastructure plans, dashboards, incident exercises, and before-and-after measurements. Improvement should be expressed through a baseline and a target. Suppose the initial process requires manual deployment and typically takes several hours, while the target is a repeatable deployment completed in under fifteen minutes with an auditable record. The team should define how duration is measured and distinguish pipeline time from waiting for approval. Similarly, a reduction in failed deployments should be supported by comparable release data, not by a single successful run. A balanced scorecard may include: - Delivery: lead time for change, deployment frequency, and change failure rate.
- Reliability: availability, latency, error rate, recovery time, and backup restoration result.
- Quality: defect escape rate, test stability, code review completion, and technical-debt trend.
- Security: unresolved high-severity findings, remediation time, secret exposure incidents, and access review completion.
- Product value: request completion time, user satisfaction, or adoption of key workflows.
Metrics can be gamed. A high deployment frequency is not valuable if releases are trivial or harmful. Teams should interpret measures together and explain limitations. A retrospective should identify an improvement hypothesis, implement a change, and evaluate its effect. This is more rigorous than claiming that automation is inherently beneficial. Illustrative Case Study: Campus Service Desk PlatformBackgroundNorthbridge University, a fictional institution, receives student service requests by email, telephone, and informal messaging. Staff cannot easily identify ownership or measure response performance. The proposed platform will provide a common request workflow for a pilot department. Situation and ProblemThe project team has twelve weeks, limited cloud expenditure, and four members. Stakeholders require authenticated submission, attachments, staff assignment, status tracking, notifications, and a report showing response performance. The team initially proposes five microservices and a Kubernetes cluster, but the operational burden threatens the delivery deadline. AnalysisThe highest risks are unauthorized access to student information, incomplete workflow integration, and inability to demonstrate reliable release. The team examines expected load, team capability, recovery needs, and the pilot scope. It concludes that independent service scaling is not required in the first release. It also identifies that attachment storage and notification delivery are external dependencies whose failures must be handled explicitly. Approach and SolutionThe team selects a modular monolith packaged as a container, a managed relational database, object storage for attachments, and a managed identity service. Infrastructure is defined in code. The repository uses short-lived branches and protected mainline integration. Pull requests require review, unit and integration tests, static analysis, dependency scanning, and secret scanning. The pipeline builds an immutable image, runs tests, deploys it to a temporary test environment, and executes critical end-to-end journeys. Production deployment uses an approval gate during the pilot. A feature flag controls notifications so that the core workflow can be validated even when the mail provider is unavailable. Database changes follow an expand-and-contract approach. Threat modelling identifies broken object-level authorization as a critical risk. Tests verify that one student cannot retrieve another student’s request by changing an identifier in the URL. Logs contain correlation identifiers but not request descriptions or attachment contents. Dashboards display successful request rate, latency, queue depth, notification failures, and database health. A runbook describes notification failure, database connectivity failure, rollback, and support escalation. OutcomeAt the end of the project, the team demonstrates a complete path from approved change to tested deployment and records evidence for each gate. A simulated notification outage does not prevent request submission; the system records the failure and exposes an operational alert. A deliberately introduced authorization defect is detected by an automated test before release. During the final review, stakeholders request additional reporting, but the team places it in a later backlog item because it is outside the agreed pilot objective. The result is not judged solely by the number of tools used. Its strength lies in the alignment between scope, architecture, controls, and evidence. The team can explain why it chose a modular monolith, how it protects data, how it detects failure, and how it would improve the service after pilot feedback. Learning PointsThe case illustrates that simplicity can be an advanced decision when it reduces operational risk. It also demonstrates that security tests must reflect real abuse paths, that external dependencies require failure handling, and that a capstone report should make trade-offs visible. Most importantly, delivery capability is demonstrated by a repeatable system of work rather than by a one-time manual success. Common Failure Patterns and Their RemediesA frequent mistake is tool-first design. Teams select a cloud platform, container orchestrator, and monitoring product before deciding what users need. A product charter and risk-ranked backlog correct this tendency. Another failure is treating the pipeline as a collection of commands. Without entry criteria, quality thresholds, ownership, and failure handling, automation merely accelerates inconsistency. Every gate should have a purpose and a response when it fails. Teams also overuse end-to-end testing and underinvest in fast tests. The remedy is a risk-based test portfolio with stable test data and explicit treatment of flakiness. Conversely, a large unit-test count does not prove that authorization, deployment, or recovery works; boundary and operational tests remain necessary. Manual infrastructure changes create drift and weaken reproducibility. Emergency changes may be necessary, but they should be recorded, reviewed, and reconciled with code. Similarly, dashboards without alert ownership, untested backups, unrotated credentials, and undocumented rollback procedures create the appearance of operational maturity without its substance. Finally, teams often report optimistic metrics without a baseline. Improvement claims should identify the measurement method, comparison period, confounding factors, and remaining limitations. Emerging DirectionsCapstone implementations increasingly incorporate policy as code, software supply-chain attestations, signed artifacts, and automated provenance. These practices help organizations establish where an artifact came from and whether it passed required controls. Platform engineering is also influencing DevOps practice by providing reusable deployment templates, paved paths, and self-service environments while preserving governance. Artificial intelligence can assist with test generation, code review suggestions, incident summarization, and anomaly investigation. Its output requires human verification because generated code may contain insecure assumptions, and generated explanations may be confident but wrong. AI-based operational tools should be evaluated for data exposure, bias, auditability, and the risk of automating an inappropriate decision. Progress is also visible in resilience testing, ephemeral environments, progressive delivery, and environmental efficiency. These developments do not replace fundamentals. A signed artifact, an AI assistant, or an advanced deployment controller cannot compensate for unclear requirements, weak authorization, or absent recovery procedures. Best-Practice Principles for the CapstoneA strong implementation follows several principles: begin with a measurable product outcome; keep the first release deliberately narrow; document decisions and alternatives; integrate frequently; test risk at the appropriate level; promote immutable artifacts; treat infrastructure and policy as code; design rollback and recovery before release; make observability actionable; protect personal data and secrets; assign ownership for every operational control; and report limitations honestly. The final deliverable should be reproducible by an assessor or another engineering team. It should explain how to obtain the code, configure safe prerequisites, run tests, provision a non-production environment, deploy the service, inspect its health, simulate a failure, and remove resources. Reproducibility is a practical test of whether the project has become an engineered system rather than a demonstration assembled for presentation. Chapter SummaryAn applied DevOps capstone integrates the complete product lifecycle. It begins with a measurable business objective and a risk-ranked backlog, then converts requirements into architecture, code, tests, infrastructure, and operational controls. Sound architecture is based on explicit trade-offs; a modular monolith may be preferable to microservices when scope and team capacity do not justify distributed complexity. Repositories, reviews, traceability, and automated testing establish collaborative quality. A mature CI/CD pipeline validates changes, scans for security issues, builds immutable artifacts, and promotes the same artifact through environments. Infrastructure as code, controlled configuration, deployment strategies, rollback planning, and recovery testing improve repeatability. Observability combines logs, metrics, traces, alerts, SLOs, and runbooks to make service behaviour actionable. Security, privacy, accessibility, licensing, and ethical review must be embedded throughout the lifecycle. Finally, capstone quality is demonstrated through evidence: baselines, targets, pipeline records, test results, security findings, operational exercises, and measured improvement. The central professional lesson is that DevOps is a system of decisions and feedback, not a collection of tools. Key TermsAcceptance criteria: Testable conditions that determine whether a requirement has been satisfied. Architecture decision record: A concise record of a significant technical decision, its context, alternatives, and consequences. Artifact promotion: Moving the same tested build artifact through environments rather than rebuilding it for each environment. Canary deployment: A release strategy that exposes a new version to a small proportion of traffic before wider rollout. Change failure rate: The proportion of deployments that require remediation, rollback, or emergency intervention. Continuous delivery: Maintaining software in a state that can be released reliably on demand. Continuous integration: Frequently integrating changes and automatically validating them through a shared pipeline. Definition of done: Agreed completion criteria covering implementation, quality, documentation, and operational readiness. Error budget: The acceptable amount of unreliability implied by a service-level objective. Infrastructure as code: Version-controlled, executable configuration used to provision and manage infrastructure. Immutable artifact: A versioned build output that is not modified after creation. Modular monolith: A single deployable application organized into explicit, relatively independent modules. Observability: The ability to understand internal system behaviour from externally produced telemetry. Progressive delivery: Gradually exposing a change while using evidence to determine whether rollout should continue. Service-level indicator: A quantitative measurement of a service characteristic, such as latency or success rate. Service-level objective: A target value or range for a service-level indicator over a defined period. Software supply chain: The people, processes, tools, dependencies, and artifacts involved in producing software. Threat modelling: Structured identification of assets, threats, attack paths, and mitigations. Traceability: The ability to connect requirements, changes, tests, deployments, and operational evidence. Trunk-based development: A collaboration approach based on frequent integration into a shared mainline through short-lived branches. Review QuestionsShort Answer Questions1. Why should a capstone begin with a product outcome rather than a technology choice? 2. What is the difference between authentication and authorization? 3. Define artifact promotion and explain its value. 4. What information should an architecture decision record contain? 5. Why are logs, metrics, and traces each useful in observability? Long Answer Questions1. Explain how requirements, acceptance criteria, backlog items, and the definition of done form a delivery control system. 2. Discuss the circumstances in which a modular monolith may be preferable to microservices in a postgraduate DevOps capstone. 3. Design a CI/CD pipeline for a service-request platform, identifying quality, security, and approval gates. 4. Explain how infrastructure as code, deployment strategy, rollback, and database migration planning contribute to release reliability. 5. Discuss the role of governance, privacy, ethical review, and security throughout the DevOps lifecycle. Analytical / Application Questions1. A team has frequent successful deployments but a high rate of production incidents. Which evidence would you examine, and what changes would you propose? 2. A new release changes both the application and database schema, and rollback is required after deployment. Analyse the risks and recommend a safer migration and release approach. 3. Design a measurement plan to demonstrate that a capstone improved delivery performance and operational reliability. Specify baselines, metrics, evidence sources, and limitations. 22. Multiple Choice Questions with AnswersQuestion 1A capstone team is deciding between five microservices and a modular monolith for a small pilot with limited operational capacity. Which consideration most strongly supports the modular monolith? A. It eliminates the need for automated testing. B. It reduces distributed-system complexity when independent scaling is not required. C. It guarantees higher performance under every workload. D. It prevents all future architectural change. Correct Answer: B. It reduces distributed-system complexity when independent scaling is not required. Question 2Which practice best demonstrates artifact promotion? A. Rebuilding the application separately for production using the same source branch. B. Deploying a manually edited production package after staging tests. C. Moving the exact versioned image tested in staging into production. D. Compiling the application on each production server. Correct Answer: C. Moving the exact versioned image tested in staging into production. Question 3A pipeline detects a high-severity dependency vulnerability. Which policy is most professionally appropriate? A. Ignore it if functional tests pass. B. Block release or require a documented, time-limited exception with an owner. C. Delete the scan result from the pipeline report. D. Release automatically and investigate only if users complain. Correct Answer: B. Block release or require a documented, time-limited exception with an owner. Question 4Which test most directly addresses broken object-level authorization in the service-request platform? A. Checking whether a page loads within two seconds. B. Verifying that a student cannot retrieve another student’s request by changing its identifier. C. Checking whether the container image has the expected label. D. Testing whether a database backup file exists. Correct Answer: B. Verifying that a student cannot retrieve another student’s request by changing its identifier. Question 5What is the principal operational advantage of a canary deployment? A. It removes the need for monitoring. B. It exposes the new version gradually, allowing evidence-based continuation or rollback. C. It guarantees that database changes are reversible. D. It requires no additional release configuration. Correct Answer: B. It exposes the new version gradually, allowing evidence-based continuation or rollback. Question 6Which statement best distinguishes observability from simple monitoring? A. Observability uses only infrastructure CPU metrics. B. Monitoring is always automated, whereas observability is always manual. C. Observability helps engineers investigate unfamiliar internal states using system outputs. D. Observability makes logs unnecessary. Correct Answer: C. Observability helps engineers investigate unfamiliar internal states using system outputs. Question 7A team wants to claim that automation improved deployment performance. What is the strongest evidence? A. A screenshot of one successful deployment. B. The number of tools listed in the project report. C. Comparable baseline and post-change measurements with defined collection methods. D. A team member’s opinion that deployment feels faster. Correct Answer: C. Comparable baseline and post-change measurements with defined collection methods. Question 8Why should production secrets not be stored in a source repository? A. Repositories cannot store text files. B. Version history and broad access can expose credentials even after deletion. C. Secrets prevent unit tests from running. D. Cloud platforms reject all repository files. Correct Answer: B. Version history and broad access can expose credentials even after deletion. Question 9Which deployment practice is safest when application and database changes must be released over separate steps? A. Make an incompatible schema change first and deploy code later. B. Use backward-compatible expansion, deploy compatible code, and clean up later. C. Disable database backups during migration. D. Rely on a code rollback to reverse all data changes. Correct Answer: B. Use backward-compatible expansion, deploy compatible code, and clean up later. Question 10In the illustrative case, why was notification functionality controlled with a feature flag? A. To avoid storing any request data. B. To allow the core workflow to operate and be tested despite notification-provider failure. C. To replace authorization tests. D. To make infrastructure provisioning unnecessary. Correct Answer: B. To allow the core workflow to operate and be tested despite notification-provider failure.
|
