14. Enterprise Strategy, Ethics and Emerging IaCIntroduction and ContextInfrastructure as Code (IaC) is often introduced as a technical method for defining servers, networks, policies, and platform services in machine-readable form. At enterprise scale, however, IaC becomes more than a provisioning technique. It becomes an operating model for expressing infrastructure decisions, governing change, distributing responsibility, and connecting technology investment with organizational strategy. Terraform, Ansible, and related tools allow organizations to replace undocumented manual procedures with repeatable, reviewable, and automatable workflows. Yet automation does not automatically produce good outcomes. Poorly designed automation can reproduce insecure assumptions, accelerate waste, conceal accountability, or create dependence on a particular vendor or platform. Consequently, enterprise IaC requires a balanced approach involving architecture, governance, economics, professional ethics, workforce development, and continuous evaluation of emerging technologies. This chapter examines how organizations can adopt IaC strategically, establish operating models and standards, construct business cases, and address questions of accountability, sustainability, vendor lock-in, and ethical automation. It also considers AI-assisted coding, autonomous remediation, intent-based infrastructure, and other developments that may alter the relationship between engineers and provisioning systems. Learning ObjectivesAfter completing this chapter, the learner should be able to: 1. Develop an enterprise roadmap for IaC adoption and transformation. 2. Compare centralized, federated, and platform-oriented IaC operating models. 3. Design standards, governance controls, and decision rights for Terraform and Ansible environments. 4. Construct a business case using cost, risk, productivity, resilience, and strategic-value arguments. 5. Evaluate vendor lock-in, workforce, sustainability, ethical, and accountability issues. 6. Assess AI-assisted infrastructure coding, autonomous remediation, and intent-based infrastructure. 7. Analyze an enterprise case and recommend an appropriate implementation strategy. From Automation Tool to Enterprise CapabilityIn a small team, IaC may mean a Terraform repository, an Ansible playbook, and a deployment pipeline. In a large organization, it includes a lifecycle: requirements, design, code creation, testing, approval, deployment, monitoring, change management, and retirement. The enterprise capability therefore consists of people, processes, platforms, policies, and technical assets. A useful distinction is between automation and industrialization. Automation performs a task without manual intervention. Industrialization creates a repeatable system in which the task is standardized, measured, governed, and continuously improved. An organization that allows every team to write independent modules may be highly automated but poorly industrialized. It can suffer from incompatible conventions, duplicated effort, inconsistent security, and uncontrolled cloud expenditure. IaC also changes the location of knowledge. In a manual environment, operational expertise may reside in individuals who know which console settings to change. In an IaC environment, knowledge is expected to reside in code, module interfaces, documentation, version history, and policy. This improves organizational memory, but only when code is understandable, maintained, and accessible to the people responsible for operating it. The strategic question is not simply, “Which tool should be adopted?” It is, “What kind of infrastructure operating capability does the organization need, and how can IaC support that capability?” Enterprise Adoption as a Transformation RoadmapIaC adoption should be staged rather than treated as a single migration project. A practical roadmap normally begins with discovery and alignment, proceeds through controlled adoption, and eventually develops into a platform and governance capability. Stage One: Establish the BaselineThe organization first inventories infrastructure, deployment methods, ownership, compliance obligations, and major sources of operational risk. It should identify which resources are manually created, which are already scripted, and which systems are too critical for immediate conversion. Baseline measures may include provisioning time, deployment failure rate, mean time to recover, configuration drift, change-related incidents, and infrastructure cost variance. This stage should also identify stakeholders. Infrastructure, security, application development, finance, procurement, risk, audit, and business owners may have different expectations. IaC introduced solely by a technical team can later encounter resistance because it affects approval rights, operational roles, and financial controls. Stage Two: Select Pilots with Strategic ValueA pilot should be significant enough to demonstrate value but bounded enough to control risk. Suitable candidates may include development environments, standardized application platforms, disaster-recovery environments, or repeatable cloud accounts. Highly regulated production systems with undocumented dependencies are usually poor first pilots. The pilot should have explicit success criteria. For example, the organization may target a reduction in environment creation time, improved recovery reproducibility, or elimination of a defined class of configuration errors. A pilot that merely produces code without measurable operational improvement provides weak evidence for wider investment. Stage Three: Standardize and ScaleOnce a pilot demonstrates value, the organization develops reusable modules, playbook conventions, repository structures, testing practices, and pipeline controls. Terraform modules may provide approved network, identity, database, or compute patterns. Ansible roles may provide hardened operating-system configurations or application deployment procedures. Scaling requires attention to interfaces. A module should expose only the variables that consumers legitimately need and should establish safe defaults. Excessive flexibility produces a module that is difficult to test and govern. Standardization should not remove all local choice; rather, it should establish a secure and supportable default while documenting exceptions. Stage Four: Create a Platform Operating ModelAt maturity, teams consume infrastructure through paved roads, templates, service catalogs, and self-service interfaces. A platform team maintains common capabilities, while product teams retain responsibility for the services they run. Governance becomes increasingly automated through policy-as-code, continuous validation, cost controls, and evidence collection. Maturity should not be measured by the number of repositories or lines of code. More meaningful indicators include the percentage of infrastructure managed declaratively, the reliability of automated changes, the proportion of resources covered by ownership metadata, the speed of compliant delivery, and the reduction of unplanned manual intervention. Operating Models and Decision RightsAn enterprise must decide who owns standards, modules, pipelines, exceptions, and production outcomes. Three operating models are common. In a centralized model, a core infrastructure team owns most IaC code and deployment processes. This promotes consistency and may be appropriate where skills are scarce or regulatory control is strong. Its weakness is that a central team can become a bottleneck and may not understand every application domain. In a federated model, individual product or business teams own their infrastructure code within enterprise-wide standards. A central enablement group provides frameworks, reference architectures, training, and guardrails. This model improves domain responsiveness but requires strong capability management and consistent controls. A platform-oriented model treats infrastructure as an internal product. The platform team offers documented, versioned capabilities, such as a compliant Kubernetes environment, a database service, or an application delivery pattern. Product teams consume these capabilities through self-service interfaces. The platform team is accountable for usability, reliability, and lifecycle management; consuming teams remain accountable for the applications and data they deploy. These models are not mutually exclusive. An enterprise may centralize identity and networking, federate application deployment, and use a platform model for common runtime services. The important issue is clarity of decision rights. A responsibility matrix should identify who designs a standard, approves an exception, maintains a module, responds to a failed deployment, and accepts residual risk. Standards, Governance, and Control DesignGovernance should enable safe delivery rather than simply add approval steps. A strong control environment places routine controls in automated pipelines and reserves human judgment for unusual or consequential decisions. Standards commonly address naming, tagging, repository structure, module versioning, secrets handling, state management, environment separation, identity permissions, logging, backup, network exposure, encryption, and retirement. They should be written as enforceable and testable requirements wherever possible. “Use secure configurations” is less useful than a policy stating that storage resources must not be publicly accessible unless an approved exception exists. A mature IaC pipeline may include the following control layers: - formatting and syntax validation;
- static analysis and security scanning;
- unit and integration tests;
- plan review and policy-as-code checks;
- approval based on risk and environment;
- controlled application of changes;
- post-deployment verification and drift detection.
Terraform state deserves particular governance attention because it may contain sensitive values and represents the organization’s understanding of managed resources. Remote state should use access control, encryption, locking, backup, and an appropriate separation of environments. Ansible requires equivalent care for inventories, credentials, become privileges, vault keys, and execution logs. Change approval should be risk-based. A routine change to a versioned, tested module may be automatically approved, whereas a change to an identity boundary, production network route, or regulated data store may require additional review. Approval should not be confused with accountability: the person who clicks an approval button is not necessarily the only person responsible for the design or outcome. Building the Business CaseThe business case for IaC should not rely solely on labor reduction. In many organizations, the most important benefits are improved reliability, faster recovery, auditability, reduced deployment risk, and the ability to provide environments consistently across regions or teams. A basic economic model can compare the total cost of the current operating approach with the cost of IaC adoption and operation. Costs include tooling, training, platform engineering, migration, testing, support, and potentially duplicated operation during transition. Benefits may include reduced manual effort, fewer incidents, shorter delivery cycles, lower recovery costs, and improved resource utilization. Financial analysis should distinguish between efficiency, avoidance, and enablement. Efficiency reduces the resources required for an existing activity. Avoidance prevents expected losses, such as outages or audit findings. Enablement creates new capacity, such as launching products in additional regions or allowing teams to provision compliant environments independently. Enablement benefits may be strategically important even when they are difficult to express as immediate savings. A credible business case includes baseline data, assumptions, risks, sensitivity analysis, and a measurement plan. For example, a claim that IaC will reduce provisioning time by 80 percent should identify the current process, the environments included, the dependencies excluded, and the conditions under which the target is measured. Benefits should be reviewed after implementation rather than treated as permanent assumptions. Skills, Culture, and Organizational ChangeIaC adoption changes professional roles. System administrators need software engineering practices such as version control, testing, code review, and modular design. Developers need greater awareness of operating-system configuration, networking, identity, resilience, and cost. Managers need to understand that a successful transformation may initially reduce visible delivery speed because teams are learning new practices and building foundations. Training should be complemented by communities of practice, reference repositories, pairing, internal documentation, and accessible expert support. Organizations should avoid measuring engineers only by the volume of infrastructure code produced. A short, reusable module that prevents repeated errors may be more valuable than thousands of lines of duplicated configuration. Cultural change is especially important where manual intervention has historically been treated as evidence of expertise. IaC may expose undocumented dependencies and challenge informal authority. Leaders should frame standardization as a means of reducing avoidable operational risk, not as a judgment on individuals. At the same time, automation must not remove the possibility of a controlled emergency response when a system is unavailable and the normal path cannot function. Vendor Lock-In and PortabilityIaC can reduce lock-in by making infrastructure definitions portable and visible, but it can also deepen lock-in. Terraform configurations may depend heavily on a cloud provider’s proprietary services, provider-specific resource models, or a particular state and workflow ecosystem. Ansible playbooks may be portable at the operating-system level while still depending on vendor-specific APIs or managed services. Portability is not an absolute virtue. A multi-cloud design may increase complexity, reduce the benefits of specialized services, and create duplicated skills and controls. The relevant question is whether the organization has a deliberate level of dependence that matches its strategy. A lock-in assessment should examine: - proprietary services and data formats;
- exit costs and migration time;
- availability of alternative providers;
- portability of data and state;
- contractual terms and support arrangements;
- internal skills required to operate alternatives.
Mitigation may include abstraction at selected boundaries, open formats, documented export procedures, modular architecture, provider version pinning, and periodic recovery or migration exercises. Abstraction should be used selectively. Hiding every provider-specific feature behind a generic interface can create a lowest-common-denominator platform that satisfies no major workload well. Ethics, Accountability, and Responsible AutomationInfrastructure automation affects users, employees, customers, and the public. Ethical analysis therefore extends beyond technical security. An automated decision to deny access, remove a resource, alter a network route, or scale down capacity may affect business continuity, privacy, safety, or employment. Four principles are particularly important. Responsibility requires identifiable owners for automated systems and their outcomes. Transparency requires that significant actions can be explained through code, policy, logs, and decision records. Proportionality requires controls and automation intensity to match the potential harm. Contestability requires a means to challenge, reverse, or review an automated decision. Automation can reproduce bias when its policies encode unequal assumptions. For instance, an access-control workflow that treats contractors as inherently untrusted may be unjustified if it is not based on role, risk, or actual need. Likewise, automated remediation that terminates resources based on incomplete cost data can disproportionately affect teams with unusual but legitimate workloads. Ethical IaC also includes honesty in audit evidence. Automatically generated compliance reports should not be presented as proof that a control is effective if they only show that a configuration value exists. Organizations must distinguish between a control being configured, operating, and achieving its intended outcome. Sustainability and Infrastructure ResponsibilityIaC can support sustainability by making resource ownership visible, enforcing expiration policies for temporary environments, selecting efficient instance types, and enabling repeatable measurement. It can also increase consumption if automation makes it effortless to create idle environments or duplicate services. Sustainability should be considered across the lifecycle: design, deployment, operation, scaling, and retirement. Useful controls include mandatory cost and ownership tags, scheduled shutdown of non-production resources, rightsizing analysis, retention limits, and policy checks for unnecessary duplication. Environmental impact cannot be inferred solely from cloud cost, because price and energy use are related but not identical measures. A responsible organization therefore treats sustainability as a design constraint and a reporting requirement. Teams should be able to explain why resources exist, who owns them, how long they are expected to live, and what evidence supports their selected capacity. AI-Assisted IaC and Autonomous RemediationGenerative AI can assist with Terraform resources, Ansible tasks, documentation, test generation, error interpretation, and migration analysis. Its value is highest when it reduces routine work while leaving architectural judgment and accountability with qualified people. AI-generated infrastructure code must be treated as an untrusted draft. Models may invent resource arguments, use insecure defaults, misunderstand provider versions, omit dependencies, or generate code that appears plausible but does not represent the organization’s policy. AI tools may also expose confidential configuration or proprietary code if prompts and integrations are not governed. A safe workflow places AI assistance inside existing controls: approved tools, restricted data, version control, static analysis, policy checks, testing, peer review, and controlled deployment. Provenance should be recorded where necessary, particularly for regulated or safety-sensitive changes. Autonomous remediation extends the idea by allowing a system to detect and correct an issue without human approval. It is appropriate for low-risk, reversible, well-understood conditions, such as restarting a failed stateless process or applying a known configuration correction. It is inappropriate to grant unrestricted authority to delete resources, change identity policies, or modify production data based on uncertain signals. A useful autonomy classification is: - advisory: the system recommends an action;
- assisted: the system prepares a change for human approval;
- bounded autonomous: the system acts within explicit limits and rollback conditions;
- fully autonomous: the system chooses and executes changes with minimal intervention.
Most enterprise environments should expand autonomy gradually, using evidence from incidents, false positives, rollback performance, and business impact. Intent-Based Infrastructure and Evolving ProvisioningTraditional IaC describes desired resources through declarative configuration. Intent-based infrastructure moves one level higher by expressing an outcome, such as “provide a highly available service with defined recovery objectives and a maximum cost,” while an engine selects implementation details. This approach resembles policy-driven and model-driven management. Its promise is reduced cognitive load and greater consistency. Its difficulty is that intent must be precise enough to evaluate. “Secure and scalable” is not an executable intent unless the organization defines security conditions, scale thresholds, availability targets, data locations, and acceptable trade-offs. Future provisioning systems are likely to combine declarative configuration, policy engines, event-driven operations, telemetry, optimization algorithms, and AI agents. The boundary between provisioning and operations may become less distinct: systems will not only create infrastructure but continuously compare observed state with organizational intent. This development increases the importance of explainability and control. Enterprises will need to know which policy led to a change, what alternatives were rejected, what data informed the decision, and how the action can be reversed. More autonomous infrastructure requires more disciplined governance, not less. Illustrative Case: Northstar Retail’s IaC TransformationBackgroundNorthstar Retail is a fictional multinational retailer operating customer-facing web applications, warehouse systems, and analytics platforms across several regions. Development teams provision cloud resources independently, while a central operations group manages production. The company uses Terraform for cloud resources and Ansible for server configuration, but practices vary substantially between teams. Situation and ProblemEnvironment creation can take several weeks because requests pass through multiple manual queues. Production incidents reveal configuration drift between regions. Security audits identify inconsistent identity permissions and incomplete ownership tags. Finance also reports a large number of idle development resources. A proposal is made to standardize all infrastructure immediately through a central Terraform team. AnalysisThe proposed central model would improve consistency but would create a bottleneck and fail to address application-team ownership. Interviews reveal that teams lack reusable patterns, testing knowledge, and clear boundaries. The organization also depends on several provider-specific managed services; attempting to remove all lock-in would delay the transformation without producing proportional value. Northstar establishes baseline measures for provisioning lead time, drift, failed changes, recovery time, resource ownership, and non-production cost. It selects a low-risk but representative pilot: a standardized application environment used by three development teams. Approach and StrategyNorthstar adopts a hybrid platform model. A central enablement group owns approved modules, pipeline templates, security policies, and training. Product teams own their application stacks and contribute improvements through a review process. Network connectivity, identity boundaries, and regulated data services remain subject to central architecture controls. The platform introduces versioned Terraform modules, Ansible roles for hardened hosts, remote state with locking and access control, mandatory tagging, secret-management integration, and policy checks. Routine development changes can proceed through automated validation, while production identity and network changes require risk-based approval. To address sustainability and cost, temporary environments receive expiration metadata and scheduled shutdown policies. Exceptions are recorded with an owner, justification, expiry date, and compensating control. An AI coding assistant is permitted only within an approved enterprise environment; generated code must pass the same tests and reviews as human-written code. OutcomeThe pilot demonstrates faster environment creation, more consistent configuration, and improved visibility of resource ownership. The organization does not claim that every result is caused solely by Terraform or Ansible; it attributes improvement to the combined effect of standard modules, pipeline controls, training, and clearer accountability. After the pilot, Northstar expands the platform gradually and retains provider-specific services where they create demonstrable business value. Learning PointsThe case illustrates that enterprise IaC is an operating-model decision. Central standards and federated ownership can coexist. Metrics must include reliability, governance, cost, and delivery outcomes. AI assistance is valuable only when embedded in established controls. Finally, portability and sustainability should be managed as explicit design considerations rather than afterthoughts. Risks, Limitations, and Common MistakesA frequent mistake is beginning with tool selection instead of operating-model design. Another is migrating manual procedures into code without simplifying them. This produces automated complexity rather than improved capability. Other risks include unmanaged state, excessive privileges in pipelines, secrets committed to repositories, untested modules, uncontrolled module dependencies, insufficient rollback planning, and failure to retire obsolete resources. Drift detection can identify differences, but automatically overwriting manual changes may destroy legitimate emergency fixes. Teams should establish how drift is classified, investigated, and reconciled. IaC also has limits. It cannot by itself resolve unclear ownership, poor architecture, inadequate monitoring, or conflicting business priorities. Declarative code may describe the intended state without proving that the service is healthy or that users are receiving acceptable performance. Infrastructure tests can reduce risk but cannot eliminate uncertainty in distributed systems. Best-Practice PrinciplesA durable enterprise approach can be summarized through the following principles: 1. Begin with measurable business and operational problems. 2. Treat IaC as a capability and operating model, not merely a tool. 3. Establish ownership, decision rights, and exception processes early. 4. Prefer secure, tested, versioned reusable patterns over duplicated configuration. 5. Place routine governance controls in automated pipelines. 6. Keep human review for high-impact, uncertain, or irreversible decisions. 7. Measure outcomes such as reliability, recovery, cost, and delivery speed. 8. Design for appropriate portability rather than theoretical independence from all vendors. 9. Make resource lifecycle, sustainability, and retirement explicit. 10. Treat AI-generated code and autonomous actions as risk-bearing engineering outputs. Chapter SummaryEnterprise IaC is a strategic capability that combines declarative configuration with governance, operating models, skills, platforms, and accountability. Successful adoption usually progresses from baseline assessment and bounded pilots to reusable standards, platform services, and policy-driven self-service. Centralized, federated, and platform-oriented models each provide different balances of consistency, autonomy, and responsiveness. A sound business case considers efficiency, risk avoidance, resilience, auditability, and strategic enablement rather than labor savings alone. Governance should be automated where possible and risk-based where human judgment is required. Vendor lock-in should be assessed deliberately, while sustainability requires visibility, lifecycle controls, and capacity discipline. Ethical IaC demands responsibility, transparency, proportionality, and contestability. AI-assisted coding and autonomous remediation can improve productivity, but generated or automated changes require testing, policy enforcement, review, and bounded authority. Intent-based infrastructure may raise the level of abstraction from resource declaration to business outcomes, making explainability and reversible control increasingly important. Key TermsIaC: The practice of defining and managing infrastructure through machine-readable, version-controlled specifications. Operating model: The arrangement of people, processes, technology, and decision rights through which work is performed. Platform team: A team that provides reusable internal technology capabilities as products for consuming teams. Policy-as-code: Machine-readable rules that automatically evaluate or enforce governance and security requirements. Configuration drift: A difference between declared infrastructure state and the state actually deployed or observed. Remote state: Centrally stored IaC state used for collaboration, locking, backup, and controlled access. Risk-based approval: Approval whose level of scrutiny depends on the potential impact and reversibility of a change. Vendor lock-in: Dependence on a provider, tool, or ecosystem that makes replacement difficult or costly. Portability: The ability to move workloads, configurations, or data between platforms with limited redesign. Paved road: An approved, supported, and relatively easy path for delivering a common technical capability. Autonomous remediation: Automated detection and correction of an operational condition without direct human execution. Intent-based infrastructure: Infrastructure management in which desired outcomes or constraints guide implementation choices. Contestability: The ability to question, review, appeal, or reverse an automated decision. Provenance: Information about the origin, history, tools, and transformations associated with an artifact or change. Sustainability control: A policy or practice that limits unnecessary resource use and supports environmental responsibility. Exception management: The formal process for authorizing, recording, reviewing, and expiring deviations from standards. Infrastructure industrialization: The standardization, measurement, governance, and continuous improvement of infrastructure operations. Residual risk: The risk remaining after controls and mitigation measures have been applied. Review QuestionsShort Answer Questions1. Why should IaC be treated as an enterprise operating capability rather than only a provisioning tool? 2. Distinguish between a centralized and a federated IaC operating model. 3. What is the purpose of policy-as-code in an IaC pipeline? 4. Identify two risks associated with AI-generated infrastructure code. 5. What does contestability mean in the context of ethical automation? Long Answer Questions1. Explain the stages of an enterprise IaC adoption roadmap and the measures that can be used to evaluate progress. 2. Discuss how an organization can design standards and governance controls without turning the IaC function into a delivery bottleneck. 3. Analyze the financial and strategic dimensions of an IaC business case. 4. Examine vendor lock-in and portability as strategic decisions rather than purely technical problems. 5. Discuss the ethical and accountability requirements for autonomous infrastructure remediation. Analytical / Application Questions1. An enterprise has independent Terraform repositories, inconsistent Ansible practices, rising cloud costs, and frequent production drift. Recommend an operating model and a two-year adoption strategy, explaining your decision rights and control mechanisms. 2. A proposed AI agent can automatically remove resources that violate cost policy. Evaluate the proposal using risk, reversibility, accountability, and contestability criteria, and design safer operating boundaries. 3. A company wants to become fully multi-cloud to avoid vendor lock-in. Using the concepts in this chapter, assess the proposal and recommend what should be abstracted, what may remain provider-specific, and how the decision should be reviewed over time. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best describes the difference between IaC automation and infrastructure industrialization? A. Automation uses cloud services, whereas industrialization uses on-premises systems. B. Automation performs tasks automatically, whereas industrialization also standardizes, measures, governs, and improves them. C. Automation is declarative, whereas industrialization is always imperative. D. Automation is used by developers, whereas industrialization is used only by auditors. Correct Answer: B. Automation performs tasks automatically, whereas industrialization also standardizes, measures, governs, and improves them. Question 2Which operating model gives product teams ownership while a central group provides standards, enablement, and guardrails? A. Fully centralized model B. Unmanaged model C. Federated model D. Manual operations model Correct Answer: C. Federated model Question 3Which control is most appropriate for protecting Terraform remote state? A. Storing state in an unrestricted public repository B. Disabling state locking to increase speed C. Using access control, encryption, locking, and backup D. Allowing every engineer to edit state directly Correct Answer: C. Using access control, encryption, locking, and backup Question 4Why should an IaC business case include enablement benefits? A. They demonstrate that all engineers can be replaced. B. They capture new organizational capacity, such as launching services in additional regions. C. They eliminate the need for baseline measurements. D. They prove that vendor lock-in has been removed. Correct Answer: B. They capture new organizational capacity, such as launching services in additional regions. Question 5Which situation is the strongest candidate for bounded autonomous remediation? A. Deleting a production database after an uncertain anomaly B. Changing identity boundaries without approval C. Restarting a failed stateless process under defined conditions with rollback controls D. Moving regulated data to another region automatically Correct Answer: C. Restarting a failed stateless process under defined conditions with rollback controls Question 6What is a central ethical requirement for significant automated infrastructure decisions? A. The decision must always be made by an AI model. B. The decision must be irreversible to prevent human interference. C. There must be identifiable responsibility and a means of review or reversal. D. The decision must optimize cost above all other objectives. Correct Answer: C. There must be identifiable responsibility and a means of review or reversal. Question 7Which approach best addresses vendor lock-in strategically? A. Avoid every provider-specific service regardless of business value. B. Use deliberate portability measures and assess exit costs against the value of specialization. C. Use several cloud providers for every workload. D. Rely on undocumented migration procedures until an exit is required. Correct Answer: B. Use deliberate portability measures and assess exit costs against the value of specialization. Question 8Why can mandatory expiration metadata support sustainability? A. It guarantees that all workloads use renewable energy. B. It identifies temporary resources that can be reviewed or shut down when no longer needed. C. It removes the need for capacity planning. D. It prevents all production scaling. Correct Answer: B. It identifies temporary resources that can be reviewed or shut down when no longer needed. Question 9How should AI-generated Terraform or Ansible code normally be treated? A. As trusted production code because it was generated automatically B. As an untrusted draft subject to testing, scanning, review, and policy controls C. As documentation rather than executable material D. As exempt from normal change-management procedures Correct Answer: B. As an untrusted draft subject to testing, scanning, review, and policy controls Question 10What is the principal challenge of intent-based infrastructure? A. It cannot express any desired state. B. It requires precise, testable definitions of outcomes, constraints, and trade-offs. C. It eliminates the need for monitoring. D. It works only with manually configured servers. Correct Answer: B. It requires precise, testable definitions of outcomes, constraints, and trade-offs.
|
