I85PREP
⌘ K
DevOps Engineering study materials
DevOps Engineering study resources

DevOps Engineering practice questions

One question at a time. Build your DevOps Engineering understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Continuous Integration and Continuous Delivery (CI/CD) Pipelines

In a CI pipeline, which practice gives the fastest and most reliable signal that a pull request has broken the build?

  1. Requiring two manual approvals before any automated test runs
  2. Running the full nightly regression suite only after merge
  3. Deploying the branch to production to observe real user behavior
  4. Running a fast subset of unit and lint checks on every pull request commit Correct answer.

Explanation

Fast feedback on every change is the core purpose of continuous integration. A short, high-value check set (compile, lint, unit tests) on each pull request commit catches breakage within minutes, before it reaches the main branch.

Question 2Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A team wants a pipeline stage that fails the build when a known-vulnerable dependency version is detected. Which pipeline element implements this?

  1. A canary traffic shift
  2. A code coverage threshold gate
  3. A software composition analysis scan in the build stage Correct answer.
  4. A post-deploy smoke test

Explanation

Software composition analysis inspects declared and transitive dependencies against vulnerability databases and can fail the build on policy violations. Coverage gates, smoke tests, and traffic shifts address different risks.

Question 3Continuous Integration and Continuous Delivery (CI/CD) Pipelines

Which artifact repository behavior best supports reproducible builds?

  1. Overwriting existing version coordinates when a rebuild occurs
  2. Storing only the latest snapshot of each branch
  3. Deleting artifacts older than seven days to save storage
  4. Making immutable, uniquely versioned artifacts retrievable by exact coordinate Correct answer.

Explanation

Reproducibility requires that a given version coordinate always resolves to the same bytes. Immutable, uniquely versioned artifacts let any pipeline rerun fetch exactly what was tested and released.

Question 4Continuous Integration and Continuous Delivery (CI/CD) Pipelines

What is the primary purpose of a build cache keyed on a lockfile hash in a CI pipeline?

  1. To reuse previously downloaded dependencies when the lockfile is unchanged Correct answer.
  2. To encrypt secrets used during the build
  3. To enforce branch protection rules
  4. To guarantee that tests run in parallel

Explanation

A cache key derived from the dependency lockfile changes only when dependencies change, so unchanged builds restore packages instead of re-downloading them. This shortens pipeline duration without affecting correctness.

Question 5Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A deployment strategy routes a small percentage of live traffic to a new version while monitoring error rates, then progressively increases traffic. What is this called?

  1. Rolling restart
  2. Feature flagging
  3. Canary release Correct answer.
  4. Blue-green deployment

Explanation

A canary release exposes the new version to a small slice of real traffic and expands exposure only while metrics stay healthy. This limits blast radius compared with a full cutover.

Question 6Continuous Integration and Continuous Delivery (CI/CD) Pipelines

Which statement describes the role of a pipeline as code file stored in the repository?

  1. It defines build, test, and deploy steps under version control with the application source. Correct answer.
  2. It replaces the need for automated tests.
  3. It is generated at runtime by the deployment target.
  4. It is only editable by the release manager in a separate tool.

Explanation

Pipeline as code keeps the CI/CD definition in the same repository as the application, so changes are reviewed, versioned, and rolled back like any other code. This removes configuration drift from manual UI edits.

Question 7Continuous Integration and Continuous Delivery (CI/CD) Pipelines

What does the DORA metric 'lead time for changes' measure in a delivery pipeline?

  1. The duration of the longest automated test
  2. The number of deployments performed per quarter
  3. The time a reviewer spends reading a pull request
  4. The time from code commit to that code running in production Correct answer.

Explanation

Lead time for changes tracks elapsed time from a commit landing to it being live in production. It captures the end-to-end efficiency of the delivery pipeline rather than any single stage.

Question 8Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline needs to run integration tests against a disposable database that is destroyed afterward. Which approach fits this requirement?

  1. Point tests at the shared staging database used by QA
  2. Run the tests only on the developer's laptop
  3. Provision an ephemeral database container per pipeline run and tear it down on completion Correct answer.
  4. Commit a database dump and reuse it across all runs without cleanup

Explanation

Ephemeral, per-run databases isolate test state so runs cannot interfere with each other or with shared environments. Tearing the resource down after the run keeps the pipeline repeatable and free of accumulated drift.

Question 9Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline builds a container image tagged only with 'latest'. Which change most improves traceability from a running deployment back to source?

  1. Enable verbose logging on the registry
  2. Push the image to multiple registries
  3. Tag each image with the immutable commit SHA as well as any human-readable tag Correct answer.
  4. Increase the number of build agents

Explanation

Tagging with the commit SHA creates a durable, unique link between a running image and the exact source revision that produced it. Mutable tags such as latest can be reassigned and cannot identify a specific build.

Question 10Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A deployment must be automatically rolled back when the post-deploy error rate exceeds a threshold. Which pipeline design achieves this?

  1. Add an automated health-check gate that triggers rollback on threshold breach Correct answer.
  2. Disable alerting during the deployment window
  3. Require a manual approval after every deployment
  4. Run the full unit test suite a second time after deployment

Explanation

An automated gate evaluates live health metrics after the deploy and initiates rollback when they breach the threshold, limiting user impact. Manual approval and repeated unit tests do not react to production error rates.

Question 11Continuous Integration and Continuous Delivery (CI/CD) Pipelines

Two pipeline jobs both write to the same deployment environment and can run concurrently. What is the most direct way to prevent interleaved deployments?

  1. Increase the timeout on both jobs
  2. Merge the two jobs into a single job with no ordering
  3. Add a concurrency lock or resource group so only one job holds the environment at a time Correct answer.
  4. Run both jobs on the same runner machine

Explanation

A concurrency lock (often called a resource group or environment lock) serializes jobs that target the same environment. This prevents two deployments from mutating shared state simultaneously.

Question 12Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A team wants to fail the pipeline when new code drops overall test coverage below the current baseline. Which gate configuration is appropriate?

  1. A fixed 100 percent coverage requirement on all files
  2. A gate that only measures coverage on files changed in the last year
  3. A threshold set to the existing coverage level with a small allowed tolerance Correct answer.
  4. No coverage gate, relying on code review instead

Explanation

Setting the gate at the current baseline with a small tolerance prevents regression without demanding an unrealistic jump. It keeps the check meaningful and achievable for the team.

Question 13Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline stores a cloud access key as a plain environment variable visible in job logs. What is the best remediation?

  1. Shorten the variable name so it is harder to find in logs
  2. Move the key into a masked secret store injected at runtime and rotate the exposed key Correct answer.
  3. Encode the key in base64 inside the pipeline file
  4. Restrict log access to senior engineers only

Explanation

Secrets should live in a dedicated secret store, be injected only when needed, and be masked in logs. Because the key was already exposed, rotating it is mandatory to invalidate the leaked credential.

Question 14Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A monorepo pipeline currently rebuilds every service on each commit. Which technique reduces wasted work while preserving correctness?

  1. Delete the pipeline cache to force consistency
  2. Run all builds nightly instead of per commit
  3. Rebuild everything but skip tests for unchanged services
  4. Use change detection to build and test only services affected by the commit Correct answer.

Explanation

Change detection maps modified paths to the services that depend on them, so only affected services are built and tested. This keeps per-commit feedback fast without skipping verification of changed code.

Question 15Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline uses a matrix to test a library across three language versions and two operating systems. How many job instances does the matrix produce?

  1. 3
  2. 2
  3. 6 Correct answer.
  4. 5

Explanation

A matrix runs the cross product of its dimensions, so three language versions times two operating systems yields six job instances. Each combination runs independently and reports its own result.

Question 16Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A release pipeline must promote the exact same artifact from staging to production. Which practice enforces this?

  1. Rebuilding from source in the production pipeline
  2. Allowing each environment to build its own image from the branch
  3. Copying source files to production and compiling there
  4. Promoting the immutable artifact built once and stored in the registry Correct answer.

Explanation

Building once and promoting the identical immutable artifact ensures that what was validated in staging is exactly what runs in production. Rebuilding introduces the risk that dependencies or toolchains differ between environments.

Question 17Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline stage intermittently fails due to a flaky integration test that passes on retry. What is the sound engineering response?

  1. Configure automatic retries and never investigate the test
  2. Quarantine the flaky test, fix the root cause, and track flakiness as a defect Correct answer.
  3. Increase the overall pipeline timeout
  4. Delete the test to keep the pipeline green

Explanation

Flaky tests erode trust in the pipeline, so they should be isolated from the blocking path while the underlying nondeterminism is fixed. Tracking flakiness as a defect ensures the temporary quarantine does not become permanent.

Question 18Continuous Integration and Continuous Delivery (CI/CD) Pipelines

An organization wants deployment approval recorded as part of the pipeline rather than in a separate ticketing tool. Which pipeline feature provides this?

  1. A manual approval gate with an audited approver identity in the pipeline run Correct answer.
  2. A longer build timeout
  3. A README checklist in the repository
  4. A branch naming convention

Explanation

A manual approval gate pauses the run until an authorized identity approves, and the pipeline records who approved and when. This produces a durable audit trail tied to the specific deployment.

Question 19Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline runs database migrations before deploying new application code. Which ordering risk must be addressed for zero-downtime releases?

  1. Migrations must drop all old columns immediately
  2. Migrations should be applied manually by a DBA during business hours
  3. Migrations must be backward compatible so old and new code can run simultaneously Correct answer.
  4. Migrations must always run after all old instances are terminated

Explanation

During a rolling or blue-green release, old and new application versions run concurrently against one schema. Backward-compatible, expand-and-contract migrations keep both versions working until the transition completes.

Question 20Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline caches a directory keyed only by branch name. What correctness problem can this cause?

  1. Branch names are too long for cache keys
  2. Caching by branch disables test parallelism
  3. Stale cached dependencies may be reused after the lockfile changes, producing builds that differ from a clean build Correct answer.
  4. The cache will always be empty

Explanation

A branch-only key does not change when dependencies change, so an outdated cache can be restored and mask a required update. Including the lockfile hash in the key invalidates the cache exactly when dependencies change.

Question 21Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A team wants to detect that a deployment is degrading the service within minutes and automatically revert. Which combination is required?

  1. Feature flags plus a longer soak test
  2. Full cutover plus a weekly review meeting
  3. Blue-green switch plus manual rollback instructions
  4. Canary traffic plus automated metric analysis with rollback automation Correct answer.

Explanation

Automatic detection and revert require both a limited-exposure rollout and automated analysis of health metrics wired to a rollback action. The canary limits impact while the analysis supplies the trigger.

Question 22Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline signs artifacts with a key stored on the shared build agent's filesystem. Why is this insufficient for supply-chain integrity?

  1. Signing is unnecessary if the artifact is versioned
  2. Artifacts cannot be signed in CI pipelines
  3. Signing keys must be longer than 256 bits to work
  4. Any job on that agent can read the key and sign arbitrary artifacts Correct answer.

Explanation

A signing key readable by any job on a shared agent can be used to sign malicious or unauthorized artifacts, undermining provenance. Keys should live in a dedicated, access-controlled signing service or hardware module.

Question 23Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline uses a fan-out/fan-in pattern where parallel test shards feed a single reporting job. What must the reporting job handle to avoid false success?

  1. It must re-run every test serially to confirm
  2. It must aggregate shard results and fail if any shard failed or was skipped Correct answer.
  3. It must run only after all shards are cancelled
  4. It must ignore shard exit codes and rely on log text

Explanation

A fan-in job must collect each shard's outcome and treat any failure or missing result as a failure of the aggregate. Otherwise a failed or skipped shard can be silently dropped and the pipeline reports success incorrectly.

Question 24Continuous Integration and Continuous Delivery (CI/CD) Pipelines

An organization wants to enforce that no commit reaches production without passing security scanning, even if a developer edits the pipeline file. Which control provides the strongest guarantee?

  1. A scheduled weekly scan of the main branch
  2. A warning comment in the pipeline file
  3. Organization-level required status checks and protected branch rules that cannot be bypassed by contributors Correct answer.
  4. A convention documented in the onboarding guide

Explanation

Required status checks enforced at the repository or organization level run independently of the contributor's pipeline edits and block merges until they pass. This makes the security gate non-bypassable by ordinary contributors.

Question 25Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A CI pipeline builds a Java service and a Go service from separate repositories that must be released together. Which design keeps their versions consistent?

  1. Use a release train or manifest that pins both artifact versions and promotes them together Correct answer.
  2. Release each service independently with no coordination
  3. Let each team pick a version at deploy time
  4. Tag both with 'latest' so they always match

Explanation

A release manifest or train records the exact versions of both artifacts and promotes them as a unit, so the deployed pair is always the tested combination. Independent or ad hoc versioning allows incompatible pairs to reach production.

Question 26Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline configuration defines the same build steps in three separate jobs. Which change best reduces long-term maintenance while keeping the jobs independent?

  1. Merge the three jobs into one so the steps exist in only one place
  2. Move the steps into a shell script stored on the build agent's home directory
  3. Copy the steps into a fourth job and have the other three call it through the API
  4. Extract the shared steps into a reusable template or included component referenced by each job Correct answer.

Explanation

Reusable templates, anchors, or included pipeline components let a single definition be referenced by many jobs, so a fix propagates everywhere while each job keeps its own identity and parallelism. Storing the logic outside version control or collapsing independent jobs sacrifices traceability and isolation.

Question 27Continuous Integration and Continuous Delivery (CI/CD) Pipelines

Which statement describes the purpose of a pipeline stage that runs only static analysis and linting, placed before the build stage?

  1. It provides fast feedback on code quality so cheap failures surface before expensive build and test work Correct answer.
  2. It guarantees the produced artifact is free of runtime defects
  3. It ensures the deployment environment matches production configuration
  4. It replaces the need for unit tests in the later stages

Explanation

Early, cheap checks such as linting and static analysis fail quickly and stop the pipeline before slower stages consume compute. They cannot prove runtime correctness or substitute for tests, and they say nothing about environment parity.

Question 28Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A team wants every pull request to show the pipeline result before merge is allowed. Which configuration achieves this?

  1. Allow merges first and run the pipeline on the main branch afterward
  2. Enable a required status check on the protected branch tied to the pipeline job Correct answer.
  3. Schedule the pipeline nightly and email results to reviewers
  4. Require reviewers to manually confirm they watched the pipeline run

Explanation

Branch protection with required status checks blocks merging until the named pipeline job reports success, making the gate automatic and auditable. Nightly runs, post-merge runs, and manual attestations all permit unverified code to reach the main branch.

Question 29Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline must deploy to three environments in sequence, and each environment's credentials differ. Which design keeps secrets scoped correctly?

  1. Store all three environments' credentials in one shared variable group available to every job
  2. Embed all credentials in the pipeline file encrypted with a single repository-wide key
  3. Attach environment-specific secrets to each deployment job so a job can read only its own environment's credentials Correct answer.
  4. Grant every job the union of all three environments' permissions to simplify configuration

Explanation

Scoping secrets per environment limits blast radius: a compromised or misconfigured staging job cannot read production credentials. Shared groups, repository-embedded secrets, and union permissions all widen exposure beyond what each job needs.

Question 30Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline's integration test stage takes 40 minutes because tests run serially in one job. Which change most directly reduces wall-clock duration without weakening coverage?

  1. Split the test suite into balanced shards executed as parallel jobs and aggregate their results Correct answer.
  2. Increase the timeout on the single test job so it is less likely to be cancelled
  3. Retry the failing tests automatically up to three times
  4. Move the integration tests to a nightly schedule and skip them on pull requests

Explanation

Parallel sharding divides the same test set across runners, cutting elapsed time roughly in proportion to the number of balanced shards while every test still runs. Longer timeouts, deferral, and retries change when or how failures appear, not the duration of a full run.

Question 31Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A build job needs a dependency cache that stays valid across branches while remaining safe when dependencies change. Which cache key design is soundest?

  1. Key on the current date so the cache refreshes daily
  2. Key on a hash of the dependency lockfile, with a branch-independent fallback prefix Correct answer.
  3. Disable caching and download dependencies on every run
  4. Key on the commit author's username

Explanation

Hashing the lockfile ties cache validity to the actual dependency set, so any change produces a new key, while a shared prefix lets branches reuse compatible entries. Date, author, and no-cache strategies either invalidate needlessly or risk stale or slow builds.

Question 32Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline promotes an artifact by rebuilding it from the same commit in each environment. Which risk does this introduce?

  1. The artifact deployed to production may differ from the one validated in staging because builds are not bit-for-bit reproducible Correct answer.
  2. The artifact registry will reject duplicate tags
  3. The pipeline will be unable to run tests in staging
  4. The commit hash will no longer identify the source revision

Explanation

Rebuilding per environment means staging and production receive separately produced binaries that can diverge through dependency drift, timestamps, or toolchain differences. Promoting one immutable artifact avoids that gap; the commit hash still identifies source, and registries handle duplicate tags routinely.

Question 33Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline runs the same integration suite twice: once in a pre-merge job and again in a post-merge job on the main branch. Which rationale justifies keeping both runs?

  1. The post-merge run replaces the need for any pre-merge feedback
  2. The post-merge run is required because pre-merge jobs cannot access the test database
  3. The post-merge run exists to satisfy licensing requirements of the CI vendor
  4. The post-merge run validates the merged result, which can differ from the pre-merge result due to concurrent changes Correct answer.

Explanation

Pre-merge jobs test a branch in isolation, so the combined main branch after merge can still break; a post-merge run catches integration effects from concurrent merges. Database access, licensing, and replacing pre-merge feedback are not valid reasons for duplication.

Question 34Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline uses a declarative configuration with a step that must run only when the previous stage succeeded and the branch is main. Which implementation is most robust?

  1. Rely on the step's position in the file, assuming later steps run only after earlier ones succeed
  2. Add a shell check inside the step that inspects the exit code of the previous job
  3. Express the condition using the pipeline's native stage dependency and branch condition expressions Correct answer.
  4. Document the requirement in the team wiki and rely on reviewers to enforce it

Explanation

Native dependency and branch conditions are evaluated by the orchestrator, so the step is skipped deterministically and the rule is visible in version control. Positional assumptions, shell checks, and documentation are fragile because they depend on runtime state or human discipline.

Question 35Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A regulated team must prove that a production deployment was executed from an approved pipeline definition and artifact. Which combination of controls provides the strongest evidence?

  1. A tag on the commit noting that the release was reviewed
  2. A screenshot of the pipeline run attached to the change ticket
  3. A verbal sign-off from the release manager during the deployment call
  4. Immutable pipeline definitions pinned by version, signed artifacts, and an audit log recording who approved and which artifact digest was deployed Correct answer.

Explanation

Pinning the pipeline definition, signing artifacts, and logging approvals with the deployed digest creates a verifiable chain from source to running software. Screenshots, verbal sign-offs, and commit tags are not tamper-evident and cannot be correlated reliably with the artifact actually deployed.

Question 36Continuous Integration and Continuous Delivery (CI/CD) Pipelines

A pipeline's deployment stage occasionally deploys a stale artifact because it resolves the image tag 'stable' at deploy time. Which change removes this race while keeping deployments repeatable?

  1. Resolve the tag to an immutable digest during the build stage and deploy that digest through every later stage Correct answer.
  2. Freeze the 'stable' tag so it cannot be moved after the first push
  3. Increase the frequency of the pipeline so the window for drift is smaller
  4. Add a retry loop around the deploy step so it re-resolves the tag until it succeeds

Explanation

Mutable tags can be repointed between stages, so resolving to a content-addressed digest at build time and promoting that digest guarantees every environment receives the same bits. Retries, tag freezing, and higher frequency either preserve the race or block legitimate releases.

Question 37Infrastructure as Code and Configuration Management

In Terraform, what does the state file primarily record about managed infrastructure?

  1. The provider plugin versions installed on each workstation
  2. The Git commit history of every change made to the configuration
  3. The IAM permissions required to apply the configuration
  4. The mapping between declared resources and real remote objects, plus cached attribute values Correct answer.

Explanation

Terraform state binds each resource address in configuration to a specific real object and stores the attribute values observed at the last refresh. Plan and apply compare this recorded snapshot with the configuration and with live infrastructure. It is not a version control log, a permission manifest, or a plugin inventory.

Question 38Infrastructure as Code and Configuration Management

An engineer runs terraform apply and the plan shows an existing resource being destroyed and recreated. Which resource attribute change is the most likely cause?

  1. An update to a mutable tag value on the resource
  2. A change to an output value that references the resource
  3. A change to an argument the provider marks as ForceNew Correct answer.
  4. A change to a variable used only inside a local value

Explanation

When a changed argument is declared ForceNew by the provider schema, Terraform cannot update it in place and must replace the object, which the plan renders as destroy-then-create. Mutable attributes such as tags are updated in place. Outputs and locals do not by themselves trigger replacement of the underlying resource.

Question 39Infrastructure as Code and Configuration Management

What is the purpose of a Terraform provider block such as provider "aws" { region = "eu-west-1" }?

  1. It configures and authenticates the plugin that talks to a target API Correct answer.
  2. It defines the module's input variables
  3. It declares the backend used to store remote state
  4. It pins the Terraform CLI version required by the module

Explanation

A provider block supplies configuration, including credentials and endpoint settings, to the provider plugin that performs CRUD calls against the target platform. Backend configuration, CLI version constraints, and variable declarations each have their own separate blocks.

Question 40Infrastructure as Code and Configuration Management

In Ansible, which construct runs a task only when a condition evaluated against gathered facts is true?

  1. A when clause attached to the task Correct answer.
  2. A handler notified by a changed task
  3. A tags attribute on the play
  4. A become directive on the task

Explanation

The when clause accepts an expression, commonly referencing ansible_facts, and the task is skipped when the expression is false. Handlers run in response to notification, tags filter which tasks run, and become controls privilege escalation.

Question 41Infrastructure as Code and Configuration Management

Which statement best describes the difference between Terraform provisioners and providers?

  1. Provisioners are the recommended way to bootstrap all server configuration, while providers are deprecated
  2. Provisioners run scripts or copy files as part of resource creation, while providers implement API calls for resource types Correct answer.
  3. Provisioners and providers are interchangeable names for the same plugin interface
  4. Provisioners manage resource lifecycle through APIs, while providers run scripts on hosts

Explanation

Provisioners such as remote-exec and file exist to run one-off actions during create or destroy, whereas providers are plugins that implement the CRUD operations behind resource types. HashiCorp documents provisioners as a last resort because they add non-declarative behavior and failure modes. The two are distinct mechanisms, not aliases.

Question 42Infrastructure as Code and Configuration Management

A team wants two engineers applying the same Terraform configuration to be prevented from corrupting shared state. Which control addresses this directly?

  1. Splitting the configuration into more modules
  2. Configuring a remote backend that supports state locking Correct answer.
  3. Committing the state file to the repository so both engineers have a copy
  4. Adding a lifecycle prevent_destroy rule to every resource

Explanation

A remote backend with locking, such as one backed by a service that supports lock records, ensures only one apply proceeds at a time and that everyone reads the same state. Committing state to Git creates divergent copies and risks secret exposure. prevent_destroy and module splitting do not serialize concurrent applies.

Question 43Infrastructure as Code and Configuration Management

What does terraform import accomplish?

  1. It validates configuration syntax without contacting any provider
  2. It generates a complete configuration file from a running environment
  3. It downloads provider plugins into the working directory
  4. It writes a state entry that associates an existing real object with a resource address Correct answer.

Explanation

terraform import attaches an already-existing remote object to a resource address in state so Terraform will manage it going forward. It does not author configuration for that resource, so the configuration must still be written to match. Plugin installation and syntax validation are separate commands.

Question 44Infrastructure as Code and Configuration Management

In Ansible, what is the effect of the serial keyword on a play?

  1. It throttles the number of retries for failed tasks
  2. It sets the number of parallel forks used by the connection plugin
  3. It limits how many hosts are processed in each batch before moving to the next Correct answer.
  4. It orders tasks by their declared priority

Explanation

serial controls rolling execution by defining how many hosts receive the play per batch, which is how canary or rolling deployments are expressed. Parallelism per task is governed by forks, and retries are handled by until and retries. Task ordering follows file order, not priority.

Question 45Infrastructure as Code and Configuration Management

Which Terraform expression references an attribute of a resource declared as resource "aws_instance" "web" in the same module?

  1. resource.aws_instance.web.id
  2. var.aws_instance.web.id
  3. aws_instance["web"].id
  4. aws_instance.web.id Correct answer.

Explanation

Resource attributes are referenced as TYPE.NAME.ATTRIBUTE, so aws_instance.web.id resolves to the id attribute of that instance. The resource keyword is not part of the reference syntax, bracket indexing applies to count or for_each instances, and var is only for input variables.

Question 46Infrastructure as Code and Configuration Management

A module uses count = 3 to create identical subnets. How should an engineer reference the second subnet's id?

  1. module.subnet["1"].id
  2. module.subnet.1.id
  3. module.subnet[2].id
  4. module.subnet[1].id Correct answer.

Explanation

With count, instances are addressed by a zero-based index, so the second instance is index 1. The expression module.NAME[INDEX].ATTRIBUTE is the correct form. Numeric indices are not written with dot notation, and quoted values are used with for_each keys rather than count.

Question 47Infrastructure as Code and Configuration Management

Which change most improves a Terraform module's reusability across environments?

  1. Hardcoding region and size values in the module's resources
  2. Exposing environment-specific values as input variables with defaults where sensible Correct answer.
  3. Adding a terraform apply step to the module's own CI pipeline
  4. Storing environment-specific state inside the module directory

Explanation

Parameterizing differences such as region, instance size, and naming through input variables lets one module serve multiple environments without edits. Hardcoded values force duplication, and modules should not apply themselves or own environment state. State belongs to the root configuration and its backend.

Question 48Infrastructure as Code and Configuration Management

In Ansible, what does an idempotent task guarantee on repeated runs?

  1. The task runs only once per inventory host across all plays
  2. The task always reports changed on every run
  3. The task skips execution whenever the host has been seen before
  4. The task produces the same end state and reports changed only when it modifies something Correct answer.

Explanation

Idempotence means repeated execution converges to the same result, and well-written modules report changed only when they actually alter the system. This is what makes repeated playbook runs safe. Reporting changed every time signals a non-idempotent command or shell task.

Question 49Infrastructure as Code and Configuration Management

A team needs to guarantee that a specific Terraform resource is never destroyed by an apply. Which configuration element enforces this?

  1. A moved block remapping the resource address
  2. An output that exports the resource id
  3. A lifecycle block containing prevent_destroy = true Correct answer.
  4. A depends_on argument pointing at the resource

Explanation

The lifecycle meta-argument with prevent_destroy = true causes Terraform to error if a plan would destroy that resource, providing a guardrail against accidental deletion. Outputs, dependencies, and address moves do not block destruction. Note that the protection disappears if the resource is removed from configuration entirely.

Question 50Infrastructure as Code and Configuration Management

What is the role of a Terraform data source such as data "aws_ami" "latest"?

  1. It stores the AMI id in remote state as a managed resource
  2. It creates a new AMI in the target account
  3. It reads existing information from the provider without managing that object Correct answer.
  4. It replaces the need for a provider block

Explanation

Data sources query the provider for information about objects that exist outside the configuration, such as the newest matching AMI, and expose the results as read-only attributes. They are refreshed during plan and are not created or destroyed by apply. They still require a configured provider.