Testing, DevOps and Cloud Deployment

Introduction and Context

Modern web applications are not completed when source code compiles. They are continuously changed, deployed, observed, secured, and improved. A small defect may affect a browser interface, an application programming interface (API), a database transaction, a machine-learning service, or an entire cloud environment. Consequently, professional web engineering combines software testing, version control, automated delivery, containerization, cloud architecture, observability, and incident response.

Testing provides evidence that software behaves as intended. DevOps provides practices for integrating development and operations so that changes can be delivered safely and repeatedly. Cloud deployment supplies elastic computing, managed services, networking, storage, and security controls. These areas are interdependent: a deployment pipeline is valuable only when tests provide meaningful confidence, and cloud infrastructure is useful only when it can be operated reliably.

For AI and ML students, these ideas are especially important. An application may include a web frontend, an inference API, data-processing jobs, model artifacts, feature stores, and monitoring for both software and model behavior. A model that is accurate in a notebook can still fail in production because of latency, incompatible dependencies, data drift, insecure endpoints, or inadequate rollback procedures.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish unit, integration, end-to-end, security, and performance testing.

2. Design a risk-based testing strategy and interpret useful test metrics.

3. Use Git branching, commits, pull requests, and code review effectively.

4. Explain CI/CD pipelines and identify appropriate quality gates.

5. Package a web application in a container and describe its runtime concerns.

6. Compare major cloud deployment models and basic infrastructure concepts.

7. Apply observability practices using logs, metrics, and traces.

8. Explain incident response, rollback, reliability, and responsible governance.

1. A Quality Model for Web Systems

Quality is multidimensional. Functional correctness asks whether a feature produces the specified result. Reliability concerns consistent operation over time. Performance concerns response time, throughput, and resource consumption. Security concerns confidentiality, integrity, availability, authentication, authorization, and resistance to abuse. Maintainability concerns how safely developers can understand and modify the system. Accessibility and usability concern whether people with varied abilities and contexts can use it.

A useful engineering principle is that quality must be built into the delivery process rather than inspected only at the end. The earlier a defect is detected, the less expensive it usually is to diagnose and correct. However, early tests cannot replace later tests: a unit test can prove the behavior of one function without proving that a browser, API, database, identity provider, and payment service work together.

Testing should therefore be risk-based. High-risk functions—such as authentication, payments, deletion, personal-data processing, and model decisions affecting people—deserve stronger tests and review than low-risk visual changes. Risk can be considered in terms of likelihood, impact, detectability, and exposure, although these factors do not form a universal numerical formula. The purpose is to prioritize engineering effort, not to create false precision.

2. Levels and Types of Testing

2.1 Unit Testing

A unit test checks a small, isolated unit, usually a function, class, or module. Good unit tests are fast, deterministic, and focused. For example, a test for a function that calculates a shopping-cart total can check discounts, rounding, empty carts, and invalid quantities without connecting to a real database.

Unit tests commonly follow the arrange–act–assert pattern:

• Arrange inputs and dependencies.
• Act by calling the unit under test.
• Assert the expected result or behavior.

Dependencies can be replaced by test doubles. A stub supplies predetermined responses; a mock verifies interactions; a fake provides a lightweight working implementation, such as an in-memory repository. Excessive mocking can make tests pass while the real components fail, so the boundary between isolated and integrated behavior must be considered carefully.

A valuable unit test is not simply one that increases coverage. It expresses an important rule and fails when that rule is broken. Branch coverage and statement coverage are indicators, not guarantees of correctness. A project with 100 percent statement coverage may still omit important input combinations and security conditions.

2.2 Integration Testing

Integration tests examine interactions among components. Examples include an API communicating with a relational database, a service publishing a message to a queue, or an application validating a token issued by an identity provider. Integration tests reveal schema mismatches, transaction problems, serialization errors, configuration defects, and incorrect assumptions about external services.

A practical approach is to run dependent services in disposable environments, often using containers. Test databases should be isolated, initialized predictably, and cleaned between tests. Where a real third-party service is expensive or unsafe, a contract test can verify that a consumer and provider agree on request and response structures. Mocks of external services should not be treated as proof that the real service behaves identically.

2.3 End-to-End Testing

End-to-end (E2E) tests exercise a complete user journey through the deployed application. A browser test might register a user, sign in, create an order, and verify the confirmation page. E2E tests provide high ecological validity but are slower and more fragile than unit tests. They may fail because of timing, network variability, test data, or changes in page structure.

E2E suites should focus on critical paths rather than attempting to test every permutation. Stable selectors, isolated test accounts, controlled data, explicit waits for meaningful conditions, and automatic capture of screenshots or traces improve diagnosis. A test that merely sleeps for a fixed time is generally weaker than one that waits for a specified state.

2.4 Security Testing

Security testing is continuous and includes more than scanning for known vulnerabilities. Important activities include:

• Static application security testing (SAST), which analyzes source or compiled code.
• Dynamic application security testing (DAST), which probes a running application.
• Software composition analysis, which identifies vulnerable dependencies and licenses.
• Secret scanning, which detects credentials accidentally committed to repositories.
• Threat modeling, which identifies assets, trust boundaries, attackers, and abuse cases.
• Manual review and penetration testing for high-risk systems.

Developers should address common web risks such as injection, broken access control, cross-site scripting, cross-site request forgery, insecure direct object references, insecure file uploads, and misconfigured security headers. Authentication proves identity; authorization determines permitted actions. These concepts must not be conflated.

Security tests should run with least privilege and should never expose production secrets. Findings require triage: a scanner may produce false positives, while an apparently minor issue may be severe in a particular business context. Remediation should include a fix, a regression test where feasible, and documentation of residual risk.

2.5 Performance and Load Testing

Performance testing investigates response time, throughput, resource use, and stability under demand. Load testing applies expected traffic; stress testing pushes beyond expected limits; spike testing examines abrupt demand changes; endurance or soak testing examines behavior over an extended period; and capacity testing estimates the point at which service objectives are no longer met.

Important measures include latency percentiles, throughput, error rate, CPU and memory use, database utilization, and queue depth. The mean latency alone can hide poor experiences. The 95th percentile latency is the value below which 95 percent of observations fall, assuming the percentile is calculated consistently over a stated measurement window. A service may have an acceptable average but an unacceptable tail caused by database locks or garbage collection.

A simple utilization relationship often used in capacity reasoning is:

`concurrency ≈ throughput × response time`

Here, concurrency is the average number of requests in the system, throughput is requests per unit time, and response time is time per request. This is an application of Little’s Law under stable operating conditions: arrivals and departures are approximately balanced, and the measured population and rates refer to the same system boundary and time interval. It is not a substitute for load testing and does not predict performance when the system is unstable.

For example, if an API sustains 50 requests per second with an average response time of 0.2 seconds, average in-system concurrency is approximately `50 × 0.2 = 10` requests. This estimate does not establish a safe maximum; memory, connection pools, downstream limits, and tail latency must also be evaluated.

3. Test Strategy and Test Architecture

A test strategy maps business risks to test levels, environments, data, ownership, and release criteria. The commonly cited “test pyramid” places many fast unit tests at the base, fewer integration tests in the middle, and a small number of broad E2E tests at the top. The pyramid is a heuristic, not a law. A data-intensive system may appropriately require substantial integration testing, while a user-interface product may need more browser coverage.

Tests should be deterministic: given the same code, inputs, and controlled environment, they should normally produce the same result. Flaky tests—tests that pass and fail without a relevant code change—reduce trust and encourage teams to ignore failures. Causes include uncontrolled time, shared mutable data, race conditions, random ports, external dependencies, and inadequate cleanup.

Test data must reflect both ordinary and exceptional cases. Personally identifiable information should be masked or synthetically generated. Production data should not be copied into development environments without legal authorization, minimization, and appropriate controls. Test environments should resemble production where differences could affect results, while remaining safe and affordable.

A release gate should be explicit. Examples include successful unit and integration tests, no unresolved critical security findings, successful container scanning, acceptable performance against a service-level objective, and a reviewed change record. Gates should not be so numerous or noisy that developers routinely bypass them.

4. Git, Collaboration, and Code Review

Git is a distributed version-control system. A commit records a snapshot and metadata; a branch is a movable reference to a line of development; a merge combines histories; and a tag identifies a significant point such as a release. Good commits are small, coherent, and descriptive. They should explain the purpose of a change rather than merely repeat an issue number.

Teams may use trunk-based development, in which short-lived branches are integrated frequently, or a longer-lived branching model. The choice should reflect release frequency, team size, regulatory controls, and the cost of maintaining divergent branches. Long-lived branches increase merge conflicts and delay feedback; an uncontrolled shared main branch can expose unfinished work. Feature flags can allow code to be deployed separately from feature activation, but flags create operational complexity and must be removed when no longer needed.

A pull request or merge request enables review before integration. Effective review examines correctness, security, performance, maintainability, tests, observability, and compatibility. Reviewers should ask whether failure modes are handled and whether the change can be rolled back. Automated formatting and linting should handle mechanical issues so human attention is directed toward design and risk. Review should be respectful and evidence-based; it is a quality-control activity, not a mechanism for personal criticism.

5. Continuous Integration and Continuous Delivery

Continuous integration (CI) means that changes are integrated frequently and automatically validated. A typical CI pipeline checks out code, installs dependencies, performs formatting and static analysis, runs unit tests, builds an artifact, executes integration tests, and publishes results.

Continuous delivery means that the software is kept in a releasable state and can be deployed through an automated process. Continuous deployment goes further by automatically releasing changes that pass the required controls. Delivery does not require automatic production deployment; organizations may retain an approval step because of risk, regulation, or business coordination.

A robust pipeline commonly contains:

1. Source and dependency validation: verify the commit, lock dependency versions, and scan for secrets.

2. Build: produce a reproducible artifact, such as a container image or package.

3. Fast checks: run linting, type checking, unit tests, and static security analysis.

4. Integration checks: use isolated services and representative configurations.

5. Deployment to a test or staging environment: apply infrastructure and configuration safely.

6. Acceptance and security checks: run contract, E2E, and dynamic tests where appropriate.

7. Production release: use approval, progressive rollout, or an automated policy.

8. Post-deployment verification: check health, error rates, latency, and key business signals.

Build artifacts should be immutable: the same tested artifact should be promoted between environments rather than rebuilt differently for production. Configuration such as URLs and credentials should be injected through environment-specific mechanisms, not hard-coded into source or images. Secrets belong in a managed secret store or protected CI variables, with rotation and access auditing.

Deployment strategies include blue–green deployment, in which two environments allow rapid switching; rolling deployment, in which instances are replaced gradually; and canary deployment, in which a small proportion of traffic reaches the new version before wider release. The correct choice depends on compatibility, rollback speed, observability, cost, and data migration constraints. Database changes require special care because an application rollback may not reverse an irreversible schema migration. Expand-and-contract migrations—add compatible structures, migrate usage, then remove old structures—reduce this risk.

6. Containers and Reproducible Runtime Environments

A container packages an application with its user-space dependencies while sharing the host operating system kernel. It is not a complete virtual machine and should not be assumed to provide perfect isolation. An image is an immutable template composed of layers; a container is a running instance of an image.

A production container should use a minimal trusted base image, pin dependencies where appropriate, run as a non-root user, exclude development tools and secrets, expose only required ports, and define health behavior. Multi-stage builds can compile or package an application in one stage and copy only runtime artifacts into a smaller final image. Smaller images reduce transfer time and attack surface, although minimality must be balanced against debuggability and support.

Containers are stateless by default. Persistent data should be stored in managed databases, object storage, or explicitly managed volumes. Logs should be written to standard output and error so the platform can collect them. A containerized service should handle termination signals and shut down gracefully, allowing in-flight work to complete or be retried safely.

Container orchestration platforms schedule containers, provide service discovery, manage health checks, and support scaling and rolling updates. They also introduce complexity: networking, resource limits, scheduling failures, configuration management, and security policies must be understood rather than hidden behind terminology.

7. Cloud Deployment and Infrastructure Concepts

Cloud services are commonly described as infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). IaaS provides virtual machines, networks, and storage; PaaS manages more of the runtime and deployment environment; SaaS provides a complete application. Serverless functions are an event-driven model in which the provider manages servers, but they still involve operational concerns such as permissions, cold starts, timeouts, observability, and vendor limits.

Cloud architecture separates concerns into compute, networking, storage, databases, identity, messaging, and monitoring. A virtual private network or equivalent logical network can isolate resources. Public exposure should be limited to required entry points, commonly a load balancer or API gateway. Security groups, firewall rules, private subnets, and identity policies should follow least privilege.

Scalability can be vertical—using a larger instance—or horizontal—adding instances. Horizontal scaling is effective when services are stateless and dependencies can handle increased load. Autoscaling policies should consider meaningful signals such as request rate, queue depth, or latency, not CPU alone. Scaling too aggressively can increase cost or overload a downstream database.

Availability is improved through redundancy, health checks, backups, and failure isolation. A backup is not useful unless restoration is tested. Recovery point objective (RPO) describes the maximum acceptable amount of data loss measured in time; recovery time objective (RTO) describes the target time to restore service. These are business requirements, not guarantees automatically supplied by a cloud provider.

Infrastructure as code (IaC) represents infrastructure configuration in version-controlled files. It enables review, repeatability, and automated provisioning. State management, secret handling, drift detection, provider changes, and destructive operations require safeguards. A plan or preview should be reviewed before applying changes, and production access should be restricted and audited.

Cloud economics is also an engineering concern. Cost depends on compute time, storage, data transfer, managed-service usage, observability volume, and commitments. Tagging, budgets, quotas, rightsizing, deletion of unused resources, and cost dashboards support financial accountability. The cheapest architecture is not necessarily appropriate if it increases downtime, security exposure, or maintenance effort.

8. Observability and Reliability

Monitoring reports known conditions; observability is the ability to infer internal system state from emitted evidence. The principal signals are:

• Logs: timestamped records of events. They should be structured, searchable, and free of unnecessary sensitive data.
• Metrics: numerical time series such as request count, error rate, latency, saturation, queue depth, and resource use.
• Traces: records of a request’s path across services, connected by correlation identifiers.

Instrumentation should support diagnosis, not merely produce data. A useful log identifies the operation, outcome, relevant correlation ID, and safe contextual fields. Sensitive tokens, passwords, and unnecessary personal information must not be logged. Alerting should be actionable: an alert should identify a condition requiring attention, have an owner, and provide runbook guidance. Excessive alerts produce fatigue and conceal important failures.

Service-level indicators (SLIs) measure user-relevant behavior, such as successful request proportion or latency. Service-level objectives (SLOs) define target performance over a period. A service-level agreement (SLA) is a formal commitment, often with business consequences. An error budget is the permitted unreliability implied by an SLO; teams can use it to balance feature delivery and reliability investment. These concepts should be based on measurement windows and clearly defined event populations.

Reliability engineering also emphasizes graceful degradation, timeouts, bounded retries with backoff, idempotency, circuit breakers, caching where appropriate, and bulkheads that limit failure propagation. Retries can worsen an outage when every client retries simultaneously. They should be used only when an operation is safe to repeat or has a carefully designed idempotency mechanism.

9. Incident Response

An incident is an event that threatens or degrades service, security, data integrity, or an important user outcome. Incident response is an organized process, not an improvised technical argument. Typical stages are preparation, detection, triage, containment, communication, recovery, and learning.

During an incident, roles should be clear. An incident commander coordinates decisions and priorities; technical leads investigate and mitigate; communications personnel provide accurate updates; and a scribe records actions and times. The immediate goal is to reduce harm and restore a safe service, not to assign blame. A rollback, feature disablement, traffic reduction, or failover may be preferable to a perfect diagnosis during an active outage.

After recovery, a blameless post-incident review should establish a timeline, contributing conditions, impact, detection quality, response effectiveness, and concrete corrective actions. “Human error” is rarely a sufficient root explanation; systems, interfaces, training, permissions, automation, and organizational incentives should also be examined. Security incidents may trigger legal notification, evidence-preservation, and privacy obligations. The applicable requirements depend on jurisdiction, sector, data type, and contractual commitments.

10. AI and ML Deployment Considerations

An ML-enabled web service must test more than HTTP behavior. It should validate model loading, preprocessing consistency, feature schemas, output ranges, latency, resource use, and fallback behavior. Offline accuracy metrics do not guarantee production usefulness because the serving population may differ from the training data.

A model registry and versioned artifacts support reproducibility. The deployed model should be linked to its training data version, code revision, dependency environment, and evaluation results. Shadow deployment can evaluate a new model without influencing user outcomes; canary deployment can expose it to a limited population. Monitoring should examine input distributions, prediction distributions, data quality, error rates where labels become available, and fairness-related outcomes when legally and ethically appropriate.

Model endpoints require ordinary web security controls plus protections against abuse such as excessive inference requests, prompt or input manipulation, extraction of sensitive information, and unauthorized access to model artifacts. Human oversight is appropriate when automated decisions have significant effects. Documentation should state intended use, limitations, known biases, and escalation procedures.

11. Illustrative Case: Deploying a Student Advising Service

Background

The following is a fictional illustrative case. A university develops a web service that recommends courses using student records, degree requirements, and an ML model. Students access a browser interface, while advisors use an authenticated dashboard.

Problem

An initial prototype worked locally but had no automated deployment. It used a shared database account, stored credentials in a configuration file, and returned recommendations slowly when many students logged in. A model update once changed input preprocessing and produced plausible but incorrect results. There was no reliable rollback or audit trail.

Analysis

The highest risks were unauthorized access to academic records, incorrect recommendations, service unavailability during registration, and inability to determine which model produced a recommendation. The team classified the service as requiring strong confidentiality, integrity, and availability controls. It also recognized that recommendations should support—not replace—advisor judgment.

Approach

The team adopted a protected Git repository and short-lived pull requests. CI ran formatting, static analysis, unit tests for prerequisite and eligibility rules, integration tests against a disposable database, dependency and secret scans, and API contract tests. E2E tests covered student sign-in, recommendation display, and advisor review.

The service was packaged as a non-root container with a pinned runtime and a separate model artifact. Secrets moved to a managed secret store, and the database account received only required permissions. An expand-and-contract migration allowed old and new application versions to coexist during rollout.

A staging environment used synthetic student records. Production deployment used a canary release. Metrics tracked request success, p95 latency, database saturation, recommendation generation time, and model-version usage. Structured logs included a request ID and model ID but excluded student identifiers where not necessary. A rollback procedure disabled the new model and restored the previous application image.

The model pipeline recorded data, code, feature-schema, and model versions. A shadow evaluation compared the new model with the current model before user exposure. Advisors could report problematic recommendations, and the system displayed explanatory information and a review pathway rather than presenting predictions as authoritative decisions.

Outcome

The service achieved repeatable deployments, faster diagnosis, and safer model releases. Load testing identified a database connection bottleneck before registration week. The canary release exposed a preprocessing mismatch in a small controlled population, allowing rollback before broad impact. The university still retained manual review for exceptional cases and documented data-retention and access policies.

Learning Points

The case demonstrates that testing is a chain of evidence rather than one activity. Secure configuration, reproducible artifacts, observability, progressive delivery, and human governance were all necessary. It also shows that ML deployment adds versioning and behavioral-monitoring concerns but does not replace ordinary web engineering disciplines.

12. Challenges, Limitations, and Best Practices

Automation cannot prove that requirements are correct, that users will find an interface understandable, or that an ML system is socially appropriate. Tests may encode outdated assumptions. Cloud abstractions can conceal costs and failure modes. Managed services reduce operational work but increase dependency on vendors and may complicate portability. Containers improve consistency but do not eliminate security responsibilities.

Best practices include:

• Test critical behavior at multiple levels and prioritize by risk.
• Keep tests deterministic, fast where possible, and meaningful.
• Treat code, configuration, infrastructure, and model artifacts as versioned assets.
• Build once and promote the same artifact through environments.
• Scan dependencies and images, but review findings intelligently.
• Use least privilege, managed secrets, encryption, and audited access.
• Make deployments reversible and database changes backward compatible.
• Define SLIs and SLOs before selecting alerts.
• Practice restoration, rollback, and incident response rather than merely documenting them.
• Protect personal data in test data, logs, analytics, and model pipelines.
• Review accessibility, fairness, explainability, and human oversight for user-impacting systems.

Contemporary practice is moving toward policy-as-code, software supply-chain attestations, platform engineering, OpenTelemetry-based telemetry, progressive delivery, and automated reliability checks. These tools are valuable when they solve a defined problem; adopting them without ownership, skills, and measurable objectives can increase complexity.

Chapter Summary

Testing provides evidence at different scopes: unit tests isolate logic, integration tests validate component boundaries, E2E tests validate user journeys, security tests assess resistance to abuse, and performance tests examine behavior under demand. A risk-based strategy combines these levels rather than treating coverage as a complete quality measure.

Git and code review support controlled collaboration. CI validates changes continuously, while continuous delivery keeps tested artifacts releasable. Containers improve runtime consistency, and cloud platforms provide configurable compute, storage, networking, identity, and managed services. Infrastructure as code makes environments reviewable and repeatable, but access, state, cost, and destructive changes require governance.

Observability combines logs, metrics, and traces to support diagnosis. SLOs, error budgets, health checks, graceful degradation, and tested recovery procedures connect technical operation to user outcomes. Incident response emphasizes preparation, coordinated mitigation, communication, recovery, and blameless learning. ML-enabled applications additionally require model and data versioning, drift monitoring, controlled rollout, and human oversight. Across all topics, secure defaults, privacy protection, accessibility, reversibility, and responsible decision-making are essential professional practices.

Key Terms

Unit test: A test of a small isolated software unit.

Integration test: A test of interactions between components or services.

End-to-end test: A test of a complete user or business workflow.

Test double: A substitute dependency used during testing.

Contract test: A test that verifies an agreed interface between services.

SAST: Static analysis of source or compiled code for security weaknesses.

DAST: Security testing performed against a running application.

CI: Continuous integration of changes with automated validation.

Continuous delivery: Keeping software in a releasable state through automation.

Container: An isolated process environment packaging an application and user-space dependencies.

Infrastructure as code: Version-controlled, executable description of infrastructure.

Canary deployment: Gradual release to a small portion of users or traffic.

Observability: Ability to infer internal system state from emitted telemetry.

SLI: A measured indicator of service behavior.

SLO: A target value or range for an SLI over a defined period.

RPO: Maximum acceptable data loss expressed as a time interval.

RTO: Target time for restoring service after disruption.

Idempotency: Property whereby repeating an operation has the same intended effect as performing it once.

Model drift: Change in data or relationships that reduces the relevance of a deployed model.

Blameless post-incident review: Structured learning review that focuses on system conditions rather than personal blame.

Review Questions

Short Answer Questions

1. What is the principal difference between unit testing and integration testing?

2. Why should production secrets not be stored in a source-code repository?

3. Distinguish continuous delivery from continuous deployment.

4. Name the three principal observability signals and state the main purpose of each.

5. What do RPO and RTO measure?

Long Answer Questions

1. Explain how a risk-based test strategy could be designed for an online payment application.

2. Describe a CI/CD pipeline from commit through post-deployment verification, including suitable quality gates.

3. Compare rolling, blue–green, and canary deployment strategies and discuss when each may be appropriate.

4. Explain how containers, cloud infrastructure, and infrastructure as code work together in a production system.

5. Discuss how an ML-enabled web service should be monitored and governed after deployment.

Analytical / Application Questions

1. An API processes 50 requests per second and has an average response time of 0.2 seconds. Estimate its average concurrency using Little’s Law, state the assumptions, and explain why the result is not a capacity limit.

2. A new release increases p95 latency and database connection utilization during a canary deployment, while error rate remains unchanged. What evidence would you collect, what immediate action would you take, and what longer-term changes might be justified?

3. Design a deployment and incident-response plan for a university advising service that handles personal records and uses an ML recommendation model. Include testing, access control, rollout, observability, rollback, and human oversight.

Multiple Choice Questions with Answers

Question 1

Which testing level primarily verifies the behavior of a small isolated function or class?

A. Unit testing

B. Integration testing

C. End-to-end testing

D. Load testing

Correct Answer: A. Unit testing

Question 2

A service sustains 50 requests per second with an average response time of 0.2 seconds. What is its approximate average concurrency under Little’s Law?

A. 2 requests

B. 10 requests

C. 50 requests

D. 250 requests

Correct Answer: B. 10 requests

Question 3

Which practice keeps the same tested artifact moving from staging to production?

A. Rebuilding separately in every environment

B. Manually editing production source code

C. Promoting an immutable artifact

D. Disabling automated tests before release

Correct Answer: C. Promoting an immutable artifact

Question 4

What is the primary purpose of a canary deployment?

A. To expose a new version gradually to limited traffic

B. To eliminate the need for monitoring

C. To permanently duplicate all databases

D. To replace source control

Correct Answer: A. To expose a new version gradually to limited traffic

Question 5

Which item is an observability signal?

A. Branch name

B. Trace

C. Compiler license

D. Pull-request title

Correct Answer: B. Trace

Question 6

What does least privilege require?

A. Every service receives administrator access

B. Users and services receive only the permissions they need

C. Credentials are shared by the whole team

D. All resources are publicly accessible

Correct Answer: B. Users and services receive only the permissions they need

Question 7

Which statement about containers is correct?

A. A container is always a complete virtual machine

B. Containers eliminate the need for application security

C. Containers package an application with user-space dependencies while sharing the host kernel

D. Containers automatically provide persistent storage

Correct Answer: C. Containers package an application with user-space dependencies while sharing the host kernel

Question 8

What does RTO describe?

A. The acceptable amount of data loss

B. The target time to restore service

C. The number of requests per second

D. The percentage of tested code

Correct Answer: B. The target time to restore service

Question 9

Why are retries potentially dangerous during an outage?

A. They always reduce latency

B. They can amplify load on an already failing dependency

C. They remove the need for timeouts

D. They prevent all duplicate operations

Correct Answer: B. They can amplify load on an already failing dependency

Question 10

Which additional practice is especially important for a deployed ML model?

A. Ignoring input-data changes after release

B. Deleting the model version identifier

C. Monitoring data or model drift and recording artifact versions

D. Replacing all human review with predictions

Correct Answer: C. Monitoring data or model drift and recording artifact versions