Career · 2026-10-25

Should You Put Configuration Screenshots on GitHub?

Put configuration screenshots in an IAM portfolio when they support a specific claim.

A setting can help explain how access was configured. A test result can help show what happened. Ten uncaptained administration screens usually make the reader reconstruct the argument for you.

Choose the evidence first, then the image. Keep the page understandable without requiring someone to open every attachment or guess which part of a screenshot matters.

Show the setting that explains the result

Suppose your fictional lab grants a project group access to a shared resource.

Useful evidence might include the relevant permission entry, the test user's membership, and the result from the user session. You don't need an image of every installation screen that preceded those steps.

Write a caption stating what the image establishes.

“Project group has read access to the sample folder” is more helpful than “Screenshot 4.” The caption should not claim more than the image actually shows.

Keep configuration and validation distinct

A configuration screenshot shows what was set at that moment. It doesn't necessarily prove the intended user could complete the task.

Pair important settings with a test result and enough context to understand the test. Identify the fictional user, action, expected result, and observed result.

For a denied-access case, make clear that denial was expected. Otherwise, a reader may mistake a successful negative test for an unfinished lab.

This distinction helps your portfolio demonstrate behavior rather than merely document that you found the correct page in an admin console.

Use a fictional environment and inspect the whole frame

Don't publish employer administration screens because the names have been blurred in one corner.

Use synthetic users and a lab you are authorized to share. Inspect the browser tabs, address bar, side panels, terminal output, and any visible notifications. Sensitive context can appear outside the area you intended to capture.

Avoid publishing credentials, tokens, private keys, personal data, or confidential organizational details.

Crop for clarity, but don't crop away information that changes the meaning of the result. Privacy and evidentiary honesty both matter.

Treat repository history as part of the exposure

Deleting a secret from the current file is not the same as making an exposed credential safe.

GitHub's guidance on removing sensitive data begins with revoking or rotating exposed secrets where applicable, then addressing repository cleanup and other copies.

Also, an ignore rule is not a retroactive eraser for material already tracked. GitHub explains that distinction in its ignoring files documentation.

The better portfolio workflow is to review material before the first commit, not depend on cleanup after publication.

Make the page understandable without opening every image

Put the problem, diagram, and main result in readable text near the top.

Use screenshots as supporting evidence, not as the only explanation. Add descriptive filenames and captions, and make the important result legible at a reasonable display size.

A reader should be able to skim the page and understand what you demonstrated. They can inspect the images for detail afterward.

For the larger structure, use a README that separates the requirement, setup, tests, and limitations.

Review each image for usefulness and exposure before sharing

Open the page as someone who has never seen the lab.

Check:

Remove an image if it adds exposure without helping understanding. More screenshots do not automatically mean stronger evidence.

The Six-Figure IAM Career Playbook connects three IAM projects with portfolio documentation and career positioning. The $9 guide helps you decide what the work should prove before collecting images.

A small set of well-explained evidence is easier to evaluate than a gallery of unexplained settings.

Originally published on CyberAndChill.

← All articles