Cloud, AI and specialized-environment security
The Cloud Security, Risk and Compliance domain tests whether you can place controls correctly across the shared responsibility model and evidence compliance. Questions typically describe a service and ask who owns a control, or which standard or legal obligation applies.
Shared responsibility
The provider is responsible for security of the cloud; the consumer for security in the cloud. The boundary moves with the service model. In IaaS the consumer patches the OS and secures the workload; in PaaS it secures code, configuration and identities; in SaaS it secures users, access rights, data classification and the settings it chooses.
Core control areas
- Identity and access management: least privilege, federation, multi-factor authentication, joiner-mover-leaver processes.
- Data protection: classification, encryption in transit and at rest, and control of keys. Customer-managed keys can change key control and access policy, but do not by themselves prove that a provider or workload can never decrypt data.
- Residency and jurisdiction: where data and metadata are stored, and which laws reach them.
- Assurance: ISO/IEC 27001 for an information security management system, ISO/IEC 27017 for cloud-specific controls, ISO/IEC 27018 for protecting PII in public clouds acting as PII processors, SOC 2 reports and the CSA STAR registry.
Legal position
Identify the applicable legal roles, contracts and data requirements for the actual service. Outsourcing processing does not by itself discharge the customer’s own obligations. Provider certifications describe a defined scope and period; inspect what services and controls they cover and what remains for the customer. No particular national contract clause, breach deadline or transfer permission is invented here.
Worked example
A company buys a SaaS HR system holding EU employee data. Who secures what? Reasoning: the provider secures the application, the underlying infrastructure and its own personnel. The company decides which data may be entered, configures roles so managers see only their team, reviews access quarterly, sets retention and answers employee requests. Encryption responsibilities depend on the actual service: some protections are enabled by default, while customers still choose relevant configuration, key policy, permissions and data classification. Inspect the documented boundary rather than assuming every encryption feature is optional.
Traps that cost marks
- Assuming the provider is responsible for everything once data is in the cloud.
- Believing encryption removes accountability - key ownership decides who is really protected.
- Treating a provider's ISO/IEC 27001 certificate as proof that your own use of the service is compliant.
- Confusing ISO/IEC 27017 with ISO/IEC 27018.
- Forgetting audit rights, breach notification timelines and data deletion at exit.
Artificial intelligence is a broad category of systems that perform tasks associated with reasoning, perception, language or decision support. Machine learning develops behavior from patterns in data rather than specifying every rule manually. Generative models create candidate text, images or other outputs; producing a fluent answer does not make that answer accurate, safe or suitable for an important decision. Begin by defining the task, the intended users, acceptable errors and how the outcome will be evaluated.
The Google certification guide discusses pre-trained APIs, automated model-building approaches and custom models. Pre-trained services can reduce development effort for a supported task, while custom development may provide differentiation when appropriate data, expertise and operating capacity exist. The guide uses the name Vertex AI for a unified model-development environment; operational documentation can use newer platform names. Treat names as versioned references and verify current capability and lifecycle information before choosing a service. This written chapter is conceptual preparation, not a claim of hands-on model-deployment competence.
Training, validation and testing answer different questions. Training fits model parameters. Validation supports choices such as model settings, and a held-out test estimates performance on data not used to make those choices. Leakage occurs when future information, duplicated records or other unavailable-at-decision-time information enters the training or evaluation process. A very high reported score can therefore reflect a flawed experiment rather than a useful system.
Choose measures that fit the cost of errors. For a supplied binary-classification exercise, precision is true positive predictions divided by all positive predictions, while recall is true positives divided by all actual positives. Accuracy can conceal poor minority-class performance. In a fictional set of one thousand cases, a system identifies ninety of one hundred actual positives but also flags ninety negative cases. Recall is ninety percent and precision is fifty percent. A claim that the model is simply ninety-percent good omits which errors matter and who bears them.
Responsible use includes suitable data permissions, representative evaluation, understandable limitations, security and an accountable human process. Assess performance across relevant groups and conditions rather than assuming one aggregate score proves fairness. A model that worked at launch may degrade when populations, behavior or business processes change. Monitoring should cover quality, drift, operational reliability and cost, with a route to investigate or disable harmful behavior.
Generative-model outputs may need grounding in approved information, evaluation against realistic tasks and human review. Do not send confidential material merely because a tool is easy to access. A short prompt, a larger model or a retrieved document is not a universal guarantee against incorrect output. The business case must consider reliability, privacy, integration and ongoing review as well as the apparent productivity gain.
Specialized platform threat models
Cloud responsibility depends on the actual service boundary. AI-enabled applications also need to distinguish untrusted inputs or model output from authority to take an action. A retrieved document or generated instruction is not permission to expose secrets, change access or invoke a privileged tool. Validate data and outputs at the decision boundary, restrict available actions and retain suitable review and audit evidence. Training-data poisoning, sensitive-data disclosure, model provenance and misleading evaluation are different risks; one content filter does not settle all of them.
Industrial and operational-technology environments add safety, availability and lifecycle constraints. Identify the physical process and approved operating boundaries before scanning, patching or changing a control network. Segment appropriate zones and paths, control remote support and removable media, and coordinate with the responsible operators. A general IT patch recommendation does not justify disrupting a live controller or bypassing a safety process. Establish tested recovery, dependency and change arrangements for the actual plant. Mobile devices and large analytical platforms likewise require actual identity, data-flow, update and disposal controls rather than a belief that a product label makes them safe. These are conceptual assessment principles, not a live operational procedure or a universal national grading decision.