Question 1

If you notice frequent collisions between two teams’ changes in the same module but different environments, what environment-based best practice could mitigate these collisions?

Options :

A : Force all changes into a single environment to avoid branching errors

B : Disable version control merges for that module, forcing local manual updates

C : Rely on puppet-lint to unify both teams’ changes automatically

D : Each team uses a dedicated dev environment or feature branch for changes, merging them only after they’re tested, preventing direct collisions on the main environment

Answer: D

Question 2

You see a module on Puppet Forge with a high “quality score” but contradictory user comments mentioning unaddressed bugs. How do you reconcile this discrepancy before deciding to adopt the module?

Options :

A : Investigate the bug reports, check the module’s issue tracker or repo commits for resolution attempts

B : Assume the user comments refer to an old version, and the quality score indicates it’s now fixed

C : Trust the quality score completely because user comments lack official review

D : Avoid the module entirely, because any negative comments mean it’s unsafe

Answer: A

Question 3

A newly published module has a tests/ directory with example usage files. You notice they lack any references to your environment or Hiera data. How should you leverage those .pp test files effectively?

Options :

A : Merge all test code into the module’s init.pp so it runs automatically in every puppet run

B : Run them locally as demonstration scenarios, adjusting them to reflect your environment or Hiera references

C : Delete the tests/ directory to avoid confusion with production code

D : Immediately deploy them in production without modification, as test manifests are always safe

Answer: B

Question 4

How might you securely tune Puppet’s configuration to handle multiple agent runs from an SSL standpoint?

Options :

A : Using certificate revocation lists, ensuring only valid agent certs are trusted

B : Disabling SSL entirely to simplify the handshake

C : Relying on environment merges that unify node keys

D : Storing agent keys in a public Git repository for easy distribution

Answer: A

Question 5

A developer attempts to create a Bolt plan that applies certain puppet agent runs on Windows nodes, but relies on direct scripts for Linux nodes. This partial approach works except Windows nodes sometimes fail with “Unable to connect to master.” They suspect concurrency saturates the master. How might they gracefully handle partial concurrency for Windows agent runs while letting Linux scripts run in parallel?

Options :

A : Switch all nodes to direct script tasks, ignoring agent-based runs

B : Lock concurrency to 1 for all nodes so the puppet master never saturates

C : Merge environment concurrency data in puppet.conf to unify Windows and Linux concurrency automatically

D : Use concurrency or batch settings specifically for Windows nodes in the orchestrator plan, while continuing full parallel execution for Linux script tasks

Answer: D

Free Puppet-Certified-Professional Mock Exam – Practice Online Confidently

Buying Options: