# Design software for a cloud native environment

Taiga Learning · Worksheet
https://taiga.training/en/lessons/cloud-native/

Use fictional or approved information. Do not put secrets in this worksheet.

## Learning objectives
- Distinguish container packaging from cloud native behavior.
- Identify state, retry, and replacement risks in a generated service.
- Define a platform contract that agents and people can verify.

## Exercise
A fictional report service stores jobs and completed files on its container disk. Draw the flow through request, job, file, and download. Mark durable state. Define what happens if the worker stops after writing a file but before confirming the job.

## Your response
- Scenario and scope:
- Assumptions and open questions:
- Proposed answer or decision, with reasons:

## Verify your response
| Claim or criterion | Evidence or test | Result or gap | Owner |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Next action
- Action, owner, and date:
- When will you review this response?

## Principle to retain
Cloud native design makes change and operation repeatable. A container image alone does not establish that behavior.

## Sources
- [CNCF: Cloud Native Definition v1.1](https://github.com/cncf/toc/blob/main/DEFINITION.md)
- [Kubernetes: Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
- [AWS Builders’ Library: Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

This worksheet supports learning. Completing it does not itself authorize a production change.
