Optimization, Platform Engineering, and Emerging CI/CD

Introduction

Continuous integration and continuous delivery (CI/CD) systems are no longer merely automation scripts that compile software and execute tests. In mature organizations, they are production-grade platforms. They consume computing resources, enforce organizational policies, provide evidence for audits, and shape how developers design and operate software.

The optimization problem is therefore multidimensional. A pipeline must be fast enough to support frequent feedback, scalable enough to serve many teams, economical enough to control infrastructure expenditure, and reliable enough to avoid reducing quality. It should also minimize unnecessary energy consumption and provide a consistent developer experience. These objectives can conflict: aggressive parallelism may reduce elapsed time but increase cost; extensive caching may improve speed but create correctness risks; highly restrictive policy controls may improve compliance but reduce delivery flow.

This chapter examines advanced CI/CD optimization through Jenkins and GitHub Actions. It then connects pipeline engineering with platform engineering, internal developer platforms, policy as code, and emerging AI-assisted capabilities. The emphasis is not on blindly automating every activity, but on designing trustworthy systems with measurable outcomes, explicit controls, and appropriate human responsibility.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain how parallelism, caching, artifact management, and ephemeral runners influence pipeline performance.
2. Apply throughput, queueing, and cost concepts when optimizing CI/CD systems.
3. Design reusable pipeline templates for Jenkins and GitHub Actions.
4. Describe the purpose and boundaries of an internal developer platform.
5. Use policy as code to express security, quality, and compliance requirements.
6. Evaluate AI-assisted pipeline generation, predictive failure analysis, and autonomous remediation.
7. Identify risks involving security, bias, privacy, explainability, and excessive automation.
8. Propose an optimization strategy using measurable engineering and business outcomes.

1. CI/CD Optimization as a Systems Problem

A pipeline is a flow system containing source-control events, schedulers, runners or agents, build tools, test environments, artifact repositories, deployment targets, and human approvals. Improving one component may simply move the bottleneck elsewhere. For example, adding more runners does not improve throughput if a database used by integration tests is saturated.

Useful objectives include:

• Lead time: time from a committed change to its usable deployment.
• Feedback time: time until a developer receives actionable test or analysis results.
• Throughput: completed pipeline executions or deployments per unit of time.
• Reliability: proportion of executions that succeed for valid reasons rather than failing because of infrastructure or pipeline defects.
• Resource efficiency: useful work achieved per unit of compute, storage, or network consumption.
• Cost per change: infrastructure and service cost attributable to a change or delivery event.
• Sustainability: reduction of unnecessary compute, storage, data transfer, and idle capacity.

Optimization should begin with measurement. At minimum, collect stage duration, queue time, runner utilization, cache hit rate, artifact size, failure cause, rerun frequency, and cost. Percentiles are generally more informative than averages because a small number of slow executions can seriously affect developer experience. The 50th percentile describes typical performance, while the 95th percentile is useful for understanding the long tail.

A simple flow model

Little’s Law provides a useful relationship for a stable system:

Here, L is the average number of items in the system, λ is the average arrival rate, and W is the average time an item spends in the system. For CI/CD, items may be queued workflow runs, provided the system is approximately stable over the period being measured and definitions are consistent.

If a service receives 30 workflow runs per hour and the average time from queue entry to completion is 10 minutes, then:

The system contains an average of five runs. This does not mean every execution takes 10 minutes, nor does it prove that five runners are required. Runs may wait, execute concurrently, or consume different resources. The equation is a measurement relationship, not a complete capacity-planning model.

2. Parallelism and Pipeline Structure

Parallelism executes independent work at the same time. Common candidates include unit-test partitions, linting, static analysis, documentation generation, and builds for independent components. Jenkins can express parallel branches in a declarative parallel block; GitHub Actions commonly uses matrix jobs or separate jobs with dependencies.

A serial pipeline with stage durations t₁, t₂, ..., t_n has elapsed execution time approximately:

If independent work is divided among p workers, an idealized lower bound is:

The overhead term includes scheduling, runner startup, checkout, data transfer, synchronization, and result aggregation. The inequality is important: parallelism cannot make the pipeline faster than its longest unavoidable dependency, and real systems incur overhead.

Amdahl’s law estimates the theoretical speedup when a fraction s of work remains serial and the remaining fraction can use p parallel workers:

The formula assumes fixed workload, a correctly identified serial fraction, and negligible or separately accounted-for parallelization overhead. If 20% of a workload is serial and 8 workers are used:

Thus, eight workers cannot produce an eightfold speedup. In practice, test coordination, resource contention, and uneven partition sizes make speedup lower.

Safe parallelization

Parallelization is appropriate only when tasks are independent or their dependencies are explicitly represented. A test suite that shares a mutable database, filesystem, port, or global test account may produce race conditions. Safe techniques include:

• partitioning tests by historical duration while periodically rebalancing partitions;
• allocating isolated databases or namespaces to each worker;
• assigning unique ports and temporary directories;
• making jobs idempotent;
• publishing results in a format that the pipeline can aggregate;
• setting concurrency limits for scarce services.

A matrix should not be expanded without considering its Cartesian-product effect. Testing five operating systems, four language versions, and three database versions creates 60 combinations before additional dimensions are included. Selective matrices, risk-based coverage, and scheduled compatibility tests can provide better value than testing every combination on every commit.

3. Caching, Artifacts, and Reproducibility

Caching avoids repeating expensive work, such as downloading dependencies or rebuilding unchanged layers. Effective caches have a clear key, a defined scope, an eviction policy, and a correctness strategy.

A cache key should include every input whose change could invalidate the cached result. For a dependency cache, this commonly includes the operating system, architecture, package-manager version, lockfile hash, and relevant configuration. A cache key based only on a branch name is usually unsafe because dependencies can change while the branch name remains constant.

A cache hit is useful only if the restored result is valid. Therefore:

1. Restore a cache using an exact or appropriately scoped key.
2. Verify that the package manager or build tool still validates integrity.
3. Recompute or update the cache after successful work.
4. Avoid storing secrets, credentials, or untrusted executable content in shared caches.
5. Establish retention and size limits.

Caches and artifacts serve different purposes. A cache is an optimization that may be deleted and regenerated. An artifact is an intentional output, such as a signed package, test report, container image, or software bill of materials (SBOM), which should be retained according to release, audit, and security requirements.

Container-layer caching can be powerful, but Dockerfile ordering matters. Stable dependency-installation layers should generally precede frequently changing application source layers. However, a smaller image and a faster build are not automatically safer. Images require vulnerability scanning, provenance, controlled base images, and reproducible version references.

Reproducibility means that the same declared inputs produce equivalent outputs. It is supported by lockfiles, pinned action and plugin versions, immutable artifact references, controlled toolchains, and recorded build metadata. Reproducibility does not require every build to be bit-for-bit identical, but unexplained environmental variation should be minimized and documented.

4. Runners, Agents, and Elastic Capacity

A Jenkins agent or GitHub Actions runner executes pipeline work. Runners may be persistent, elastic, self-hosted, or ephemeral.

Ephemeral runners are created for a job or short-lived group of jobs and then destroyed. They reduce cross-job contamination and make the execution environment easier to reason about. They are particularly valuable for untrusted pull requests, although isolation must be real: a virtual machine or isolated workload is usually stronger than merely clearing a workspace.

A secure runner design should consider the trust level of code, token permissions, network egress, workload identity, privilege escalation, secret exposure, and cleanup. Pull-request workflows from forks require special care because submitted code may be malicious. Secrets should not be exposed to untrusted code, and privileged deployment jobs should be separated from build jobs.

Autoscaling should respond to queue depth and job demand without creating a cost or availability cycle. A practical policy may maintain a small warm capacity for ordinary demand, add runners when queue time exceeds a threshold, and impose an upper bound to protect downstream systems. Capacity decisions should use observed workloads rather than a single peak estimate.

5. Cost and Sustainability Optimization

Pipeline cost is influenced by execution duration, runner type, concurrency, storage, network transfer, observability, and retry behavior. A simplified cost estimate is:

This is an accounting decomposition, not a universal billing formula. Each term must be defined using the provider’s pricing model. If a runner costs $0.008 per minute and a workflow uses four runners for 12 minutes each, compute cost is:

This assumes billing is directly proportional to runner-minutes and excludes storage, transfer, taxes, discounts, and minimum billing increments.

Cost optimization should avoid reducing quality through indiscriminate test removal. Better measures include:

• running fast, high-signal checks first;
• cancelling obsolete runs for superseded commits where appropriate;
• scheduling expensive compatibility tests intelligently;
• deleting obsolete artifacts according to retention policy;
• reducing redundant dependency downloads;
• selecting runner sizes based on measured utilization;
• separating mandatory checks from advisory checks;
• using changed-component detection in monorepositories.

Sustainability overlaps with cost optimization but is not identical. A fast, oversized runner may cost more and consume more energy than a slower, right-sized runner. Organizations can track compute minutes, idle capacity, storage growth, and repeated work as operational sustainability indicators. The responsible goal is efficient delivery, not merely minimizing execution time.

6. Reusable Pipelines and Engineering Standards

As the number of repositories grows, copy-and-paste pipelines become difficult to update and audit. Reusable components create a standard path while allowing controlled variation.

In Jenkins, shared libraries can provide common functions, declarative stages, security checks, notifications, and deployment patterns. Libraries should be versioned and reviewed. Unrestricted dynamic code in a shared library can become a high-impact supply-chain risk because it executes in many projects.

GitHub Actions supports reusable workflows, composite actions, and workflow-call interfaces. A reusable workflow should define clear inputs, outputs, permissions, supported environments, and failure semantics. Actions should be pinned to trusted immutable references where feasible, and updates should be managed rather than silently floating.

Good templates provide:

• a secure default;
• documented extension points;
• consistent artifact and test-report conventions;
• standard logging and observability;
• explicit versioning;
• backward-compatibility expectations;
• a migration path when standards change.

Templates must not become opaque platforms that teams cannot debug. A developer should be able to identify which template version ran, what inputs were supplied, and where failure occurred.

7. Platform Engineering and Internal Developer Platforms

Platform engineering treats internal development capabilities as products. An internal developer platform (IDP) may provide repository creation, service templates, CI/CD workflows, environment provisioning, secrets integration, observability, security controls, and deployment interfaces.

The platform team is not simply a central operations group. It serves internal customers—developers, testers, security specialists, and product teams—and should measure adoption, satisfaction, reliability, time to first deployment, support demand, and successful self-service completion.

A useful distinction is between a golden path and a mandatory path. A golden path is a well-supported, secure, and convenient default for common cases. Exceptions remain possible when justified. Making every team conform to one rigid process can cause workarounds and shadow tooling.

An effective IDP separates concerns:

• developers declare application intent and relevant configuration;
• the platform supplies repeatable workflows and infrastructure interfaces;
• security and compliance controls are applied consistently;
• product teams retain responsibility for application behavior and operational outcomes.

Platform abstraction must be balanced. Excessive abstraction hides important operational consequences; insufficient abstraction forces every team to solve the same problem independently. Documentation, transparent interfaces, diagnostics, and escape mechanisms are therefore essential.

8. Policy as Code and Governance

Policy as code expresses rules in machine-readable form and evaluates them consistently. Examples include:

• rejecting deployment when an image has a critical unaccepted vulnerability;
• requiring an SBOM and provenance statement;
• preventing production deployment from an unprotected branch;
• requiring approved reviewers for sensitive environments;
• enforcing least-privilege permissions;
• restricting infrastructure configurations that violate organizational standards.

Policy should be separated conceptually into advisory, blocking, and exception-controlled rules. A blocking rule should have a clear rationale, owner, evidence requirement, and appeal or exception process. Policies that fail closed can protect high-risk systems but may also interrupt emergency recovery; policies that fail open improve availability but increase exposure. The appropriate behavior depends on the asset and threat model.

Policy evaluation should produce explainable results. A failed rule should identify the resource, violated condition, evidence, and remediation guidance. Policies must be tested like software, including positive cases, negative cases, boundary cases, and regression tests.

Governance also requires version control and change management. A policy change can affect hundreds of repositories, so staged rollout, dry-run mode, impact analysis, and communication are important. Policy as code standardizes decisions, but it does not eliminate the need for human judgment in ambiguous or exceptional situations.

9. AI-Assisted CI/CD

AI can support pipeline work in several ways:

1. Pipeline generation: producing an initial Jenkinsfile or GitHub Actions workflow from repository metadata and organizational templates.
2. Failure summarization: grouping logs and explaining likely causes.
3. Predictive failure analysis: estimating whether a run is likely to fail based on historical signals.
4. Test selection: recommending tests affected by a code change.
5. Remediation assistance: proposing configuration changes, dependency updates, or rollback actions.
6. Operational agents: executing narrowly authorized actions under policy and approval controls.

AI-generated configuration must be treated as untrusted code until reviewed. Common risks include overbroad permissions, unsafe shell commands, secret leakage, incorrect assumptions about the repository, insecure action references, and accidental removal of essential tests. A generated pipeline should pass the same review, static analysis, security scanning, and policy checks as manually authored code.

Predictive failure analysis is useful only when its predictions are evaluated. Important measures include precision, recall, false-positive rate, calibration, and the operational cost of incorrect predictions. A model that marks nearly every run as risky may appear sensitive but create alert fatigue. A model that misses rare security failures may be unacceptable even if its average accuracy is high.

AI systems can also reproduce historical bias. If past failures were recorded inconsistently, the model may learn that certain teams, services, or change types are inherently risky when the real cause was poor observability or unequal testing. Training data should be assessed for quality, representativeness, and leakage. Sensitive source code, logs, credentials, and personal data must not be sent to an external model without authorization and appropriate controls.

Autonomous remediation boundaries

Autonomous remediation should be introduced gradually:

• Observe: AI explains or recommends but takes no action.
• Assist: a human approves a proposed change.
• Constrained automate: the system performs low-risk, reversible actions within strict limits.
• Autonomous operation: the system acts independently only where safety, authorization, rollback, and monitoring are demonstrably adequate.

Examples of relatively suitable constrained actions include retrying a known transient infrastructure operation, recycling an unhealthy ephemeral runner, or rolling back to a previously verified artifact. Examples requiring stronger controls include changing production access policies, modifying authentication, deleting data, or upgrading security-sensitive dependencies.

Every automated action should have an identity, authorization scope, audit record, timeout, rate limit, and rollback strategy. Human approval is not a substitute for good system design, but it is an important control for high-impact decisions.

10. Observability and Continuous Improvement

Pipeline observability includes structured logs, traces across orchestration steps, metrics, artifacts, and event history. Useful dimensions include repository, branch type, workflow version, runner class, stage, dependency, and failure category. Care is required to avoid logging secrets or excessive personal information.

Failures should be classified rather than counted as a single number. Categories may include product-test failure, pipeline defect, infrastructure failure, dependency outage, policy rejection, timeout, cancellation, and user error. This classification supports targeted improvement. For example, increasing runner capacity will not solve a flaky test.

A practical improvement loop is:

1. Establish a baseline.
2. Identify the dominant bottleneck or failure class.
3. Form a specific hypothesis.
4. Change one relevant factor where possible.
5. Compare equivalent measurements.
6. Check for regressions in cost, reliability, and security.
7. Standardize the improvement or revert it.

Optimization should be reviewed against multiple dimensions. A pipeline that becomes 30% faster but doubles flaky failures is not necessarily an improvement.

11. Illustrative Case: A Growing E-Commerce Platform

Background

An illustrative e-commerce company operates 80 repositories using Jenkins for services and GitHub Actions for selected libraries. The average pull-request pipeline takes 28 minutes, while the 95th percentile is 64 minutes. Developers frequently retry jobs, and monthly CI compute expenditure is increasing.

Problem

Analysis shows that 35% of elapsed time is queue time, 25% is repeated dependency installation, and 18% is integration-test contention. Several jobs run on persistent agents containing stale tools. The organization also has inconsistent security checks and no standard artifact-retention policy.

Analysis

The platform team measures queue time separately from execution time and classifies failures for four weeks. It discovers that increasing agent count alone would overload the shared integration database. It also finds that many repositories use slightly different versions of the same build tool.

Approach

The team implements the following design:

• fast lint and unit-test jobs run in parallel;
• integration tests use isolated database schemas and a bounded concurrency group;
• dependency caches use lockfile and toolchain hashes;
• deployment artifacts are immutable and retained according to environment requirements;
• ephemeral runners are used for untrusted pull requests;
• a versioned reusable workflow supplies standard security and reporting steps;
• policy checks run in advisory mode for two weeks before selected rules become blocking;
• a dashboard separates queue time, execution time, infrastructure failures, and product-test failures;
• an AI assistant summarizes logs but cannot alter workflows or deploy software.

Outcome

After six weeks, the median pipeline time falls from 28 to 17 minutes, while the 95th percentile falls from 64 to 39 minutes. The organization also observes fewer cross-job contamination failures. Compute spending falls modestly because reduced repeated work offsets the cost of additional parallel runners. The team does not claim that all improvements are caused by one change; results are compared with baseline measurements and reviewed for changes in workload.

Learning points

The case demonstrates that optimization is a systems activity. Parallelism helped only after dependencies were isolated. Caching required correct keys. Ephemeral runners improved isolation but required startup and cache planning. Policy rollout was staged to avoid unexpected disruption. Finally, AI was introduced first as an explanatory assistant rather than an uncontrolled operator.

12. Challenges, Limitations, and Professional Responsibilities

Advanced CI/CD introduces several enduring challenges:

• Complexity: more jobs, caches, templates, and policies can make diagnosis harder.
• Brittle abstractions: templates may hide assumptions about languages, networks, or deployment targets.
• Supply-chain exposure: plugins, actions, images, packages, and shared libraries are executable dependencies.
• False confidence: a green pipeline proves only that defined checks passed under defined conditions.
• Cost displacement: moving work to a hosted platform may hide rather than eliminate expenditure.
• Security trade-offs: broad runner permissions improve convenience but increase blast radius.
• AI uncertainty: generated text may be plausible but technically wrong, incomplete, or unsafe.
• Organizational resistance: platform standards fail when teams cannot see value or influence design.

Professional practice requires least privilege, transparent evidence, documented ownership, secure secret handling, accessibility of developer tooling, and respect for privacy. Auditability is especially important when automated systems make decisions affecting production access, deployment eligibility, or incident response.

Best-Practice Checklist

1. Measure queue time, execution time, reliability, cost, and resource utilization separately.
2. Parallelize only independent, isolated work.
3. Use cache keys that represent all invalidating inputs.
4. Distinguish disposable caches from governed release artifacts.
5. Prefer ephemeral execution for untrusted or sensitive workloads where isolation is adequate.
6. Pin and review third-party actions, plugins, images, and shared libraries.
7. Design reusable workflows with clear interfaces and versioning.
8. Treat an internal platform as a product with users and service-level objectives.
9. Test, explain, version, and stage policies before making them blocking.
10. Introduce AI through bounded, observable, reversible capabilities.
11. Require human review for high-impact generated changes and actions.
12. Evaluate every optimization for speed, reliability, security, cost, and sustainability.

Chapter Summary

CI/CD optimization is a systems-engineering discipline rather than a search for the shortest individual job. Parallelism reduces elapsed time when work is genuinely independent, but serial dependencies and overhead limit achievable speedup. Caching reduces repeated work only when cache keys and trust boundaries are correct. Ephemeral runners improve isolation, while elastic capacity must be governed to control cost and downstream contention.

Reusable Jenkins libraries and GitHub Actions workflows support consistency, but they require versioning, transparency, and secure supply-chain practices. Platform engineering extends these ideas into internal developer platforms that provide self-service golden paths while preserving team responsibility. Policy as code makes governance repeatable and auditable when rules are explainable, tested, and supported by an exception process.

AI can generate configurations, summarize failures, predict risk, and propose remediation. Its outputs remain probabilistic and must be reviewed, evaluated, and constrained. Autonomous action should be limited by authorization, reversibility, monitoring, and blast-radius controls. The central professional principle is balanced optimization: faster delivery is valuable only when it remains reliable, secure, economically responsible, and sustainable.

Key Terms

Amdahl’s law: A model showing how the serial fraction of work limits parallel speedup.

Artifact: A deliberate output of a pipeline, such as a package, image, report, or SBOM.

Cache key: An identifier used to determine whether cached data corresponds to current inputs.

Concurrency limit: A control restricting the number of simultaneous jobs or operations.

Ephemeral runner: A short-lived execution environment created for limited pipeline work.

Golden path: A recommended, supported route for completing a common engineering task.

Internal developer platform: An internal product providing standardized development and delivery capabilities.

Little’s Law: A stable-system relationship connecting average items, arrival rate, and time in system.

Matrix job: A workflow pattern that runs a job over multiple declared configuration combinations.

Policy as code: Machine-readable rules evaluated automatically in engineering workflows.

Predictive failure analysis: Use of historical and current signals to estimate likely pipeline failure.

Reproducibility: The ability to produce equivalent results from equivalent declared inputs.

Runner: The agent or execution environment that performs pipeline tasks.

Shared library: Reusable Jenkins code supplying common pipeline behavior.

Software bill of materials: A structured inventory of components contained in software.

Supply-chain security: Protection of code, tools, dependencies, artifacts, and delivery processes.

Throughput: Completed work per unit of time.

Workflow template: A reusable definition of standard pipeline behavior.

Review Questions

Short Answer Questions

1. Why is queue time measured separately from execution time in CI/CD analysis?
2. State two conditions required for safe pipeline parallelism.
3. What is the difference between a cache and an artifact?
4. Why are ephemeral runners useful for untrusted pull requests?
5. What is meant by a golden path in platform engineering?

Long Answer Questions

1. Explain how parallelism, Amdahl’s law, and resource contention affect pipeline optimization.
2. Discuss the design principles of reliable dependency and container-layer caching.
3. Compare persistent, elastic, hosted, and ephemeral runners, including security and cost considerations.
4. Explain how an internal developer platform can improve developer experience without removing team accountability.
5. Evaluate the governance requirements for AI-generated pipeline code and autonomous remediation.

Analytical / Application Questions

1. A pipeline has 15 minutes of serial work and 45 minutes of parallelizable work. Estimate the ideal execution time with six workers, ignoring overhead, and explain why the real result will be longer.
2. A team’s pipeline becomes faster after adding runners, but integration-test failures increase. Diagnose possible causes and propose a measurement-led solution.
3. Design a staged adoption plan for policy as code and AI-assisted failure analysis in an organization that has low trust in centralized platform teams.

Multiple Choice Questions with Answers

Question 1

Which change most directly reduces queue time when downstream services have sufficient capacity?

A. Adding appropriately sized runners

B. Increasing artifact retention indefinitely

C. Disabling all unit tests

D. Logging more personal data

Correct Answer: A. Adding appropriately sized runners

Question 2

In Amdahl’s law, what limits the maximum speedup of a parallelized pipeline?

A. The number of repositories

B. The serial fraction of the workload

C. The artifact naming convention

D. The number of approval comments

Correct Answer: B. The serial fraction of the workload

Question 3

Which statement correctly distinguishes a cache from an artifact?

A. A cache is always immutable and audit-retained

B. An artifact is disposable intermediate data only

C. A cache is an optimization that can be regenerated

D. Artifacts must never be scanned

Correct Answer: C. A cache is an optimization that can be regenerated

Question 4

What is a primary security benefit of an ephemeral runner?

A. It guarantees that code contains no defects

B. It reduces persistent state and cross-job contamination

C. It eliminates the need for access control

D. It prevents all network attacks

Correct Answer: B. It reduces persistent state and cross-job contamination

Question 5

Which practice produces a safer dependency cache?

A. Using only the branch name as the cache key

B. Including relevant lockfile and toolchain inputs in the key

C. Storing credentials in the cache

D. Sharing executable cache contents without trust boundaries

Correct Answer: B. Including relevant lockfile and toolchain inputs in the key

Question 6

What is the main purpose of a golden path?

A. To provide a supported default for a common engineering task

B. To prohibit all technical exceptions

C. To replace application ownership

D. To maximize the number of custom tools

Correct Answer: A. To provide a supported default for a common engineering task

Question 7

Which is an appropriate characteristic of policy as code?

A. Rules are untestable because they are governance documents

B. Failures should be explainable and linked to remediation

C. All policies must fail open

D. Policies should change without version control

Correct Answer: B. Failures should be explainable and linked to remediation

Question 8

What is a significant risk of AI-generated pipeline configuration?

A. It may introduce excessive permissions or unsafe commands

B. It always increases reproducibility

C. It cannot produce syntactically valid text

D. It removes the need for security review

Correct Answer: A. It may introduce excessive permissions or unsafe commands

Question 9

A workflow uses four runners for 12 minutes each at $0.008 per runner-minute. Ignoring other charges, what is the compute cost?

A. $0.032

B. $0.096

C. $0.384

D. $3.840

Correct Answer: C. $0.384

Question 10

Which autonomous action is generally most suitable for early, constrained automation?

A. Deleting production data

B. Changing production authentication policy

C. Recycling an unhealthy ephemeral runner with audit logging

D. Granting unrestricted administrator access

Correct Answer: C. Recycling an unhealthy ephemeral runner with audit logging