Cloud Infrastructure

Trick 1 · Data and Access Management Are ALWAYS the Customer's Responsibility

The provider's responsibility grows from IaaS to SaaS — but data governance and who has access are always the customer's job. No exceptions.

The exam will present SaaS breach scenarios and ask who was responsible. The distractor answer places responsibility on the provider because "SaaS means the provider handles everything." This is wrong for data and access.

The shared responsibility model has one constant that applies across all service models:

Data: The customer decides what data goes into the cloud service, how it is classified, and what retention policies apply. The provider stores it securely, but the data governance decisions are always the customer's.
Access management: The customer decides who gets an account, what permissions they have, and when accounts are disabled. If a former employee's SaaS account remains active for months after they leave, that is the customer's failure — the provider has no way to know the employee left.

The exam tests this in two directions: "who is responsible for X in SaaS?" and "which layer did the customer fail at in this breach?" For any answer involving data classification, access permissions, account lifecycle, or MFA enforcement, the answer is always the customer — even in full SaaS.

Exam distractor: "A SaaS vendor's platform was used to exfiltrate data because a former employee's account was still active six months after termination. The SaaS provider failed to implement automatic account expiration, which is a provider responsibility in the SaaS model."

Correct: Account lifecycle management is the customer's responsibility in every cloud service model. The provider manages the application; the customer manages who has access to it. A former employee's active account is an offboarding process failure at the customer — not a provider accountability gap. The SaaS provider cannot know that the customer's employee left the organization.

Trick 2 · IaC Drift Prevention Is a Feature, Not a Bug — Manual Changes Should Flow Through Code

When IaC overwrites a manual change and breaks something, that is IaC working correctly. The failure was making the change outside the IaC process.

The exam presents scenarios where a manual cloud console change is later overwritten by an IaC deployment, causing an operational disruption. The distractor frames this as an IaC flaw — "IaC deleted a legitimate security configuration." The correct framing is the opposite: the manual change should never have been made directly. It bypassed the review process.

The reason configuration drift prevention is a security benefit:

Manual changes made under incident pressure at 2AM are often too broad — an engineer opens a port from 0.0.0.0/0 instead of a specific subnet because it is faster.
Manual changes are not reviewed — they bypass the second set of eyes that would catch a misconfiguration before it reaches production.
Manual changes accumulate — over months, the production environment diverges significantly from the documented state, making security audits unreliable.
When the IaC deployment reverts the manual change, it enforces the reviewed, approved policy.

The correct process: make the emergency manual change to restore service (acceptable), immediately file a ticket to update the IaC code, go through the review process, and deploy the code update before the next scheduled deployment overwrites the manual change. The emergency change is a temporary bridge, not a permanent configuration method.

Exam distractor: "A Terraform deployment removed a security group rule that was manually added by an engineer to fix a monitoring gap. This demonstrates a flaw in IaC — it cannot accommodate legitimate emergency changes and creates operational risk by blindly overwriting manual configurations."

Correct: Terraform overwriting the manual change is working as designed. IaC treats the code as the source of truth — this prevents unapproved, unreviewed configurations from persisting indefinitely. The operational risk was created by the manual change, not by Terraform's drift prevention. The correct process is: emergency manual change for immediate service restoration + IaC code update through the review process before the next deployment. Drift prevention is a security feature that enforces the reviewed policy over ad-hoc changes.

Trick 3 · Serverless Shifts OS Responsibility to the Provider — Not Application Security

The provider managing the OS in serverless does not mean security is delegated. The customer's responsibility moves entirely to the application layer.

The exam will present serverless scenarios where something went wrong and ask what the root cause was. Distractors will suggest the provider failed because "in serverless, the provider manages all infrastructure." The distinction: in serverless, the provider manages infrastructure — OS, runtime, scaling, hardware. The customer still owns everything about the code they deploy: its logic, its permissions, its inputs, its secrets, its dependencies.

The four customer responsibilities that never go away in serverless:

Function code security: SQL injection, SSRF, command injection, and all other application vulnerabilities are in the function code. The provider patching the OS does not fix the customer's code vulnerabilities.
IAM least privilege: The customer assigns the IAM role to the function. AdministratorAccess is never an acceptable IAM role for a production function. A compromised over-privileged function grants the attacker all of the function's permissions — which may be full account access.
Input validation: Functions triggered by events (HTTP webhooks, message queues, S3 file uploads) receive data from external sources. All event payload data must be validated before processing.
Secrets management: Hardcoded API keys in function code are exposed to anyone who can read the deployment package, its environment variables, or its logs.

Exam distractor: "A Lambda function was exploited via a crafted event payload that triggered a server-side request forgery vulnerability. Since Lambda is serverless and the provider manages all infrastructure, this is a provider security failure — the customer had no OS-level responsibility and therefore no responsibility for this vulnerability."

Correct: SSRF is an application-layer vulnerability in the function code — it is the customer's responsibility regardless of service model. The provider managing the OS, runtime, and infrastructure has no effect on whether the function code properly validates URLs before making requests. Application code security (including SSRF prevention via input validation and URL allowlisting) is the customer's responsibility in every service model that involves customer-deployed code: IaaS, PaaS, and serverless FaaS.

Trick 4 · "Internal Network = Trusted" Is the Wrong Microservices Security Model

Microservices require zero-trust between services. A compromised internal service can call any unauthenticated API. Network location is not identity.

The exam presents microservices API security questions where the distractors offer "network segmentation is sufficient" or "internal APIs don't need authentication because they're not internet-facing." Both are wrong, and they represent the classic perimeter security mistake applied to a modern architecture.

Why internal microservice APIs must be authenticated:

In a microservices architecture with N services, a compromise of any one service gives the attacker a foothold inside the "trusted" internal network perimeter.
From that compromised service, the attacker can make API calls to any other service that accepts unauthenticated internal requests — and those services will respond as if the caller is legitimate.
Without service-to-service authentication, the account service cannot distinguish a call from the legitimate transaction service from a call from a compromised reporting service. Both have network access to the account service's port.
Network segmentation controls which pods/services can reach which ports. Authentication controls whether a caller with network access is authorized to get a response. Both layers are required.

The zero-trust principle applied to microservices: "never trust, always verify" — every service-to-service call must include proof of the caller's identity, regardless of whether the network path is internal or external.

Exam distractor: "A microservices architecture running in a private cloud VPC does not require inter-service API authentication because all services are isolated from public internet access and network segmentation ensures only authorized services can reach each other's ports."

Correct: Network segmentation controls network-level path access — it does not verify service identity. When one service is compromised, the attacker inherits that service's network access to all peers. Without authentication, the compromised service can make API calls to any reachable peer and receive valid responses. The correct model: network segmentation restricts which services can reach which ports (defense in depth) AND service-to-service authentication verifies that the caller is the specific service authorized to make the request (identity verification). Both layers together prevent lateral movement via API calls after a single service compromise.

Performance Task

You are the cloud security architect for a regional insurance company. The following three scenarios require cloud security decisions. For each, identify the relevant model or principle, explain your decision, and describe the failure mode you are addressing.

Scenario 1

The company is migrating its policy management database (containing 500,000 customer policy records with SSNs, financial data, and medical history) to AWS. The infrastructure team proposes three options: (A) deploy the database on EC2 virtual machines managed by the team; (B) use Amazon RDS (a managed database service where AWS handles OS and database engine patching); (C) use a SaaS insurance platform that hosts the data on behalf of the insurer. For each option, describe the customer's security responsibilities and which layer the customer must focus on securing. Identify which option reduces the customer's OS-patching responsibility and which option reduces it the most.

Click to reveal answer

Option A — EC2 (IaaS):

The customer is responsible for every layer from the OS upward. Specifically: OS installation, OS patching (every Patch Tuesday, third-party app patches, emergency patches), OS hardening (disabling unnecessary services, configuring the host firewall, least privilege user accounts), database engine installation and patching, database configuration and hardening, network security group configuration, data encryption at rest and in transit, backup encryption, and access management (IAM roles for database access, application credentials, DBA accounts). The customer has the most control and the most responsibility. A missed OS patch on the database server is entirely the customer's failure.

Option B — Amazon RDS (PaaS):

AWS manages the EC2 instance, the operating system, and the database engine at the infrastructure level — including OS patching, database engine updates, and automated backups. The customer is responsible for: the database schema and queries (SQL injection prevention at the application layer), data encryption settings (RDS supports encryption at rest via KMS — the customer must enable it), access management (which IAM roles and RDS user accounts can connect), network access (security group rules restricting which application servers can reach the RDS endpoint), and the application code connecting to the database. Option B reduces the customer's OS-patching responsibility significantly compared to Option A — the customer never touches the underlying OS.

Option C — SaaS insurance platform:

The SaaS provider manages the entire stack through the application. The customer's responsibilities are the smallest: configure which of their employees can access the platform and at what permission level, ensure MFA is enforced for all users, manage the data classification and governance of what they upload (the SSNs, financials, and medical records are still the customer's data), and negotiate contractual protections (breach notification timeline, data deletion on contract termination, right to audit). Option C reduces OS-patching responsibility the most — the customer has no OS responsibility at all. However, the customer also has the least control and the most dependency on the provider's security practices. The customer must thoroughly vet the SaaS provider (SOC 2 Type II, HIPAA BAA if medical data is involved) precisely because the customer cannot directly verify the provider's infrastructure security.

Which option reduces OS-patching responsibility? Option B (RDS) eliminates OS patching for the database tier. Option C (SaaS) eliminates OS patching for all tiers — Option C reduces it the most. Option A (EC2) — the customer retains full OS patching responsibility.

Scenario 2

The company's development team has built a new claims processing system as microservices running on AWS EKS (Kubernetes). There are five services: claims-intake, document-analysis, fraud-detection, payments, and audit-log. The claims-intake service is internet-facing; the others are internal. A security review finds: (A) all inter-service APIs are unauthenticated; (B) the payments service IAM role has permissions to read all S3 buckets in the account, not just the specific payment-document bucket; (C) the fraud-detection Lambda function has hardcoded database credentials in its source code. Describe the risk each finding creates and the specific remediation for each.

Click to reveal answer

Finding A — Unauthenticated inter-service APIs:

Risk: If any one of the five services is compromised (e.g., an attacker exploits a vulnerability in claims-intake via its internet exposure), the attacker gains network access within the EKS cluster. From that position, they can make API calls to all other services without restriction. A compromised claims-intake service can call the payments service's transfer endpoint, the audit-log service's delete endpoint, or the fraud-detection service's bypass endpoint — all without authentication. The internal network perimeter provides no protection once one service is breached.

Remediation: Implement service-to-service authentication using service account tokens (Kubernetes service accounts with IRSA — IAM Roles for Service Accounts), mutual TLS (each service has a certificate proving its identity), or a service mesh (Istio, Linkerd) that handles mutual TLS automatically for all inter-service communication. Define authorization policies: claims-intake can call document-analysis but not payments directly; payments can only be called by fraud-detection after a fraud check passes. Every service-to-service call must carry a verifiable identity token.

Finding B — Payments service over-privileged IAM role:

Risk: The payments service needs access to one specific S3 bucket for payment documents. Granting read access to all S3 buckets violates least privilege. If the payments service is compromised, the attacker inherits permissions to read every S3 bucket in the account — potentially including: policy holder PII buckets, internal audit documents, backup archives, and any other sensitive data stored in S3. A vulnerability in the payments service becomes a full-account data exposure incident rather than a payments-specific one.

Remediation: Modify the IAM policy attached to the payments service role to explicitly specify the ARN of the allowed bucket: {"Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],"Resource":"arn:aws:s3:::payment-documents-prod/*"}. All other S3 buckets are implicitly denied. The policy should be the minimum required: if the payments service only reads documents (not writes), remove s3:PutObject. Test the updated policy in a staging environment before production deployment.

Finding C — Hardcoded database credentials in fraud-detection Lambda:

Risk: Credentials hardcoded in source code are exposed to: every developer with repository access (including contractors and former employees whose access may not have been revoked), any CI/CD pipeline that processes the code, any log output if the credentials appear in error messages, and any attacker who gains read access to the Lambda deployment package. Hardcoded credentials cannot be rotated without changing the code and redeploying — making routine credential rotation practically impossible and leaving old credentials valid indefinitely.

Remediation: Remove the hardcoded credentials from the source code immediately. Store them in AWS Secrets Manager with automatic rotation configured. Update the fraud-detection Lambda to retrieve credentials at runtime: aws secretsmanager get-secret-value --secret-id prod/fraud-detection/db. Assign the Lambda function an IAM role with permission to read only this specific secret. Enable rotation — when the database password rotates automatically, the Lambda retrieves the new credentials on its next invocation without code changes or redeployment. Audit the Git history to ensure the credentials are removed from all prior commits (git history rewrite or repository archive rotation if the repository is potentially compromised).

Scenario 3

The company is evaluating an MSP to manage their AWS and Azure cloud environments. The MSP proposes to use a single set of global administrator credentials across all customer accounts for operational efficiency. The MSP's SOC 2 Type II report is 18 months old (the most recent available). The contract includes a 30-day breach notification requirement. The security team must assess the risks and negotiate appropriate controls. What are the three highest-priority security concerns, and what specific contractual or technical controls address each?

Click to reveal answer

Concern 1 — Global administrator credentials shared across all customer accounts:

Risk: A single set of global admin credentials represents the highest-possible privilege level with the widest blast radius. If those credentials are compromised (phishing attack on an MSP employee, MSP infrastructure breach, disgruntled MSP employee), the attacker has full administrative access to every customer account the MSP manages simultaneously — not just this company's account. This is the supply chain breach scenario that affects all customers at once.

Required controls:

Technical: Reject the global admin credential proposal. Require just-in-time (JIT) privileged access — MSP engineers request elevated access for a specific task, access is granted for a limited time window (e.g., 2 hours), and access automatically expires. No standing administrative access.
Technical: MFA mandatory for all MSP access — hardware security keys preferred (phishing-resistant).
Technical: All MSP actions must be logged in the company's SIEM (CloudTrail, Azure Monitor events forwarded to the company's log aggregation) — the company, not just the MSP, must have visibility into what the MSP does.
Contractual: Define in the contract the maximum privilege level the MSP may use, the requirement for JIT access, and the logging requirements. MSP accessing beyond the defined scope is a contract breach.

Concern 2 — SOC 2 Type II report is 18 months old:

Risk: A SOC 2 Type II report assesses security controls over a specific audit period — typically 12 months. An 18-month-old report means the most recent audit covered a period that ended at least 18 months ago. The MSP's security posture, staffing, processes, and infrastructure may have changed significantly since then. Personnel changes, technology migrations, or reduced investment in security controls would not be reflected in the old report.

Required controls:

Contractual: Require the MSP to provide a current SOC 2 Type II report (issued within the last 12 months) before contract execution. Include a contract clause requiring the MSP to provide updated reports annually and to notify the company of any qualified opinions or significant control findings in future audits.
Contractual: Include a right-to-audit clause allowing the company to commission its own security assessment of the MSP's practices affecting the company's accounts, at the company's expense, with reasonable notice.

Concern 3 — 30-day breach notification requirement:

Risk: A 30-day breach notification timeline is likely incompatible with the company's regulatory obligations. GDPR requires notification to supervisory authorities within 72 hours of discovering a personal data breach. State privacy laws (California CCPA, New York SHIELD Act) and insurance industry regulations (NAIC Model Law) have notification timelines far shorter than 30 days for affected individuals and regulators. If the MSP causes a breach of customer data and takes 25 days to notify the company, the company may already be in violation of its regulatory obligations before it even learns of the breach.

Required controls:

Contractual: Negotiate the breach notification requirement down to 24–48 hours of the MSP becoming aware of a suspected incident affecting the company's data or environment. The timeline should trigger on "awareness of a suspected incident," not "confirmed breach determination" — waiting for confirmation adds days that eat into the company's regulatory response window.
Contractual: Define "breach" broadly in the contract to include unauthorized access, unauthorized configuration changes, and suspected compromises — not only confirmed data exfiltration events.
Technical: The company's independent SIEM monitoring of MSP activity (from Concern 1) provides the company with direct visibility into anomalous events — reducing dependency on MSP self-reporting for initial detection.

Cloud Infrastructure — Exam Tricks

The provider's responsibility grows from IaaS to SaaS — but data governance and who has access are always the customer's job. No exceptions.

When IaC overwrites a manual change and breaks something, that is IaC working correctly. The failure was making the change outside the IaC process.

The provider managing the OS in serverless does not mean security is delegated. The customer's responsibility moves entirely to the application layer.

Microservices require zero-trust between services. A compromised internal service can call any unauthenticated API. Network location is not identity.

Performance Task