Cloud Security Exam Prep

Cloud security exams do not reward the person who has memorised the most service names. They reward the person who can read a short business scenario, see which layer is broken, who owns that layer, and which single action fixes it with the least collateral damage. This lesson gives you that way of thinking: a map of the ten domains these exams cover, a reasoning model you can apply to any question, one scenario solved completely from first alert to final answer, and a study plan for four, eight or twelve weeks.

• 12lessons in the course
• 10exam domains mapped and explained
• 130original practice questions with explanations
• ~22 minreading time for this lesson

What cloud security certification exams actually test

This course prepares you for the topics covered by vendor-neutral and provider-specific cloud security exams, similar to exams such as ISC2 CCSP, the CSA CCSK, AWS Certified Security – Specialty, Microsoft's Azure security engineer exam and Google's Professional Cloud Security Engineer. Formats and domain weightings differ and change, so the official outline is your source of truth. What they share is more useful for preparation: they test judgement under constraints, not recall.

A typical item is a short scenario of three to six sentences. A company, a requirement, a symptom and a constraint ("with the least operational overhead"), then four options that are often all technically possible. Your job is to find the one the stem asks for. That is why people with years of hands-on experience sometimes fail these exams: they answer the question they would face at work, not the one on the screen.

The four question shapes you will see again and again

• FIRST / NEXT questions. Several options are correct steps, but only one belongs at this point. In incidents, containment comes before eradication, and evidence preservation before anything destructive.
• BEST / MOST appropriate questions. All options reduce risk; one does it at the root, with a preventive control, and in proportion to the problem. Watch for qualifiers like "cost-effective", "scalable" or "least privilege" that decide between two otherwise good answers.
• Responsibility questions. Who must do this: the provider, the customer, or both? These hinge on the service model and on "security of" versus "security in" the cloud.
• Mechanism questions. Which control actually achieves the requirement? At rest versus in transit, resource policy versus identity policy, stateful versus stateless filter, audit log versus flow log.

Provider-specific exams add "which service or feature" questions. This course explains every concept vendor-neutrally first and then shows how AWS, Azure and Google Cloud implement it.

The perspective the exam expects from you

Most cloud security exams quietly assume a role. Vendor-neutral exams tend to put you in the seat of a security architect or manager advising the business: you think about risk, policy, contracts and design before configuration. Provider-specific exams put you at the console as the engineer choosing the right feature. If you read every stem as "what would a careful, senior person responsible for this company's cloud security recommend?", you will avoid most of the traps described later in this lesson.

The cloud security map: ten domains in one table

Figure 1 shows the domains as a map; the table adds a typical question for each and the one idea you must never forget. Use it as the skeleton of your notes.

The same ideas keep returning – responsibility, identity, keys, logs, blast radius – because the cloud reduces infrastructure to API calls, and API calls are made by identities, authorised by policies, recorded in logs and limited by boundaries.

The LAYER method: five questions that solve most scenarios

When you read a scenario, resist the urge to jump at the first option that sounds familiar. Instead, run through five quick questions. We call this the LAYER method, because almost every cloud security problem lives on a particular layer of the stack and belongs to a particular owner.

• L · Layerwhich layer and service model is involved, and who owns it?
• A · Accesswhich identity acts, and is its access short-lived and minimal?
• Y · Your datawhat data is at stake, how is it classified, where must it live?
• E · Evidencewhat is logged, what proves it, what must be preserved?
• R · Recoverhow do you contain, restore and prevent a repeat?

You will not need all five for every question. A pure responsibility question is solved at L. A federation question is solved at A. But walking the list in order stops you from overlooking the constraint that decides the item, and it gives you a structured way to eliminate options: an answer that ignores the owner of the layer, grants broad access, moves data somewhere it may not go, destroys evidence or fixes only the symptom is almost never the best one.

Three more memory hooks

• "Prevent, then detect, then respond." A preventive guardrail usually beats an answer that only adds an alert. During an active incident, respond first, then fix the cause.
• "Native, automatic, central." Between two working answers, prefer the managed, built-in control that applies organisation-wide over a manual process or a one-server script.
• "Snapshot before you shoot." Capture snapshots, metadata and logs before terminating anything.

A fully solved scenario: the leaked key and the midnight bill

Here is a complete example of the kind of reasoning the exams expect. The scenario is invented for teaching, but every element of it is a pattern that occurs in real environments. Read it once, try to answer, and then follow the solution step by step.

1. Terminate all virtual machines in the unused region and delete the ci-deploy user.
2. Deactivate the leaked access key and block any sessions already issued from it.
3. Open a support case asking the provider to investigate and stop the mining.
4. Rotate every credential in the organisation and rebuild the production account from scratch.

Step 1 – Read the stem like an examiner

The decisive words are "cloud security lead" and "FIRST": an incident in progress, and the first action, not the complete plan. The rest is context: personal data may be breached, the unused region shows broad permissions, and the admission gives the root cause.

Step 2 – Apply LAYER

• Layer: the provider is not broken; a legitimate customer credential is being abused. This is "security in the cloud", so the customer must act. Option C hands the problem to the wrong owner.
• Access: the attacker's power comes entirely from the access key. As long as it works, anything else you do can be undone by the attacker within seconds. Cutting that access is the containment step.
• Your data: the order exports may already have been read. You need to know, and you must not destroy the means of finding out.
• Evidence: the audit log and the instances' disks hold the evidence. Option A destroys it before anyone has looked.
• Recover: rotating everything and rebuilding (option D) may become necessary later, but it is disproportionate as a first step and leaves the active key working while you plan.

Answer: B. Deactivate the key and invalidate sessions derived from it. It contains the incident immediately, it is reversible, it preserves evidence, and it sits squarely in the customer's area of responsibility.

Step 3 – What the next hour looks like in practice

The next exam item will ask about the follow-up steps, so know their order. The commands use the AWS CLI; Azure and Google Cloud offer the same through their activity and audit logs. Run them only in your own lab account.

# 1) Contain: deactivate (do not delete yet) the leaked key
aws iam update-access-key --user-name ci-deploy \
    --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

# 2) Scope: which API calls were made with this key in the region of the miners?
aws cloudtrail lookup-events --region ap-southeast-2 \
    --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
    --query 'Events[].[EventTime,EventName,EventSource]' --output text

# 3) Persistence: did the attacker create new identities or keys?
#    IAM is a global service – its events appear in the us-east-1 event history
aws cloudtrail lookup-events --region us-east-1 \
    --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
    --query 'Events[].[EventTime,EventName]' --output text

Example output of the second command (abridged; times and values will differ):

2026-03-13T21:41:07+00:00   DescribeRegions     ec2.amazonaws.com
2026-03-13T21:43:55+00:00   RunInstances        ec2.amazonaws.com
2026-03-13T21:43:56+00:00   CreateTags          ec2.amazonaws.com
2026-03-13T21:44:30+00:00   AuthorizeSecurityGroupIngress   ec2.amazonaws.com

And of the third command, which is the one that should worry you most:

2026-03-13T21:38:12+00:00   GetCallerIdentity
2026-03-13T21:39:40+00:00   CreateUser
2026-03-13T21:39:41+00:00   CreateAccessKey
2026-03-13T21:39:44+00:00   AttachUserPolicy

The attacker checked whose key it was, then created a new user with its own key – a classic persistence step that deactivating the original key does not touch. Containment is not finished until that key is disabled too. One audit record:

{
  "eventTime": "2026-03-13T21:39:41Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "CreateAccessKey",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "203.0.113.45",
  "userIdentity": { "type": "IAMUser", "userName": "ci-deploy",
                    "accessKeyId": "AKIAIOSFODNN7EXAMPLE" },
  "requestParameters": { "userName": "backup-svc" }
}

Two expert details make good exam questions. First, temporary credentials that were already issued from the leaked key remain valid until they expire, even after the key is deactivated. On AWS you attach a deny-all policy conditioned on the token issue time, which invalidates every earlier session; other providers have equivalent "revoke sessions" mechanisms. Second, the audit log above records control-plane calls. Whether the attacker downloaded the order exports is a data-plane question, recorded only if data-event logging was enabled beforehand. Otherwise you may be unable to prove that personal data was not accessed – which matters for breach notification (Lesson 9).

1. T+0 minCost alert and threat findings arrive; incident declared, roles assigned.
2. T+5 minLeaked key deactivated; sessions issued before now are denied.
3. T+15 minAudit log reviewed by key ID across regions; new user backup-svc and its key found and disabled.
4. T+30 minMining instances isolated with a deny-all security group; disk snapshots taken and tagged as evidence.
5. T+60 minInstances terminated after evidence capture; data-access logs checked for the export bucket.
6. Next daysRoot cause fixed: pipeline moved to federated short-lived credentials, guardrail denies unused regions, secret scanning blocks pushes with keys.

Step 4 – The lessons the exam wants you to draw

Federated, short-lived credentials for the pipeline remove the long-lived key entirely (Lesson 3 and Lesson 10). An organisation-level guardrail that denies all regions except the ones in use would have stopped the miners even with a stolen key (Lessons 3 and 11). Data-event logging on sensitive buckets turns "we cannot tell" into "we can prove" (Lesson 7). Snapshot-then-terminate is standard cloud forensics (Lesson 8). And the question of whether a breach notification is required belongs to Lesson 9. One scenario, six domains: that is how these exams are built.

Worked example 2: choosing the MOST appropriate encryption answer

A mechanism question: every option is a real feature, and the requirement decides. Try it first.

1. Enable default server-side encryption with provider-managed keys.
2. Encrypt data with a customer-managed key in the provider's key management service, log every key use, and schedule key deletion when the data must be destroyed.
3. Use TLS 1.3 for all uploads and downloads.
4. Ask the provider to delete all backups when the contract ends.

Solution. TLS (C) protects data in transit and does nothing for stored copies. Provider-managed keys (A) encrypt at rest, but the customer controls neither their lifecycle nor a dedicated audit trail. A deletion promise (D) is not verifiable. Option B uses envelope encryption: each object is encrypted with a data key, and data keys are themselves encrypted by a key the customer controls. Every key use is logged, and once the key is deleted, every copy becomes unreadable wherever it is stored – this is called crypto-shredding. Answer: B.

The trap is option A. It sounds secure ("it is encrypted!") and it is the default. But the requirement was about control and proof, not about encryption as such.

Exam angle: how these topics are asked and the classic traps

Every lesson in this course ends with an exam-angle section, because knowing the material and passing the exam are two different skills. Here are the traps that appear across all domains. Learn to spot them and you will eliminate one or two options in many questions before you have even fully understood the technology involved.

Common reasoning errors of experienced candidates

Beginners struggle with vocabulary; experienced engineers struggle with their own habits.

Your study plan: 4, 8 or 12 weeks

The right plan depends on what you already know. If you work with cloud platforms daily, four focused weeks may be enough. If cloud is new to you, or you are preparing for a broad vendor-neutral exam with many legal and governance topics, plan for eight to twelve weeks. All three plans follow the same rhythm: learn a domain, practise questions on it, and keep revisiting earlier domains so that nothing fades.

How to study each lesson for retention

1. Skim, then read. Read the headings and the exam-angle section first, then the whole lesson.
2. Explain it without notes. Write five sentences on the core idea; if you cannot, reread.
3. Answer before you look. Commit to an answer before opening each explanation.
4. Keep an error log. For each miss, note the domain, the trap and the warning word in the stem.
5. Revisit on a schedule. Redo questions after a day, a week and a month.

Check yourself: six exam-style questions

You can now…

• Name the ten domains – and the one idea that anchors each of them.
• Apply the LAYER method – layer, access, your data, evidence, recover.
• Eliminate options with four filters – owner, requirement, root cause, proportion.
• Order incident steps – contain, scope, preserve, eradicate, fix the cause.
• Explain crypto-shredding – and why the key, not the data, is the control point.
• Spot the classic traps – "the provider does it", destroy-to-fix, manual heroics.
• Choose a study plan – four, eight or twelve weeks, with spaced review.

Glossary