Study event streaming by following a record from its producer to a consumer and a business result. These free Confluent study guides connect Kafka developer and administrator learning with record contracts, partition reasoning, failure cases and operational evidence. Start with application development or cluster operations, then use the matching CCDAK or CCAAK Premium PDF for additional targeted review.
Want free reference PDFs? Email freelearning@ciscoforall.com with your exam code and name. We will send an available older reference file free of charge. Availability varies. See the request section below.
Browse All Confluent Premium PDFs
Choose the learning direction closest to your role and current knowledge. These orientations help you organise practice; they are not official exam objective lists. Compare your chosen target with the exact current syllabus and record any additional topics you need.
| Learning path | Who it suits | Topics to understand | First practice task |
|---|---|---|---|
| Kafka development | Learners building event-driven applications | Record contracts, keys and consumer processing | Trace a fictional order event. |
| Kafka administration | Learners operating streaming services | Cluster dependencies, access and observation | Map a producer-to-consumer service path. |
| Streaming reliability | Learners investigating failure behaviour | Replay, duplicates and progress evidence | Explain a repeat-processing case. |
Connect additional review material with a specific preparation gap. Open a relevant product to explore its details, confirm its code and version, and decide how it supports your learning goal.
| Premium resource | Preparation focus |
|---|---|
| CCAAK — Confluent Certified Administrator for Apache Kafka — Premium PDF | Review CCAAK for the product and version shown in the listing. |
| CCDAK — Confluent Certified Developer for Apache Kafka — Premium PDF | Review CCDAK for the product and version shown in the listing. |
The two featured references are CCDAK and CCAAK. Developer, administrator and cloud-operator targets are distinct; this guide does not claim that either featured file covers every Confluent credential.
Browse All Confluent Premium PDFs
A fictional order event records that an order was accepted. Define its identifier, business time and required fields. Decide whether it represents a fact that already occurred or an instruction requesting work. Consumers need a stable meaning, not merely a collection of values.
Practice task: Write accepted-order and cancelled-order examples with explicit identifiers. Expected result: Each record has a business interpretation another component can use. Common mistake to avoid: Using one event name for unrelated business meanings.
A task needs related records for one fictional order to be handled coherently. Describe which records share a business identity and why their relationship matters. Separate the application’s required order from an assumption that every record in an entire topic has one global sequence.
Practice task: Arrange events for two orders and mark the ordering requirement within each. Expected result: The scope of the ordering assumption is explicit. Common mistake to avoid: Assuming all topic records share a single global ordering guarantee.
A consumer receives an event and changes a fictional downstream record. Describe the point where work becomes visible and the point where progress is recorded. A crash between these observations can make the result uncertain and requires a reasoned recovery design.
Practice task: Draw receive, validate, apply and record-progress stages with a failure between them. Expected result: The note identifies possible repeated or incomplete work. Common mistake to avoid: Assuming a client error proves that no business change occurred.
A repeated delivery of the same accepted-order event should not create a second fictional shipment. Define how the business identity is recognised and which outcome counts as already processed. Reliability reasoning depends on the requirement and system boundaries, not a slogan alone.
Practice task: Process the same identifier twice in a written example. Expected result: One logical order produces the intended single business effect. Common mistake to avoid: Treating every delivery as a new business event.
A producer adds an optional field to an event used by two consumers. Record what existing readers expect and what the new field means. Evaluate compatibility in the exact tooling and policy you study rather than assuming every change has the same effect.
Practice task: Compare an older event, a newer event and a missing-field example. Expected result: The consumer contract defines acceptable handling for each. Common mistake to avoid: Changing a required field without assessing existing consumers.
A fictional dashboard updates late. Compare production time, availability of records and consumer progress before blaming one component. The visible delay may involve processing rate, a stopped consumer or a downstream dependency. Define the affected scope and compare a working path.
Practice task: Write three observations that distinguish missing records from delayed processing. Expected result: The next investigation narrows a specific uncertain stage. Common mistake to avoid: Declaring the cluster slow from the final dashboard symptom alone.
Map the producer, broker dependencies, consumer and destination. Introduce one unavailable component and describe what should continue or stop. Configuration presence is different from demonstrated resilience. Keep the scope of the exercise and the exact platform release in its result record.
Practice task: Compare a normal flow with a single-dependency failure. Expected result: The expected recovery behaviour and validation evidence are stated. Common mistake to avoid: Calling the complete service resilient because one component is redundant.
Complete these activities as written exercises or in an authorised practice environment with fictional data. Define the expected outcome before starting and save a brief explanation of what the result establishes. Verify version-specific steps for your selected technology.
| Activity | What to do | Expected result |
|---|---|---|
| Give an event a clear meaning | Write accepted-order and cancelled-order examples with explicit identifiers. | Each record has a business interpretation another component can use. |
| Use a key to explain an ordering requirement | Arrange events for two orders and mark the ordering requirement within each. | The scope of the ordering assumption is explicit. |
| Trace consumer progress alongside the business action | Draw receive, validate, apply and record-progress stages with a failure between them. | The note identifies possible repeated or incomplete work. |
| Design duplicate handling around identity | Process the same identifier twice in a written example. | One logical order produces the intended single business effect. |
Use these comparisons to find an assumption worth revisiting. For each mistake, write a new example with different details and explain why the corrected principle still applies.
| Common mistake | Why it matters | Better approach |
|---|---|---|
| Changing a required field without assessing existing consumers. | This prevents the exercise from establishing its intended outcome. | The consumer contract defines acceptable handling for each. |
| Declaring the cluster slow from the final dashboard symptom alone. | This prevents the exercise from establishing its intended outcome. | The next investigation narrows a specific uncertain stage. |
| Calling the complete service resilient because one component is redundant. | This prevents the exercise from establishing its intended outcome. | The expected recovery behaviour and validation evidence are stated. |
Explanation: Only if the requirement treats it as a distinct business order. For a repeated event with the same order identity, the design should recognise the prior effect and preserve the intended single outcome. Compare event identity, processing evidence and the downstream action before repeating uncertain work.
Write your own answer before reading the explanation. Identify the evidence supporting it, then change one detail and decide whether your answer should change. This is an original learning exercise, not an actual exam question.
| Stage | Focus | Practice outcome |
|---|---|---|
| Week 1 | Select the target and foundations | Write accepted-order and cancelled-order examples with explicit identifiers. Each record has a business interpretation another component can use. |
| Week 2 | Apply core concepts | Arrange events for two orders and mark the ordering requirement within each. The scope of the ordering assumption is explicit. |
| Week 3 | Investigate weak topics | Draw receive, validate, apply and record-progress stages with a failure between them. The note identifies possible repeated or incomplete work. |
| Week 4 | Review mixed examples | Process the same identifier twice in a written example. One logical order produces the intended single business effect. |
Four weeks is an example schedule, not a promise of readiness. Adjust each stage to your experience and available time. Extend a stage when you cannot explain the topic without the notes or apply it to a fresh scenario. Revisit the exact target objectives so a familiar topic does not replace a relevant topic you have not practised.
Create a tracker with target topic, initial explanation, practice activity, observed result and next review date. Separate a topic you recognise from a topic you can apply. A useful record makes the remaining gap visible and helps you choose the next activity instead of repeatedly rereading the same material.
When an answer is wrong, preserve the initial assumption, the contradicting evidence and the corrected principle. Create a second example using different details. If the explanation works only for the first example, return to the concept before adding more resources. Review recurring errors together: they may reveal a missing foundation rather than several unrelated weaknesses.
| Tracker field | Example entry to write | Review question |
|---|---|---|
| Requirement | Write accepted-order and cancelled-order examples with explicit identifiers. | What outcome am I trying to establish? |
| Evidence | Each record has a business interpretation another component can use. | Which observation supports my explanation? |
| Limitation | State what the exercise did not establish. | Am I making a broader claim than the evidence allows? |
| Next activity | Arrange events for two orders and mark the ordering requirement within each. | What new example will test the principle? |
Email freelearning@ciscoforall.com with your exam code and name, the product or framework version if known, and the topics you need. We will send an available older reference file free of charge. Availability varies; a file may not be available for every target. The original notes, tables and exercises on this page are free to read without requesting a file.
Keep the code and version visible when using an older reference. Terminology, objectives and product behaviour may differ from your current target. Compare the material with the scope you intend to study and verify release-specific information before using it in a lab. We share only resources we are permitted to distribute. If you are unsure of the target name, include the learning goal so the request can be understood.
Use this guide to organise foundations and identify weaker topics. Then choose a relevant Confluent Premium PDF for additional review. Give the resource a clear purpose: explain a concept, compare alternatives or repeat a practical scenario. Track the exact target and version alongside your notes so useful older material is not mistaken for complete current coverage.
Build a preparation routine around topic review, original exercises and an error log. After reviewing a resource, close it and explain the principle in your own words. Apply that principle to an unfamiliar example and record any remaining uncertainty. The value comes from understanding and application, rather than the number of files collected.
Review CCAAK for the product and version shown in the listing. — Premium PDF · Review CCDAK for the product and version shown in the listing. — Premium PDF
Browse All Confluent Premium PDFs
Yes. The learning notes, tables, study plan and original exercises here are free to read. Premium PDFs are available separately through the linked product pages.
Choose developer-oriented study for event contracts, application processing and streaming behaviour. Choose administrator-oriented study for cluster operation, configuration and service dependencies. The two resources address different preparation goals.
Yes. Email freelearning@ciscoforall.com with your name, exact target and exam code. We will send an available older reference file free of charge. Availability varies.
It may explain useful foundations while describing an earlier version. Compare its code, objectives and product behaviour with your exact target before treating it as a complete preparation resource.
Use the product table to find a resource matching your target. Explore its details and version, then connect it with the concept or practice gap you want to strengthen.
No. Adjust the schedule to your experience, available time and practice results. Repeat a stage until you can explain its concepts and apply them to a different example.
No. The scenarios are original exercises for understanding and decision-making. They are designed to help you practise explanations and evidence-based reasoning.
No. Results depend on your knowledge, practical skills and preparation.
Complete one small activity today and record its result. For an available older reference, email freelearning@ciscoforall.com. For additional preparation, choose a relevant Premium PDF above or browse the vendor selection below.