Automation System Design and Project Engineering

Introduction and Context

Industrial automation projects rarely fail because a programmable logic controller (PLC) cannot execute a control instruction. They fail more often because requirements are incomplete, process assumptions are undocumented, interfaces are misunderstood, safety is treated as an afterthought, or changes are introduced without assessing their effects. Automation system design is therefore a systems-engineering activity: it connects process requirements, instrumentation, control logic, information systems, people, suppliers, cost, schedule, safety, cybersecurity, and long-term operation.

A successful project converts an operational need into a controlled and verifiable set of engineering products. Typical products include a process description, control philosophy, process and instrumentation diagrams (P&IDs), I/O list, functional design specification (FDS), hardware and software architecture, network design, cause-and-effect matrix, alarm philosophy, safety requirements, test plans, training documents, and maintenance information.

This chapter presents a practical design method for batch and continuous automation projects. It emphasizes ISA-88, ISA-95, lifecycle thinking, vendor selection, cost estimation, configuration control, and project risk.

Learning Objectives

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

1. Translate process and business requirements into a control philosophy.
2. Develop a structured I/O list and relate it to P&IDs and PLC hardware.
3. Explain the purposes of an FDS, software architecture, and verification plan.
4. Apply the ISA-88 batch model and ISA-95 enterprise-control-system hierarchy.
5. Estimate automation project cost using a transparent bottom-up approach.
6. Compare vendors using weighted technical, commercial, and lifecycle criteria.
7. Manage requirements, interfaces, changes, cybersecurity, safety, and project risk.
8. Evaluate lifecycle value rather than selecting solely on initial purchase price.

1. From Requirements to a Control Philosophy

1.1 Requirements engineering

A requirement states what the system must achieve, not merely how a designer intends to achieve it. Good requirements are specific, testable, traceable, and classified according to their source. Common sources include:

• process objectives, such as production rate or product quality;
• operating constraints, such as temperature, pressure, residence time, and cleaning limits;
• safety requirements, including emergency shutdown and hazardous-area constraints;
• regulatory and quality requirements;
• maintenance and availability expectations;
• information requirements, including historian, production, and reporting data;
• cybersecurity and access-control requirements; and
• project constraints involving cost, schedule, existing equipment, and skills.

A useful requirement record includes an identifier, statement, source, priority, acceptance criterion, owner, verification method, and status. For example:

Requirements should be separated into normal operation, abnormal operation, shutdown, maintenance, and recovery conditions. This prevents a specification from describing only the ideal case.

1.2 The control philosophy

The control philosophy is the bridge between process intent and detailed design. It explains how the plant will be operated and controlled. It should address:

• operating modes: automatic, manual, semi-automatic, maintenance, and emergency;
• equipment states and permitted transitions;
• regulatory and basic process control loops;
• permissives, interlocks, trips, and resets;
• sequence steps and transition conditions;
• alarm priorities and operator responses;
• startup, normal shutdown, emergency shutdown, and restart after power loss;
• instrument failure behavior and fallback states;
• operator commands, displays, trends, and reports;
• data retention and time synchronization; and
• interfaces with safety systems, drives, analyzers, and higher-level systems.

A permissive is a condition that must be true before an action is allowed. An interlock prevents or interrupts an action when an unsafe or damaging condition exists. A trip is an action that places equipment or a process in a defined protective state. These terms must be used consistently because ambiguous language produces inconsistent programming and testing.

1.3 Functional decomposition

A complex plant should be decomposed into areas, units, equipment modules, and control modules. For example, a liquid blending plant may contain raw-material storage, dosing, blending, filling, cleaning-in-place, utilities, and wastewater areas. Each area can then be assigned ownership, I/O, sequences, alarms, and interfaces.

The decomposition should follow process behavior rather than PLC cabinet boundaries. Hardware boundaries may change during procurement; process responsibilities and functional boundaries should remain stable.

2. P&IDs, Instrumentation, and the I/O List

2.1 P&IDs as a design language

A P&ID communicates process equipment, piping, valves, instruments, connections, and control relationships. It is not a complete PLC program and should not be used alone to define sequence behavior. The P&ID normally identifies equipment tags, instrument tags, valve functions, flow directions, control loops, drains, vents, utility connections, and safety devices.

A P&ID review should ask:

1. Can every process variable required for control, protection, quality, or reporting be measured?
2. Can every manipulated variable be operated safely?
3. Are isolation, bypass, drain, vent, calibration, and maintenance provisions adequate?
4. Are failure positions of control valves and actuators defined?
5. Are interfaces between process areas explicit?
6. Are safety functions distinguished from ordinary control functions?

The P&ID should be checked against process mass balances, equipment data sheets, hazardous-area classifications, and the cause-and-effect matrix.

2.2 Instrument and signal classification

Typical signals include:

• AI: analog input, such as 4–20 mA pressure or temperature;
• AO: analog output, such as a valve position command;
• DI: digital input, such as a limit switch or motor-running status;
• DO: digital output, such as a contactor or solenoid command;
• pulse or frequency signals, such as flowmeter pulses;
• serial or Ethernet data from intelligent instruments and drives; and
• safety I/O handled by a safety PLC or safety instrumented system.

A signal count alone is insufficient. Engineering must also consider signal quality, isolation, intrinsic safety, redundancy, marshalling, spare capacity, scan time, communication loading, and whether a signal is standard or safety-rated.

2.3 Building the I/O list

The I/O list is a controlled register linking process devices to control-system resources. Typical fields are:

The I/O list should be reconciled with the P&IDs, instrument index, cable schedule, panel drawings, PLC configuration, HMI database, and FAT/SAT procedures. A discrepancy among these documents is a configuration-management problem, not merely an administrative inconvenience.

2.4 Sizing I/O and panels

For each signal category, installed points should include calculated signals plus spare capacity. If N is the required number of signals and s is the spare fraction, a planning estimate is:

Here, ⌈ ⌉ denotes rounding upward. The estimate is valid only when the spare fraction is applied consistently and module granularity is subsequently checked. A 20% spare allowance does not guarantee that an additional complete I/O module, terminal strip, fuse group, or network connection is available.

For example, 37 analog inputs with a 20% planning spare give:

If modules contain 16 channels, at least three modules are required, providing 48 channels. The design should document whether the spare channels are physically wired, terminated only, or reserved in software.

3. Functional Specifications and Architecture

3.1 Functional Design Specification

The FDS defines what the automation system shall do in sufficient detail for implementation and testing. It commonly includes:

• system scope and exclusions;
• equipment and tag conventions;
• operating modes and state models;
• sequence narratives and step-transition-action tables;
• control-loop descriptions and tuning requirements;
• interlocks, permissives, trips, and reset rules;
• alarm philosophy and operator response;
• HMI screen requirements;
• historian and report requirements;
• communications and external interfaces;
• fail-safe behavior and recovery after faults;
• user roles and access control;
• testable acceptance criteria; and
• traceability to requirements and design documents.

A strong FDS avoids prescribing code structure unless that structure is necessary for safety, maintainability, or standardization. It specifies observable behavior. For example, “the pump starts” is incomplete. A better statement is: “When the operator selects automatic transfer, the discharge valve proves open, the receiving tank level is below its high-high limit, and no pump trip is present, P-201 shall start. Failure to prove running within 5 s shall generate a high-priority alarm and close the discharge valve.”

3.2 Layered automation architecture

A common architecture separates field devices, basic control, supervisory operation, manufacturing operations, and enterprise systems. The layers should exchange only the data and commands required for their responsibilities.

Figure: A layered architecture separating field control, supervisory operation, manufacturing operations, and enterprise planning.

The architecture should define ownership of functions. Fast interlocks generally belong in the control or safety layer, operator visualization in the supervisory layer, production scheduling in manufacturing operations, and financial planning in enterprise systems. A layered model does not imply that every plant needs every product or that communication must be strictly one-way; it provides a disciplined basis for deciding what belongs where.

Redundancy may be applied to controllers, power supplies, networks, servers, or instruments. It should be justified by the consequence of failure and required availability, not added indiscriminately. Redundancy also introduces common-cause risks, synchronization requirements, testing obligations, and additional cost.

4. ISA-88 and ISA-95 Models

4.1 ISA-88 for batch control

ISA-88 provides a model for organizing batch processes and recipes. Its physical model commonly distinguishes:

• process cell;
• unit;
• equipment module; and
• control module.

A process cell may contain a complete production area. A unit performs a major processing activity, such as mixing or reacting. An equipment module performs a coordinated function, such as charging a material. A control module is a basic controllable entity, such as a valve, motor, or temperature loop.

The procedural model separates recipe procedure, unit procedure, operation, and phase. This separation improves reuse. For example, a “charge water” phase can be reused in several recipes while parameters such as target mass and maximum time vary by product.

A phase should define its command interface, parameters, states, completion criteria, failure behavior, and operator interaction. Typical states include idle, running, held, stopped, aborted, and complete. State models make recovery and exception handling explicit rather than embedding them in undocumented code.

ISA-88 is valuable because it separates product-specific recipe information from reusable equipment control. It does not remove the need for process engineering, validation, or safety analysis.

4.2 ISA-95 for enterprise integration

ISA-95 describes activities and information exchanges between enterprise systems and manufacturing operations. It is commonly represented as levels:

• Level 0: physical process;
• Level 1: sensing and manipulation;
• Level 2: monitoring and control;
• Level 3: manufacturing operations management; and
• Level 4: business planning and logistics.

ISA-95 is not simply a communication protocol. It provides models for equipment, personnel, material, process segments, production schedules, performance, and capability. It helps define interfaces between an MES and an ERP system without forcing production logic into an enterprise application or business planning into a PLC.

Important integration questions include which system owns the batch identifier, how orders are acknowledged, how material and equipment status are represented, how timestamps are synchronized, and what happens when communication is unavailable. A robust design defines store-and-forward behavior, duplicate-message handling, data validation, and reconciliation after recovery.

5. Engineering Workflow and Verification

A disciplined workflow typically follows these stages:

1. feasibility and concept definition;
2. requirements and process-data collection;
3. basic design and control philosophy;
4. detailed design, P&IDs, I/O, architecture, and FDS;
5. procurement and vendor engineering;
6. software and panel development;
7. factory acceptance testing (FAT);
8. installation, loop checks, and site acceptance testing (SAT);
9. commissioning, performance testing, training, and handover; and
10. operation, maintenance, optimization, and eventual decommissioning.

Verification asks whether the system was built according to the specification. Validation asks whether the system meets the intended operational need. FAT can verify PLC logic, HMI behavior, alarms, simulated interlocks, and communication. SAT verifies field wiring, instrument calibration, valve action, network installation, and real equipment behavior. Performance testing demonstrates production capacity, quality, repeatability, or energy objectives.

A traceability matrix connects each requirement to design elements and tests. It exposes requirements that have no implementation or tests that do not verify a stated need.

6. Cost Estimation and Vendor Selection

6.1 Bottom-up cost estimation

An automation estimate should identify direct, indirect, and contingency costs. A simple project estimate is:

Each term is a cost in the selected currency. The equation is a planning model, not an accounting standard; its usefulness depends on complete scope and avoidance of double counting.

Contingency may be estimated as a fraction of identified cost:

where r is the contingency fraction and C_base is the defined base cost. The fraction should reflect uncertainty and risk exposure, not compensate for deliberately incomplete engineering.

For an illustrative project, suppose hardware costs $84,000, software and licenses $26,000, engineering $62,000, installation $38,000, testing $18,000, and training $7,000. Then:

With a 15% contingency:

This estimate excludes taxes and financing because they were not defined. A professional estimate states inclusions, exclusions, currency, price basis, escalation assumptions, and confidence range.

6.2 Vendor evaluation

Vendor selection should use a weighted decision matrix. If w_i is the weight for criterion i and s_i is the normalized vendor score, the weighted score is:

The weights should sum to 1, and scores should use a documented scale. Criteria may include functional fit, safety capability, interoperability, cybersecurity, lifecycle support, delivery schedule, training, installed base, maintainability, and total cost of ownership.

A low purchase price may be outweighed by proprietary interfaces, scarce programming skills, expensive licenses, poor spare-parts availability, or unacceptable outage risk. Technical compliance should be assessed before commercial scoring; a vendor that cannot satisfy a mandatory safety requirement should not win through a high price score.

7. Lifecycle Value, Risk, and Change Control

7.1 Lifecycle value

Lifecycle value includes acquisition, engineering, operation, maintenance, downtime, upgrades, energy, training, cybersecurity, and disposal. A simplified present-value model is:

Here, C₀ is initial investment at time zero, B_t is benefit in year t, C_t is operating cost in year t, and d is the annual discount rate. The model assumes cash flows are represented consistently and occur at defined time points. It should not be used to hide nonfinancial requirements such as safety or legal compliance.

For example, if an upgrade costs $100,000 initially and produces net benefits of $45,000, $45,000, and $35,000 over three years, at a 10% discount rate:

The positive result suggests economic value under the assumptions, but sensitivity analysis should test downtime, benefit, cost, and discount-rate uncertainty.

7.2 Risk management

Risk is commonly described through an event, its cause, and its consequence. A qualitative risk register records probability, consequence, owner, response, trigger, and residual risk. A simple risk-priority calculation is sometimes used:

where P, I, and D are ordinal ratings for probability, impact, and detectability. Because ordinal numbers are not true physical measurements, the resulting risk-priority number should support discussion rather than determine decisions automatically. High-severity safety risks require formal hazard analysis even if their numerical score is modest.

Typical automation risks include incomplete process data, late P&ID changes, incompatible vendor protocols, insufficient panel space, incorrect fail positions, poor alarm rationalization, cybersecurity exposure, unavailable plant personnel, and inadequate commissioning time.

7.3 Configuration and change control

A change-control process should identify the requested change, reason, affected documents, safety and cybersecurity implications, cost, schedule effect, test impact, approval authority, and implementation status. Baselines should be established for requirements, P&IDs, I/O, FDS, software, hardware configuration, and test records.

“Small” changes can have large consequences. Changing a valve from normally closed to normally open may alter process safety, sequence logic, air-failure behavior, panel wiring, HMI symbols, and FAT procedures. Every change should therefore be evaluated across technical, operational, commercial, and compliance dimensions.

8. Safety, Cybersecurity, Ethics, and Governance

Safety-related control functions should be identified through hazard and risk analysis. Basic control should not be credited as a safety function unless its independence, reliability, verification, and management satisfy the applicable safety framework. Safety requirements may involve emergency stops, guarding, burner management, pressure protection, or instrumented shutdowns.

Cybersecurity should be designed into architecture rather than added at commissioning. Relevant practices include network segmentation, least privilege, secure remote access, asset inventories, patch management, backups, application allow-listing where appropriate, logging, time synchronization, incident response, and tested recovery. Safety and cybersecurity interact: a cyber event can defeat an interlock, alter a setpoint, or prevent an operator from seeing an alarm.

Ethical engineering requires honest reporting of uncertainty, transparent assumptions, protection of worker safety, respect for privacy in production data, and refusal to bypass testing or conceal defects. Automation engineers must also consider the human consequences of poor alarm design, excessive surveillance, workforce displacement, and opaque decision-support systems.

9. Contemporary Developments and AI

Modern projects increasingly use industrial Ethernet, edge computing, digital twins, condition monitoring, cloud analytics, and model-based engineering. These technologies can improve visibility and maintenance, but they introduce dependencies, data-quality requirements, and cybersecurity exposure.

AI can assist with alarm analysis, document comparison, anomaly detection, predictive maintenance, and natural-language search of engineering records. It should not autonomously alter safety logic or production control without defined authority, validation, auditability, and human oversight. Training data may contain bias or incorrect operating conditions. An AI recommendation must be treated as evidence for engineering judgment, not as a substitute for hazard analysis or approved change control.

10. Illustrative Case: Batch Blending System

Background

A food-ingredient manufacturer plans to automate a blending cell containing three raw-material bins, a liquid dosing skid, a heated blend tank, and a transfer pump. The existing system relies on manual valve operation and paper batch records. Management requires improved recipe repeatability, electronic records, and reduced operator exposure to hot liquid.

Problem analysis

The initial request—“install a PLC and HMI”—is insufficient. Workshops identify requirements for recipe control, material verification, temperature control, tank high-level protection, cleaning sequences, operator roles, batch genealogy, and recovery after power loss. A P&ID review identifies that the liquid dosing line lacks a prove-open valve limit switch and that the tank has no independent high-high level switch.

The project team decomposes the cell into material-handling units, the blending unit, a cleaning unit, equipment modules for dosing and transfer, and control modules for valves, pumps, instruments, and the temperature loop. This follows ISA-88 principles.

Approach and solution

The control philosophy defines automatic, manual, cleaning, maintenance, and emergency modes. A recipe phase called “Dose liquid” checks material identity, confirms the receiving tank is available, proves the route, opens the valve, starts the pump, and terminates on measured mass or timeout. A high-high level switch stops dosing independently of the normal level transmitter.

The I/O list identifies 42 digital inputs, 31 digital outputs, 12 analog inputs, and 5 analog outputs. With a 20% planning spare, the estimated points are 51 DI, 38 DO, 15 AI, and 6 AO, rounded upward according to actual module sizes. The architecture uses a PLC with a separate safety controller, an operator station, a historian interface, and a segmented connection to the manufacturing operations system.

The FDS specifies phase states, alarm priorities, operator prompts, batch-record fields, and test criteria. FAT uses simulated instruments and valve feedback. SAT verifies field wiring, valve fail positions, pump rotation, temperature calibration, and cleaning behavior.

Outcome

The redesigned project detects the high-high level design gap before commissioning. Electronic batch records improve traceability, while phase reuse reduces recipe-development effort. The project costs more than a direct PLC replacement because it includes independent protection, documentation, testing, and integration. However, the lifecycle evaluation shows that reduced rework, fewer batch deviations, and lower exposure justify the additional investment.

Learning points

The case demonstrates that automation design is not equivalent to programming. Requirements, process safety, ISA-88 decomposition, I/O quality, independent protection, testing, and lifecycle value must be considered together.

Challenges and Limitations

No model fully captures plant complexity. ISA-88 and ISA-95 provide useful structures but require local interpretation. Cost estimates are uncertain when process data or vendor quotations are incomplete. Weighted scoring can create false precision if criteria or weights are biased. Risk matrices can understate rare catastrophic events. Redundancy cannot correct poor maintenance or common-cause design errors. Digital technologies can increase dependence on specialized skills and introduce cyber risks. Finally, a technically correct system may still fail if operators are not involved in design, training, testing, and continuous improvement.

Best-Practice Checklist

• Establish a traceable requirements baseline.
• Use P&IDs, control philosophy, I/O lists, and FDS as mutually consistent documents.
• Define normal, abnormal, maintenance, emergency, and recovery behavior.
• Separate basic control, safety functions, supervisory operation, and enterprise integration.
• Apply ISA-88 to reusable batch equipment and procedural structures.
• Apply ISA-95 to information ownership and manufacturing-enterprise interfaces.
• Estimate cost from transparent scope and state exclusions.
• Select vendors using technical compliance and lifecycle value, not purchase price alone.
• Test requirements at FAT, SAT, commissioning, and performance stages.
• Control changes through documented impact assessment and approval.
• Integrate safety, cybersecurity, human factors, and maintainability from the beginning.

Chapter Summary

Automation system design converts operational, safety, quality, information, and business requirements into a controlled engineering baseline. The control philosophy defines modes, sequences, interlocks, alarms, failures, and operator interaction. P&IDs and I/O lists provide the process and signal foundations, while the FDS describes observable behavior and testable acceptance criteria. Layered architectures allocate responsibilities among field devices, controllers, supervisory systems, manufacturing operations, and enterprise planning.

ISA-88 structures batch equipment and procedures for reuse and recovery. ISA-95 structures information and responsibilities between manufacturing operations and enterprise systems. Bottom-up cost estimation, weighted vendor evaluation, lifecycle economic analysis, risk management, and configuration control support sound project decisions. Safety, cybersecurity, ethics, human factors, and AI governance are integral to professional engineering. The central principle is that a reliable automation project is engineered as a complete lifecycle system, not merely delivered as PLC code.

Key Terms

Requirement: A documented statement of a needed capability, condition, or constraint.

Control philosophy: The approved description of how a process will be operated and controlled.

P&ID: Process and instrumentation diagram showing process equipment, piping, instruments, and control relationships.

I/O list: Controlled register linking field signals to control-system channels and functions.

Functional Design Specification: Document defining required automation behavior in sufficient detail for implementation and testing.

Permissive: Condition that must be true before an operation is allowed.

Interlock: Logic that prevents or interrupts an operation when a defined condition exists.

Trip: Protective action that moves equipment or a process to a specified safe state.

FAT: Factory acceptance test performed before shipment or site installation.

SAT: Site acceptance test performed after installation at the operating facility.

ISA-88: Standardized model for batch physical equipment, procedures, recipes, and states.

ISA-95: Model for integration between enterprise systems and manufacturing operations.

Traceability: Ability to connect requirements, design elements, implementation, and tests.

Configuration management: Controlled identification, approval, and tracking of system versions and changes.

Lifecycle value: Total value considering acquisition, operation, maintenance, risk, benefits, and disposal.

Contingency: Budget allowance for identified uncertainty and risk exposure.

Risk register: Controlled record of risks, causes, consequences, owners, responses, and status.

Safety instrumented function: A defined safety action implemented with specified reliability and independence.

Defense in depth: Use of multiple independent or complementary protective layers.

Manufacturing execution system: System that manages and records manufacturing operations between planning and control.

Review Questions

Short Answer Questions

1. What is the purpose of a control philosophy?
2. Distinguish a permissive, an interlock, and a trip.
3. Why must an I/O list be reconciled with the P&ID and test documents?
4. What is the main purpose of ISA-88 in batch automation?
5. State two differences between FAT and SAT.

Long Answer Questions

1. Explain how a process requirement is transformed into a control philosophy, FDS, I/O list, and test procedure.
2. Describe the ISA-88 physical and procedural models and explain how they support reuse.
3. Explain the role of ISA-95 in integrating manufacturing operations with enterprise systems.
4. Discuss the technical and lifecycle factors that should influence automation vendor selection.
5. Explain why safety, cybersecurity, and configuration management must be included from project conception.

Analytical / Application Questions

1. A project has 37 analog inputs and requires a 20% planning spare. Calculate the required number of channels and determine how many 16-channel modules are needed. State one limitation of this calculation.
2. Design a change-control impact assessment for changing a process valve from normally closed to normally open. Identify at least six affected engineering or operational areas.
3. Propose an automation architecture for a batch blending cell using ISA-88 and ISA-95. Identify the responsibilities of field control, supervisory control, manufacturing operations, and enterprise systems.

Multiple Choice Questions with Answers

Question 1

Which document primarily defines the observable behavior of an automation system for implementation and testing?

A. Functional Design Specification

B. Cable schedule

C. Purchase order

D. Equipment nameplate

Correct Answer: A. Functional Design Specification

Question 2

An automation project requires 37 analog inputs and a 20% planning spare. Using upward rounding, how many channels should be planned?

A. 37

B. 40

C. 44

D. 45

Correct Answer: D. 45

Question 3

In ISA-88, which element is a reusable procedural action such as charging a material or controlling a temperature hold?

A. Enterprise resource

B. Phase

C. Process cell

D. Production schedule

Correct Answer: B. Phase

Question 4

Which ISA-95 level is most closely associated with manufacturing operations management?

A. Level 0

B. Level 1

C. Level 3

D. Level 4

Correct Answer: C. Level 3

Question 5

What is the main purpose of a permissive?

A. To record historical data

B. To allow an operation only when required conditions are true

C. To calculate project contingency

D. To replace a safety analysis

Correct Answer: B. To allow an operation only when required conditions are true

Question 6

Which activity most directly verifies field wiring and installed instrument behavior?

A. Concept study

B. Factory acceptance test

C. Site acceptance test

D. Vendor prequalification

Correct Answer: C. Site acceptance test

Question 7

If the base project cost is $235,000 and contingency is 15%, what is the total estimated cost before taxes and financing?

A. $238,525

B. $250,000

C. $270,250

D. $305,500

Correct Answer: C. $270,250

Question 8

Which factor is most appropriate when evaluating lifecycle value?

A. Purchase price only

B. Initial price, operating cost, maintenance, downtime, and upgrade effects

C. Number of vendor brochures

D. Color of the HMI screens

Correct Answer: B. Initial price, operating cost, maintenance, downtime, and upgrade effects

Question 9

Why should a high-severity safety risk not be dismissed solely because its risk-priority number is low?

A. Ordinal risk scores may not represent catastrophic consequences adequately

B. Safety risks never require documentation

C. Risk numbers are always financial values

D. Low scores prove that the design is safe

Correct Answer: A. Ordinal risk scores may not represent catastrophic consequences adequately

Question 10

Which practice best supports cybersecurity in an industrial automation architecture?

A. Allowing unrestricted remote access

B. Using one shared administrator account

C. Network segmentation and least-privilege access

D. Disabling all event logs

Correct Answer: C. Network segmentation and least-privilege access