12. Governance, Compliance and Responsible OperationsIntroduction and ContextKubernetes changes the operational boundary of a software organisation. Applications are no longer deployed manually to identifiable servers; instead, desired states are declared through manifests, reconciled by controllers, and distributed across clusters, clouds, regions, and teams. This elasticity creates substantial operational value, but it also creates governance challenges. A misconfigured admission policy, an overprivileged service account, an unencrypted secret, or an unrecorded production change can affect thousands of workloads within minutes. Governance in a cloud-native environment is therefore not limited to approval committees or periodic audits. It is the continuous design of decision rights, technical controls, evidence, accountability, and ethical safeguards. Compliance is the demonstrable alignment of operations with laws, regulations, contractual commitments, and internal policies. Responsible operations extend this idea further by asking whether a technically permitted action is safe, fair, proportionate, sustainable, accessible, and consistent with professional duty. This chapter examines how organisations establish secure Kubernetes baselines, express policy as code, maintain auditability, assign risk ownership, govern data, and manage regulatory and ethical responsibilities. It also considers privacy, sustainability, accessibility, artificial-intelligence-related risks, shared responsibility, and decision-making under operational pressure. The central argument is that governance is most effective when embedded in engineering workflows rather than added as an external inspection layer. Learning ObjectivesBy the end of this chapter, students should be able to: 1. Explain governance, compliance, assurance, and responsible operations in a Kubernetes context. 2. Design a policy-as-code approach using preventive, detective, and corrective controls. 3. Establish a secure and auditable Kubernetes baseline. 4. Allocate risk ownership across platform, application, security, data, and cloud teams. 5. Apply data-governance and privacy principles to cloud-native workloads. 6. Analyse regulatory, sustainability, accessibility, and AI-related operational risks. 7. Evaluate shared-responsibility boundaries and make defensible operational decisions. 8. Recommend practical governance improvements for a cloud-native organisation. Governance as an Operating CapabilityGovernance answers four connected questions: who may decide, what standards apply, how decisions are enforced, and what evidence demonstrates that obligations have been met. In Kubernetes, these questions apply to cluster creation, namespace ownership, image selection, workload deployment, secret management, network access, data retention, incident response, and decommissioning. Compliance should not be confused with security. Security seeks to reduce threats and protect confidentiality, integrity, and availability. Compliance establishes obligations and evidence, which may include security controls but may also cover privacy, records management, accessibility, financial controls, or sector-specific requirements. A system can be compliant with a narrow audit requirement and still be insecure; conversely, a secure system may lack the documentation or evidence required by a regulator. Responsible operations add a human and societal dimension. They require teams to consider foreseeable harm, affected stakeholders, proportionality, transparency, and the reversibility of decisions. For example, automatically deleting unused persistent volumes may reduce cost but could destroy records subject to retention requirements. Automatically blocking every unapproved image may improve consistency but could delay a critical medical service if emergency exceptions are impossible. Good governance therefore combines standardisation with controlled discretion. A useful governance model has three layers: - Direction: policies, risk appetite, legal obligations, architecture principles, and organisational values.
- Control: technical mechanisms that prevent, detect, or correct undesirable behaviour.
- Assurance: evidence, testing, reviews, metrics, and independent assessment.
These layers should operate across the lifecycle: design, build, deploy, run, change, incident response, and retirement. Policy-as-Code and the Control Plane of GovernancePolicy-as-code represents organisational rules in machine-evaluable form. Instead of stating only that “production workloads must use approved images,” an organisation can encode rules that verify image provenance, vulnerability status, signing, registry origin, and exception expiry. Policy-as-code makes governance repeatable and enables controls to run in development pipelines as well as at cluster admission. A mature policy model distinguishes three control types. Preventive controls stop a prohibited action, such as rejecting a deployment that requests privileged access. Detective controls identify an existing violation, such as scanning running workloads for host-path mounts. Corrective controls restore an acceptable state, such as removing an exposed credential, rotating a secret, or isolating a compromised namespace. Relying only on prevention is unsafe because policies can be bypassed, misconfigured, or rendered ineffective by changes in the environment. Kubernetes admission control is a major enforcement point. Admission webhooks and policy engines can validate or mutate resources before they are persisted. Policies may require non-root execution, restrict host networking, enforce resource requests and limits, require labels for ownership and data classification, or prevent containers from using unapproved registries. However, admission policies should be designed carefully. A rule that is technically correct but impossible for developers to interpret will generate workarounds and exception requests. Policy quality can be assessed through five questions: 1. Is the rule linked to a specific risk or obligation? 2. Is the scope clear, including namespaces, workloads, and environments? 3. Is the policy enforceable at the earliest practical stage? 4. Is there an accountable owner and an exception process? 5. Can compliance be demonstrated through reliable evidence? Policies should be version-controlled, reviewed like software, tested against representative manifests, and released through controlled pipelines. A policy repository should record its purpose, severity, affected resources, enforcement mode, rationale, owner, review date, and exception procedure. Initially, organisations may run a policy in audit mode to measure impact before switching to enforcement. This staged approach reduces unexpected production disruption. Establishing a Secure Kubernetes BaselineA secure baseline is the minimum acceptable configuration for clusters and workloads. It is not a guarantee of security; rather, it establishes a consistent starting point from which risk can be assessed. Baselines should cover the control plane, nodes, identity, workloads, networking, supply chain, data, observability, and recovery. At the cluster level, administrators should restrict access to the API server, use strong identity federation and multi-factor authentication, separate administrative roles, and review cluster-admin assignments. The principle of least privilege should apply to human users, service accounts, controllers, and automation. Unused service-account tokens and legacy authentication paths should be removed or restricted. At the workload level, the baseline normally includes non-root execution where feasible, read-only root filesystems where compatible, dropped Linux capabilities, seccomp or equivalent system-call restrictions, explicit resource requests and limits, and avoidance of privileged containers. Network policies should express permitted communication rather than relying on implicit cluster-wide reachability. Namespaces should provide organisational separation, but they should not be treated as a complete security boundary for highly sensitive workloads. The software supply chain requires controls over source repositories, build systems, dependencies, container registries, image scanning, signing, provenance, and deployment approval. Image tags alone are weak evidence because tags can move. Immutable digests, trusted registries, signed artifacts, and build provenance provide stronger assurance. Vulnerability scanning is valuable but imperfect: a vulnerability database may not reflect exploitability in a particular configuration, and a clean scan does not prove that an image is trustworthy. Secrets deserve special treatment. Kubernetes Secret objects provide an interface for sensitive values, but base64 encoding is not encryption by itself. Organisations should use encryption at rest, external key management where appropriate, short-lived credentials, rotation, access logging, and controls that prevent secrets from entering images, source repositories, or ordinary logs. Data classification should determine where secrets and regulated data may be stored and processed. A baseline is incomplete without recovery. Backup policies should address cluster state, persistent data, encryption keys, retention, geographic considerations, restoration testing, and recovery objectives. An untested backup is an assumption, not an assurance control. Auditability, Evidence, and ObservabilityAuditability is the ability to reconstruct what happened, who or what initiated it, which policy applied, and whether the resulting action was authorised. Kubernetes audit logs can record API requests, identities, resources, verbs, timestamps, and response outcomes. These records become useful only when they are protected against unauthorised alteration, retained for an appropriate period, correlated with deployment and identity systems, and regularly reviewed. Evidence should be designed rather than collected accidentally. Examples include signed build records, deployment approvals, policy evaluation results, vulnerability findings, access reviews, backup restoration results, incident timelines, and records of exceptions. Evidence should demonstrate both control operation and control effectiveness. A policy file may show that a rule exists, but a report of successful evaluations and investigated violations provides stronger assurance. Observability supports governance when logs, metrics, traces, events, and audit records are connected to ownership and risk. Excessive logging can create privacy exposure and cost, while insufficient logging prevents investigation. Teams should define what must be logged, minimise sensitive content, synchronise time sources, control access, and establish retention and deletion rules. Audit data itself may contain personal information and must therefore be governed. A practical control-evidence matrix maps each requirement to its control, owner, implementation location, evidence source, frequency, and escalation path. This prevents the common mistake of discovering during an audit that a control exists operationally but cannot be demonstrated. Risk Ownership and Shared ResponsibilityRisk ownership means accepting accountability for a risk and ensuring that treatment decisions are made. It is different from performing the technical work. A platform team may implement network policy, but the application owner remains responsible for identifying required application communications. A security team may define encryption standards, while a data owner determines whether a dataset is sufficiently protected for its classification. A responsibility assignment matrix can clarify relationships among the cloud provider, platform engineering, security, application teams, data owners, privacy officers, compliance functions, and business leaders. The cloud provider may secure underlying facilities and managed control-plane components, but the customer remains responsible for identities, configurations, workloads, data, and often the security of interfaces between services. Managed Kubernetes reduces operational burden; it does not eliminate customer governance. Risk registers should describe the risk event, cause, affected assets, likelihood, impact, existing controls, treatment decision, owner, target date, and acceptance authority. Risk acceptance should be explicit, time-bound, and proportionate to the potential harm. An emergency exception may be justified during an outage, but it should include compensating controls, a rollback plan, and post-event review. A useful distinction is between technical ownership and business ownership. Technical owners maintain systems and controls. Business owners decide the acceptable level of service disruption, data exposure, financial loss, or regulatory risk. Confusing these roles can cause engineers to make unmandated risk decisions or managers to assume that technical teams have accepted risks on their behalf. Data Governance, Privacy, and Regulatory ControlsCloud-native data governance begins with knowing what data exists, where it flows, who may access it, how long it must be retained, and when it must be deleted. Data inventories and flow diagrams should include application databases, object storage, message queues, logs, backups, caches, replicas, test environments, and telemetry platforms. Replication and observability frequently create secondary copies that are overlooked in privacy assessments. Core privacy principles include purpose limitation, data minimisation, accuracy, retention limitation, confidentiality, transparency, and accountability. A workload should not collect or retain personal data merely because storage is inexpensive. Test environments should use synthetic or appropriately de-identified data. Logs should avoid personal content unless necessary, and access should be limited and monitored. Privacy impact assessments are useful when introducing new processing, cross-border transfer, behavioural analytics, biometric information, or automated decision-making. They should examine the purpose of processing, categories of data and subjects, threats, potential harms, safeguards, retention, data-subject rights, and residual risk. Technical controls may include encryption, tokenisation, pseudonymisation, field-level access, network segmentation, deletion workflows, and key separation. Regulatory controls vary by jurisdiction and sector, but recurring themes include access control, segregation of duties, change management, incident notification, records retention, resilience, third-party oversight, and evidence. Organisations should avoid treating a named framework as a checklist detached from actual risk. Compliance mappings are useful only when translated into operating controls and tested in context. Responsible Operations Beyond SecuritySustainabilityCloud-native elasticity can improve utilisation, but unnecessary replicas, oversized nodes, verbose telemetry, frequent image rebuilding, and inefficient data transfer can increase energy use and cost. Sustainable operations involve right-sizing, autoscaling based on meaningful signals, workload scheduling, efficient storage tiers, lifecycle policies, and measurement of resource consumption. Carbon-aware scheduling may be appropriate where service requirements permit, but availability, latency, data-residency, and fairness constraints must be respected. Cost optimisation and sustainability often overlap, but they are not identical. A cheaper region may have different energy characteristics or create unacceptable latency. Reducing replicas may lower consumption while undermining resilience. Responsible decisions evaluate service objectives, environmental impact, and user consequences together. Accessibility and InclusionOperational platforms and services should be usable by people with varied abilities. Accessibility includes user-facing applications, administrative consoles, incident communication, dashboards, documentation, and authentication processes. Automated systems should not assume that every operator can respond through a single visual or highly time-sensitive channel. Alerts should be actionable, available in accessible formats, and supported by clear escalation procedures. Accessibility also influences reliability. A runbook that depends on colour alone, unreadable graphs, or inaccessible command-line output can delay incident response. Inclusive design is therefore an operational control, not merely a product concern. Artificial Intelligence and Automation RisksAI-enabled systems and AIOps tools can summarise incidents, recommend remediation, classify data, or generate Kubernetes manifests. Their use introduces risks involving inaccurate recommendations, opaque reasoning, prompt injection, sensitive-data disclosure, automation bias, model drift, and excessive permissions. An AI system should not receive unrestricted cluster-admin access simply because it can generate commands. Controls should include bounded permissions, human approval for high-impact actions, separation between suggestion and execution, input and output logging, evaluation against representative incidents, protection of confidential data, and rollback mechanisms. Teams should identify whether AI outputs affect individuals, access decisions, safety-critical operations, or regulated processes. Human review must be meaningful: reviewers need sufficient time, information, authority, and competence to reject the recommendation. An Operating Model for GovernanceGovernance becomes sustainable when integrated into normal delivery. A practical lifecycle is as follows: 1. Establish obligations and risk appetite. Identify legal, contractual, business, customer, and ethical requirements. 2. Classify workloads and data. Assign criticality, sensitivity, recovery objectives, ownership, and geographic constraints. 3. Define the baseline. Specify mandatory identity, network, workload, supply-chain, logging, backup, and recovery controls. 4. Encode and test policies. Implement controls in source repositories, CI pipelines, admission layers, and continuous monitoring. 5. Deploy with evidence. Record approvals, policy results, artifact provenance, configuration state, and responsible owners. 6. Operate and measure. Monitor drift, access, incidents, exceptions, cost, sustainability, and control effectiveness. 7. Review and improve. Reassess risks after incidents, architectural changes, new regulations, and emerging technology. Maturity should be measured by outcomes rather than by the number of policies. Useful indicators include the proportion of workloads with accountable owners, mean time to remediate critical findings, percentage of deployments with provenance evidence, successful backup-restoration rate, aged exceptions, unauthorised access attempts, policy false-positive rates, and the time required to produce trustworthy audit evidence. Metrics should not incentivise concealment. For example, measuring only the number of blocked deployments may encourage teams to weaken policies; measuring recurrence, remediation quality, and justified exceptions is more informative. Illustrative Case Study: Regulated Healthcare PlatformBackgroundA fictional organisation, MedAxis, operates a multi-region Kubernetes platform supporting appointment services, clinical messaging, and analytics. The platform is managed by a central engineering team, while product teams deploy independently. Some workloads process sensitive health information, whereas others handle only public information. Situation and ProblemAn internal review finds that namespaces are inconsistently labelled, several services use long-lived credentials, production images are deployed by mutable tags, and audit logs are retained in the same account as application logs. A product team has copied production data into a test environment to reproduce a performance issue. The organisation cannot quickly identify who approved the copy, where all replicas exist, or whether deletion obligations have been met. AnalysisThe problem is not a single insecure setting. It is a governance failure involving classification, ownership, technical enforcement, evidence, and organisational incentives. The platform team owns cluster controls, but product and data owners have not been assigned clearly. The absence of labels prevents policy targeting and cost attribution. Mutable tags weaken release traceability. Shared log storage creates a risk that an attacker who compromises an application can alter evidence. The test-data copy creates privacy and retention concerns. Approach and StrategyMedAxis first classifies workloads into public, internal, confidential, and regulated categories, assigning a data owner and business criticality to each. A namespace admission policy requires ownership, data classification, environment, and recovery labels. Production deployments must reference immutable image digests and verified provenance. Policies deny privileged containers, uncontrolled host access, and service accounts without defined owners. Sensitive data is prohibited in ordinary test environments unless a documented exception is approved. Synthetic data generation and de-identification become the default. Encryption keys are separated from application accounts, and audit logs are exported to a protected, access-controlled store with retention and integrity controls. Short-lived workload credentials replace static secrets where supported. A data-flow inventory records primary, replica, backup, cache, and telemetry locations. The organisation introduces an exception register with an owner, reason, compensating control, expiry date, and approval authority. It also conducts restoration exercises and quarterly access reviews. Policies are first deployed in audit mode, allowing teams to correct labels and manifests before enforcement. Product owners receive dashboards showing violations and remediation deadlines. OutcomeThe platform gains consistent ownership and traceability. Deployment evidence can be linked to a commit, image digest, approver, policy decision, and workload identity. Test-data use becomes visible and controlled. The organisation does not eliminate all risk, but it reduces unmanaged risk and can explain residual risk to auditors, customers, and leadership. Learning PointsThe case demonstrates that compliance cannot be achieved by adding a scanner to an otherwise ungoverned platform. Data classification, ownership, policy enforcement, evidence protection, and operational behaviour must reinforce one another. It also shows why staged enforcement and usable developer feedback are important: governance that cannot be adopted will be bypassed. Challenges, Limitations, and Common MistakesOne common mistake is treating Kubernetes namespaces as equivalent to strong isolation. Isolation depends on identity, network policy, node configuration, storage, control-plane settings, and the sensitivity of the workload. Another is creating excessively broad policies that produce false positives. Developers then request repeated exceptions, and the control loses credibility. Organisations may also confuse documentation with governance. A policy that is not implemented, monitored, or evidenced is an aspiration. Conversely, technical enforcement without explanation can create opaque systems that operators circumvent. Excessive centralisation is another risk: a platform team may become a bottleneck and make decisions without sufficient business or data context. Audit logging can generate large volumes of sensitive information and should therefore be governed. Vulnerability scanning can produce noise, miss runtime behaviour, or prioritise theoretical severity over actual exposure. Automated remediation can cause cascading failures if it lacks scope limits and rollback. Finally, governance programmes may focus on passing an audit rather than reducing harm. Effective leadership continually tests whether controls work under realistic operational conditions. Current Developments and Strategic ImplicationsCloud-native governance is moving toward continuous control monitoring, software supply-chain attestations, identity-centric security, confidential computing, stronger workload provenance, and automated evidence collection. Platform engineering increasingly provides approved “golden paths” that make the secure choice the easiest choice. Regulatory attention is also expanding from infrastructure security toward resilience, third-party risk, privacy, automated decision-making, and environmental accountability. These developments have strategic implications. Governance capabilities can become a competitive advantage when they accelerate trustworthy delivery rather than merely restrict it. Executives must fund platform controls, training, independent assurance, and recovery capabilities as operational infrastructure. Engineering leaders must treat policy design, data stewardship, and ethical review as professional skills. Boards and senior managers should ask not only whether a control exists, but whether the organisation can detect failure, limit harm, recover, and explain its decisions. Best-Practice GuidanceA responsible Kubernetes governance programme should: - assign named technical and business owners to clusters, namespaces, workloads, data, and risks;
- maintain a version-controlled, tested policy catalogue linked to obligations and evidence;
- enforce least privilege, secure workload defaults, supply-chain integrity, and network boundaries;
- classify data and map its primary, temporary, replicated, backed-up, and logged forms;
- protect audit evidence independently from the systems it records;
- use time-bound, compensating-control-based exceptions;
- test restoration, incident response, access review, and policy failure scenarios;
- measure control effectiveness and operational outcomes rather than compliance volume alone;
- require bounded human oversight for high-impact AI-assisted actions; and
- review governance after incidents, major changes, new obligations, and emerging technologies.
Chapter SummaryGovernance, compliance, and responsible operations are essential capabilities for Kubernetes-based organisations. Governance establishes decision rights and accountability; compliance translates obligations into demonstrable controls; responsible operations consider safety, privacy, fairness, sustainability, accessibility, and human consequences. Policy-as-code enables preventive, detective, and corrective controls across pipelines, admission points, and runtime monitoring. Secure baselines should cover identity, workloads, networks, supply chains, secrets, data, logging, and recovery. Auditability depends on protected evidence that connects actions to identities, approvals, policies, and outcomes. Risk ownership must distinguish technical responsibility from business acceptance, while shared responsibility must be negotiated among cloud providers, platform teams, application owners, security functions, and data stewards. Data governance requires classification, minimisation, lifecycle control, and visibility into replicas and telemetry. AI assistance can improve operations only when permissions, human review, data protection, evaluation, and rollback are carefully designed. The strongest governance programmes embed these practices into everyday engineering and continuously test whether they reduce real operational risk. Key TermsPolicy-as-code: Machine-readable rules that automatically evaluate or enforce organisational requirements. Governance: The structures, responsibilities, policies, and processes used to direct and control technology operations. Compliance: Demonstrable adherence to applicable laws, regulations, contracts, standards, and internal requirements. Assurance: Evidence-based confidence that controls are designed appropriately and operate effectively. Preventive control: A control intended to stop an unauthorised or unsafe action before it occurs. Detective control: A control that identifies a violation, anomaly, or failure after or during occurrence. Corrective control: A control that restores an acceptable state or reduces the effect of a detected problem. Admission control: Kubernetes processing that validates or modifies resources before they are stored in the cluster. Secure baseline: The minimum approved configuration and control set for a system or workload. Risk owner: The person or role accountable for managing a risk and accepting its treatment decision. Exception: A formally approved, limited departure from a policy or baseline. Shared responsibility: Allocation of security and governance duties among the cloud provider and customer. Data classification: Categorisation of data according to sensitivity, criticality, or handling requirements. Data minimisation: Collecting and retaining only the data necessary for a defined purpose. Auditability: The capacity to reconstruct actions, identities, decisions, and outcomes from reliable evidence. Provenance: Verifiable information about the origin, construction, and integrity of a software artifact. Least privilege: Granting only the permissions necessary to perform an authorised task. Responsible operations: Operational decision-making that considers security, legal, human, societal, and environmental consequences. Control effectiveness: The degree to which a control achieves its intended risk-reduction outcome. Review QuestionsShort Answer Questions1. Distinguish governance from compliance in a Kubernetes environment. 2. What are preventive, detective, and corrective controls? Give one example of each. 3. Why are immutable image digests stronger than mutable image tags for auditability? 4. Explain why Kubernetes Secret objects should not be regarded as encryption by themselves. 5. What information should a time-bound policy exception contain? Long Answer Questions1. Explain how a secure Kubernetes baseline should address identity, workloads, networking, supply chains, secrets, logging, and recovery. 2. Discuss how policy-as-code can be integrated into development pipelines, admission control, and runtime monitoring. 3. Analyse the relationship between data classification, privacy, retention, replication, and observability. 4. Explain shared responsibility and risk ownership in a managed Kubernetes environment. 5. Evaluate the governance implications of AI-assisted remediation in production clusters. Analytical / Application Questions1. A deployment pipeline blocks an image because it lacks a signature, but a critical service must be restored immediately. Design a proportionate emergency exception and identify compensating controls. 2. An organisation has excellent vulnerability scanning but cannot prove who approved production changes or where personal data is replicated. Diagnose the governance gaps and propose a control-evidence plan. 3. A platform team proposes reducing replicas and moving workloads to a cheaper region to improve sustainability. Analyse the decision using availability, latency, data residency, resilience, cost, and environmental considerations. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best describes the relationship between governance and compliance in Kubernetes operations? A. Governance is limited to technical security, while compliance concerns only costs. B. Governance defines direction, accountability, and controls, while compliance demonstrates adherence to obligations. C. Compliance replaces the need for risk ownership when a system is audited. D. Governance applies only to cloud providers, while customers manage applications independently. Correct Answer: B. Governance defines direction, accountability, and controls, while compliance demonstrates adherence to obligations. Question 2A policy rejects a production workload unless it uses a signed image digest from an approved registry. This is primarily what type of control? A. Preventive control B. Detective control C. Corrective control D. Compensating recovery control Correct Answer: A. Preventive control Question 3Why should audit logs be stored independently from ordinary application logs? A. To increase application logging volume B. To allow developers to modify audit records easily C. To reduce the risk that a compromised application can alter evidence D. To eliminate the need for identity controls Correct Answer: C. To reduce the risk that a compromised application can alter evidence Question 4Which responsibility normally remains with a customer using managed Kubernetes? A. Maintaining the cloud provider’s physical facilities B. Replacing the provider’s data-centre hardware C. Managing workload identities, configurations, applications, and customer data D. Designing the provider’s control-plane software Correct Answer: C. Managing workload identities, configurations, applications, and customer data Question 5A team copies production health records into a test namespace without approval. Which governance principle is most directly violated? A. Data minimisation and controlled data use B. Elastic scaling C. Immutable infrastructure D. Geographic load balancing Correct Answer: A. Data minimisation and controlled data use Question 6Which item provides the strongest evidence that a deployment is traceable? A. A mutable image tag and an informal chat message B. A container name chosen by a developer C. An image digest linked to build provenance, commit, policy result, and approval D. A vulnerability scan performed on an unrelated image Correct Answer: C. An image digest linked to build provenance, commit, policy result, and approval Question 7What is the main purpose of a time-bound exception process? A. To permanently suspend controls for high-priority teams B. To permit controlled deviation while preserving accountability and review C. To conceal policy violations from auditors D. To transfer all risk to the platform team Correct Answer: B. To permit controlled deviation while preserving accountability and review Question 8Which practice best addresses AI-related operational risk in a production cluster? A. Give the AI system unrestricted cluster-admin privileges B. Allow automatic execution without logging to improve speed C. Separate recommendations from execution and require human approval for high-impact actions D. Disable all monitoring of AI-generated commands Correct Answer: C. Separate recommendations from execution and require human approval for high-impact actions Question 9Why is a tested backup more valuable than an untested backup for governance purposes? A. Testing demonstrates that restoration objectives and procedures work in practice B. Testing eliminates the need for encryption C. Testing guarantees that no incident can occur D. Testing makes retention policies unnecessary Correct Answer: A. Testing demonstrates that restoration objectives and procedures work in practice Question 10Which metric most directly indicates a weakness in exception governance? A. Number of namespaces created this month B. Average container image size C. Number of expired or long-overdue exceptions D. Total number of application developers Correct Answer: C. Number of expired or long-overdue exceptions
|
