DevOps Interview KB Review: Timed Mocks, Self-Scoring, and Question Filters

DevOps Interview KB offers a public timed rehearsal with explicit self-scoring and links to fuller explanations. Use it to preserve an unaided explanation before revealing the answer. The main boundary is evaluation: a countdown and a self-selected rating do not establish that an independent interviewer has checked your reasoning or that you are ready for a particular level.

PracHub publishes this review and owns the complementary practice links. Our Linux host and filesystem question offers another place to test the assumptions behind a permission diagnosis. The path-access model and junior-to-staff comparison below are original exercises, separate from DevOps Interview KB’s scoring.

Confirm the product and the evaluation method

The reviewed domain is devopsinterviewkb.com. Its linked public GitHub repository describes a Git-driven DevOps knowledge base. We verified that identity and the repository destination, without auditing every question or reproducing the application from source.

Direct observation, November 3, 2026: Interview Mode exposed level, type, difficulty, category, question-count and timing controls. The default interface reported 600 matches; we did not independently count unique items. Junior plus Linux plus Troubleshooting returned none. Removing the type condition returned one question.

When configuring a session, check the filtered intersection rather than relying on the headline count. An empty result says that the selected combination has no match in the current interface. It does not establish that the broader category is empty or that the learner has exhausted the subject.

Our assessment: start with the decision you want to practise, then inspect the resulting pool. If the intersection is too small, loosen one condition deliberately and record what changed. Do not treat a longer session setting as a guarantee of distinct, relevant questions.

What we observed in the reveal flow

With five requested but one matching question, the sample session used one. It displayed a 7:30 countdown initially and 7:08 when we revealed the answer. We did not calibrate timer accuracy. Three manual rating buttons appeared. We ended early without choosing one; results showed zero answered and zero of zero points, alongside zero percent.

That result is an unscored interface probe, not a measured ability score. Read the denominator before interpreting the percentage: no rated answers cannot establish that the learner knows none of the material. We did not complete a graded timed mock or test AI evaluation.

In your own rehearsal, preserve the answer you produced before the reveal. Compare it with the explanation and note a concrete omission. A self-rating becomes more useful when it has a reason attached: for example, “decoded the file bits, but missed parent-directory search permission.”

The same rating can otherwise conceal different gaps. A candidate may remember a definition but fail to apply it, or identify a failure but propose an unnecessarily broad fix. Those need different practice, even if both attempts receive the same manual label.

The linked full explanation adds useful follow-ups

The sampled question concerned numeric file modes. Its full explanation goes beyond the short answer: it explains owner, group and other permissions and includes follow-ups about directory execute permission, special bits and umask. It also links Linux references.

Use the short answer and follow-up for different checks. Answer from memory, reveal the short version, then use a follow-up to test application. We did not assess every full explanation or establish that every question has the same depth.

For ordinary permission bits, the numeric representation follows read, write and execute values. The chmod manual explains how octal digits represent these permissions. Knowing the digits is a beginning; the operation, actor and path determine which bits matter.

For example, reading a known configuration file is different from executing it. A service does not need the execute bit on a data file simply because it uses the file. Directory search permission is a separate requirement during path resolution.

Original counterexample: the readable file is still unreachable

Consider an invented deployment. A service is a member of the group assigned to both a configuration file and its immediate parent directory. It owns neither object, has no special privileges, and all earlier parent directories are searchable. We deliberately restrict the model to traditional mode bits.

The file has mode 0640, giving its group read permission. Initially, its parent directory has mode 0740. The group bits on that directory are read-only, without search permission. The service therefore cannot open the known file through that directory under our model.

The Linux path-resolution manual explains the directory-search requirement and the permission-denied outcome when it is missing. File readability alone cannot bypass that earlier step in the pathname.

Our original comparison keeps the requested operation fixed and changes one condition:

The second row grants directory search without granting the group directory-read permission. It illustrates access to an already-known path under the stated assumptions; it is not a claim that every directory operation will succeed.

A small local bit model checked all three outcomes and the two parent group-bit values. The checks passed. It did not perform a Linux access test or evaluate ACLs, capabilities, security modules, namespaces, symlinks or mount behavior. It also did not execute any operation on a production service.

The counterexample exposes the missing condition in an answer such as “the config is readable, so permissions are fine.” A better explanation identifies the process identity, selects the applicable permission class and walks the path before proposing a change.

Avoid turning the successful model row into a universal deployment fix. A real service may run under a different user or group, use a different mount or require another path. Validate the intended access policy before deciding which permission should change.

A junior-to-staff rubric for the same symptom

The product’s level labels help organize a session. They do not establish an employer’s leveling standard. The following is our original preparation rubric for deepening the same permission-denied case, not a description of how the site assigns levels.

Deepen the explanation by connecting the symptom to deployment and ownership decisions. It needs a clearer account of how a local symptom relates to the system’s deployment and ownership rules. A staff discussion might ask why the artifact was created under the wrong group and how the pipeline should enforce the intended contract.

Another follow-up asks what could make the bit model misleading. An ACL may provide additional rules. A process may have privileges outside the model. A container may see a different filesystem view. Name the relevant uncertainty and explain how you would check it rather than claiming the mode table resolves every case.

This rubric also makes self-scoring more precise. If you decoded 0640 correctly but never examined the parent, your next practice is path reasoning. If you found the failing permission but proposed broad access for everyone, your next practice is policy and change scope. Those are different weaknesses.

Give the reveal step a purpose within the time budget

A timer creates a constraint, but the site cannot make a self-rating objective. Decide what a complete answer should contain before starting: an observation, an assumption, a next check and a way to verify the result.

Here is an original answer-reveal map for the permission case. It is a suggested practice method, not the application’s timer algorithm or an observed employer schedule.

If you are stuck, state a bounded hypothesis and the next observation you need. Reading the answer can then resolve a named gap. Revealing immediately without making an attempt may be appropriate for initial study, but it should not be recorded as successful unaided recall.

You can separate study from rehearsal across two attempts. On the first, read the detailed explanation and annotate the unknowns. On the next, close it and solve a changed version. Changing the parent or file mode in this example checks understanding more directly than repeating the same remembered sentence.

Job-specific context introduces a separate claim

The job-specific configuration displayed resume and job-description inputs and claimed that the material stays in the browser. We viewed the form without entering text or uploading a file. We did not audit network behavior, storage or the skill-extraction process, so the local-processing statement remains a provider claim.

Before using that mode, inspect the extracted requirements and compare them with the actual role. Check whether the selected questions cover the role’s important decisions, beyond matching keywords. A resume claim should also remain within the work you can demonstrate.

For an initial check, use public or synthetic context you are authorized to share. Then ask whether the resulting practice exposes a particular gap. We did not test personalization quality, private data handling, paid allowances or learning outcomes.

Practice the gaps the product leaves open

Use these complementary PracHub prompts to practise the permission and diagnostic reasoning around the sampled question. They are separate from DevOps Interview KB’s bank and self-ratings.

Who should use DevOps Interview KB next

Use it for structured recall, a visible time constraint and a deliberate comparison with fuller explanations. Keep its self-scoring boundary visible and inspect the actual filtered pool. We cannot recommend it as independently validated grading or as a prediction of a hiring result.

For the next attempt, take the Linux host and filesystem question, explain the three mode combinations and name the assumptions that make the model valid. Reveal an explanation only after preserving your own answer. Record the missing mechanism and practise a changed case before raising your self-rating.

Sources and Further Reading

• DevOps Interview KB Interview Mode
• DevOps Interview KB public repository
• The inspected chmod explanation
• chmod manual: symbolic and numeric modes
• Linux path resolution and directory search permissions