The Baseline You Need First

The DOP-C02 exam guide is unusually candid about what it will not teach you. Its target candidate, in AWS's own words, "should have 2 or more years of experience in provisioning, operating, and managing AWS environments" and "experience with the software development lifecycle and programming and/or scripting" — and everything quietly packed inside those two sentences is assumed on every one of the seventy-five questions, examined directly on none of them, and defined nowhere. That is the floor: Linux, networking, Git, and one cloud's core compute, storage and identity primitives. This page unpacks it honestly, area by area, says which of the six domains leans on each one and how hard, and ends with ten diagnostic questions and a two-tier self-test with a full answer key — so you find the gaps here, in an afternoon, rather than at question forty of a three-hour closed-book paper.

Why DOP-C02 never teaches you the basics

☺ Like you're 10: This is the advanced class. The teacher assumes you already did the earlier ones, even though nobody checks your homework at the door.

Read the DOP-C02 exam guide's Content Outline and you'll find a sentence most candidates skim straight past: "This guide does not provide a comprehensive list of the content on the exam." That is not a disclaimer about the six domains — those are laid out in detail, task statement by task statement. It is a disclaimer about everything underneath them. The guide describes what a DevOps engineer on AWS is asked to do; it says almost nothing about the operating system that engineer is administering, the network their traffic crosses, the repository their pipeline reads from, or the identity model that decides whether any of it is permitted to happen. All four are simply assumed.

It is worth being precise about where AWS states the assumption, because it is more specific than "you should be experienced." Alongside the two-years-of-AWS line, the guide's Recommended General IT Knowledge and Experience section lists exactly three things the target candidate should have — and its Recommended AWS Knowledge section lists exactly one.

Notice how narrow that AWS-specific recommendation is. Of everything AWS could have named — pipelines, monitoring, autoscaling — the guide singles out securing AWS infrastructure. That is a real signal about where the floor is highest, and it lines up with the blueprint: Security & Compliance is a 17% domain in its own right, and identity quietly decides the correct answer in a great many questions filed under the other five.

The ceiling AWS drew for you — and it is a relief

The same guide contains something candidates rarely exploit: an explicit list of job tasks that are out of scope, introduced as things "the target candidate is not expected to be able to perform." There are four.

• Possess advanced networking knowledge — the guide's own examples are advanced routing algorithms and failover techniques.
• Provide deep-level security recommendations to developers.
• Design, query, and optimize the performance of databases.
• Develop full-stack application code.

Read that list as a budget, because that is what it is. You do not need BGP, or transit-gateway route arithmetic, or query-plan tuning, or the ability to write a front end. You need to recognise a VPC path, know which storage class or database engine fits a stated requirement, and read code without writing it. The distinction between "administer competently" and "design deeply" is where the exam's real edge sits, and naming it is the single most useful thing this page can do for anyone about to over-prepare on the wrong axis.

Two different kinds of "I know this"

DOP-C02 is closed-book multiple choice — no terminal, no docs tab, no cluster to fix. That format has an unintuitive consequence for how you should assess yourself, and it is the organising idea of this whole page.

Every genuine pass account converges on the same observation about question style. Husain Yusuf, writing up his preparation on DEV Community in December 2024, put it most compactly: on DOP-C02, "all the answer options could be implemented." Tolu Nimi, in an October 2024 Medium write-up of his own sitting, drew the contrast with the associate tier — where one option usually "stands out" — and said the professional exam "required a deeper understanding of the concepts and technologies to identify the best answer." Nothing on the screen is technically wrong. Three or four things would all work. You are being asked which one a person who has actually operated this would choose.

So there are two thresholds, and they are not the same threshold.

That "half the options fall away" figure is not this page's invention. @Crowncrow, writing a Japanese-language pass report on Qiita in June 2026 after scoring 815 — and holding six other AWS certifications to compare against — described the mechanic exactly: you can usually eliminate about half the options on service characteristics alone, and the exam is then won or lost on the final discrimination between the two that remain. Tier 1 does the halving. Tier 2 does the deciding.

The whole floor, at a glance

Six baseline areas carry almost everything. Every section below opens with a ⚖ Where it bites marker naming the domains that lean on it hardest, so you can triage before you read. Here is the map:

Linux and operating-system administration

☺ Like you're 10: The cloud is still a computer. When something goes wrong inside the machine, you need to know where the machine keeps its notes.

⚖ Where it bites — heaviest in D1 SDLC Automation and D2 Configuration Management & IaC, both of which are full of scenarios where something ran on a host and didn't do what was expected.

"Experience in administering operating systems" is one of only three general-IT items AWS names, and on this exam it cashes out in a very particular way. You will almost never be asked a Linux question. You will constantly be asked questions whose correct answer depends on knowing how a Linux box behaves — because AWS's automation surface on EC2 is, underneath, a set of scripts that a machine runs as root at a particular moment in its life, and the wrong answers are the ones that misunderstand which moment.

The five places automation actually touches the OS

That table is the single highest-value thing on this page for D1 and D2, because it converts a class of questions from "which service?" into "at which moment?" — and once you're asking about moments, the distractors that sound reasonable stop sounding reasonable.

The Linux you should be able to do without thinking

Nothing exotic. This is the everyday set, and the test is whether it is automatic rather than whether you could look it up.

# where did the boot-time automation put its output?
sudo cat /var/log/cloud-init-output.log        # user data's stdout and stderr
sudo tail -f /var/log/messages                 # Amazon Linux / RHEL family
sudo journalctl -u amazon-ssm-agent -n 50      # is the SSM Agent even running?

# is the service up, and did it fail on start or later?
systemctl status nginx
systemctl is-enabled nginx                     # will it come back after a reboot?

# permissions: the reason a hook script "did nothing"
ls -l /opt/app/scripts/after_install.sh        # is it executable?
id ec2-user                                    # which user is this running as?

# exit codes: the contract every pipeline stage and hook is built on
./deploy.sh; echo "exit=$?"                    # 0 means success, anything else fails the stage

# disk, the cause of a surprising share of "the agent stopped reporting"
df -h /var
du -sh /var/log/*

The exit-code line deserves a sentence of its own, because it is the connective tissue of the entire delivery chain. A pipeline stage, a CodeBuild phase, a CodeDeploy hook and an SSM Run Command step all mean the same thing by "failed": a process exited non-zero. Every automatic rollback, every gate, every alarm-triggered stop in this course ultimately rests on that one convention. If it isn't reflexive, half of D1 will feel arbitrary.

What to do if this section found a gap

If Linux is genuinely shaky — not "I'd have to check the flag" but "I don't know where the log is" — the honest fix is a few weeks of using it, not more reading. The LFCS page in this course is the on-ramp: it is the Linux administration credential that maps most directly onto the DOP-C02 assumption, and even if you never sit it, its objective list is a good syllabus for the gap. For the AWS-side mechanisms in the table above, Immutable Infrastructure & Golden Images covers the bake-versus-boot trade and Configuration management covers the converge-at-runtime alternative.

Networking — to exactly the depth the exam wants

☺ Like you're 10: You need to be able to follow a letter from the postbox to the front door, and say which gate stopped it. You do not need to design the postal service.

⚖ Where it bites — D3 Resilient Cloud Solutions and D6 Security & Compliance, plus a steady trickle everywhere else disguised as "the deployment succeeded but the health check failed."

This is the area where AWS's out-of-scope list does the most work for you. Advanced networking is explicitly not expected — so the depth you need is a single, complete mental model of a packet's journey and the four or five places it can be stopped. The exam's Technologies and Concepts list names precisely one networking item: "Network ACL and security group design and implementation." That is the giveaway. Learn that distinction properly and you have most of what the exam wants.

The route table is what makes a subnet public

Start here, because it is the fact that unlocks the rest. There is no "public" checkbox on a subnet. A subnet is public if its route table has a route to an internet gateway; it is private if it doesn't. A private subnet that needs outbound access (to pull packages, call an AWS API, or reach an update server) reaches it through a NAT gateway that itself lives in a public subnet — outbound only, never inbound. And an instance with no public IP in a public subnet is still unreachable from the internet, because reachability needs three things, not one: a route, an address, and a permissive security group.

That three-part requirement is worth memorising as a shape, because a very large family of exam scenarios is one of its three legs quietly removed.

Security groups vs network ACLs — the distinction the guide names

Two consequences follow, and both are examinable. First: if a question needs a deny, it needs a NACL — a security group cannot express "block this one address." Second: if a question's symptom is "the request goes out but nothing comes back," suspect the stateless layer, because that asymmetry is exactly what a NACL missing its ephemeral-port return rule produces, and exactly what a security group cannot produce.

Load balancers and the two health checks people conflate

The chain is short and worth being able to recite: a listener accepts traffic on a port and protocol, a rule decides where it goes, and a target group holds the registered targets plus the health check that decides which are eligible. An Application Load Balancer works at HTTP level and routes on host, path and header; a Network Load Balancer works at TCP/UDP level and is the answer when you need static IPs, extreme throughput, or protocols the ALB doesn't speak.

Now the trap. There are two independent health notions in a typical deployment, and questions exploit the difference constantly:

• The target group health check decides whether the load balancer sends this target traffic.
• The Auto Scaling group health check decides whether the instance is replaced. By default an ASG only looks at EC2 status checks; it considers load-balancer health only if you have told it to.

So "the app is broken but the instance is healthy and never gets replaced" is a completely coherent state, and it is the intended answer to more than one kind of scenario. Layer a health check grace period on top — the window after launch during which the ASG ignores health signals so a slow-booting app isn't killed mid-startup — and you have the second half of that family of questions.

DNS, and why failover is never instant

You need Route 53 at concept depth, not record-syntax depth. Know that an alias record points at an AWS resource, resolves at query time, and can sit at a zone apex where a CNAME cannot. Know the routing policies that matter operationally — weighted (the basis of DNS-level canaries and blue/green cutovers), failover (paired with a health check), and latency — and know that Route 53 health checks can drive failover automatically.

And know the thing that catches people in real incidents as often as in exams: TTL is a promise you already made. Resolvers and clients cache. A DNS-based cutover takes effect over the TTL window, not immediately, which is precisely why deployment strategies that need instant, complete rollback do not use DNS as the switch.

Private connectivity — the cause you'll forget

An instance in a private subnet calling an AWS API is doing something people rarely picture correctly: by default it is calling a public endpoint, and needs a path to the internet to do it. Remove the NAT gateway to save money and a great many things stop working at once, in ways that look like permissions failures and aren't. The fix is a VPC endpoint: a gateway endpoint (a route-table entry, available for Amazon S3 and DynamoDB) or an interface endpoint (an ENI in your subnet, powered by AWS PrivateLink, for most other services).

Git and the repository layer

☺ Like you're 10: The pipeline has to start somewhere. That somewhere is a repository, and the rules you put around it decide what the pipeline is even allowed to build.

⚖ Where it bites — D1 SDLC Automation, the heaviest domain on the exam at 22%. The guide's Technologies and Concepts list names "code repository best practices" outright.

Git itself is not examined. What is examined is the layer immediately above it: the conventions a team puts around a repository so that "what is in main" is a statement you can act on automatically. Almost every D1 scenario is really a question about that layer — what triggers, what gates, what is allowed to reach production, and what happens to the change that shouldn't have.

The repository facts a D1 question assumes

The single most useful reflex here is knowing that revert is a forward operation. Rolling back by creating a new commit that undoes the change keeps history linear and keeps the pipeline as the only path to production; rolling back by rewriting history or deploying an older artifact by hand breaks the correspondence between the repository and reality. Which of those two a scenario is describing is very often the whole question. The roll-back drill in this course is built on exactly that distinction.

Where the source actually comes from — and a drift worth knowing about

Here is a genuinely useful thing that neither the exam guide nor most study material will tell you, and it sits precisely in this baseline area.

The DOP-C02 exam guide has an appendix of in-scope AWS services. In the original v1.0 guide, published when the exam launched in 2023, AWS CodeCommit appeared in the Developer Tools list and in a task statement — it was the assumed default source for a CodePipeline. In the current v1.6 guide, CodeCommit does not appear anywhere: not in the service list, not in any task statement. What has not been added in its place is AWS CodeConnections, the service (previously named AWS CodeStar Connections) that connects a pipeline to a repository hosted elsewhere — GitHub, GitLab, Bitbucket. It is absent from the v1.6 in-scope list entirely.

Candidates report meeting it anyway. @boloyome, in a Qiita post from 10 June 2026 whose title translates as "the story of meeting a service I'd never heard of when I took the AWS DOP," describes CodeConnections appearing repeatedly on his exam, having never encountered it before, and being unsettled to find it missing from the official service list. Independently, Irene Bonso, writing up her 2025 sitting for Tutorials Dojo, lists AWS CodeConnections among the topics that came up frequently for her. Meanwhile AWS's own free sample-questions PDF for this exam still opens with a CodeCommit scenario.

A note on Bonso's write-up, in the interest of you weighing it properly: she is a software engineer at Tutorials Dojo, and the post recommends her employer's paid study materials throughout. The account itself reads as genuine and first-hand, and her topic list corroborates @boloyome independently — but it is published somewhere with a commercial interest in your study budget, and you should read it knowing that.

IAM — the one AWS area the guide names explicitly

☺ Like you're 10: Every single thing that happens on AWS is a request that something has to approve. If you don't know how the approval works, you can't predict what will happen — and that's most of the exam.

⚖ Where it bites — D6 Security & Compliance at 17%, and invisibly in all five other domains. It is also the only AWS-specific item in the guide's Recommended AWS Knowledge section: "experience in securing AWS infrastructure."

If you fix one baseline gap before starting the blueprint, fix this one. A DevOps engineer's day is spent making automated things act on their behalf — a pipeline assuming a role in another account, an instance reading a parameter, a Lambda writing to a bucket, a container pulling an image — and every one of those is an IAM question wearing a different service's clothes. Get identity wrong in your head and a surprising number of "which service?" questions become unanswerable, because the difference between the two remaining options turns out to have been a difference in who is acting.

Four nouns, and where a policy can live

Every policy statement answers four questions: which principal, doing which action, on which resource, under which condition. What changes between policy types is which of those four is implied rather than written.

• An identity-based policy is attached to a user, group or role. The principal is implied — it's whoever the policy is attached to — so the document names actions, resources and conditions.
• A resource-based policy is attached to the resource itself: an S3 bucket policy, an SQS queue policy, a Lambda function policy, a KMS key policy. Here the resource is implied and the principal is written explicitly. This is the type that makes cross-account access possible without copying credentials anywhere.
• A permissions boundary and a service control policy (SCP, applied through AWS Organizations) are guardrails. Crucially, they never grant anything — they set the maximum that any grant inside them can reach.
• A trust policy is the special resource-based policy on a role that says who is allowed to assume it. It is a completely separate document from the role's permissions policy, and confusing the two is the most common IAM error a new engineer makes.

// The role's PERMISSIONS policy - what the role may DO once assumed
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::build-artifacts-prod/*",
    "Condition": { "StringEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } }
  }]
}

// The role's TRUST policy - WHO may become it. A different document entirely.
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "codebuild.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Read those two blocks until the split is obvious, because a whole family of questions is built on it: "the pipeline still gets AccessDenied even though the role has the permission" is almost always a trust-policy problem, and "anyone in the account can assume the deployment role" is almost always a trust policy that was written too broadly.

How a request is actually decided

The evaluation order is short, deterministic, and worth being able to recite. It is also the thing that makes IAM predictable rather than mysterious.

Three consequences fall straight out of that diagram, and each of them is worth more on the exam than a memorised service list:

• An explicit Deny is final. No Allow anywhere overrides it. So "we added the permission and it still fails" points at a Deny — very often in an SCP the engineer cannot see from inside their own account.
• Guardrails don't grant. Attaching an SCP that "allows" S3 gives nobody S3 access; it merely stops the account from being restricted away from it. Any option that solves an access problem by adding a permissive SCP is wrong for that reason alone.
• Cross-account needs both ends. The caller's identity policy must allow the action and the resource's policy (or a role trust policy) must allow the caller. One side alone is never enough, and that asymmetry is the backbone of multi-account pipeline questions.

Roles, and the four disguises they wear

Roles are how AWS avoids long-lived credentials, which is why they are everywhere in a DevOps context. What trips people is that the same mechanism has four different names depending on where it's attached:

Compute and storage primitives

☺ Like you're 10: You need to know which of these things breaks when a whole building loses power, and which one doesn't even notice.

⚖ Where it bites — D3 Resilient Cloud Solutions and D5 Incident & Event Response. Every high-availability and disaster-recovery question is really a question about the failure behaviour of these primitives.

The scoping rule that answers half of D3

Before any specific service, get this straight: every AWS resource is scoped to a Region, an Availability Zone, or globally, and its scope decides what kind of failure kills it. Candidates who know the service names but not their scope reliably lose resilience questions, because resilience is scope.

Two immediate corollaries worth carrying: an EBS volume lives in one Availability Zone and attaches to one instance at a time (Multi-Attach on certain io-family volumes is the narrow exception), whereas EFS is a shared file system reachable from multiple zones — so "several instances need the same files" and "this instance needs its own fast disk" are different questions with different answers. And an EBS snapshot is stored regionally and can be copied to another Region, which is how zonal storage participates in a regional DR plan at all.

EC2, Auto Scaling and the replace-don't-repair instinct

The compute baseline is less about EC2 itself than about the group around it. Know the chain: an AMI is the image, a launch template describes how to start an instance from it (versioned, and the current mechanism — launch configurations are the legacy form AWS has been retiring, so if both appear as options the template is almost always intended), and an Auto Scaling group maintains a desired count across subnets in multiple zones.

The behaviours that get examined:

• Scaling policies. Target tracking holds a metric at a value and is the default right answer for "keep CPU near 50%." Step scaling reacts in graduated stages to alarm breaches. Scheduled scaling handles known, clock-driven demand. If a scenario names a metric and a target, it is describing target tracking.
• Lifecycle hooks. A hook pauses an instance as it enters service or as it terminates, so something can run — drain connections, ship the last logs, register or deregister. When a question needs work to happen at the boundary of an instance's life, this is the mechanism.
• Instance metadata. Credentials for the instance's role are served from the metadata service; the modern, session-oriented form (IMDSv2) requires fetching a token first. Enforcing it is a routine hardening answer.

And underneath all of it, the instinct this course is built on: instances are cattle. When the exam offers "log in and fix the instance" against "replace it from a known-good image," that is what it is testing.

Serverless compute, in the two facts that matter here

You do not need Lambda depth at the baseline, but two structural facts get used as discriminators. First, the execution role vs resource policy split from the IAM section: one says what the function may do, the other says who may invoke it. Second, versions and aliases — a published version is immutable, an alias is a movable pointer to one, and an alias can split traffic by weight between two versions, which is how a canary release is expressed in Lambda terms and why progressive delivery questions sometimes have a serverless-shaped answer.

S3, and the lore that is now wrong

S3 is the substrate for artifacts, logs, backups, state files and static content, so it appears everywhere. The baseline facts: buckets are regional but names are globally unique; versioning keeps prior versions and turns a delete into a delete marker; lifecycle rules move or expire objects by age; a bucket policy is the resource-based policy that makes cross-account access possible; event notifications can fire Lambda, SQS or EventBridge when an object lands, which is how a great many "when a new artifact appears, do X" designs are wired.

Where storage meets resilience, one pairing carries the load: RTO (how long you can be down) and RPO (how much data you can afford to lose). Those two numbers pick the DR pattern, and the DR patterns are examined by name. They are drilled in Know It Cold; this page only asks that the distinction is already automatic before you get there.

Containers — the vocabulary floor

☺ Like you're 10: A recipe, a meal cooked from it, and a waiter making sure there are always four meals on the table. Three different words, and people mix them up constantly.

⚖ Where it bites — D1 and D3 mostly, and it is a smaller baseline than you might expect. AWS's in-scope list is broad here, but the exam is not a Kubernetes exam.

The floor is genuinely modest. Know that a container image is an immutable, layered filesystem plus metadata, that Amazon ECR is the registry it lives in, and that tags are mutable unless you make them immutable — which is the same argument as Git tags, and the same reason "deploy :latest" is a wrong answer in any question about reproducibility.

For ECS, three nouns and one distinction. A task definition is the recipe: images, CPU and memory, environment, logging, the two roles. A task is one running instance of it. A service keeps a desired number of tasks running and registers them with a load balancer. The distinction is Fargate vs EC2 launch type: with Fargate you do not manage instances at all, which quietly removes a whole category of answer — anything involving patching or scaling the underlying hosts. (The two roles are the ones from the IAM section above, and they remain the most examined container detail on this exam.)

For EKS, recognition is enough at baseline: managed Kubernetes, control plane AWS's problem, nodes yours unless they're Fargate, and IAM identities mapped to Kubernetes identities rather than replacing them. If you want more, the course has a Kubernetes tool page and containers & orchestration — but that is well beyond what DOP-C02 asks.

Scripting and the software development lifecycle

☺ Like you're 10: You never have to write code on this exam. You do have to read it, quickly, over and over, while a clock runs.

⚖ Where it bites — D1, D2 and D4 Monitoring & Logging. Not as a topic — as a tax on your reading speed in every question that contains a snippet.

The guide asks for "programming and/or scripting" experience and simultaneously puts full-stack development out of scope. Both are true, and the resolution is simple: this is a reading skill, not a writing skill. Nobody will ask you to author a function. Plenty of questions will put a template fragment, a build spec, a policy document or a log query on the screen and expect you to see what it does at a glance — and the exam's real adversary, on every honest account of it, is reading time.

That is not a soft claim. Simon Mafany E., writing up his first-attempt pass in October 2024, did the arithmetic that everyone else's tactics follow from: "Questions are very lengthy, and you have practically 2.4 minutes to read a question, understand it, read the options, analyze them, eliminate distractors, before select[ing] the best option." He also described the stamina cost plainly — tired after the first hour, concentration nearly gone by the end of the second. Every second you spend parsing YAML you should have been able to skim is drawn from that budget.

The four file shapes you will meet

# JMESPath, via the CLI's --query - this is not jq, and the syntax differs
aws ec2 describe-instances \
  --query 'Reservations[].Instances[?State.Name==`running`].[InstanceId,PrivateIpAddress]' \
  --output table

# CloudWatch Logs Insights - a pipeline, not JMESPath
# fields @timestamp, @message
# | filter @message like /ERROR/
# | stats count(*) by bin(5m)
# | sort @timestamp desc

Finally, the lifecycle itself. "Modern development and operations processes and methodologies" is the third of AWS's three recommended-experience items, and on this exam it means you can reason about the sequence — commit, build, test, artifact, deploy, observe, respond — as a chain where each link constrains the next. That is what the whole DevOps lifecycle page is for, and if any link in that chain is vague for you, read it before the blueprint rather than after.

Ten questions that find the gap

☺ Like you're 10: Cover the page. Answer out loud. The ones you can't answer are exactly the ones worth a week.

These are deliberately not multiple choice — recognising the right option is precisely the skill that hides a baseline gap, and the Exam Simulator and the five mock exams already give you plenty of that. Answer each in a sentence or two, from memory, before opening the key. Track which area each miss belongs to; that mapping is the output of this exercise, not the score.

1. (Linux) You install your application from a user data script. The instance is stopped for a maintenance window and started again a week later. Is the application still installed? Explain what happened, and say what you would change.
2. (Linux / IaC) What does cfn-signal do, and what does CloudFormation believe about an instance that never sends one?
3. (Networking) A subnet's route table has a route to a NAT gateway and no route to an internet gateway. An instance in that subnet has been given a public IP address. Can you reach it over SSH from the internet? Why?
4. (Networking) Traffic leaves an instance but replies never arrive. Which of a security group and a network ACL can produce that symptom, which cannot, and why?
5. (IAM) A build role's identity policy grants s3:GetObject on the exact bucket, and the build still fails with AccessDenied. Name three structurally different causes.
6. (IAM / containers) What is the difference between an ECS task role and a task execution role, and which one is at fault when a task cannot pull its image from ECR?
7. (Storage) Instances in three Availability Zones must all read and write the same files. EBS or EFS — and what makes the other one wrong?
8. (Compute) An Auto Scaling group's instances are running, but the application inside them has crashed and is returning errors through the load balancer. The ASG never replaces them. What is the most likely reason?
9. (Git) A release is bad and must be undone in a way that stays auditable and keeps main an honest description of production. What do you do, and what do you specifically avoid doing?
10. (Scripting) A CodeDeploy lifecycle hook script exits with status 1. What happens to the deployment — and what does that imply about how you write those scripts?

Score yourself — the baseline self-test

☺ Like you're 10: Tick only what you could genuinely do right now. The empty boxes are the useful part.

Two tiers, for the two thresholds from the top of this page. Tier 1 is the vocabulary floor: if you can't tick these, blueprint study will be uphill because you will be translating instead of learning. Tier 2 is the hands-on floor: each item asks whether you have done the thing, not whether you could describe it. Be strict with yourself on Tier 2 in particular — it is the tier that decides the last two options, and the one nobody can bluff on the day. Your ticks are saved on this device.

Tier 1 — the vocabulary floor

• ① Linux & the operating system
• Say when user data runs, how often, and where its output lands
• Explain what cfn-signal is for and what a CreationPolicy waits on
• Name the three independent reasons an instance can show as not managed by Systems Manager
• State what a non-zero exit code means to a pipeline stage, a build phase and a deployment hook
• ② Networking
• Say what actually makes a subnet public, and name the three things inbound reachability needs
• Give four differences between a security group and a network ACL without hesitating
• Explain why only one of those two can express a deny, and what that implies for a question
• Distinguish a target group health check from an ASG health check and say what each one causes
• Say what a VPC endpoint is for, and which two services get the gateway kind
• Explain why a DNS-based cutover is never instant
• ③ Identity
• Recite the evaluation order: explicit Deny, then guardrails, then an explicit Allow, else implicit deny
• Explain why an SCP that "allows" something grants nobody anything
• Distinguish a role's trust policy from its permissions policy, and say which one an assume failure implicates
• Say what a resource-based policy makes possible that an identity policy alone cannot
• Distinguish an ECS task role from a task execution role by the failure each one produces
• ④ Compute, storage & the repository
• Classify ten common resources as global, Regional or zonal without checking
• Say why EBS cannot satisfy a shared, multi-AZ, read-write requirement and what can
• Explain RTO vs RPO in one sentence each and say which one backups mostly move
• Name the three ECS nouns — task definition, task, service — and what each adds
• Explain why mutable tags (Git or image) break traceability, and what to use instead

Tier 2 — the hands-on floor

• ⑤ Things you have actually done
• Debugged a bootstrap script that silently did nothing by reading the instance's own logs
• Written and re-run declarative infrastructure and watched a no-op run change nothing
• Traced a request end to end and found the hop that was blocking it
• Caused an AccessDenied yourself and worked out which of several policies produced it
• Set up cross-account access and got both ends of the grant right
• Watched an Auto Scaling group replace an instance, and know what triggered it
• Rolled something back under real pressure and can describe what you did first
• Built a pipeline whose failure actually stopped a release, rather than being ignored
• ⑥ Reading speed and judgement
• Skim a CloudFormation template and say what it creates without reading every line
• Read a buildspec.yml and say which phase would fail first, and why
• Tell a CLI --query (JMESPath) expression from a Logs Insights query on sight
• Spot the three YAML traps — tabs, unquoted booleans, unquoted colon-space — while reading
• Look at four all-workable options and pick on operational fit rather than technical validity
• Eliminate roughly half the options on service characteristics alone, before reasoning about the scenario
• Read a long scenario once, at pace, and hold the requirement in your head while you evaluate options

What your score means

Count the unticked boxes in each tier separately. The gaps are the signal; a combined total tells you nothing useful, because the two tiers fail in completely different ways.

Closing the gaps you found

☺ Like you're 10: You now have a short list of wobbly bits. Fix those. Don't start the whole book again from page one.

Resist the urge to re-read everything. You have a specific list now, and specific lists are closed with specific drills — which is also the difference between a week that moves your score and a week that feels productive.

For vocabulary gaps

Take one unticked Tier 1 item and explain it out loud, from memory, in a paragraph — then check it against the section above and mark what came out thin. That retrieval loop is the entire method, and it is what Self-Check and Flashcards mechanise: closed-page recall, immediate feedback, misses saved for a retry. The glossary is for the terms you keep dropping. And if the gap is specifically AWS names for things you already do — the fastest gap on this page to close — The AWS Service & Command Reference is organised by domain for exactly that purpose, and Know It Cold is the short list of facts that have to survive a closed-book exam without a docs tab.

For hands-on gaps

There is no substitute and no shortcut: build something, break it, and fix it. The capstone track is the long version — six parts that take one change from a pipeline through infrastructure, deployment, observability, incident response and hardening — and the guided drills are the short version, each one built around a single failure you should have met before the exam rather than during it. If a Tier 2 box is unticked, there is very likely a drill whose whole purpose is to tick it.

One technique from a real candidate is worth borrowing verbatim. Suraj Solanki, a senior DevOps engineer writing up his 2025 pass, describes pairing every revision topic with a specific memory of work he had actually done — multi-account CI/CD with a particular GitHub Actions and CodePipeline setup, disaster-recovery strategies with a DR drill he had personally run, EventBridge with the time he used it to auto-restart failed ECS tasks. The value is not the anecdotes; it is that a topic you cannot attach to a memory is precisely a Tier 2 gap, and this method surfaces them one by one. Do it as you read the blueprint pages and you get a running audit of your own experience for free.

When you go looking for more

Two honest warnings, because both will cost you time otherwise.

First, the top of your search results is not the evidence. Queries like "DOP-C02 exam experience" reliably return practice-dump sites, course listings and content-farm "2026 guides" well above genuine first-hand write-ups. Third-party guides also drift ahead of the facts: one widely linked study plan asserts that DOP-C02 includes ordering, matching and case-study question types, when the current exam guide states there are exactly two — multiple choice and multiple response. AWS did introduce those newer formats on some certifications, but no official source places them on this one. When a third-party page and the exam guide disagree, the exam guide wins.

Second, and more usefully: the most current first-hand accounts of this exam are in Japanese. a search for DOP-C02 on Qiita returns well over a hundred posts, many tagged 合格体験記 ("pass experience report"), and several from mid-2026 report exact scaled scores and real exam-day detail — including the three cited on this page: @Crowncrow (815), @boloyome (the CodeConnections account) and @Rabbit_booK (the one-week preparation). They machine-translate cleanly, and for an English-speaking candidate that is the single best-value research tip here. The English-language accounts worth your time are the ones named above: Tolu Nimi, Simon Mafany E., Rishab Kumar, Suraj Solanki, Irene Bonso and Husain Yusuf.

Then, and only then, start the blueprint

Once the boxes here are ticked, everything downstream gets cheaper — not because you know more, but because the constant, quiet translation cost disappears. SDLC Automation becomes "the repository practice I already have, expressed in AWS services." Configuration Management & IaC becomes "bake or converge, and at which moment." Security & Compliance becomes "the evaluation order, applied at scale." That is the whole return on this week: the blueprint stops feeling hard and starts feeling like naming things you can already do.