Container Platform Management and Adoption

Introduction

Containerization is often introduced as a technical method for packaging applications, but organizational adoption is principally a management and governance problem. A container image can be built in minutes; operating thousands of images, clusters, registries, identities, networks, and deployment pipelines safely requires standards, ownership, reliable services, and sustained organizational capability.

A container platform is the collection of technologies, processes, people, and policies that enable teams to build, store, deploy, operate, secure, and retire containerized workloads. Docker may be central to the developer experience, while registries, CI/CD systems, orchestration platforms, observability tools, identity systems, and cloud services complete the operating environment.

This chapter examines how an organization can adopt containers deliberately. It focuses on platform-team responsibilities, service-level objectives (SLOs), governance, risk controls, documentation, technology selection, and the relationship between platform standardization and developer autonomy.

Learning Objectives

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

1. Explain the organizational components of a container platform.
2. Define ownership boundaries between platform teams, development teams, security, and operations.
3. Establish useful standards for images, registries, deployment, networking, secrets, and observability.
4. Design SLOs and operational indicators for container-platform services.
5. Identify major adoption risks and select appropriate controls.
6. Evaluate container technologies using explicit technical, financial, operational, and governance criteria.
7. Prepare a practical adoption roadmap and supporting documentation.

1. The Container Platform as an Internal Product

A platform should be managed as an internal product rather than as a collection of infrastructure components. Its users are application teams, testers, security specialists, data engineers, and operations personnel. These users need a dependable path from source code to production, not merely access to a cluster.

A useful platform value chain is:

Source → Build → Test → Scan → Store → Deploy → Observe → Improve → Retire

Each stage creates dependencies and governance questions. For example:

• Build: Which Dockerfile conventions and base images are approved?
• Test: Which tests must pass before an image is released?
• Scan: Which vulnerabilities block release, and who grants exceptions?
• Store: How are images tagged, signed, replicated, and retained?
• Deploy: Which environments and deployment strategies are supported?
• Observe: Which logs, metrics, traces, and alerts are mandatory?
• Retire: How are obsolete images, credentials, and workloads removed?

Treating the platform as a product encourages user research, a service catalogue, versioned interfaces, a roadmap, release communication, support channels, and measurable outcomes. It also discourages the common error of measuring success by the number of clusters created rather than by improved delivery and operational performance.

Platform capabilities and platform services

A capability is something the organization can do, such as build an image reproducibly or roll back a deployment. A platform service is the managed product through which users obtain that capability, such as a hosted registry or a deployment portal.

Typical services include:

The platform does not necessarily own every underlying component. It owns the experience, standards, integration, and service commitments presented to its users.

2. Operating Model and Ownership

Successful adoption requires explicit accountability. Without it, teams may assume that someone else is responsible for vulnerability remediation, capacity, backups, or incident response.

The platform team

The platform team designs and operates the paved road: the supported, well-documented route for common workloads. Its responsibilities commonly include:

• providing approved templates, base images, and pipeline components;
• operating or coordinating registries, runtimes, and shared services;
• defining platform standards and publishing exceptions procedures;
• maintaining access controls, tenancy boundaries, and audit records;
• providing observability and operational dashboards;
• managing platform capacity, upgrades, and resilience;
• supporting incident response and post-incident improvement;
• measuring platform adoption, reliability, cost, and user experience.

The platform team should not become the owner of every application. It provides common capabilities and guardrails; application teams remain accountable for application behavior and business outcomes.

Application teams

Application teams normally own:

• application source code and runtime configuration;
• Dockerfiles and application-specific dependencies;
• image vulnerability remediation within agreed time limits;
• resource requests and limits based on application behavior;
• health checks, dashboards, and meaningful alerts;
• data protection, backup requirements, and recovery testing;
• application-level SLOs and release decisions.

A platform can make these responsibilities easier, but it cannot eliminate them.

Security, risk, and governance functions

Security teams define organizational risk requirements, assist with threat modelling, review controls, and coordinate vulnerability management. They should enable secure patterns rather than rely only on manual approval. Compliance and legal teams may define requirements concerning data residency, retention, auditability, software licensing, privacy, and regulated workloads.

A RACI model is useful for clarifying roles:

• Responsible: performs the work.
• Accountable: owns the result and approves decisions.
• Consulted: provides expertise before a decision.
• Informed: receives relevant information.

For example, the platform team may be responsible for registry availability, the platform manager accountable for its service level, security consulted on access and scanning, and application teams informed about maintenance windows.

Team cognitive load and the paved road

A platform should reduce unnecessary cognitive load. A development team should not need to become expert in registry replication, cluster scheduling, certificate rotation, and kernel isolation merely to deploy a web service. However, abstraction must not conceal important consequences. Teams still need to understand resource consumption, failure modes, data persistence, and security obligations.

The best platform commonly provides a paved road for standard workloads and a documented off-road process for exceptional requirements. The paved road should be easier, safer, and faster—not a coercive mechanism that prevents legitimate engineering choices.

3. Standards for Container Adoption

Standards should be specific enough to reduce avoidable variation while allowing justified exceptions. A standard is effective when it has an owner, a rationale, an enforcement method, and a review date.

Image standards

An organizational image standard should address:

1. Trusted bases: Use maintained, minimal base images from approved sources.
2. Pinning: Pin base-image references by version and preferably by immutable digest where reproducibility is important.
3. Non-root execution: Run as a non-root user unless a documented technical requirement exists.
4. Minimal contents: Exclude compilers, package caches, credentials, and debugging tools from production images.
5. Metadata: Include ownership, source revision, build time, and licensing information.
6. Scanning: Scan operating-system packages and application dependencies.
7. Signing and provenance: Record how, where, and from which source an image was built.
8. Lifecycle: Define retention and retirement rules for obsolete tags and digests.

A tag such as production is mutable unless the registry enforces immutability. A digest identifies content more precisely than a tag. This distinction matters when an organization must prove which artifact was deployed.

Dockerfile and build standards

Dockerfiles should use deterministic and reviewable instructions. Dependencies should be obtained from approved repositories, and builds should avoid embedding secrets in layers or build arguments. Multi-stage builds can separate compilation tools from the runtime image. Build contexts should be controlled so that local credentials or unnecessary files are not copied into images.

The organization should define whether builds may access the public internet, how dependency caches are managed, and what happens when a build dependency becomes unavailable. Reproducibility is not absolute: upstream repositories, timestamps, compiler versions, and package metadata can change. Therefore, the organization should document its required reproducibility level and test it periodically.

Registry standards

Registry governance should specify authentication, authorization, network access, replication, scanning, retention, backup, and incident procedures. Repository ownership should be visible. Production repositories should generally have stronger controls than experimental repositories, including immutable releases and restricted deletion.

Runtime and deployment standards

Standards may include:

• approved runtime versions and upgrade windows;
• namespace or project ownership;
• mandatory resource requests and limits;
• non-privileged execution and restricted host access;
• read-only filesystems where feasible;
• health checks and graceful termination behavior;
• network policies and ingress controls;
• deployment history and rollback procedures;
• separation between development, test, and production;
• restrictions on host mounts, privileged containers, and host networking.

A policy should distinguish a must, a should, and a may. Excessive mandatory controls can encourage bypasses; weak recommendations may produce unsafe inconsistency.

Secrets and configuration

Secrets must not be stored in Dockerfiles, source repositories, image layers, or ordinary environment files committed to version control. They should be obtained from an approved secret-management service, with least-privilege access, rotation, audit logging, and emergency revocation. Configuration that is not secret should be managed separately so that changes can be reviewed without rebuilding an image.

Observability standards

A deployable workload should expose enough information to answer three questions: Is it working? Is it serving users acceptably? What changed? Minimum expectations often include structured logs, service health indicators, request latency, error rates, resource consumption, and deployment metadata. Alerts should identify actionable conditions rather than merely report every unusual measurement.

4. Service-Level Objectives for Platform Services

An SLO is a target level of service over a stated measurement period. It is more useful than a vague claim that a service is “highly available.” An SLO is supported by a service-level indicator (SLI), which is the measured aspect of service performance. A service-level agreement (SLA) may include contractual consequences; an SLO is primarily an engineering and management target.

Availability SLI

For a request-based service, availability can be represented as:

“Successful” must be defined, for example as responses that are not classified as platform or server errors. Health-check traffic, maintenance windows, and excluded dependencies must be specified before measurement. The formula is meaningful only when numerator and denominator refer to the same period, population, and measurement method.

If a registry receives 20,000 valid pull requests in a month and 19,980 succeed, availability is:

The corresponding error budget is the permitted unsuccessful proportion. For a 99.9% monthly SLO, the budget is 0.1%. If the measurement period contains 43,200 minutes, the approximate time equivalent is:

This time conversion is only an approximation for time-based availability; request-based and time-based SLOs are not interchangeable.

Latency and freshness objectives

A platform may define that at least 95% of image pulls complete within a target duration, or that vulnerability results for newly published images are available within a specified time. Percentiles are preferable to averages when a small number of slow operations materially affect users. The percentile definition and observation population must be documented.

Other useful platform indicators include:

• deployment success rate;
• median time to restore a failed platform service;
• age of critical vulnerabilities;
• percentage of workloads using supported images;
• percentage of production workloads with required telemetry;
• platform change failure rate;
• support-request response and resolution time.

Error budgets and decision-making

An error budget is the difference between the target reliability and perfect reliability. If incidents consume the budget rapidly, the platform team may pause risky feature work and prioritize reliability improvements. This should not be applied mechanically: security emergencies, regulatory deadlines, and business-critical changes may override normal policies. The value of an error budget lies in making trade-offs explicit.

5. Risk Controls and Governance

Container isolation is not equivalent to a complete security boundary. Containers share a host kernel, and a misconfiguration, vulnerable runtime, excessive privilege, or compromised image can increase the impact of an attack.

Major risks and controls

Controls should be layered. Scanning alone cannot prevent a privileged container from accessing sensitive host resources, and network segmentation alone cannot identify a malicious package in an image.

Vulnerability management

Risk-based vulnerability management considers severity, exploitability, exposure, asset importance, and available mitigation. A critical vulnerability in an internet-facing production image should receive different treatment from a low-severity issue in an isolated development tool. Exception records should include the affected asset, rationale, compensating controls, owner, expiry date, and review authority. Permanent exceptions are usually evidence that a standard or architecture requires reconsideration.

Supply-chain security

The container supply chain includes source repositories, dependencies, build runners, base images, registries, deployment systems, and runtime environments. Controls should establish:

• who can modify source and pipeline definitions;
• which builders are trusted;
• how artifacts are linked to source revisions;
• whether image signatures are verified before deployment;
• how dependencies are approved and updated;
• how compromised credentials or artifacts are revoked.

Security automation should provide rapid feedback to developers and a clear remediation path. A policy that merely blocks releases without explaining the reason can produce unsafe workarounds.

Governance and compliance

Governance should cover data classification, retention, privacy, audit logs, licensing, geographic placement, and third-party service dependencies. Regulated workloads may require stronger separation, evidence preservation, access review, and documented recovery tests. Governance controls should be proportional to risk and integrated into normal delivery workflows.

6. Documentation and Knowledge Management

Documentation is an operational control. If a procedure exists only in the memory of one engineer, the organization has a resilience risk.

A container platform documentation set should include:

1. Platform catalogue: supported runtimes, registries, templates, versions, and service owners.
2. Getting-started guide: how to build, scan, publish, deploy, observe, and remove a workload.
3. Standards: image, security, networking, secrets, resource, and naming requirements.
4. Reference architectures: recommended patterns for stateless services, workers, scheduled jobs, and stateful systems.
5. Runbooks: diagnosis and recovery procedures for common failures.
6. Service definitions: SLOs, support hours, dependencies, maintenance, and escalation routes.
7. Decision records: important architectural choices, alternatives considered, and review dates.
8. Disaster-recovery documentation: backup scope, restoration steps, recovery objectives, and test results.
9. Exception register: deviations, owners, controls, and expiry dates.
10. Change communication: upgrade notices, deprecations, migration instructions, and release notes.

Documentation should be versioned with the platform where practical. Examples should be executable or regularly tested. A runbook that has never been used in an exercise may be incomplete even if it appears detailed.

7. Selecting Container Technologies

Technology selection should begin with requirements rather than popularity. Docker Engine may be suitable for local development and simple workloads, while larger organizations may require an orchestrator, managed container service, or specialized platform. No technology eliminates the need for operating-model decisions.

Selection criteria

A structured evaluation should consider:

• Workload fit: stateless services, batch jobs, stateful systems, edge workloads, or high-performance computing;
• Operational complexity: installation, upgrades, backup, troubleshooting, and skill requirements;
• Security: isolation, identity integration, policy enforcement, auditability, and supply-chain support;
• Reliability: failure handling, multi-zone operation, recovery, and upgrade behavior;
• Developer experience: local parity, templates, feedback speed, and self-service;
• Ecosystem: integrations, community health, support providers, and available skills;
• Portability: dependence on proprietary APIs, data services, and deployment assumptions;
• Cost: licensing, infrastructure, support, training, migration, and operational labor;
• Lifecycle: release cadence, deprecation policy, and upgrade path;
• Compliance: evidence generation, data location, and regulatory compatibility.

A weighted decision matrix can make assumptions visible. Let w_i be the weight assigned to criterion i, and r_i the normalized score of a technology for that criterion. If the weights sum to 1, the weighted score is:

Here, S is the total score, n is the number of criteria, 0 ≤ w_i ≤ 1, and 0 ≤ r_i ≤ 5 if a five-point scoring scale is used. The score is a decision aid, not an objective truth. Scores should be supported by evidence, pilots, and sensitivity analysis.

For example, an organization may assign weights of 0.30 to security, 0.25 to operational fit, 0.20 to developer experience, 0.15 to cost, and 0.10 to portability. A platform scoring 4, 4, 5, 3, and 4 respectively obtains:

The organization should also identify “non-negotiable” requirements. A high total score must not compensate for failure to meet a mandatory security or regulatory condition.

Pilot design

A pilot should include representative workloads, not only a simple demonstration application. It should test deployment, rollback, upgrades, failures, observability, access review, backup restoration, cost measurement, and developer onboarding. Define exit criteria before starting. A pilot that succeeds only because experts provide continuous manual assistance does not demonstrate sustainable adoption.

8. Adoption Roadmap

A staged roadmap limits risk and creates learning opportunities.

Stage 1: Discover and assess

Inventory existing applications, delivery methods, operating systems, dependencies, data classifications, reliability requirements, and team skills. Classify workloads by suitability. Not every application benefits from immediate containerization; some may be better modernized, retained, or retired.

Stage 2: Establish foundations

Create the platform team, ownership model, registry, identity integration, baseline security controls, image standards, documentation repository, and initial support model. Select a small number of supported patterns.

Stage 3: Pilot representative services

Choose workloads that are valuable but not exceptionally dangerous. Test the complete path from commit to production and record friction, defects, support demand, and operational outcomes.

Stage 4: Scale through reusable products

Publish templates, reusable pipeline components, base images, observability integrations, and self-service workflows. Introduce SLO reporting, capacity management, regular platform upgrades, and communities of practice.

Stage 5: Optimize and govern

Review cost, reliability, security, adoption, and user experience. Remove obsolete patterns, revise standards, automate controls, and evaluate whether the platform still fits organizational needs.

Adoption metrics should include outcomes, such as deployment lead time, change failure rate, restoration time, vulnerability remediation age, platform availability, and user satisfaction. Counting containers is not an adequate measure of transformation.

9. Illustrative Case: Northstar Retail

Background

Northstar Retail, a fictional regional retailer, operates online shopping, inventory, and pricing systems. Teams deploy applications differently: some use virtual machines, some use manually managed Docker hosts, and others use a cloud provider’s managed service. Security cannot reliably identify which images are running in production.

Problem

The organization experiences inconsistent patching, long release lead times, and unclear responsibility during incidents. A security review finds that several images contain embedded credentials and that production tags can be overwritten. Management proposes “moving everything to containers” within six months.

Analysis

The platform group rejects an immediate mass migration. It inventories workloads and finds three categories:

• stateless web and API services suitable for an initial platform;
• scheduled data-processing jobs requiring stronger storage and identity analysis;
• a legacy system whose vendor does not support container deployment.

The group defines a responsibility model: the platform team owns the registry, deployment platform, templates, and runtime controls; product teams own application images, resource definitions, health checks, and remediation; security owns policy requirements and risk review.

Approach and solution

Northstar establishes a private registry with immutable release repositories, vulnerability scanning, access logs, and retention rules. It publishes a hardened base-image catalogue and a pipeline template that builds, tests, scans, signs, and promotes images. Production deployment requires an approved digest, a non-root runtime where technically possible, declared resources, health checks, and externalized secrets.

The first pilot includes one customer-facing API, one internal service, and one scheduled job. The platform team measures deployment success, pull latency, vulnerability age, restoration time, and developer effort. It also performs a failed-deployment rollback and a registry recovery exercise.

Outcome

The pilot reveals that the registry’s initial retention policy would remove images required for rollback, so retention is revised to preserve approved production artifacts. Developers request exceptions for debugging tools; instead of allowing those tools in production images, the platform provides a controlled ephemeral-debug procedure. The legacy vendor system remains outside the platform, but its integration boundary is documented.

Northstar then expands gradually. Its success is not defined by migrating every system. It is defined by repeatable delivery, visible ownership, reduced credential exposure, tested recovery, and reliable platform services.

Learning points

1. Adoption should be based on workload suitability, not a universal migration target.
2. Ownership must follow the application-platform boundary.
3. Security controls are most effective when automated in the delivery path.
4. Recovery and rollback must be tested, not merely documented.
5. Exceptions should lead to improved patterns when the same request recurs.
6. A platform is successful when it improves organizational capability and outcomes.

10. Challenges, Limitations, and Contemporary Developments

Skills and organizational change

Containers can expose gaps in Linux, networking, security, software delivery, and reliability engineering. Training should combine conceptual learning with supervised operational practice. Platform teams also need product-management skills because prioritizing user experience and managing a service catalogue are not purely infrastructure tasks.

Cost and hidden complexity

Containers may improve utilization, but orchestration introduces control-plane, observability, security, networking, support, and training costs. Cloud pricing can obscure the cost of idle capacity, data transfer, managed control planes, and premium support. Cost allocation should identify platform shared costs and workload-specific consumption without creating incentives to bypass controls.

Stateful workloads

Containers do not automatically make databases, queues, or file systems portable or resilient. State requires explicit decisions about storage, consistency, backup, recovery, identity, and failure domains. A container restart is not a data-recovery strategy.

AI-assisted development

AI tools can generate Dockerfiles, deployment manifests, policies, and troubleshooting suggestions. They can improve productivity but may also introduce insecure defaults, obsolete dependencies, licensing concerns, or incorrect assumptions about the runtime. Generated artifacts require review, testing, scanning, provenance, and human accountability. Confidential configuration and credentials must not be submitted to unauthorized AI services.

Emerging practices

Current platform practice increasingly emphasizes software supply-chain provenance, policy-as-code, workload identity, confidential computing in selected use cases, platform engineering, internal developer portals, and automated environment creation. These practices are valuable only when they address a demonstrated need and can be operated sustainably. Technology novelty is not itself evidence of organizational benefit.

Best-Practice Checklist

Before expanding container adoption, an organization should be able to answer “yes” to most of the following questions:

• Is every platform service assigned an owner?
• Are application and platform responsibilities documented?
• Are production images traceable to source and build processes?
• Are secrets externalized and access audited?
• Are privileged workloads restricted and exceptions time-limited?
• Are SLOs, SLIs, error budgets, and support paths defined?
• Are vulnerability findings prioritized by risk and assigned to owners?
• Are backups and restoration procedures tested?
• Are platform upgrades and deprecations communicated?
• Can teams use a supported paved road without specialist intervention?
• Is there a documented route for legitimate exceptions?
• Are technology decisions based on evidence, pilots, and lifecycle considerations?

Chapter Summary

Container adoption is an organizational capability involving technology, people, processes, and governance. A container platform should be managed as an internal product with a clear service catalogue, user-oriented documentation, ownership boundaries, and a roadmap. Platform teams provide reusable capabilities and guardrails, while application teams remain accountable for application behavior, configuration, observability, and remediation.

Standards should cover image construction, registries, runtime security, deployment, secrets, networking, observability, and lifecycle management. SLOs translate reliability expectations into measurable targets; SLIs define the measurements, and error budgets support explicit trade-offs between change and reliability. Security requires layered controls spanning the software supply chain, identity, runtime, host, network, and data.

Technology selection should use explicit criteria, weighted evidence, mandatory requirements, and representative pilots. Adoption should proceed in stages, beginning with assessment and foundations and continuing through pilot, scale, and optimization. The most meaningful outcomes are reliable delivery, reduced risk, improved recovery, and lower cognitive load—not the number of containers deployed.

Key Terms

Container platform: The people, processes, policies, and technologies used to build and operate containers.

Platform team: A team that provides and manages shared delivery and runtime capabilities for application teams.

Internal product: A service designed, supported, and improved for organizational users.

Paved road: The recommended, supported path for common engineering tasks.

Service-level indicator (SLI): A measurement of a service attribute, such as availability or latency.

Service-level objective (SLO): A target value or range for an SLI over a defined period.

Service-level agreement (SLA): A service commitment that may include contractual obligations or consequences.

Error budget: The permitted unreliability implied by an SLO.

Container registry: A service that stores and distributes container images.

Image digest: An immutable content identifier for an image artifact.

Image provenance: Evidence describing an artifact’s source, build process, and inputs.

Policy-as-code: Machine-readable rules that automatically evaluate or enforce governance requirements.

Workload identity: An identity assigned to an application or workload for controlled access to resources.

RACI: A responsibility model identifying who is Responsible, Accountable, Consulted, and Informed.

Exception: An approved, documented deviation from a standard.

Resource request: The amount of a resource used by scheduling or capacity decisions.

Resource limit: The maximum resource consumption permitted for a container or workload.

Observability: The ability to understand system behavior from outputs such as logs, metrics, and traces.

Platform engineering: The discipline of designing and operating internal platforms that improve developer delivery and operational outcomes.

Review Questions

Short Answer Questions

1. What distinguishes a container platform from a container runtime?
2. State two responsibilities of a platform team and two responsibilities of an application team.
3. Why is an image digest more reliable than a mutable production tag for identifying deployed content?
4. What is the relationship between an SLI, an SLO, and an error budget?
5. Name four criteria that should be considered when selecting a container technology.

Long Answer Questions

1. Explain how an organization can design a paved road while preserving legitimate technology choice and exceptions.
2. Discuss the standards required for secure and reproducible container image production.
3. Explain how ownership boundaries and a RACI model reduce operational ambiguity.
4. Describe a staged roadmap for organizational container adoption and the evidence required at each stage.
5. Evaluate the role of documentation, runbooks, and decision records in platform resilience.

Analytical / Application Questions

1. A registry receives 50,000 valid image pulls in one month, of which 49,950 succeed. Calculate request-based availability and determine whether a 99.9% SLO is met.
2. Design a weighted technology-selection matrix for an organization whose highest priorities are security, operational simplicity, and developer experience. Justify the weights and identify at least one non-negotiable requirement.
3. A team requests permission to run a privileged container because its debugging utility cannot operate under a restricted profile. Propose a risk analysis, compensating controls, approval process, and expiry condition for the exception.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a container platform?

A. Only the Docker Engine installed on a host

B. A collection of containers with no operating procedures

C. People, processes, policies, and technologies for operating container workloads

D. A registry used exclusively for storing images

Correct Answer: C. People, processes, policies, and technologies for operating container workloads

Question 2

Who normally owns application-specific health checks and resource definitions?

A. The application team

B. The legal department

C. The registry vendor

D. The network provider

Correct Answer: A. The application team

Question 3

Why is an image digest useful in production deployment?

A. It automatically increases CPU capacity

B. It identifies image content immutably

C. It replaces the need for access control

D. It prevents all vulnerabilities

Correct Answer: B. It identifies image content immutably

Question 4

If 19,980 of 20,000 valid registry requests succeed, what is request-based availability?

A. 95.0%

B. 99.0%

C. 99.9%

D. 99.99%

Correct Answer: C. 99.9%

Question 5

For a 99.9% SLO, what proportion represents the error budget?

A. 0.001%

B. 0.01%

C. 0.1%

D. 1.0%

Correct Answer: C. 0.1%

Question 6

Which practice best protects secrets used by containerized applications?

A. Embedding them in Dockerfiles

B. Committing them to a public image repository

C. Storing them in an approved secret-management service

D. Writing them into image labels

Correct Answer: C. Storing them in an approved secret-management service

Question 7

What is the main purpose of an error budget?

A. To calculate developer salaries

B. To support explicit trade-offs between reliability and change

C. To replace vulnerability scanning

D. To determine image size

Correct Answer: B. To support explicit trade-offs between reliability and change

Question 8

Which is an appropriate technology-selection practice?

A. Choose the newest tool without a pilot

B. Use only popularity as the evaluation criterion

C. Evaluate workload fit, security, operations, cost, and lifecycle

D. Ignore training and migration costs

Correct Answer: C. Evaluate workload fit, security, operations, cost, and lifecycle

Question 9

What should a documented exception normally include?

A. Only the name of the requesting developer

B. A rationale, owner, compensating controls, and expiry or review date

C. A permanent exemption with no review

D. A replacement for all security controls

Correct Answer: B. A rationale, owner, compensating controls, and expiry or review date

Question 10

Which outcome is a stronger measure of container adoption success than the number of containers deployed?

A. Improved delivery reliability and recovery capability

B. The number of unused image tags

C. The number of platform components installed

D. The number of privileged containers created

Correct Answer: A. Improved delivery reliability and recovery capability