← Back to all posts
Build in Public

AWS AI Practitioner — Day 12: Project Polish

Learn: documentation and reproducibility make your project useful for others and exam evidence.

Hands-on: ensure README has steps to reproduce the dataset, training, and deployment in one hour (<1 hour).

Practice question:

Q1: What belongs in a reproducible project README?

A) Steps to provision resources, run training, and run tests B) Only architecture diagrams with no commands C) Encrypted credentials D) Irrelevant notes

Answer: A — include clear commands and steps for provisioning and testing.

Daily Practice Questions (new)

Q1: What should a reproducible README include?

A) Commands to provision, train, and test B) Only marketing copy C) Secrets in plaintext D) Unrelated screenshots

Answer: A — include clear commands so others can reproduce results.

Q2: How do you verify README steps?

A) Follow them on a fresh environment or separate account B) Assume they work C) Only read them superficially D) Share them on social media

Answer: A — testing on a fresh environment ensures reproducibility.

Q3: What CI check complements a README?

A) A script that runs smoke tests from README steps B) A social media post C) A manual screenshot only D) No checks needed

Answer: A — automated smoke tests validate the README steps.

Q4: How to document resource names consistently?

A) Use consistent naming conventions in README B) Use random names each time C) Omit names entirely D) Use names with secrets

Answer: A — consistent naming simplifies reuse and automation.

Q5: What should data preparation docs include?

A) Commands and expected outputs B) Only data sizes C) Only environment variables D) Only binary files

Answer: A — show steps and what outputs to expect.

Q6: How should costs be noted in README?

A) Approximate instance types and durations B) Exact final bill projections only C) No cost info D) Plaintext secrets

Answer: A — provide rough cost guidance to avoid surprises.

Q7: How should secrets be handled in README?

A) Never include plaintext credentials B) Paste keys directly C) Share passwords publicly D) Store in repo root

Answer: A — never expose secrets in documentation.

Q8: What is a reproducibility checklist?

A) Steps confirming dataset, training, deployment, and tests B) A list of random commands C) A list of users D) A billing sheet

Answer: A — checklist ensures all reproducible steps are covered.

Q9: How to test reproducibility in CI?

A) Use ephemeral resources and teardown scripts B) Use persistent long-lived test infra only C) Run tests manually only D) Skip teardown

Answer: A — ephemeral infra avoids cross-test contamination and cost overruns.

Q10: How to version the project?

A) Tag releases and reference tags in README B) Use random commit messages only C) Avoid versioning D) Store versions in S3 only

Answer: A — tags help identify reproducible snapshots.

Review Questions (previous lessons)

Q1: What is a smoke test in the context of reproducibility?

A) Quick verification of endpoint or pipeline steps B) Full performance load test C) Billing reconciliation D) DNS update

Answer: A — smoke tests check key steps quickly.

Q2: How do you ensure reproducibility of experiments?

A) Save seeds, run IDs, and artifacts B) Never log anything C) Use undocumented steps D) Randomize all inputs

Answer: A — recorded metadata enables exact reruns.

Q3: What supports reliable deployments?

A) Infrastructure-as-Code templates and versioned artifacts B) Manual one-off scripts only C) Random file names D) No version control

Answer: A — IaC and artifacts make deployments repeatable.

Q4: Why document approximate costs in README?

A) For predictability and budget control B) To obscure costs C) To delay runs D) To ignore billing

Answer: A — cost guidance avoids surprises.

Q5: How should secrets be represented in README examples?

A) Use placeholders and store real secrets in CI secrets stores B) Paste secrets directly C) Share keys publicly D) Use plaintext in repo

Answer: A — placeholders and secure secret storage keep credentials safe.

Q6: What is a teardown step for reproducibility tests?

A) A script that deletes provisioned resources to avoid leftover costs B) A manual cleanup only after a week C) Never deleting anything D) Deleting random resources

Answer: A — teardown scripts clean up ephemeral infra.

Q7: How to validate outputs in reproducible runs?

A) Automated tests comparing outputs to expected results B) Manual eyeballing only C) Don’t validate at all D) Rely on logs only

Answer: A — automated checks ensure correctness.

Q8: Which file is a typical model artifact for SageMaker?

A) model.tar.gz stored in S3 B) index.html C) package.json D) README.md

Answer: A — model.tar.gz is the standard artifact package.

Q9: Why parameterize commands in reproducible instructions?

A) To allow easy reruns with different settings B) To hardcode paths only C) To avoid reuse D) To increase complexity

Answer: A — parameters make instructions flexible for different runs.

Q10: How do you track project versions for reproducibility?

A) Use git tags and release notes B) Use random commit messages only C) No versioning D) Store versions in S3 only

Answer: A — tags and releases identify exact snapshots.