Security, Privacy, Ethics and Data Governance

Introduction

Big data engineering is not only the construction of scalable pipelines, data lakes, warehouses, and analytical services. It is also the controlled management of information that may identify people, reveal sensitive behaviour, influence decisions, or create legal and social risks. A technically efficient platform can still be unacceptable if it exposes personal data, permits unauthorised inference, retains information indefinitely, or produces discriminatory outcomes.

Security, privacy, ethics, and governance are related but distinct. Security protects data and systems against unauthorised actions. Privacy concerns appropriate collection, use, disclosure, and inference about individuals. Ethics examines whether data practices are fair, justifiable, and socially responsible. Data governance establishes decision rights, policies, accountability, quality controls, and evidence of compliance.

For postgraduate practitioners, these subjects must be treated as architectural and organisational concerns rather than as final-stage compliance checks. Decisions about schemas, identifiers, partitioning, replication, logging, machine-learning features, cloud services, and retention affect risk from the moment data is collected.

Learning Objectives

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

1. Distinguish security, privacy, ethics, and data governance.
2. Design identity and access management for distributed data platforms.
3. Select suitable encryption, masking, tokenisation, and pseudonymisation controls.
4. Design auditing, retention, deletion, and incident-response mechanisms.
5. Apply privacy-engineering principles and reason about re-identification risk.
6. Establish cataloguing, stewardship, ownership, lineage, and regulatory controls.
7. Evaluate bias, surveillance, consent, and responsible use of data and AI.
8. Critically assess governance trade-offs in a realistic big-data environment.

1. A Unified Conceptual Foundation

1.1 Security, privacy, ethics, and governance

Security is commonly analysed through confidentiality, integrity, and availability. Confidentiality limits disclosure to authorised parties; integrity protects correctness and prevents unauthorised alteration; availability ensures that authorised users can access services when needed. Big-data systems add concerns such as provenance, isolation between tenants, inference attacks, supply-chain security, and resilience across replicated infrastructure.

Privacy is not equivalent to secrecy. A person may consent to a health service using information for treatment while objecting to its use for advertising. Privacy therefore includes purpose, context, choice, proportionality, transparency, control, and limits on secondary use. Even data with names removed may remain personal if combinations of attributes can identify individuals.

Ethics asks whether a practice is morally defensible, including whether benefits and burdens are fairly distributed. A legal practice can still be exploitative, manipulative, or discriminatory. Governance translates principles into repeatable organisational arrangements: who may decide, who owns a data product, which rules apply, how controls are tested, and what evidence is retained.

1.2 Risk as a design concept

A useful qualitative model treats risk as a combination of threat, vulnerability, likelihood, and impact. A more formal expected-loss model is:

where p_i is the probability of adverse event i, I_i is its impact, and the sum covers identified events. This is not a precise prediction unless probabilities and impacts are defensible. In practice, organisations often use ordinal scales such as low, medium, and high. Risk assessment should identify affected data subjects, attack paths, operational consequences, legal exposure, and reversibility of harm.

A control is appropriate only when it addresses a real risk without creating disproportionate operational or social costs. For example, encrypting a public dataset may provide little benefit, while failing to protect an unencrypted backup of identity records may be severe.

2. Identity and Access Management

2.1 Identity lifecycle

Identity and access management (IAM) governs digital identities, authentication, authorisation, and accountability. A mature lifecycle includes identity proofing, provisioning, role changes, periodic review, suspension, and removal. Dormant accounts, shared administrator credentials, unmanaged service accounts, and excessive privileges are common sources of compromise.

Authentication establishes who or what is requesting access. Passwords should be supplemented or replaced by phishing-resistant multi-factor authentication, such as hardware-backed credentials. Authorisation determines what an authenticated subject may do. Accountability requires that actions can be associated with a responsible identity without exposing unnecessary personal information.

2.2 Authorisation models

Role-based access control (RBAC) grants permissions through job or system roles. It is understandable and effective where responsibilities are stable, but role proliferation can become difficult to manage. Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and context. A policy might permit a clinician to read records for patients assigned to that clinician, during an active care relationship, from an approved environment.

The principle of least privilege gives each identity only the permissions needed for an approved task. Separation of duties prevents one person from completing incompatible stages, such as requesting and approving a sensitive export. Just-in-time access grants elevated privileges for a limited period and records the justification. Deny-by-default is safer than assuming that unlisted access is permitted.

Data platforms should implement IAM at several layers: cloud account, network, storage, database, table, column, row, query, notebook, API, and administrative interface. Coarse infrastructure controls alone cannot protect sensitive columns from an otherwise authorised analyst.

2.3 Service identities and policy enforcement

Distributed systems rely heavily on service accounts, workload identities, connectors, and orchestration agents. These identities should be unique, non-interactive where possible, short-lived, and restricted to specific resources. Secrets should be stored in a managed secrets service rather than source code or configuration files.

Policy enforcement points should operate close to the data. A policy decision point evaluates the request, while a policy enforcement point permits, denies, filters, or masks the result. Policies should be tested as code, version-controlled, reviewed, and monitored for unexpected changes.

3. Cryptographic and Data-Protection Controls

3.1 Encryption

Encryption transforms plaintext into ciphertext using a key. At rest, it protects files, databases, snapshots, and backups when storage media or infrastructure is accessed improperly. In transit, it protects network communication, typically using authenticated protocols such as TLS. In use, data is generally exposed to software during processing, although trusted execution environments and advanced cryptographic techniques can reduce exposure in specialised cases.

Encryption is effective only when key management is sound. Keys require generation, storage, rotation, access control, backup, revocation, destruction, and documented ownership. Key separation is important: a database administrator should not automatically control the keys needed to decrypt all regulated data. Envelope encryption commonly uses a data-encryption key to encrypt data and a separately managed key-encryption key to protect that data key.

Encryption does not prevent an authorised but malicious query from retrieving sensitive information. It must therefore be combined with IAM, monitoring, minimisation, and output controls.

3.2 Hashing, tokenisation, masking, and pseudonymisation

Hashing is a one-way transformation useful for integrity checks and, with suitable design, password verification. Unsalted hashes of predictable identifiers are vulnerable to dictionary and enumeration attacks. A keyed hash, such as a message authentication code, is appropriate when only trusted parties should validate or generate values.

Tokenisation replaces a value with a token and stores the mapping separately. It is useful for payment or customer identifiers when applications need stable references without routinely seeing the original value. Pseudonymisation replaces direct identifiers while retaining the possibility of re-linking through separately protected information. Pseudonymised data remains potentially personal data because re-identification may be possible.

Masking changes what a user sees, such as displaying only the last four digits of an account number. Static masking creates a protected copy; dynamic masking changes presentation at query time. Masking is a presentation control, not necessarily protection against privileged extraction or inference.

Anonymisation aims to make identification no longer reasonably likely in the relevant context. It is difficult to guarantee because auxiliary datasets, repeated releases, rare attributes, and high-dimensional data can enable re-identification. Claims of anonymity must therefore specify the threat model, available auxiliary information, release context, and residual risk.

4. Privacy Engineering

Privacy engineering embeds privacy into system requirements, architecture, implementation, testing, and operation. Important principles include:

• Data minimisation: collect and retain only what is necessary for a specified purpose.
• Purpose limitation: do not silently reuse data for incompatible purposes.
• Privacy by design and default: make protective settings the normal configuration.
• Transparency: explain collection, processing, sharing, and automated decisions in understandable language.
• User control: provide meaningful access, correction, objection, portability, or deletion mechanisms where applicable.
• Security: protect information against unauthorised access and loss.
• Accountability: document decisions and demonstrate compliance.

4.1 Privacy threat modelling

A privacy threat model should examine more than attackers. It should consider curious insiders, powerful data users, third-party recipients, unexpected inferences, and harms caused by legitimate processing. A practical process is:

1. Identify data subjects, data flows, purposes, and recipients.
2. Classify direct identifiers, quasi-identifiers, sensitive attributes, and derived features.
3. Identify collection, linkage, inference, surveillance, exclusion, and misuse threats.
4. Estimate likelihood and impact.
5. Select controls and define residual risk.
6. Test controls and reassess when purpose, data, or technology changes.

4.2 Differential privacy

Differential privacy provides a formal way to limit how much the output of an analysis depends on any one individual. For neighbouring datasets D and D', differing in one person’s record, a random mechanism M satisfies ε-differential privacy if:

for every possible output set S. Here ε is the privacy-loss parameter; smaller values generally provide stronger privacy, although utility depends on the query, dataset, mechanism, and composition. The probability is over the mechanism’s randomness. Differential privacy does not make data universally safe: poor parameter choices, repeated releases, sensitive outputs, or governance failures can still cause harm.

For a count query with global sensitivity 1, a Laplace mechanism may add noise drawn from a Laplace distribution with scale 1/ε, under the standard assumptions of the mechanism. The noise has the same units as the count. The example illustrates a trade-off: stronger privacy requires more noise and may reduce analytical accuracy. Privacy budgets must be tracked across multiple releases because privacy loss can accumulate.

5. Auditing, Retention, and Incident Response

5.1 Auditing and lineage

An audit record should normally contain the initiating identity, time, action, resource, decision, relevant policy version, source or destination, and outcome. Logs must be protected against tampering, access-controlled, time-synchronised, and retained according to documented requirements. Logging every data value can itself create a privacy risk; often it is preferable to record metadata, query fingerprints, and controlled samples rather than full sensitive results.

Data lineage records where data originated, how it was transformed, which rules were applied, and where it was delivered. Technical lineage supports debugging and reproducibility; business lineage explains meaning and accountability. Together, lineage and audit evidence help answer: What was used? Who changed it? Which model or report depended on it? Which people or systems received it?

5.2 Retention and deletion

Retention must balance legal obligations, operational needs, analytical value, storage cost, and privacy risk. A defensible retention schedule specifies data class, purpose, owner, retention trigger, retention period, archive conditions, deletion method, and exception process. “Keep everything indefinitely” is rarely a sound governance policy.

Deletion in distributed systems is difficult because copies may exist in object storage, caches, indexes, replicas, backups, notebooks, and downstream exports. A deletion workflow should identify all repositories, propagate deletion or suppression markers, address immutable backups through expiry controls, and verify completion. Legal holds may suspend ordinary deletion, but they should be documented and narrowly scoped.

5.3 Incident response

An incident programme should define preparation, detection, triage, containment, eradication, recovery, notification, and lessons learned. Big-data incidents may involve credential compromise, malicious queries, poisoned data, exposed buckets, model inversion, ransomware, or inappropriate internal use. Evidence preservation and communication responsibilities should be established before an incident occurs.

6. Data Governance as an Operating Model

Data governance is the exercise of authority and control over data assets. It is not merely a committee or policy document. Effective governance connects strategy, people, processes, architecture, controls, and measurable outcomes.

6.1 Roles and decision rights

The data owner is accountable for the business purpose, risk acceptance, access rules, and appropriate use of a data domain. The data steward manages definitions, quality rules, metadata, issue resolution, and day-to-day policy implementation. The data custodian operates technical storage and protection controls. The privacy officer or equivalent advises on privacy obligations and risk. The security function designs and monitors protective controls. A data subject remains the person to whom personal data relates; this is different from organisational ownership.

RACI matrices can clarify who is Responsible, Accountable, Consulted, and Informed for activities such as approving access, defining quality thresholds, responding to rights requests, and authorising secondary use.

6.2 Catalogues, metadata, and quality

A data catalogue should provide searchable technical, business, operational, and governance metadata. Useful fields include name, description, owner, steward, classification, sensitivity, source, lineage, schema, update frequency, quality indicators, permitted purposes, retention rule, legal basis where relevant, and access procedure.

Data quality should be measured against purpose. Common dimensions include accuracy, completeness, consistency, timeliness, validity, uniqueness, and conformity. A completeness rate for a field can be expressed as:

where n_non-null is the number of records with an acceptable non-null value and n_total is the number of records assessed. The metric is meaningful only when the denominator and acceptable-value rule are specified; a complete field can still be inaccurate or biased.

Data contracts make expectations explicit between producers and consumers. They may define schema, semantic meaning, quality thresholds, ownership, compatibility rules, privacy classification, and change notification. Contracts reduce silent breakage in complex pipelines.

6.3 Regulatory controls

Regulatory obligations vary by jurisdiction and sector. Examples include privacy and data-protection laws, financial-record rules, health-information requirements, employment law, consumer-protection rules, cybersecurity obligations, and cross-border transfer restrictions. Compliance analysis should identify the applicable jurisdiction, data subject, processing purpose, legal basis or authorisation, rights, safeguards, transfer mechanism, breach obligations, and accountable organisation.

Frameworks such as the NIST Privacy Framework, NIST Cybersecurity Framework, ISO/IEC 27001, ISO/IEC 27701, and sector-specific standards can structure programmes, but no framework automatically guarantees compliance. Organisations must map framework controls to actual processes and evidence.

7. Ethics, Bias, Surveillance, and Responsible AI

7.1 Consent and legitimate expectations

Consent should be informed, specific, freely given, and withdrawable where the governing regime requires those properties. A long privacy notice or forced consent is not necessarily meaningful consent. Consent is also not a universal solution: a power imbalance, inability to refuse, or unexpected secondary use may make the practice ethically problematic even when a formal agreement exists.

Engineers should ask whether the data subject reasonably expects the use, whether the use is proportionate, whether alternatives exist, and whether the benefit justifies the intrusion. Public availability does not automatically imply ethical permission to aggregate, profile, or commercialise data.

7.2 Bias and fairness

Bias can enter through historical decisions, under-representation, measurement error, proxy variables, labels, sampling, missingness, model objectives, or deployment context. A system may be accurate overall while systematically harming a minority group. Fairness criteria can conflict; for example, calibration and equal error rates generally cannot both hold across groups when base rates differ, except under special conditions. Therefore, fairness is a socio-technical judgement, not a single metric.

Governance should require representative evaluation, subgroup performance analysis, documented limitations, human review for high-impact decisions, appeal routes, monitoring for drift, and an accountable owner. Removing protected attributes from a model does not remove bias because correlated attributes may act as proxies.

7.3 Surveillance and power

Large-scale location, browsing, workplace, biometric, and behavioural datasets can enable continuous monitoring. Surveillance risks include chilling effects, function creep, discriminatory targeting, and inability to contest classifications. Proportionality, necessity, transparency, restricted access, short retention, independent oversight, and meaningful redress are important safeguards.

7.4 Responsible use of AI

AI systems require governance across the full lifecycle: data acquisition, labelling, feature engineering, training, validation, deployment, monitoring, retirement, and incident response. Documentation should describe intended use, prohibited use, data provenance, limitations, evaluation populations, known failure modes, human oversight, and decision authority. Generative AI introduces additional concerns involving confidential prompts, memorisation, intellectual property, fabricated outputs, and uncontrolled downstream use.

8. Illustrative Case: A National Health Analytics Platform

Background

The fictional National Health Analytics Platform (NHAP) combines hospital encounters, laboratory results, pharmacy records, and regional demographic data to support public-health planning and approved research. Data arrives from hundreds of institutions and is processed in a cloud lakehouse.

Problem

An initial design stores names and national identifiers in a shared analytical zone. Analysts use broad group permissions, service accounts do not expire, and copies are exported to notebooks. The organisation has no complete catalogue, retention schedule, or reliable mechanism to honour deletion and correction requests. A proposed research project also intends to infer disease risk from mobility data collected for a different purpose.

Analysis

The risks include excessive privilege, re-identification through linkage, unclear purpose compatibility, uncontrolled exports, weak service-account governance, incomplete lineage, and secondary use without meaningful safeguards. The mobility data creates a surveillance and consent concern even if direct identifiers are removed. Health and demographic attributes may produce serious harms if disclosed or used in discriminatory decisions.

Approach and solution

NHAP establishes domain owners and stewards, classifies data, and records purposes and legal authorisations in a catalogue. Direct identifiers are held in a separately governed identity vault. Analytical systems use project-specific tokens, while the re-identification key is protected by an independent function. Encryption is applied in transit and at rest, with centrally managed keys and audited access.

Access is redesigned using least privilege, ABAC rules, time-limited research grants, multi-factor authentication, and separate roles for data scientists, administrators, and approvers. Sensitive columns are masked or excluded by default. Every export requires a documented purpose, owner approval, automated scanning for identifiers, and an expiry date.

The research team must demonstrate necessity and proportionality for mobility data. A privacy impact assessment evaluates linkage and surveillance risks. Where population statistics are sufficient, the project uses aggregated outputs with a managed differential-privacy budget rather than individual-level records. Model evaluation includes subgroup analysis, human review, and a prohibition on using outputs for unapproved eligibility or insurance decisions.

A retention schedule deletes temporary extracts after thirty days, removes project data after its authorised period, and applies controlled expiry to backups. Lineage and audit logs are retained longer where required for accountability. Incident exercises test credential compromise, unauthorised export, and erroneous deletion.

Outcome

NHAP improves discoverability and analytical reliability while reducing unnecessary exposure. Research access becomes slower at the approval stage but faster overall because definitions, quality rules, and standard secure environments are available. The platform cannot eliminate all risk, but it makes risk visible, accountable, and governable.

Learning points

1. Separation of identity data from analytical data reduces routine exposure.
2. Governance must cover service accounts, notebooks, exports, and backups, not only databases.
3. De-identification is contextual and does not automatically resolve privacy concerns.
4. Ethical review is required when data enables surveillance or high-impact inference.
5. Privacy, security, quality, and usability must be designed together.

9. Implementation Blueprint and Critical Limitations

A practical implementation can proceed through the following sequence:

1. Inventory data assets, flows, systems, processors, and purposes.
2. Classify sensitivity and identify applicable obligations.
3. Assign owners, stewards, custodians, and decision rights.
4. Establish IAM, key management, network boundaries, and secure defaults.
5. Implement catalogue, lineage, quality monitoring, and data contracts.
6. Define retention, deletion, legal-hold, and rights-request workflows.
7. Conduct threat modelling and privacy impact assessments for high-risk uses.
8. Establish audit, incident response, independent review, and evidence collection.
9. Measure control effectiveness and revise policies as systems and threats change.

Governance programmes face limitations. Excessive controls can obstruct legitimate work and encourage shadow systems. Automated classification can mislabel data. Privacy techniques may reduce utility or fail against unexpected auxiliary data. Compliance checklists may create false assurance. Fairness metrics may conflict, and technical teams may lack authority to challenge commercial objectives. Governance therefore requires proportionality, independent challenge, user education, senior accountability, and continuous review.

Contemporary developments include confidential computing, privacy-enhancing computation, federated learning, synthetic data, data clean rooms, automated policy enforcement, and machine-readable consent and purpose metadata. These technologies are valuable but not magical. Synthetic data can preserve bias, federated systems can leak information through updates, and clean rooms still require governance over permitted queries and outputs.

Chapter Summary

Secure big-data engineering integrates confidentiality, integrity, availability, privacy, ethical responsibility, and governance. IAM should manage the complete identity lifecycle and enforce least privilege, separation of duties, contextual authorisation, and accountable service identities. Encryption protects data in transit and at rest, but key management and complementary controls determine its effectiveness. Tokenisation, masking, pseudonymisation, and anonymisation have different properties and should not be treated as interchangeable.

Privacy engineering applies minimisation, purpose limitation, transparency, user control, threat modelling, and privacy-preserving computation throughout the data lifecycle. Differential privacy offers a formal privacy guarantee under explicit assumptions, while privacy impact assessments address broader contextual risks. Auditing, lineage, retention, deletion, and incident response make controls operational and demonstrable.

Data governance assigns ownership and stewardship, maintains catalogues and contracts, measures quality, and maps obligations to evidence. Ethical practice requires scrutiny of consent, secondary use, bias, surveillance, power, and AI impacts. The central professional lesson is that secure and responsible data use is a socio-technical design problem requiring continuous accountability rather than a one-time technical implementation.

Key Terms

Access control: Rules determining which identities may perform which actions on resources.

Anonymisation: Processing intended to make identification of individuals no longer reasonably likely in a defined context.

Attribute-based access control: Authorisation based on subject, resource, action, and contextual attributes.

Data catalogue: A searchable inventory containing technical, business, quality, lineage, and governance metadata.

Data owner: Person or function accountable for a data domain’s purpose, risks, and access decisions.

Data steward: Practitioner responsible for definitions, quality, metadata, and operational governance.

Data lineage: A record of data origin, transformations, dependencies, and destinations.

Data minimisation: Limiting collection and retention to what is necessary for an explicit purpose.

Differential privacy: A formal framework limiting the effect of one individual’s data on an analytical output.

Encryption: Cryptographic transformation that protects data from unauthorised reading.

Identity and access management: Governance of identities, authentication, authorisation, and accountability.

Least privilege: Granting only the permissions required for an authorised task.

Masking: Restricting the values visible to a user or system, often by hiding selected characters.

Pseudonymisation: Replacing identifiers while retaining a separately controlled possibility of re-linking.

Purpose limitation: Restricting data use to specified and compatible purposes.

Retention schedule: Approved rules specifying how long data is kept and how it is disposed of.

Tokenisation: Replacing sensitive values with tokens whose mapping is separately protected.

Privacy impact assessment: Structured assessment of privacy risks and proposed safeguards.

Review Questions

Short Answer Questions

1. Distinguish security, privacy, ethics, and data governance.
2. What is the principle of least privilege, and why is it important in a data lake?
3. Explain the difference between tokenisation and masking.
4. Why can pseudonymised data remain personal data?
5. Name four dimensions of data quality.

Long Answer Questions

1. Explain how IAM, encryption, auditing, and retention controls should work together in a distributed data platform.
2. Discuss the assumptions, benefits, and limitations of differential privacy.
3. Design a governance operating model involving owners, stewards, custodians, privacy officers, and security teams.
4. Analyse how secondary use and consent concerns arise when mobility data is combined with health data.
5. Evaluate the ethical and technical challenges of fairness in high-impact AI systems.

Analytical / Application Questions

1. A company gives all analysts access to a customer table containing names, addresses, purchase history, and inferred income. Propose a redesigned architecture and access model, explaining each control.
2. A public dashboard releases daily counts for small geographic areas. Explain how repeated releases and rare categories could create privacy risk, and recommend safeguards.
3. A deletion request arrives after data has been copied into a lake, warehouse, cache, model-training dataset, notebook, and backup. Design a verifiable deletion and exception-handling workflow.

Multiple Choice Questions with Answers

Question 1

Which control principle grants an identity only the permissions needed for an authorised task?

A. Least privilege

B. Data replication

C. Purpose expansion

D. Open authorisation

Correct Answer: A. Least privilege

Question 2

Which statement best distinguishes tokenisation from masking?

A. Tokenisation replaces a value with a separately mapped token, while masking changes what is displayed

B. Tokenisation always destroys data, while masking encrypts database files

C. Tokenisation is used only for public data, while masking is used only for passwords

D. Tokenisation removes all re-identification risk, while masking guarantees anonymity

Correct Answer: A. Tokenisation replaces a value with a separately mapped token, while masking changes what is displayed

Question 3

In the differential-privacy expression Pr[M(D) ∈ S] ≤ e^ε × Pr[M(D') ∈ S], what does ε represent?

A. The number of records in the dataset

B. A privacy-loss parameter

C. The database encryption key

D. The percentage of missing values

Correct Answer: B. A privacy-loss parameter

Question 4

Who is typically accountable for a data domain’s business purpose, access rules, and risk acceptance?

A. Data owner

B. Network router

C. External auditor only

D. End-user device

Correct Answer: A. Data owner

Question 5

Why is deleting data from a distributed platform difficult?

A. Data may exist in replicas, caches, backups, indexes, notebooks, and exports

B. Encryption prevents all deletion operations

C. Catalogues automatically duplicate every record forever

D. Access control makes storage locations unknowable

Correct Answer: A. Data may exist in replicas, caches, backups, indexes, notebooks, and exports

Question 6

Which practice most directly supports traceability of transformations from source to analytical output?

A. Data lineage

B. Dynamic masking

C. Password rotation

D. Network segmentation alone

Correct Answer: A. Data lineage

Question 7

A field has 9,500 acceptable non-null values among 10,000 assessed records. Using C = n_non-null ÷ n_total × 100%, what is its completeness rate?

A. 5%

B. 9.5%

C. 90%

D. 95%

Correct Answer: D. 95%

Question 8

Which statement about removing protected attributes from a model is most accurate?

A. It guarantees fairness

B. It may not remove bias because correlated proxy variables can remain

C. It prevents all surveillance

D. It eliminates the need for subgroup evaluation

Correct Answer: B. It may not remove bias because correlated proxy variables can remain

Question 9

What is the primary purpose of a privacy impact assessment?

A. To estimate cloud storage cost only

B. To identify privacy risks and evaluate proposed safeguards

C. To replace all security testing

D. To guarantee that a project is ethically acceptable

Correct Answer: B. To identify privacy risks and evaluate proposed safeguards

Question 10

Which service-account practice is generally strongest?

A. Use one shared permanent administrator account

B. Embed credentials in source code

C. Use unique, restricted, preferably short-lived workload identities

D. Disable logging to protect privacy

Correct Answer: C. Use unique, restricted, preferably short-lived workload identities