45 PLC & SCADA Interview Questions + 5 Practical Tests

Direct answer: prepare the data contract and failure evidence, not just definitions

The most useful PLC and SCADA interview questions test whether you can trace a physical condition through field instrumentation, PLC or RTU logic, communications, tag quality and timestamps, a SCADA server, historian, alarm state and operator display—then identify the first layer whose observed evidence disagrees with the expected state. Prepare architecture, tag contracts, command handshakes, alarm lifecycle, historical data, redundancy, OT security and troubleshooting. Be ready to complete a practical scenario, not merely expand the acronym SCADA.

A strong answer follows four moves:

1. Model: define the component, state or data path precisely.
2. Evidence: name the values, quality, timestamps, logs, versions or physical measurements that would prove it.
3. Boundary: state what the available evidence does not prove and which platform details must be verified.
4. Action: propose the next controlled test, expected result and recovery check.

Interview target	Likely emphasis	Evidence to prepare	Weak answer pattern
junior SCADA/HMI engineer	tags, screens, navigation, alarms, basic PLC/network path	small project, tag list, screen hierarchy and test record	“I know the software” without a working artifact
PLC/SCADA integrator	request/command/feedback contracts, drivers, commissioning	I/O-to-tag mapping, handshake trace and FAT/SAT evidence	treats HMI bits as direct machine truth
SCADA support technician	services, clients, drivers, databases, backups and diagnosis	incident timeline, logs, recovery steps and verified restore	restarts every server before isolating a layer
senior SCADA engineer	architecture, availability, alarm/historian lifecycle, security and change	design basis, RTO/RPO tests, version matrix and review record	claims redundancy means zero interruption or data loss
hiring manager	safe reasoning, depth, communication and practical proof	consistent rubric and role-calibrated scenario	grades confidence or vendor vocabulary only

These questions are original preparation material. They are not recalled employer questions, leaked tests or a guarantee about a particular interview. Use the job description, vendor stack, industry, installed version and project lifecycle to choose depth.

This page owns SCADA-specific interview preparation and practical assessment. The PLC programmer interview guide owns deeper ladder, scan, I/O and PLC-platform questions. The automation engineer interview guide owns the broader role across PLC, instrumentation, PID, networks, HMI/SCADA, drives, safety and projects. The SCADA architecture guide owns system design without the interview format.

SCADA architecture interview questions and answers

1. What is SCADA?

SCADA is a supervisory control and data acquisition system: software and supporting infrastructure that acquires process data, presents status and alarms, records history, and—where authorized—sends supervisory requests or setpoints to controllers. It does not replace the deterministic/local control, interlocks or safety functions owned by PLCs, RTUs, DCS controllers or safety systems. NIST SP 800-82 Rev. 3 describes SCADA as combining acquisition, transmission and HMI software for centralized monitoring and control of distributed process inputs and outputs.

An interview-quality answer adds scope: one platform may include drivers/OPC servers, tag services, HMI clients, alarm services, historians, reporting, identity and redundancy, while another delegates several of those functions to separate products.

2. What is the difference between an HMI and SCADA system?

An HMI is the operator-facing human-machine interface. SCADA describes the wider supervisory system and may include many HMI clients plus data acquisition, server services, alarms, history, reports, remote sites and security controls. A standalone machine touchscreen can be an HMI without being a plant-wide SCADA system. Product marketing blurs the boundary, so define the actual architecture rather than arguing from a label.

3. What is the difference between PLC, RTU, DCS and SCADA?

System	Core role	Interview boundary
PLC	controller executing application logic against local/distributed I/O and tasks	exact scan/task, I/O update and protocol behavior are platform-specific
RTU	remote telemetry/control unit for distributed sites and constrained/remote communications	store/forward, low-power, timestamping and protocol behavior depend on target
DCS	integrated distributed control platform, commonly process-oriented	controller, operations, engineering and historian integration vary by system
SCADA	supervisory acquisition, visualization, alarming, history and authorized commands	must not be described as the owner of every fast loop or safety function
HMI	human interaction and visualization surface	displayed value may be stale, bad quality or merely a request/echo

The best answer explains ownership on the interviewer's system. For example, a PID loop may execute in a PLC while SCADA supplies a bounded setpoint and trends process response.

4. Describe the data path from a field sensor to an operator screen.

Trace the physical signal, input module/channel, raw value and quality, PLC/RTU scaling and engineering tag, communications endpoint/driver, SCADA tag/provider, expression or derived layer, server service, client binding and displayed object. Include source timestamp, server receipt time and data age where available. For history, add sampling/change policy, deadband/compression, store-and-forward, database/historian and query/render path.

At every layer, state expected versus observed. “The screen is wrong” is a symptom, not a layer.

5. Why are request, command and feedback separate tags?

An operator request says what a user asks for. PLC logic may accept or reject it based on mode, authority, permissives and state. A command is the controller's final ordinary-control intent toward an output/device. Feedback is an independent observation that the final element or process achieved a condition. Separating them lets the screen show Requested, Starting, Running, Rejected and Faulted honestly.

If one Run bit serves all roles, an operator cannot tell whether the button write failed, the PLC rejected it, the output was not commanded, or the motor failed to respond.

6. What is polling versus report by exception?

Polling requests values on a configured schedule. Report by exception or subscribed/change-driven transfer reports values/events when a defined change occurs, often with keepalive or integrity mechanisms. Neither is universally better. Choose from protocol capability, bandwidth, point count, latency, time coherence, deadband, outage recovery and operational requirements.

Also separate communications acquisition from screen refresh and historian storage. A driver may subscribe at 250 ms, the client may render at 1 s, and history may store on change plus a maximum interval. Calling all three “the scan rate” hides the actual design.

7. How do PLC scan time, communication rate and display refresh interact?

They are different clocks. The PLC task produces values at its configured execution/update model. The driver or server samples/subscribes according to protocol and group settings. Network queuing and server/client subscriptions add latency. The display renders at its own update policy. The operator therefore sees a value whose age can exceed any one interval.

A defensible budget is:

worst observed age ≈ controller production/update
                   + acquisition interval/latency
                   + server processing/queue
                   + client subscription/render
                   + clock uncertainty

Measure end-to-end behavior for the critical signal; do not add nominal values and call that guaranteed worst case without jitter and outage analysis.

8. What belongs in a SCADA tag contract?

At minimum: stable identity and description; source owner/address; data type; units; normal and engineering range; scaling owner; read/write authority; quality mapping; source/server timestamp policy; stale-age rule; acquisition/update behavior; history sampling/deadband/compression; alarm/event rules; security role; fallback/degraded behavior; version; and acceptance evidence.

Download the PLC/SCADA interview tag-contract example. It maps a tank temperature, level, pump request/accept/command/feedback/fault/error/reset chain without pretending that one vendor's import format is portable.

9. Why is a tag value alone insufficient?

A value such as 72.4 °C is meaningful only with identity, units, range, quality, timestamp and age. The same number can be current and good, a last-known value after communications failure, a server-substituted value, an engineering-unit mismatch or historical data displayed as live. A screen that paints an old value green because the numeric range is normal can mislead the operator.

OPC UA's Data Access model defines status/quality and timestamps; exact support and mapping depend on the server/client and underlying source. Current Ignition 8.3 documentation likewise exposes current value, quality and timestamp in tag diagnostics and stores timestamp, quality and value for configured history. Use the target product's actual semantics.

10. What is the difference between source timestamp and server timestamp?

The source timestamp represents when the data source says the value was generated or observed; the server timestamp represents when the server received/processed it. The gap can reveal transport or queue delay, but only if clocks and timestamp origins are known. Some sources cannot supply a meaningful source time, and intermediaries may remap timestamps. Record clock synchronization, timezone/UTC handling, precision and behavior across daylight-saving changes where local display time is used.

HMI and alarm interview questions and answers

11. What makes an effective SCADA display?

An effective display supports the operator's task and abnormal-situation recognition. It uses a documented hierarchy, consistent navigation, readable units and ranges, honest quality/stale indication, restrained color reserved for state significance, clear command/feedback distinction, discoverable alarm context and predictable interaction. It is tested with representative operators and failure states rather than accepted because it looks modern.

ISA-101 describes an HMI lifecycle spanning philosophy, design, implementation, operation and continuous improvement. In an interview, cite the lifecycle and evidence; avoid claiming one gray palette or symbol set is universally mandated.

12. What is the difference between an alarm, event and status?

An alarm indicates an abnormal condition requiring a defined, timely operator response. An event records a transition or action that may be important but does not itself demand operator correction. Status reports current state. Motor Start pressed is normally an event; Motor Running can be status; Pump discharge pressure dangerously low while running may be an alarm if a specific operator action is required.

Making every fault or state an alarm creates overload and destroys prioritization.

13. What does alarm acknowledgement mean?

Acknowledgement records that an authorized user recognized the alarm. It does not mean the condition cleared, the root cause was repaired, the machine reset or the process is safe. Active/cleared and acknowledged/unacknowledged are independent dimensions in common alarm models. Preserve user, time and comment/audit context according to requirements.

14. Explain the alarm lifecycle.

The lifecycle begins with philosophy and identification, then rationalization, detailed design, implementation, operation, maintenance, monitoring/assessment and management of change. At runtime, a single alarm event may be active-unacknowledged, active-acknowledged, cleared-unacknowledged or cleared-acknowledged depending on the product model. Suppression and shelving add distinct visibility/management states.

ISA-18.2 covers alarm-system lifecycle management in process industries. OPC UA Part 9 models active, acknowledged, suppressed and shelved concepts. A product can present different labels or transition details, so map the project's exact state model.

15. How should alarms be prioritized?

Prioritize from consequence and required operator response time under the approved alarm philosophy—not from equipment importance alone or a developer's preference. Rationalization should record cause, consequence, operator action, time available, setpoint, delay/deadband, priority, suppression rules, reset/return behavior and proof test. The number of priority bands and labels is project-specific.

16. What is alarm deadband versus delay?

Deadband/hysteresis requires the process value to move away from a threshold before the alarm clears or changes state, reducing chatter near the boundary. On-delay requires the abnormal condition to persist for a time before activation; off-delay can affect return behavior where specified. Both can hide fast hazards if chosen casually. Base them on process dynamics, consequence and operator needs, then boundary-test duration and value crossings.

17. What is the difference between suppression and shelving?

Suppression is generally a designed/system-driven prevention of alarm presentation under a known operating condition, such as equipment out of service, with explicit logic and governance. Shelving is typically a time-bounded operator action to temporarily remove a nuisance alarm from normal display. Exact definitions follow the selected standard/product. Both need visibility, authorization, audit and recovery; neither is a permanent repair.

18. How do you diagnose alarm flooding?

Capture rate, priority distribution, top contributors, standing alarms, chattering alarms, consequence and timeline around the initiating event. Identify cascades and bad instrumentation rather than raising every delay. Repair rationalization, state-based suppression, deadbands, equipment diagnostics and first-out evidence under change control. Then replay or test the abnormal scenario and measure improvement against the alarm philosophy.

19. How should a SCADA command be designed?

Define user/role, target identity, current mode/state, request value and sequence/nonce where required; let the controller validate and report accepted/rejected; expose progress, completion/failure and timeout; prevent stale/replayed or repeated actions; audit the user/time/result; and define behavior on client, server or network loss. A momentary Boolean write can be lost or repeated, so do not assume it is a handshake.

For a simple Pump Start, useful states include StartRequest, RequestId, AcceptedRequestId, Commanded, RunningFeedback, Faulted, ErrorId and CommandQuality. The exact implementation must suit the PLC and SCADA platform.

20. How do you test an HMI screen?

Test every meaningful state, not only normal operation:

Test group	Required cases
data	minimum, normal, maximum, out-of-range, bad, uncertain, stale and missing
command	authorized, unauthorized, accepted, rejected, delayed, lost, repeated and concurrent
equipment	stopped, starting, running, stopping, faulted, unavailable and contradictory feedback
alarm	activation, delay, deadband, priority, acknowledgement, return, suppression, shelving and flood context
navigation	every path, faceplate/context, back behavior, resolution and multi-monitor target
failure	driver loss, server loss, historian/database outage, clock issue and recovery
accessibility/use	contrast, focus/input, readable units, color-independent meaning and operator task completion

Record the target version, test stimulus, expected result, observed result, evidence reference and disposition.

Historian and data-integrity interview questions

21. What is a historian?

A historian is a time-series data service optimized to acquire, preserve and query operational values/events with their time and data-quality context. It is not merely “a SQL database.” Products may use proprietary or standard storage, compression, aggregation, replication and retrieval models. Define source, timestamp, quality, sampling, deadband/compression, retention, late-data behavior, access and recovery requirements.

22. What is the difference between sampling, deadband and compression?

Sampling decides when the acquisition/history layer evaluates or records a candidate value. Deadband decides whether a change is significant enough relative to the configured rule. Compression can reduce stored points while aiming to preserve a trend within an error rule. Product terms differ, and a display subscription policy is not automatically the historian policy.

For each critical tag, test a slow ramp, step change, oscillation inside/outside deadband, short excursion, bad quality, communications outage and backfill. Confirm that later analysis can answer the engineering question the data was collected for.

23. Which timestamp should history use?

Prefer a documented timestamp representing the required event/measurement time where the source and clocks can support it. Retain enough context to distinguish source time from server receipt/ingest time. If a remote RTU buffers values during an outage, source time can reconstruct the event sequence; if that clock is wrong, it can also corrupt chronology. Define synchronization, drift monitoring, UTC/timezone conversion, daylight-saving display and out-of-order acceptance.

24. How do you handle stale or bad-quality values in trends?

Preserve quality and represent gaps or invalid regions honestly. Do not connect the last good value through a long outage as if the process stayed constant. Set a stale policy based on expected acquisition and process criticality, show the operator data age, and keep substituted/manual values distinguishable. Queries and reports must either filter, annotate or calculate with quality according to a documented rule.

25. What is store-and-forward?

Store-and-forward buffers records locally when the target historian/database is unavailable and sends them later after recovery. A good answer discusses finite buffer capacity, ordering, duplicate handling, source timestamps, backpressure, disk health, security, monitoring and what happens when the outage exceeds capacity. It is not a promise that every record survives any outage.

26. Why can a historian trend disagree with the live display?

The paths may have different source tags, timestamps, sampling, deadbands, expressions, aggregation, time ranges, quality filters, units or server clocks. The live display may show a current subscription while the chart uses stored aggregates. Compare tag identity and source first, then raw current value/quality/time, history configuration, stored raw records and query/render settings.

27. How do you test a historian after a database outage?

Define the outage stimulus and safe test window. Record the last pre-outage value/time, buffer/store-forward state, values generated during the outage, recovery time, backlog drain, duplicates, order, quality and final query result. Compare the measured gap and delay with RPO/retention requirements. Verify alarms and disk monitoring for an approaching full buffer.

28. What is an audit trail, and how is it different from process history?

Process history records operational values/events. An audit trail records security- and change-relevant actions such as login, command, acknowledgement, configuration edit, download, recipe change or privilege change, with identity, time, target and outcome according to requirements. Audit records must be protected and reviewable. Do not claim an application log is automatically a compliant audit trail without the regulated/system context.

SCADA networking, redundancy and security questions

29. How do you diagnose a PLC-to-SCADA communication failure?

Work layer by layer:

1. confirm scope—one tag, device, driver, server, client or site;
2. record physical/link state and network-path evidence;
3. verify addresses/routes, duplicate addresses and firewall/rule context;
4. inspect controller/RTU communications status and resource loading;
5. inspect driver/session state, request errors and reconnect behavior;
6. compare configured device, protocol, port, slot/unit/node and tag addresses;
7. inspect tag quality, timestamp and age at the server;
8. inspect client binding/cache; and
9. prove recovery without leaving tests, forces or temporary firewall changes.

“Ping works” proves only a limited network observation; it does not prove the industrial protocol session, address map or fresh application data.

30. What is an OPC server, and what does OPC UA add?

An OPC server exposes industrial data and related services to clients through an OPC specification. OPC UA provides a platform-independent service and information model with typed nodes, status codes, timestamps, subscriptions and security capabilities, with profiles determining implemented features. Data Access, historical access and Alarms & Conditions are separate specification parts/capabilities. Verify server/client profiles, certificates/trust, endpoint security policy/mode, identity, namespace/address stability and exact feature support.

Do not answer “OPC UA is secure by default.” Security must be configured, certificates and trust maintained, identities authorized, and insecure/legacy endpoints controlled.

31. When would Modbus, OPC UA or a message broker fit?

Need	Likely fit	Boundary to state
simple register/coil access to a supported device	Modbus TCP/serial	application meaning, data type, word order, freshness and security are not self-describing enough by themselves
structured client/server industrial data with quality/time/model	OPC UA	implementation profiles, namespace, security and mapping still require design
decoupled publish/subscribe telemetry across services/sites	MQTT-based architecture, possibly Sparkplug where supported	broker availability, state/birth/death semantics, retained messages, QoS and command safety need explicit design

Protocol selection follows roles, failure behavior, timing, installed support and security—not a popularity ranking.

32. What is SCADA redundancy?

Redundancy provides an alternate component/path that can continue a defined service when the primary becomes unavailable. It can apply separately to HMI servers, data servers, historians/databases, networks, directories/identity, clients, power and controllers. A redundant HMI server does not automatically make the driver, database, network or controller redundant.

A strong answer names the failure set, active/standby or other model, state synchronization, detection, switchover, client behavior, command risk, data gaps, recovery, test cadence and maintenance mode.

33. What are RTO and RPO?

Recovery Time Objective (RTO) is the target time to restore a defined service after disruption. Recovery Point Objective (RPO) is the acceptable data-loss window or point in time to which data must be restored. Define the service/data set and failure case; one system can have different targets for live control view, alarms, history and reports. Then test and report measured recovery time and observed data gap.

34. How do you test SCADA failover?

Test an approved failure, not an improvised production outage. Establish a synchronized baseline and active/standby health. Generate identifiable changing values and a controlled command state. Trigger one defined failure—service, host, network path or power—then measure detection, role transition, client reconnect, tag quality/time, alarm continuity, command duplication/loss, history gap, audit events and recovery. Repeat failback/maintenance conditions separately.

Current Ignition and FactoryTalk documentation illustrate product-specific redundancy settings and states, but neither makes a universal zero-gap guarantee. Use the exact platform/version manual and test architecture.

35. What is split-brain risk?

Split brain occurs when redundant partners cannot coordinate but more than one may believe it should be active, potentially causing conflicting service or state. The exact risk and prevention mechanism depend on product and architecture. Discuss heartbeat/quorum/witness or tie-breaking design, network partition cases, fencing, command ownership, alarm/history duplication and recovery. Never test by severing links without understanding the platform's active-role logic.

36. How should SCADA remote access be secured?

Begin with business/operational need and an approved access architecture. Use segmented paths rather than direct exposure, strong identity and multi-factor authentication where supported, least privilege, managed/jump access, time-bound authorization, encrypted supported protocols, logging/monitoring, hardened endpoints, controlled file transfer, session termination and an incident/revocation procedure. Validate the effect of access loss and do not make safety or essential control depend on remote connectivity.

NIST SP 800-82 Rev. 3 addresses OT security with its performance, reliability and safety constraints; CISA retains control-system remote-access and defense-in-depth recommended practices. Tailor controls through risk assessment and current product/vendor requirements.

37. How do least privilege and role-based access apply to SCADA?

Define roles from tasks: view, command, acknowledge, change setpoints, manage recipes, configure tags/screens, administer servers, manage users and export data. Grant the minimum scope and duration, separate engineering/admin from routine operation, remove shared/default accounts, protect service identities, review dormant access and log sensitive outcomes. Test denied as well as allowed actions. A hidden button is not authorization; server-side/platform enforcement is required.

38. How do you patch a SCADA system?

Maintain an asset/version/dependency inventory, monitor vendor and security advisories, assess consequence and exploitability, confirm support/compatibility, back up and prove recovery, test in representative non-production conditions, schedule approved change, protect required availability, deploy in a controlled order, validate drivers/clients/alarms/history/redundancy, monitor and document rollback. “Never patch OT” and “install every patch immediately” are both weak blanket policies.

SCADA troubleshooting scenario questions

39. The HMI says Run, but the motor is stopped. What do you do?

First define what “Run” represents. Read the operator request and its quality/time, PLC acceptance/rejection, mode/permissives, final run command and all writers, output image/module status, measured electrical output under approved procedures, contactor/drive state, motor feedback and process response. Stop at the first mismatch. Check alarm/event chronology before resetting anything. Do not force the output to test a guess.

40. One tag is stale while other tags from the PLC are current. What do you check?

Compare its exact source path/address, data type, read mode, tag-group/subscription, enabled state, expression/dependency, quality code and timestamp with a known-good neighbor. Check controller tag existence/scope, optimized or external-access settings where relevant, array/index bounds and driver diagnostics. A one-tag issue usually narrows the fault below the site/network layer.

41. The driver reports connected, but all values are wrong. What could cause it?

Connection proves a session, not a correct data contract. Check target controller/node/unit/slot, register/tag map, address base, byte/word order, data type, scaling, firmware/project version, stale cache and whether the driver connected to the wrong but reachable device. Compare one controlled source value at controller and server raw layers before editing hundreds of tags.

42. Live values work, but history is missing. How do you isolate it?

Confirm history is enabled on the intended tag/provider and that the tag ID/path matches the query. Inspect sampling/deadband, quality filters, historian/database connection, store-and-forward/backlog, disk and service health, time range/timezone and query aggregation. Read a raw stored record around a deliberate change. Do not increase logging rate before proving the storage path.

43. An alarm is active in the PLC but absent from the SCADA banner. What do you inspect?

Identify whether the PLC bit is the alarm source or an upstream condition. Check its tag value/quality/time at SCADA, alarm configuration/enabled state, condition/setpoint, active delay, suppression/shelving/out-of-service state, display filter, area/priority, user permissions and client/server clock. Query active alarm status at the server, then compare the banner filter. Preserve the audit trail before unshelving or changing configuration.

44. Timestamps from two sites disagree by an hour. How do you respond?

Separate stored UTC or source times from client display timezone. Check site/server/client timezone, daylight-saving rules, clock synchronization source/status, offset/drift and whether the protocol preserves source time. Use a known event visible at both ends, capture raw timestamps and conversions, then correct the configuration under change control. Editing historical records may be inappropriate; document the affected interval.

45. What should be verified after SCADA service restoration?

Verify correct version/configuration, role and dependencies; current/fresh tag quality; driver and device coverage; alarm state reconciliation; pending/stale commands; client reconnect/navigation; history/audit backlog; redundancy synchronization; time synchronization; user/role behavior; reports/integrations; disk/resource health; temporary account/firewall/test changes cleared; and an operational handback record. “Service is running” is not proof the supervisory function is restored.

Five practical PLC/SCADA interview tests

Use a small transfer system: Tank 101 has temperature and level measurements; Pump 101 has Start request, PLC acceptance, final command, run feedback, fault and error identity. The SCADA system displays status, trends temperature/level, lets an authorized operator request Start/Reset, alarms failed start and high temperature, and retains history through a bounded database outage.

Download the tag-contract example and 100-point practical scorecard. No generic project file can run unchanged across Ignition, WinCC, FactoryTalk, AVEVA and other products, so candidates should implement the same contract in the employer's named platform or present vendor-neutral evidence without inventing portability.

Practical 1: draw and defend the architecture

Prompt: Draw field instruments/actuator, PLC, network, acquisition/driver, SCADA server, historian/database and two clients. Mark command and observation directions, security zones/trust transitions, time sources and five failure boundaries.

Acceptance: another engineer can trace Tank temperature to the display and Pump Start from user request to PLC response; no screen write bypasses the controller's command validation; safety remains separate.

Failure injection: remove the historian connection. Explain which live functions remain, which degrade, which alarms notify the outage and what buffer limit matters.

Practical 2: complete the tag contract and command handshake

Prompt: Complete all CSV fields for the nine supplied tags and draw a request/accepted/rejected/completed sequence. Define quality, age, timeout, authorization, audit and repeated/lost request behavior.

Acceptance: tags have type, units, source/write owner, quality/time policy and test evidence; a stale request cannot start the pump after reconnection; HMI shows rejected versus failed-to-start distinctly.

Failure injection: delay acceptance beyond the HMI timeout, then deliver a late acceptance. Explain how sequence identity prevents the late response being mistaken for the next request.

Practical 3: rationalize and test two alarms

Prompt: Define P101 Start Feedback Timeout and TK101 High Temperature: cause, consequence, operator action, time available, setpoint/preset, delay/deadband, priority, suppression rule, acknowledgement, return/reset and test cases.

Acceptance: each condition needs operator action, has defensible priority, distinguishes acknowledgement from clearance/reset, and includes boundary/chatter/bad-quality tests.

Failure injection: create ten threshold crossings around High Temperature. Show how deadband/delay and process dynamics should be evaluated without hiding a real fast event.

Practical 4: diagnose “HMI says Run, motor stopped”

Prompt: The display is green, P101_START_REQ=1, motor is visibly stopped. You may ask for five observations before proposing a change.

Strong five observations: tag quality/time and meaning of green state; accepted/rejected status; PLC final command and permissive/fault cause; output/drive/contactor evidence; independent run feedback/process response. A different set can score fully if it isolates the first failed boundary safely.

Acceptance: candidate separates observation from inference, avoids forcing, preserves chronology, predicts the result of the next approved test and verifies recovery.

Practical 5: design a failover and recovery test

Prompt: The requirement says live supervisory view RTO ≤ 15 minutes and history RPO ≤ 5 minutes for loss of the primary SCADA server. Design the test.

Acceptance: manifest and synchronized baseline; defined primary failure; changing sequence-tag stimulus; active/standby role evidence; client/tag/alarm/command behavior; measured RTO; measured history gap against RPO; recovery/failback; configuration sync; temporary-state clearance and signed result.

Failure injection: the standby becomes active, but its display is one revision old. Explain why service availability alone is not acceptance and how version/replication evidence should have caught it.

Score the practical assessment consistently

Category	Points	Full-credit behavior	Red flag
architecture and boundaries	20	clear owners, interfaces, control/observation split and failure effects	one vague network cloud or SCADA owns all control
tag contract	20	type, units, quality, time, authority, history and tests	address list only
alarm management	20	actionable lifecycle, priority, state and abnormal tests	every event is critical; acknowledge equals reset
diagnosis	20	first failed layer, expected/observed evidence and recovery proof	guesses component or restarts everything
evidence and safety	20	versions, audit, RTO/RPO, limits, safe authority and handoff	forcing/bypass suggestion or unsupported zero-loss claim

For junior roles, permit prompting and emphasize accurate basics. For senior roles, add capacity, lifecycle, security, migration and conflicting-stakeholder constraints. Do not use trick questions based on one vendor's menu path unless that exact version is an essential job requirement and the candidate has fair notice.

Vendor-specific follow-up questions

Ask platform follow-ups only after the vendor-neutral model is correct:

Platform/context	Useful follow-up	Strong boundary
Ignition	tag providers/UDTs, tag groups, quality/time, alarm states, history/store-forward and Gateway redundancy	answer names installed 8.1/8.3 version and module/database dependencies
FactoryTalk View SE	network distributed application, HMI/data servers, Directory/security, redundancy, archive/restore and version support	answer distinguishes HMI server, data server and historian redundancy
Siemens WinCC	exact TIA/WinCC generation, tag/connection, alarm/history, client/server and redundancy options	answer does not mix Classic, Professional and Unified behavior
AVEVA/Wonderware lineage	exact System Platform/InTouch/historian release, objects, deployment and redundancy	answer avoids universalizing a legacy Galaxy/application workflow
OPC UA integration	endpoint/profile, certificates, namespace, status/time, subscription and recovery	“connected” is not proof of correct fresh data
remote RTU estate	low-bandwidth/reporting, store-forward, source time, integrity scan and communications loss	answer includes stale/late data and autonomous local control

Prepare one project story in this format: requirement; architecture; your exact responsibility; target/version manifest; tag/alarm contract; normal and abnormal tests; one defect found; evidence; change/recovery; outcome; and limitation. Redact customer names, credentials, addresses, proprietary code and sensitive network diagrams.

Frequently asked questions

What PLC and SCADA interview questions should a beginner prepare?

Prepare SCADA versus HMI/PLC, field-to-screen data flow, tag type/units/quality/time, request versus command versus feedback, basic alarms and acknowledgement, historian purpose, one communications diagnosis and one safe motor scenario. Practise explaining a small project and its tests aloud.

What should a SCADA engineer know about PLCs?

Enough to understand controller ownership, scan/task and I/O update concepts, data types, mapping, command/permissive/feedback state, quality, safe online access, change control and diagnostics. The required programming depth depends on whether the role builds controller logic or integrates it.

What is the best answer to “What is SCADA?”

SCADA is the supervisory acquisition, visualization, alarming, history and authorized-command layer over PLCs, RTUs or other controllers. Add the actual architecture and state that local control, interlocks and safety do not automatically belong to SCADA.

How many SCADA interview questions should I practise?

Depth matters more than count. Be able to answer the 45 here briefly, then demonstrate the five practical categories. Ten memorized definitions are less convincing than one tag contract, alarm rationale, fault trace and failover test with evidence.

Do I need experience with the employer's exact SCADA software?

If it is an essential requirement, expect version-specific follow-ups. Still lead with portable architecture, data, alarm and diagnostic reasoning, then map it to the exact product honestly. Do not claim experience from watching a tutorial; show transferable evidence and a learning plan.

What practical task appears in a SCADA interview?

Common fair tasks include drawing an architecture, mapping tags, designing a screen/command handshake, rationalizing alarms, diagnosing stale/wrong data, explaining historian gaps or designing redundancy tests. The task should state platform/version, scope, safety boundary, time and scoring.

How do I answer “HMI says Run but the motor is stopped”?

Clarify what Run means, then trace request, PLC acceptance, mode/permissives, final command, output/drive/contactor, independent feedback and process result with quality/timestamps. Find the first mismatch, propose one controlled test and verify recovery. Do not guess or force first.

Is alarm acknowledgement the same as alarm reset?

No. Acknowledgement records recognition by a user. The abnormal condition can remain active. Reset changes a latched equipment/control state only under its designed prerequisites. Return-to-normal describes the process condition clearing. Keep the states separate.

What is the difference between RTO and RPO in SCADA?

RTO is the target time to restore a defined service. RPO is the acceptable data-loss point/window. Name the service, history set and failure case, then measure both during a controlled failover/recovery test.

What cybersecurity topics belong in a SCADA interview?

Asset/version inventory, segmentation, identity and least privilege, secure remote access, supported encrypted protocols, backups/recovery, patch/vulnerability handling, logging/monitoring, incident response, vendor access and safety/availability constraints. Avoid claiming one firewall or air gap solves OT security.

Should I memorize vendor menu paths for a SCADA interview?

Only after understanding the system model. Menu paths change with versions and products. For a version-specific job, rehearse the exact installed release; otherwise explain the evidence you need and where the platform exposes it.

Can a browser simulator prove SCADA production readiness?

No. It can train request/command/feedback, diagnosis and interview reasoning. Production readiness requires the real platform/version, architecture, drivers, security, performance, availability, backups, alarms, history, operator testing, field interfaces and approved commissioning evidence.

Primary sources and current product evidence

• NIST, SP 800-82 Rev. 3: Guide to Operational Technology Security. Current final OT architecture, threat, control and SCADA/PLC context used here; review NIST's listed planning notes and future revisions.
• ISA, ISA-101 Series of Standards. Official HMI philosophy, design, implementation, operation and lifecycle overview.
• ISA, ISA-18 Series of Standards. Official alarm-management lifecycle, rationalization, prioritization and performance context.
• OPC Foundation, OPC UA Part 8: Data Access. Current status, data-access and timestamp specification family; verify the implemented profile and release.
• OPC Foundation, OPC UA Part 9: Alarms & Conditions. Current condition, acknowledgement, active, suppression and shelving model.
• Inductive Automation, Ignition 8.3 Tags and Tag Diagnostics. Current official tag, quality, timestamp and diagnostic behavior.
• Inductive Automation, Ignition 8.3 Alarming. Current active/cleared and acknowledged/unacknowledged event-state documentation.
• Inductive Automation, Ignition 8.3 Tag History. Current timestamp, quality, value, sampling and history configuration context.
• Inductive Automation, Ignition 8.3 redundancy setup and database considerations. Product-specific failover and dependency boundaries.
• Rockwell Automation, FactoryTalk View Site Edition User's Guide and current HMI documentation index. Current network/distributed, security, server, archive and redundancy evidence; verify installed version in PCDC.
• Rockwell Automation, FactoryTalk View SE HMI server redundancy. Product-specific role, synchronization and client continuity behavior.
• CISA, ICS Recommended Practices. Official defense-in-depth, remote-access, patch and incident-response resource index.
• Modbus Organization, Modbus Application Protocol Specification. Primary function, data-model and exception reference; transport/security and application meaning remain separate.
• Eclipse Foundation, Sparkplug Specification. Primary MQTT topic/payload/session-state convention where Sparkplug is selected and supported.
• ISA, ISA/IEC 62443 Series of Standards. Official industrial-automation/control-system security program, risk, system and component lifecycle context; purchased/adopted parts and project requirements govern detailed application.

Product documentation illustrates how a principle is implemented; it does not make that product's tag, alarm or redundancy semantics universal. Cite the exact installed version during an interview or design review.

Final preparation checklist

• I can draw the field-to-client and historian paths from memory.
• I separate request, accepted command, output, feedback and process result.
• I read value, quality, source/server time and age together.
• I can complete the downloadable tag contract without hiding assumptions.
• I distinguish alarm, event, status, acknowledgement, reset, suppression and shelving.
• I can explain historian sampling, deadband, quality, time and outage recovery.
• I diagnose communications and data errors by the first failed layer.
• I define and measure RTO/RPO instead of promising zero loss.
• I address segmentation, identity, remote access, backup and patching with OT constraints.
• I can perform one practical task and grade it from recorded evidence.
• I know the employer's platform, major version and role expectations.
• I state safety, cybersecurity, authorization and simulator limits explicitly.
• My portfolio is redacted, reproducible and tied to requirements and tests.

The candidate who says “I would check communications” has named a category. The candidate who compares source value/quality/time at the PLC, driver, server tag and client; identifies the first mismatch; predicts the next test; preserves audit and safety boundaries; and proves restoration has demonstrated SCADA engineering.