Cloud, Distributed and Emerging Database Security

Introduction

Database security has expanded beyond the protection of a server in a controlled data centre. Contemporary organisations use managed cloud databases, data warehouses, data lakes, NoSQL platforms, distributed ledgers, containers and services distributed across several cloud providers. These technologies improve scalability, availability and analytical capability, but they also introduce new security boundaries, identities, interfaces, dependencies and legal obligations.

A secure database environment must therefore be evaluated as a socio-technical system. Security depends not only on encryption and access controls, but also on cloud contracts, service configuration, application programming interfaces (APIs), software supply chains, tenant isolation, monitoring, incident response and data governance. The central question is not simply whether a database product is secure. It is whether the complete architecture, operational process and responsibility allocation protect the confidentiality, integrity, availability and lawful use of information.

This chapter examines the security of cloud and distributed database environments at diploma level. It focuses on practical evaluation: identifying assets and trust boundaries, understanding shared responsibility, selecting controls, testing assumptions and responding to failure.

Learning Objectives

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

1. Explain the security characteristics of managed databases, cloud data warehouses, NoSQL systems, distributed ledgers and containerised database services.
2. Apply the shared-responsibility model to database security decisions.
3. Evaluate tenant isolation, identity, API security, encryption, resilience and monitoring controls.
4. Analyse data sovereignty, privacy, compliance and cross-border processing risks.
5. Identify supply-chain risks in cloud-native database architectures.
6. Compare security implications in single-cloud, hybrid-cloud and multi-cloud designs.
7. Recommend proportionate controls for a realistic organisational scenario.

1. The Changing Database Security Boundary

In a traditional environment, an organisation often owned the hardware, operating system, database engine, network and physical facility. Responsibility was concentrated within one administrative domain. In cloud and distributed environments, responsibility is divided among cloud providers, database vendors, managed-service operators, application teams, platform engineers, contractors and data owners.

The security boundary has consequently become layered:

• Physical layer: data centres, hardware, power, cooling and physical access.
• Infrastructure layer: virtual machines, storage, networks and hypervisors.
• Platform layer: database engines, managed services, orchestration platforms and identity services.
• Application layer: code, APIs, queries, stored procedures and business logic.
• Data layer: classification, retention, quality, access and lawful processing.
• Governance layer: policies, contracts, audit evidence, risk acceptance and incident response.

A weakness at any layer can undermine the others. For example, a well-encrypted database may still be exposed through a public API with broken authorisation. Conversely, a correctly configured database may be placed at risk by a compromised container image or stolen administrative token.

2. Shared Responsibility in Managed Database Services

A managed database service typically provides the database engine, patching, backups, replication and infrastructure operations. This reduces operational effort but does not transfer every security obligation to the provider.

The exact division differs by provider and service type, so the service agreement and security documentation must be examined rather than assumed. A useful general model is:

The customer remains accountable for deciding what data may be stored, who may access it, how access is authorised, which regions may process it and whether the service satisfies organisational and regulatory requirements.

A practical responsibility assessment

For each database service, an organisation should create a responsibility matrix containing:

1. The asset or control, such as encryption keys, backups or audit logs.
2. The party responsible for implementation.
3. The party responsible for verification.
4. Evidence required, such as configuration exports, test results or provider attestations.
5. A review frequency and escalation route.

This prevents the common failure known as “responsibility ambiguity”, in which the provider assumes the customer configured a control and the customer assumes the provider supplied it automatically.

3. Managed Relational Databases and Cloud Data Warehouses

Managed relational databases provide familiar tables, transactions, constraints and SQL interfaces. Their principal security concerns include excessive privileges, insecure network exposure, weak credentials, unencrypted backups, vulnerable extensions and inadequate logging.

Important controls include:

• private network placement where feasible;
• security groups, firewall rules and service endpoints that restrict source and destination traffic;
• federated identity and short-lived credentials rather than shared passwords;
• separate administrative, operational, development and reporting roles;
• encryption in transit and at rest;
• protected and tested backups;
• database activity monitoring and immutable audit storage;
• patch and version management;
• parameterised queries and stored procedure review;
• masking or tokenisation of sensitive fields in non-production environments.

Cloud data warehouses and lakehouses concentrate large volumes of data and support analytical workloads. Their risk profile differs from an operational database. A single overprivileged analyst, exposed storage bucket or poorly governed data-sharing feature can reveal information from many source systems. Security must therefore address data ingestion, transformation, catalogue metadata, derived datasets and exports, not merely the warehouse endpoint.

Warehouse-specific risks

Overbroad analytical access: Analysts may receive access to complete tables when aggregated or column-restricted views would meet their needs.

Data-copy proliferation: Extracts, temporary tables, notebooks and local downloads create uncontrolled duplicates.

Metadata leakage: Table names, query histories and column descriptions may disclose confidential projects or personal information.

Cross-account sharing: Data-sharing features can bypass traditional file-transfer controls if recipients and revocation processes are not carefully governed.

Inference risk: Even when direct identifiers are removed, combinations of rare attributes may identify individuals. Aggregation and suppression rules should be evaluated against realistic background knowledge.

A robust warehouse architecture applies least privilege to datasets, schemas, columns, rows and operations. It also records lineage: where data originated, how it was transformed and where it was delivered.

4. NoSQL Database Security

NoSQL systems include key-value stores, document databases, wide-column systems and graph databases. They are not inherently insecure, but their security mechanisms and failure modes differ from those of relational systems.

Key-value and document databases

These systems often expose APIs rather than traditional SQL. Security issues include predictable object identifiers, unrestricted document fields, weak tenant filters and permissive access policies. An application may correctly authenticate a user but fail to verify that the requested document belongs to that user. This is an object-level authorisation failure.

Document flexibility can also create validation problems. If an application accepts arbitrary fields, an attacker may insert fields that alter application behaviour, bypass workflow controls or cause excessive resource consumption. Schema validation, input allow-lists and explicit mapping between external requests and internal records are therefore important.

Wide-column and graph databases

Wide-column systems can support high-volume workloads but may expose broad partition access if key design and permissions are poorly aligned. Graph databases contain relationships that can be more sensitive than individual records. A graph query may reveal social, financial, medical or organisational connections even when node attributes are partially masked.

NoSQL control principles

• Enable authentication and authorisation explicitly; never rely on a default deployment.
• Restrict administrative interfaces to trusted networks.
• Define tenant boundaries in both policy and application logic.
• Validate document structure and maximum size.
• Control query complexity and rate to reduce denial-of-service risk.
• Encrypt backups, replicas and snapshots.
• Test authorisation using records belonging to different users and tenants.
• Monitor unusual query patterns, bulk reads and administrative changes.

NoSQL security is strongest when the data model, authorisation model and application workflow are designed together.

5. Distributed Ledgers and Blockchain-Based Databases

A distributed ledger maintains replicated records across multiple participating nodes. Consensus mechanisms help nodes agree on the order or validity of transactions, while cryptographic signatures provide evidence of transaction origin.

Distributed ledgers can improve tamper evidence and shared auditability, but they do not automatically provide confidentiality, correctness or legal compliance. A ledger may preserve inaccurate data permanently. A private key may be valid cryptographically while being held by an unauthorised person. Smart contracts may execute exactly as programmed even when the programme contains a logic error.

Security properties and limitations

Sensitive personal data should generally not be placed directly on an immutable shared ledger unless legal, architectural and governance analysis supports that decision. A common design stores minimal references or cryptographic commitments on the ledger and retains amendable sensitive data in a controlled off-chain system. This design reduces exposure but does not eliminate the need to protect the off-chain data or assess whether a reference itself is personal information.

Key-management governance is essential. Organisations should define signing authority, approval thresholds, key rotation, revocation, recovery and separation of duties. Consensus participation should also be monitored for collusion, denial of service and malicious or compromised nodes.

6. Containers and Cloud-Native Database Platforms

Containers package applications and dependencies into deployable images. They improve portability but are not equivalent to virtual machines and should not be treated as a complete security boundary. A container shares the host kernel, and a compromised workload may exploit kernel or runtime weaknesses.

Database workloads in containers introduce further concerns:

• loss of data when ephemeral containers are recreated;
• insecure persistent-volume permissions;
• secrets embedded in images or environment variables;
• vulnerable base images and database extensions;
• excessive container or orchestration privileges;
• exposed management dashboards;
• unverified images from public registries;
• weak network policies between application and database pods.

A secure container supply chain uses trusted registries, signed images, vulnerability scanning, minimal base images, pinned versions, non-root execution, read-only filesystems where practical, restricted capabilities and admission policies. Secrets should be supplied through a managed secrets system and rotated without rebuilding images.

Persistent storage must be encrypted and backed up independently of the container lifecycle. Recovery procedures should be tested by restoring a database into a clean environment, not merely by confirming that backup jobs completed.

7. API Security for Distributed Databases

APIs are often the effective front door to a database. Their security must be evaluated at several levels:

1. Transport: use authenticated and encrypted connections.
2. Authentication: verify the identity of users, services and devices.
3. Authorisation: enforce what the authenticated identity may do to each resource and operation.
4. Input validation: reject malformed, excessive or unexpected data.
5. Output control: return only fields and records required for the operation.
6. Abuse resistance: apply rate limits, quotas, pagination and anomaly detection.
7. Auditability: record security-relevant events without logging secrets or unnecessary personal data.

A valid session does not imply valid access to every record. Authorisation should be checked server-side for every sensitive operation. API gateways can provide useful central controls, but they cannot replace business-level authorisation inside the service.

Common database API weaknesses include injection, broken object-level authorisation, mass assignment, excessive data exposure, unrestricted bulk operations and insecure direct access from clients. Security testing should include negative tests: a user should be unable to read, modify or delete another tenant’s records even when the record identifier is known.

8. Tenant Isolation

Multi-tenant services allow several customers or organisational units to share infrastructure. Isolation may be implemented through separate accounts, projects, databases, schemas, tables, rows, encryption keys or application policies. These approaches provide different levels of separation and operational cost.

Tenant isolation must be tested, not inferred from design diagrams. Tests should attempt cross-tenant reads, updates, exports, backup restoration and administrative actions. Isolation also includes side channels such as query timing, resource exhaustion, logs, metrics and error messages.

No isolation model is absolute. Providers should disclose relevant architectural assumptions, vulnerability-reporting processes and incident-notification commitments. Customers should understand whether encryption keys, administrators, support personnel and backup systems are shared.

9. Data Sovereignty, Privacy and Compliance

Data sovereignty concerns the authority of the jurisdiction in which data is stored, processed or made accessible. Data may be subject to the laws of the storage location, the provider’s location, the customer’s location and locations from which support personnel can access it.

A sovereignty assessment should ask:

• Where are primary data, replicas, snapshots and logs stored?
• Where are encryption keys generated and used?
• Can provider personnel access content, metadata or support copies?
• Are disaster-recovery regions outside the approved jurisdiction?
• Which subprocessors handle the data?
• What happens when a legal request conflicts with the customer’s obligations?
• Can data be securely deleted from active systems, backups and caches?

Compliance is not the same as security. A provider certificate or audit report can provide evidence about controls, but it does not prove that a customer’s configuration is correct or that the processing is lawful for a particular purpose. Data minimisation, purpose limitation, retention control, access rights and breach notification requirements must be addressed through governance and system design.

Useful technical measures include regional deployment restrictions, customer-controlled keys, tokenisation, pseudonymisation, field-level encryption, confidential computing where appropriate, and policies that prevent unauthorised replication. These controls must be assessed for operational impact, recoverability and lawful reversibility.

10. Multi-Cloud and Distributed-Environment Security

Multi-cloud designs may be adopted for resilience, negotiation, regulatory separation or specialised services. They also multiply complexity. Each provider may use different identity models, logging formats, network controls, key services and incident procedures.

Major risks include:

• inconsistent security policies across providers;
• duplicated privileged accounts;
• insecure data movement between environments;
• unclear responsibility during a joint incident;
• configuration drift;
• differing backup and deletion behaviour;
• expanded attack surface through management APIs;
• dependency on a common identity provider or software pipeline.

A practical multi-cloud programme should establish common control objectives rather than assuming identical implementations. For example, the objective may be “all production database access is strongly authenticated, least-privileged, logged and reviewed.” Each provider can then implement the objective using its own technology, while central monitoring verifies the result.

Identity federation, central policy management, infrastructure as code, standard logging schemas and regular cross-cloud recovery exercises reduce inconsistency. However, centralisation also creates concentration risk. A single identity provider, secrets manager or deployment pipeline can become a high-impact point of failure. Critical controls should have tested emergency procedures and, where justified, independent recovery paths.

11. Supply-Chain Risk

A database environment depends on more than the database vendor. It may rely on operating-system packages, container images, drivers, connectors, plugins, infrastructure modules, CI/CD tools, open-source libraries, managed security services and subcontractors.

Supply-chain attacks can introduce malicious code, steal credentials, alter build artefacts or exploit an unpatched component. Security evaluation should therefore include:

• an inventory of direct and transitive dependencies;
• software bills of materials where available;
• signed and verified artefacts;
• reproducible or controlled builds;
• protected source repositories and build runners;
• separation between development and production credentials;
• dependency vulnerability monitoring;
• rapid revocation and rotation of compromised secrets;
• vendor security assessments and breach-notification clauses;
• tested rollback and rebuild processes.

A vulnerability scanner is useful but insufficient. It may miss malicious behaviour, configuration weaknesses or vulnerabilities in proprietary services. Provenance, change control, runtime monitoring and independent testing are complementary controls.

12. Security Monitoring, Resilience and Incident Response

Distributed databases generate events across provider consoles, database logs, API gateways, identity systems, orchestration platforms, operating systems and applications. Logs should be time-synchronised, access-controlled, protected against unauthorised alteration and retained according to investigative and legal requirements.

Monitoring should detect:

• unusual administrative activity;
• privilege changes;
• access from unexpected locations or workloads;
• large exports and abnormal query volume;
• disabled logging or encryption;
• changes to network exposure;
• failed authentication patterns;
• unusual replication or backup behaviour;
• container image and deployment changes.

Resilience is broader than availability. Recovery plans must protect confidentiality and integrity during restoration. Backups should be isolated from production credentials, encrypted, tested and assessed for malware or corruption. Recovery objectives should be agreed with business owners. A recovery time objective defines the maximum acceptable restoration time; a recovery point objective defines the maximum acceptable amount of data loss measured in time. These are business requirements, not merely technical settings.

Incident response plans should identify provider contacts, evidence-preservation procedures, legal notification responsibilities, credential-revocation steps and customer communication channels. Exercises should include provider outages, compromised administrative identities, accidental public exposure, ransomware and corrupted replication.

13. A Structured Evaluation Framework

A diploma-level security assessment can follow this sequence:

Step 1: Identify data and business processes

Classify personal, financial, confidential, regulated and mission-critical data. Document data flows, owners, retention periods and dependencies.

Step 2: Map trust boundaries

Show users, administrators, applications, APIs, providers, networks, regions, replicas, backups and third parties. Mark where authentication, authorisation and encryption occur.

Step 3: Analyse threats

Consider credential theft, misconfiguration, malicious insiders, vulnerable software, tenant escape, API abuse, denial of service, data corruption, supply-chain compromise and legal access demands.

Step 4: Evaluate controls and evidence

Check configuration, access reviews, key-management records, provider attestations, penetration tests, logs, backup restorations and incident exercises.

Step 5: Assess residual risk

Consider likelihood, impact, detectability, recovery capability and legal consequences. Prioritise risks affecting many tenants, large datasets or irreversible operations.

Step 6: Choose treatment

Reduce, transfer, avoid or accept the risk. Document assumptions, owners, deadlines and measures of success.

Step 7: Reassess continuously

Cloud services change rapidly. Review significant architecture, provider, region, software, identity and data-use changes through formal change management.

Applied Case: Illustrative Multi-Cloud Health Analytics Platform

Background

A fictional healthcare organisation, MedData, stores identifiable patient records in a managed relational database. It copies pseudonymised data to a cloud warehouse for research and uses a containerised API to provide authorised access to hospitals. A second cloud provider hosts disaster recovery. Some research partners receive datasets through a data-sharing API.

Problem

An internal review finds that the warehouse contains more identifiers than necessary, the disaster-recovery region has not been legally approved, API tokens remain valid for twelve months, and a container image includes an outdated database driver. Tenant filtering is enforced partly in application code and is not tested automatically.

Analysis

The main risks are excessive data replication, sovereignty non-compliance, stolen-token abuse, supply-chain exploitation and cross-tenant disclosure. The use of pseudonymisation reduces direct exposure but does not remove privacy obligations because re-identification may remain possible. The shared-responsibility analysis shows that the providers operate the services, while MedData controls data selection, API design, identity policy and regional choices.

Approach and solution

MedData adopts the following controls:

• removes direct identifiers from the research warehouse and applies documented re-identification controls;
• moves disaster recovery to an approved region and verifies the location of backups and logs;
• replaces long-lived API tokens with short-lived, scoped credentials;
• introduces service-to-service authentication and explicit object-level authorisation;
• uses automated cross-tenant tests in the deployment pipeline;
• rebuilds the container from a trusted minimal image and pins the driver version;
• signs production images and blocks unsigned images through admission policy;
• separates research, operational and administrative roles;
• sends centralised audit events to protected monitoring storage;
• conducts a restoration exercise and a simulated stolen-token incident.

Outcome

The architecture becomes easier to audit, and the organisation can demonstrate where sensitive data is processed. The changes do not eliminate all risk: provider compromise, insider misuse and re-identification remain possible. However, exposure is reduced, detection improves and recovery responsibilities are clearer.

Learning points

1. Pseudonymisation is a risk-reduction technique, not an automatic exemption from privacy duties.
2. Multi-cloud recovery is useful only when regions, credentials and restoration procedures are governed.
3. API authorisation must be tested at the object and tenant levels.
4. Supply-chain security includes drivers and container images, not only application code.
5. Evidence and exercises are necessary to validate stated controls.

Ethical and Professional Considerations

Security professionals must balance availability, privacy, safety, cost and organisational objectives. A decision to centralise data may improve monitoring but increase the consequences of compromise. A decision to retain detailed logs may support investigations but create additional personal-data obligations. Automated analytics and AI services may infer sensitive characteristics from apparently harmless records; data minimisation and transparency should therefore include derived information.

Professionals should avoid overstating provider certifications, disclose uncertainty, preserve evidence responsibly and report material weaknesses through approved channels. Security controls should not be designed to discriminate against legitimate users or create unjustified surveillance. Decisions should be proportionate, documented and reviewable.

Contemporary Developments

Several developments are shaping database security:

• Confidential computing seeks to protect data while it is being processed using hardware-backed trusted execution environments. Its guarantees depend on hardware, firmware, workload design and attestation procedures.
• Policy-as-code expresses access and configuration requirements in machine-checkable form, improving consistency but requiring careful testing.
• Zero-trust architectures avoid assuming that network location establishes trust and continuously evaluate identity, device, workload and request context.
• Database activity analytics uses behavioural baselines to identify unusual access, although false positives, privacy and explainability must be managed.
• Data clean rooms and privacy-enhancing computation allow limited analysis across organisational boundaries while reducing direct disclosure. They require careful evaluation of inference and governance risks.
• Generative AI assistants for databases can produce queries and administrative suggestions. They must be constrained because generated queries may disclose data, consume excessive resources or implement incorrect business logic. Human review, least privilege, query controls and logging remain necessary.

These technologies are useful tools, not substitutes for sound identity management, secure design, governance and testing.

Best-Practice Checklist

A secure cloud or distributed database programme should:

• classify data before selecting a service;
• document responsibilities and obtain provider evidence;
• use least privilege, strong authentication and short-lived credentials;
• restrict network and API exposure;
• encrypt data, backups and replicas with a managed key lifecycle;
• test tenant isolation and object-level authorisation;
• control regions, subprocessors and cross-border transfers;
• secure containers, dependencies, images and build pipelines;
• centralise and protect audit logs;
• test backup restoration and incident response;
• monitor configuration drift and privileged activity;
• review data copies, exports and derived datasets;
• reassess controls after material service or architecture changes.

Chapter Summary

Cloud, distributed and emerging databases change the location of security responsibility and expand the number of trust boundaries. Managed services reduce infrastructure administration but leave customers responsible for data governance, identity, configuration, access, application security and lawful processing. Warehouses require control of data copies, analytical privileges and lineage. NoSQL systems demand careful object-level authorisation, validation and query control. Distributed ledgers provide tamper evidence and shared consensus but do not guarantee confidentiality, correctness or legal compliance. Containers require secure images, restricted privileges and independent protection of persistent data.

Tenant isolation must be designed and tested across records, backups, logs and side channels. APIs must authenticate, authorise, validate, limit and audit every sensitive operation. Data sovereignty requires knowledge of storage, processing, support access, replicas and keys. Multi-cloud strategies improve resilience in some circumstances but create policy, identity, monitoring and recovery complexity. Supply-chain security requires dependency inventory, trusted artefacts, protected build processes and tested response.

Effective evaluation combines technical controls, provider evidence, governance, legal analysis, monitoring and exercises. The most reliable security posture is continuously assessed rather than assumed from a product name or compliance certificate.

Key Terms

Managed database service: A database platform operated partly by a cloud provider on behalf of a customer.

Shared responsibility model: A framework dividing security duties between provider and customer.

Data warehouse: A system designed to store and analyse integrated data, often at large scale.

NoSQL: A group of non-relational database technologies, including document, key-value, graph and wide-column systems.

Distributed ledger: A replicated record system maintained by multiple participating nodes.

Consensus: A process by which distributed nodes agree on transaction order or validity.

Smart contract: Program code that automatically executes rules or transactions on a ledger platform.

Tenant isolation: Separation preventing one customer or organisational unit from accessing another’s resources.

Object-level authorisation: Checking whether a user may access the specific record or resource requested.

Data sovereignty: The effect of jurisdiction and legal authority over data based on where it is stored or processed.

Pseudonymisation: Replacing identifiers with substitutes while retaining a controlled possibility of linkage.

Container: A packaged process environment sharing the host operating-system kernel.

Software supply chain: The people, code, tools, dependencies and processes used to build and deliver software.

Infrastructure as code: Machine-readable definitions used to provision and manage infrastructure.

Configuration drift: Unplanned divergence between approved configuration and deployed configuration.

Recovery time objective: The maximum acceptable time to restore a service after disruption.

Recovery point objective: The maximum acceptable period of data loss measured backward from disruption.

Confidential computing: Techniques intended to protect data during processing using trusted execution mechanisms.

Data lineage: A record of data origin, transformation, movement and use.

Review Questions

Short Answer Questions

1. What does the shared-responsibility model mean in a managed database service?
2. Why is pseudonymisation not necessarily sufficient to remove privacy obligations?
3. Identify two security risks specific to containerised database deployments.
4. What is tenant isolation, and why must it be tested?
5. Distinguish a recovery time objective from a recovery point objective.

Long Answer Questions

1. Explain how security controls for a cloud data warehouse differ from those for an operational relational database.
2. Discuss the security benefits and limitations of distributed ledgers.
3. Describe a structured method for evaluating a multi-cloud database architecture.
4. Explain how API authentication, authorisation, validation and monitoring work together to protect database services.
5. Analyse the role of supply-chain security in containerised and managed database environments.

Analytical / Application Questions

1. An organisation stores customer records in a shared NoSQL table using a tenant identifier. Propose tests and controls to determine whether tenants are adequately isolated.
2. A cloud provider offers disaster recovery in a cheaper overseas region. Identify the technical, legal and governance questions that should be answered before approval.
3. A stolen service token is used to download a large warehouse dataset. Design an incident-response sequence covering containment, investigation, notification and long-term prevention.

Multiple Choice Questions with Answers

Question 1

Which responsibility normally remains with the customer when using a managed database service?

A. Maintaining the provider’s physical data centre

B. Replacing failed provider hardware

C. Classifying data and assigning appropriate access

D. Patching the provider’s hypervisor

Correct Answer: C. Classifying data and assigning appropriate access

Question 2

Which control most directly prevents a user from retrieving another tenant’s document when the document identifier is known?

A. Object-level authorisation

B. Increasing storage capacity

C. Changing the database colour theme

D. Disabling backups

Correct Answer: A. Object-level authorisation

Question 3

Why can a distributed ledger preserve a security problem permanently?

A. It always deletes old transactions

B. It may make an incorrect or sensitive record difficult to alter or remove

C. It prevents all nodes from storing copies

D. It does not use cryptographic techniques

Correct Answer: B. It may make an incorrect or sensitive record difficult to alter or remove

Question 4

Which practice best protects a containerised database software supply chain?

A. Embedding passwords in the container image

B. Using unsigned images from any public registry

C. Running every container with unrestricted privileges

D. Verifying signed images and scanning dependencies

Correct Answer: D. Verifying signed images and scanning dependencies

Question 5

Which statement about data sovereignty is most accurate?

A. Only the physical location of the primary database matters

B. Replicas, backups, logs and support access may also create jurisdictional concerns

C. Encryption automatically removes all sovereignty obligations

D. Provider certification eliminates the need for customer assessment

Correct Answer: B. Replicas, backups, logs and support access may also create jurisdictional concerns

Question 6

A data warehouse contains unnecessary direct identifiers copied from an operational system. Which principle most directly addresses this problem?

A. Data minimisation

B. Consensus voting

C. Container orchestration

D. Network address translation

Correct Answer: A. Data minimisation

Question 7

What is a major risk of long-lived API tokens?

A. They make encryption mathematically impossible

B. They increase the impact and duration of token theft

C. They prevent all authorised access

D. They eliminate the need for audit logs

Correct Answer: B. They increase the impact and duration of token theft

Question 8

Which feature is especially important for secure database recovery?

A. Testing that backups can actually restore usable data

B. Storing all backups with production administrator credentials

C. Disabling encryption during backup

D. Keeping only one untested backup copy

Correct Answer: A. Testing that backups can actually restore usable data

Question 9

What does configuration drift mean?

A. A database becoming relational

B. A difference between approved and deployed configuration

C. A legal transfer of data between countries

D. A cryptographic signature on a transaction

Correct Answer: B. A difference between approved and deployed configuration

Question 10

Why can a multi-cloud strategy increase security complexity?

A. It removes all administrative identities

B. It guarantees identical controls across providers

C. It may create inconsistent policies, logging and incident procedures

D. It prevents data replication by definition

Correct Answer: C. It may create inconsistent policies, logging and incident procedures