12. CI/CD, GitOps and Platform Engineering

Introduction and Context

Infrastructure as Code (IaC) becomes strategically valuable when it is connected to the wider software delivery system. Writing Terraform modules or Ansible playbooks is only one part of infrastructure automation. The more difficult organizational problem is deciding how infrastructure changes are proposed, reviewed, tested, approved, deployed, observed, and, when necessary, reversed. These activities form an infrastructure delivery lifecycle.

Continuous integration and continuous delivery (CI/CD) provide the operational workflow for that lifecycle. GitOps extends the model by treating version-controlled repositories as the authoritative source of desired system state. Platform engineering then builds reusable internal products—such as deployment templates, infrastructure modules, policy controls, and self-service portals—that allow development teams to consume infrastructure safely without mastering every underlying implementation detail.

Together, these practices change infrastructure from an individually operated technical resource into a governed, collaborative, and programmable organizational capability. They also introduce important questions. Who may approve a production change? How can a team prove what was deployed and why? When should automation stop and require human judgment? How can developers obtain databases, networks, or environments without bypassing security and cost controls? This chapter examines these questions through the connected perspectives of CI/CD, GitOps, platform engineering, self-service infrastructure, golden paths, and progressive delivery.

Learning Objectives

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

1. Explain how CI/CD pipelines apply to Terraform and Ansible workflows.

2. Design a controlled sequence of validation, planning, review, approval, application, rollback, and audit stages.

3. Distinguish push-based IaC delivery from pull-based GitOps.

4. Evaluate the role of repositories, state, policy, credentials, and observability in infrastructure delivery.

5. Explain how internal developer platforms, self-service infrastructure, and golden paths support organizational scalability.

6. Relate progressive delivery to infrastructure and application change management.

7. Analyze the risks, governance requirements, and trade-offs of automated infrastructure pipelines.

From IaC Code to a Governed Delivery System

An IaC repository contains more than executable configuration. It represents an operational contract: the desired resources, their relationships, security properties, dependencies, and ownership. A reliable delivery system must therefore establish confidence before changing a live environment.

A typical infrastructure change moves through several logical states. A developer first modifies a Terraform module, Terraform root configuration, Ansible role, inventory definition, or policy file. Automated checks then inspect syntax, formatting, static correctness, security implications, and compliance rules. Terraform may generate a plan showing the proposed resource actions, while Ansible may perform a dry run using check mode. Reviewers examine both the code and the expected operational effect. After authorization, a controlled execution mechanism applies the change. The resulting state is recorded through version history, pipeline logs, cloud audit trails, and monitoring systems.

This sequence is more significant than the particular CI product used. GitHub Actions, GitLab CI, Jenkins, Azure DevOps, and other systems can all implement comparable principles. The essential design question is whether the pipeline makes change visible, repeatable, attributable, and reversible.

A useful distinction is between continuous integration and continuous delivery. Continuous integration validates proposed changes frequently and early. In IaC, this may include formatting checks, module tests, validation commands, dependency analysis, policy tests, and security scanning. Continuous delivery ensures that a validated change can be released through an established path, usually with an approval boundary for sensitive environments. Continuous deployment goes further by automatically releasing changes when predefined conditions are met. Production infrastructure does not necessarily require continuous deployment; an organization may rationally choose continuous delivery with explicit human authorization.

A Reference IaC Pipeline

Although implementations vary, a mature pipeline commonly contains the following stages.

Source, Branching, and Change Intent

The workflow begins with a version-controlled change. A pull request or merge request should communicate not only what files changed, but also why the change is needed, which environments are affected, expected cost or capacity implications, and any migration or rollback considerations. Small, focused changes are easier to review and reverse than large collections of unrelated modifications.

Branching policies should protect important branches, require successful checks, and prevent unreviewed direct changes. Some organizations use short-lived branches; others use trunk-based development. The choice is less important than maintaining a clear relationship between an approved commit and the deployed result.

Validation and Testing

Validation operates at several levels. Basic checks include formatting, syntax, type or schema validation, and dependency resolution. Terraform commonly uses `terraform fmt`, `terraform validate`, and provider or module tests. Ansible workflows may use YAML validation, `ansible-lint`, role tests, and Molecule-based testing.

More advanced tests examine behavior. A Terraform module might be tested against an ephemeral account or environment, checking that a network, identity policy, or database is created with the intended properties. Ansible tests may verify idempotence: running the playbook a second time should produce no unintended changes. Security scanners inspect exposed ports, weak encryption settings, embedded credentials, and excessive permissions. Policy-as-code tools can reject configurations that violate organizational rules before they reach a cloud account.

Testing is not equivalent to proving that a change is safe in every circumstance. Infrastructure interacts with external systems, quotas, provider behavior, existing state, and data. Tests reduce uncertainty; they do not eliminate the need for review and operational judgment.

Plan and Preview

The plan stage is the central visibility mechanism in Terraform-based delivery. `terraform plan` compares configuration with the current state and provider observations, producing proposed additions, modifications, and destructions. A plan should be generated from the same commit that reviewers approve and should be retained as an artifact where practical.

Ansible does not produce an identical dependency graph, but check mode, diff mode, and controlled inventory execution provide a preview of intended actions. The quality of this preview depends on module behavior, fact gathering, privilege configuration, and whether tasks accurately report changes.

A plan is evidence, not authorization. Reviewers should examine destructive actions, identity changes, network exposure, replacement of stateful resources, unexpected drift, and changes in cost or availability. A technically valid plan may still be operationally inappropriate.

Review and Approval

Code review provides distributed technical judgment. Infrastructure review should include appropriate expertise for the affected domain: application engineering, security, networking, data protection, or finance where relevant. A change affecting a production database should not be approved solely because the syntax is valid.

Approval models should be risk-based. Low-risk changes may be automatically merged after checks. High-risk changes may require environment owners, separation of duties, scheduled maintenance windows, or explicit business authorization. Approval should be linked to a specific commit and plan rather than to an informal message or a mutable branch.

Apply and Release

The apply stage changes the target environment. It should use controlled credentials, a locked state backend, concurrency protection, and a known artifact. Terraform pipelines should avoid generating a new plan after approval unless the regenerated plan is reviewed again; applying a materially different plan undermines the approval process.

For Ansible, the pipeline should pin the collection and role versions, identify the inventory and variables used, and record the exact command context. Production execution should be isolated from developer workstations. Pipeline agents require only the permissions necessary for their task, and short-lived credentials are preferable to long-lived static secrets.

Verification, Rollback, and Audit

Deployment is incomplete until the outcome is verified. Verification may include cloud resource queries, service health checks, synthetic transactions, policy evaluation, configuration compliance, and application-level metrics. A successful command does not guarantee a healthy service.

Rollback requires careful definition. For stateless infrastructure, reverting a commit and applying it may restore a previous configuration. For database schemas, data migrations, security policy changes, or irreversible resource replacement, rollback may be impossible or unsafe. A forward fix, backup restoration, traffic diversion, or blue-green switch may be more appropriate. Rollback plans must therefore be designed before deployment, not invented during an incident.

Auditability connects technical execution with governance. A strong record identifies the requester, commit, reviewer, plan, approver, executor, target environment, credentials or identity used, timestamps, resulting changes, and verification evidence. Repository history alone is insufficient because it does not prove what was actually applied.

GitOps: Desired State and Reconciliation

GitOps applies a particular operating model to delivery. Desired state is stored declaratively in a version-controlled repository, and an automated agent continuously or periodically compares that desired state with the actual environment. When a difference exists, the agent attempts to reconcile the environment.

This model is especially prominent in Kubernetes, where controllers continuously reconcile resources, but its principles can also be applied to cloud infrastructure and configuration management. A GitOps controller may invoke Terraform, manage Terraform-compatible resources, or coordinate other declarative operators. The key feature is not simply that Git is used; it is that the repository is treated as the authoritative declaration and the deployment mechanism observes and reconciles from it.

GitOps is often contrasted with a conventional push pipeline. In a push model, a CI runner receives a commit and actively connects to the target environment to apply it. In a pull model, an agent inside or near the target environment retrieves approved desired state and performs reconciliation. Pull-based delivery can reduce inbound network access and keep deployment credentials within the environment. It can also improve consistency across many clusters or accounts.

GitOps introduces its own design issues. If an administrator changes a resource manually, the controller may revert that change, creating a conflict between emergency action and declared state. If the repository contains a faulty declaration, the controller may repeatedly apply an undesirable state. Reconciliation must therefore be combined with validation, policy controls, drift alerts, emergency procedures, and clear ownership.

A practical pattern separates application source from environment configuration. An application pipeline builds and signs an image, while a configuration repository records the approved image version and deployment parameters. A pull request changes the environment repository, and the GitOps agent reconciles the approved result. This separation improves traceability, but it also adds coordination between repositories and may increase release latency if poorly designed.

Platform Engineering and the Internal Developer Platform

Platform engineering responds to a recurring organizational problem: teams need infrastructure capabilities, but asking every team to become expert in cloud networking, identity, Terraform internals, security policy, and operational reliability is inefficient and unsafe. A platform team creates an internal developer platform (IDP) that packages these capabilities behind consistent interfaces.

An IDP is not merely a portal. It may include service catalogs, infrastructure modules, templates, deployment workflows, identity integrations, observability defaults, policy enforcement, documentation, and support processes. Its purpose is to reduce cognitive load while preserving appropriate control. Developers should be able to request a service or environment through a well-defined interface without needing to understand every implementation detail, but they should still understand the resulting ownership, cost, data classification, and operational responsibilities.

The platform should be treated as a product. It has users, user journeys, reliability expectations, documentation, versioning, feedback mechanisms, and a lifecycle. Platform teams must avoid becoming a centralized ticket queue. Self-service is valuable when it provides a safe, repeatable path with rapid feedback; it is not achieved merely by placing a request form in front of a manual approval process.

Self-Service Infrastructure

Self-service infrastructure allows an authorized user or team to provision approved capabilities independently. Examples include creating a development environment, requesting a managed database, registering a message queue, or deploying a standard web service. Underlying Terraform modules and Ansible roles encode organizational knowledge, while interfaces expose only supported choices and parameters.

Effective self-service requires guardrails. Parameters may constrain regions, instance sizes, network zones, encryption settings, retention periods, and allowed images. Automated policy can enforce mandatory tags, ownership metadata, budget limits, vulnerability standards, and data residency requirements. The platform should also provide lifecycle operations such as upgrade, backup, decommissioning, and ownership transfer; provisioning alone creates unmanaged sprawl.

Golden Paths

A golden path is a recommended, supported route for performing a common task. It is not an inflexible rule and should not prevent justified exceptions. A golden path for a web service might provide a repository template, CI workflow, container build, deployment configuration, standard monitoring, identity integration, and infrastructure provisioning. The user receives a productive default while the organization obtains consistency in security, reliability, and observability.

Golden paths succeed when they are easier than bypassing them. Excessive abstraction, slow provisioning, poor documentation, or lack of customization drives teams toward unapproved alternatives. Platform teams should therefore measure adoption, time to first deployment, failure rates, support demand, and user satisfaction rather than assuming that publication equals value.

Progressive Delivery and Risk Reduction

Progressive delivery releases change gradually and uses feedback to determine whether to continue. It applies to application versions, infrastructure changes, configuration, and policy updates. Common techniques include canary releases, blue-green deployment, feature flags, ring-based rollout, staged regional deployment, and automated rollback.

For an application, a canary may send a small percentage of traffic to a new version while monitoring latency, errors, saturation, and business indicators. For infrastructure, progressive delivery may involve applying a module change to a development account, then a staging environment, then one production region before wider rollout. Changes to a fleet can be partitioned by host groups or availability zones using Ansible.

Progressive delivery depends on reliable signals and explicit decision criteria. “No pipeline error” is not a sufficient health signal. Teams should define thresholds, observation periods, abort conditions, and ownership of the decision. Automation can pause or reverse a release, but it cannot compensate for missing telemetry or poorly chosen indicators.

Infrastructure changes sometimes cannot be progressively rolled out. A global IAM policy, central network route, or shared control-plane upgrade may affect many consumers simultaneously. In such cases, techniques such as compatibility windows, staged policy enforcement, shadow evaluation, backups, and tested recovery procedures become more important.

An Operating Model for Governance and Accountability

Automation changes the distribution of responsibility; it does not remove responsibility. A mature organization defines who owns modules, environments, pipelines, policies, state, secrets, and operational outcomes. The RACI model—responsible, accountable, consulted, and informed—can clarify roles, although it should not become a bureaucratic substitute for clear engineering ownership.

Policy should be implemented at multiple layers. Repository controls protect branches and require reviews. CI checks validate code and dependencies. Policy-as-code evaluates infrastructure intent. Cloud organization policies constrain what can be created. Runtime monitoring detects drift, vulnerabilities, and service degradation. No single control is sufficient because each observes a different stage of the lifecycle.

Secrets require particular care. Credentials should not be committed to repositories, printed in plans or logs, or embedded in machine images. Secret managers, workload identity, short-lived tokens, masked variables, and least-privilege roles reduce exposure. Terraform state may contain sensitive values even when configuration does not; encrypted remote backends, access controls, state locking, and appropriate redaction are therefore essential.

Compliance evidence should be produced as a by-product of delivery rather than assembled manually after the fact. Signed commits, immutable artifacts, plan records, approval logs, policy results, cloud audit events, and monitoring evidence can establish an auditable chain. Nevertheless, automation must respect privacy and employment considerations: excessive individual surveillance of pipeline activity can be ethically problematic, and audit data should be collected for legitimate governance purposes.

Illustrative Case: A Regulated Digital Services Platform

Background

The following is an illustrative case. A growing financial-services organization operates services across three cloud regions. Development teams frequently request networks, managed databases, Kubernetes namespaces, and observability components. Initially, each team used its own Terraform repositories and manual cloud-console procedures. Production changes were often approved through informal conversations.

Situation and Problem

The organization experienced inconsistent encryption settings, abandoned development resources, unclear ownership of cloud accounts, and lengthy security reviews. An incident revealed that the repository history did not match the resources that had actually been deployed. The organization needed faster delivery without weakening auditability or regulatory controls.

Analysis

An assessment identified four root causes. First, infrastructure modules had no stable product ownership. Second, CI pipelines mixed validation and production execution, allowing a developer-controlled runner to hold broad credentials. Third, there was no standardized plan-review-approval record. Fourth, teams were offered infrastructure primitives rather than usable service journeys, so they bypassed modules when those modules were difficult to use.

The organization decided not to pursue unrestricted auto-approval. Its risk profile required human authorization for production data stores and identity changes, while allowing automated delivery for low-risk development resources.

Approach and Strategy

A platform team created versioned Terraform modules for networks, databases, and service environments. Each module encoded encryption, tagging, backup, and ownership defaults. A service catalog exposed supported parameters, while a policy engine rejected unapproved regions, public database endpoints, missing cost centers, and excessive instance sizes.

Pull requests triggered formatting, validation, security scans, unit tests, and a generated plan. The plan was attached to the review record. Development environments could be applied automatically after successful checks. Staging required an environment-owner approval. Production required two designated approvals for database or identity changes and used a protected runner with short-lived cloud credentials.

The organization also introduced a GitOps repository for Kubernetes environment configuration. Application pipelines produced signed images; a change to the environment repository updated the approved image reference. A controller reconciled the cluster, while monitoring determined whether a canary should continue. Terraform remained responsible for foundational cloud resources, whereas the GitOps controller managed the desired Kubernetes configuration.

Outcome

The new model reduced ad hoc console changes and made infrastructure ownership visible. Teams obtained standard environments more quickly because common decisions were encoded in modules and templates. Security and audit teams could inspect policy results, approvals, and execution records without reconstructing events from chat messages. The platform did not eliminate exceptions: unusual workloads still required architectural review, and some changes used forward fixes rather than rollback because data transformations were irreversible.

Learning Points

The case demonstrates that automation alone does not create a platform. Value emerged from the combination of reusable technical components, risk-based approvals, secure execution, clear ownership, and user-oriented interfaces. It also shows why Terraform, Ansible, GitOps, and platform engineering should be integrated selectively rather than forced into a single toolchain. Different layers may require different control loops and delivery mechanisms.

Challenges, Limitations, and Common Mistakes

A frequent mistake is treating a green pipeline as proof of operational safety. Tests may omit provider failures, quota limits, data dependencies, or business impact. Another is allowing the pipeline to run `apply` from arbitrary branches or to regenerate a plan after approval without renewed review.

State management is another source of failure. Concurrent applies, unprotected state files, manual state edits, and inconsistent workspaces can create destructive confusion. Teams should design state boundaries deliberately and use locking and recovery procedures.

Over-automation creates risk when every change is automatically approved, while under-automation creates slow queues and encourages bypasses. The appropriate balance depends on blast radius, reversibility, service criticality, and confidence in testing. Similarly, excessive platform abstraction can hide important behavior from engineers. A platform should simplify consumption without making diagnosis impossible.

GitOps may produce reconciliation loops, deployment storms, or repeated restoration of an unsafe state. Platform teams must provide pause mechanisms, emergency access, drift visibility, and tested recovery. Progressive delivery can also fail if monitoring measures technical symptoms but not customer outcomes.

Finally, organizations sometimes confuse standardization with uniformity. A golden path should encode proven defaults while permitting controlled variation. A platform that cannot accommodate legitimate requirements will be bypassed, weakening both governance and developer experience.

Emerging Directions

Several developments are shaping this field. Policy-as-code is becoming more integrated with pull requests, cloud organization controls, and runtime admission systems. Software supply-chain security increasingly connects signed source, provenance, dependency scanning, artifact verification, and deployment authorization. Infrastructure testing is moving toward ephemeral environments and contract tests that validate module interfaces as well as individual resources.

AI-assisted tools can summarize plans, identify unusual changes, generate policy suggestions, and help diagnose failed runs. Their output should be treated as advisory. An AI system may misunderstand a destructive replacement, overlook a regulatory constraint, or expose sensitive configuration through an external service. Human accountability, deterministic checks, and protected execution remain necessary.

Internal platforms are also moving toward paved interfaces that span infrastructure, application deployment, observability, security, and cost management. The strategic challenge is to maintain a coherent developer experience without creating a monolithic platform that becomes difficult to evolve. Modular platform capabilities, clear APIs, and product-oriented ownership are likely to remain important.

Best-Practice Principles

A robust IaC delivery system generally follows these principles:

• Keep desired configuration, policy, and reusable modules under version control.
• Generate a visible plan or preview from the exact commit under review.
• Separate validation, approval, execution, and verification responsibilities according to risk.
• Use protected runners, least privilege, short-lived credentials, encrypted state, and state locking.
• Treat rollback as a design problem and distinguish reversible changes from irreversible migrations.
• Record approvals, plans, execution identities, outcomes, and audit evidence.
• Prefer reusable modules and golden paths, but provide a controlled exception process.
• Design self-service around complete lifecycle operations, not only provisioning.
• Use progressive delivery where blast radius can be reduced through staged exposure.
• Measure platform outcomes such as lead time, change failure rate, recovery time, adoption, cost, and developer effort.

Chapter Summary

CI/CD turns IaC changes into a repeatable lifecycle of validation, planning, review, approval, application, verification, and audit. Terraform plans and Ansible previews make intended changes visible, but neither replaces risk-based judgment. GitOps extends version-controlled desired state with automated reconciliation, commonly using pull-based agents that reduce direct deployment access while introducing drift and emergency-management considerations.

Platform engineering packages IaC, policies, workflows, and operational defaults into an internal developer platform. Self-service infrastructure and golden paths reduce cognitive load when they are easy to use, governed by guardrails, and maintained as products. Progressive delivery limits blast radius by releasing changes in stages and using reliable health signals. The strategic objective is not maximum automation; it is trustworthy, observable, secure, and efficient change at organizational scale.

Key Terms

CI/CD: Practices and automated workflows for integrating, validating, releasing, and deploying software or infrastructure changes.

Infrastructure as Code: The declarative or procedural management of infrastructure through machine-readable configuration.

Plan: A preview of infrastructure actions proposed by a tool such as Terraform before execution.

Drift: A difference between declared configuration and the actual state of an environment.

State: Recorded information that helps an IaC tool relate configuration to managed resources.

GitOps: An operating model in which version-controlled desired state drives automated reconciliation of environments.

Reconciliation: The process of comparing actual state with desired state and correcting differences.

Pull-based delivery: A model in which an agent in the target environment retrieves and applies approved configuration.

Push-based delivery: A model in which an external pipeline connects to a target environment and deploys changes.

Platform engineering: The discipline of building internal platforms that provide reusable, governed capabilities to development teams.

Internal Developer Platform: An internal product combining tools, workflows, interfaces, and controls for developer self-service.

Self-service infrastructure: Provisioning and operating infrastructure through approved interfaces without manual platform-team intervention for every request.

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

Policy as code: Machine-evaluable rules that enforce security, compliance, architecture, or cost requirements.

Progressive delivery: Releasing a change gradually while using feedback to decide whether to continue, pause, or reverse it.

Canary release: A staged release that exposes a change to a limited population before wider deployment.

Immutable artifact: A versioned build output whose contents do not change after publication.

Idempotence: The property that repeating an operation produces the intended stable result without unintended additional changes.

Blast radius: The extent of systems, users, or resources affected by a failure or change.

Audit trail: A record linking actions, identities, approvals, timestamps, inputs, and outcomes for accountability.

Review Questions

Short Answer Questions

1. What is the purpose of generating a Terraform plan before approval?

2. How does GitOps differ from a conventional push-based deployment pipeline?

3. Why is Terraform state a security and governance concern?

4. Define a golden path in the context of platform engineering.

5. What is meant by progressive delivery?

Long Answer Questions

1. Explain the stages of a mature IaC pipeline from source change through audit, and discuss the purpose of each stage.

2. Compare CI/CD and GitOps as infrastructure delivery models, including their security and operational trade-offs.

3. Explain how an internal developer platform can provide self-service infrastructure without eliminating governance.

4. Discuss the role of platform engineering in reducing developer cognitive load and improving organizational scalability.

5. Analyze why rollback is not always a simple reversal of a previous commit, particularly for stateful systems and data migrations.

Analytical / Application Questions

1. A production plan proposes replacing a database instance and modifying its network policy. Design an approval, execution, verification, and recovery workflow for this change.

2. An organization’s GitOps controller repeatedly restores a misconfigured resource after an administrator applies an emergency fix. Analyze the conflict and propose a safe operating procedure.

3. A platform team has low adoption of its golden path because provisioning takes several days and supported options are highly restrictive. Recommend changes using the principles of self-service, governance, and platform-as-product thinking.

22. Multiple Choice Questions with Answers

Question 1

Which sequence best represents a governed IaC delivery workflow?

A. Apply, plan, review, validate, audit

B. Validate, plan, review, approve, apply, verify, audit

C. Review, apply, validate, approve, rollback

D. Audit, apply, merge, plan, verify

Correct Answer: B. Validate, plan, review, approve, apply, verify, audit

Question 2

Why should an approved Terraform plan be retained and linked to the commit under review?

A. To eliminate the need for testing

B. To ensure the executed change corresponds to the reviewed intent

C. To permit unrestricted state modification

D. To replace cloud audit logs

Correct Answer: B. To ensure the executed change corresponds to the reviewed intent

Question 3

Which characteristic most specifically distinguishes GitOps from merely storing IaC in Git?

A. Use of multiple programming languages

B. Continuous reconciliation of actual state with version-controlled desired state

C. Mandatory manual deployment from a laptop

D. Prohibition of automated testing

Correct Answer: B. Continuous reconciliation of actual state with version-controlled desired state

Question 4

A platform team exposes only approved regions, sizes, encryption settings, and tags through a provisioning interface. What is this primarily an example of?

A. Guardrailed self-service infrastructure

B. Uncontrolled infrastructure sprawl

C. Manual change management

D. Blue-green application deployment

Correct Answer: A. Guardrailed self-service infrastructure

Question 5

Which statement about rollback is most accurate?

A. Every infrastructure change can be reversed by reverting the Git commit

B. Rollback is unnecessary when a pipeline succeeds

C. Data migrations and destructive changes may require a forward fix or recovery procedure

D. Rollback should be designed only after an incident occurs

Correct Answer: C. Data migrations and destructive changes may require a forward fix or recovery procedure

Question 6

A pipeline passes syntax checks, but its plan opens a production database to the public internet. What should happen next?

A. Apply automatically because validation succeeded

B. Ignore the plan because syntax is correct

C. Reject or escalate the change through policy and security review

D. Delete the state file and retry

Correct Answer: C. Reject or escalate the change through policy and security review

Question 7

Which feature most directly supports progressive delivery?

A. Applying a high-impact change globally without observation

B. Releasing to a limited region or traffic segment and evaluating defined health signals

C. Removing monitoring to reduce pipeline complexity

D. Allowing every team to bypass the platform

Correct Answer: B. Releasing to a limited region or traffic segment and evaluating defined health signals

Question 8

Why should an internal developer platform be treated as a product?

A. Because it requires no users or maintenance

B. Because it has users, supported journeys, quality expectations, feedback, and a lifecycle

C. Because it must be implemented as a commercial product

D. Because product teams should own all cloud credentials

Correct Answer: B. Because it has users, supported journeys, quality expectations, feedback, and a lifecycle

Question 9

Which control best reduces the risk of a pipeline exposing long-lived cloud credentials?

A. Embedding credentials in Terraform variables

B. Printing credentials in job logs for auditing

C. Using short-lived credentials and least-privilege workload identity

D. Storing credentials in a public repository

Correct Answer: C. Using short-lived credentials and least-privilege workload identity

Question 10

A second Ansible run reports unintended changes to the same hosts. Which property is likely missing or defective?

A. Idempotence

B. Canary routing

C. Artifact signing

D. Branch protection

Correct Answer: A. Idempotence