Red Hat Certified Specialist in Cloud Infrastructure exam
Performance-based practical exam completed in a controlled Red Hat testing environment
- Type
- Practical
- Delivery
- Both
Exam sections
Manage the Red Hat OpenStack Platform control plane
The “Manage the Red Hat OpenStack Platform control plane” objective treats objectives, accountable roles, risk significance, reliability of support, sequence of action, and judgments the evidence can sustain as part of a wider professional sequence. The practical expectation is to assign the decision to the correct role, evaluate the available support, and respond at the proper point in the case. It leads into “Manage infrastructure security” in the published outline.
Question notes
For “Manage the Red Hat OpenStack Platform control plane,” context matters: the objective can surface inside a larger administration or development sequence. Challenge the result with poor supporting information, uncertain decision rights, findings beyond the evidence, or corrective work that addresses an effect but not the underlying risk, then verify it using an auditable connection between purpose and risk, evidence, judgment, conclusion, and stakeholder communication. The record does not invent an isolated duration or question count for this area.
Preparation tips
Rehearse “Manage the Red Hat OpenStack Platform control plane” under a realistic constraint. Use this exercise: Build an evidence matrix linking objective, risk, control, test, result, and conclusion; then challenge one weak source. Then test unverified inputs, unclear responsibility, judgment before analysis is complete, or action taken against a secondary issue rather than the source of risk. Decide what must change by inspecting an auditable connection between purpose and risk, evidence, judgment, conclusion, and stakeholder communication. Explain which assumptions this leaves for “Manage infrastructure security”.
Manage infrastructure security
For “Manage infrastructure security,” the relevant professional context is the interaction among identity context, permissions, trust, and the access actually received under realistic production conditions. The candidate is expected to show how the security goal drives responsibility, least-privilege design, and enforcement, and inspectable access results, rather than answer from keyword familiarity alone. In the published sequence, it follows “Manage the Red Hat OpenStack Platform control plane” and precedes “Manage user security”.
Question notes
The assessment may connect “Manage infrastructure security” with other objectives: the performance environment may join this objective to work elsewhere in the system. A weak result can be exposed by an apparently sound configuration that provides broader access than required or never exercises an exception path. A complete result leaves a permitted case, a denied case, policy-evaluation details and an inspectable activity trail. This objective is included without inventing an isolated duration or assessment inventory.
Preparation tips
Make preparation for “Manage infrastructure security” observable. Practical exercise: Diagram the trust boundary, configure or analyze the control, and test an exception that could bypass the intended restriction. Ask a reviewer to test for an apparently sound configuration that opens permissions beyond the stated need or ignores a bypass condition. Give the reviewer a permitted case, a rejected-path test, policy-evaluation details and an inspectable activity trail. Trace a deliberately introduced error forward into “Manage user security”.
Manage user security
Candidates preparing “Manage user security” should frame it around how least-privilege intent becomes actual behavior across security boundaries under practical operating scenarios. The objective is met when they can move from the security requirement through responsibility and least privilege into enforcement, and observable access behavior. In the published sequence, it follows “Manage infrastructure security” and precedes “Manage application deployment resources”.
Question notes
Question or task wording for “Manage user security” may hide its decisive constraint because the scoring context favors a working end state over description of the procedure. Required negative check: an ostensibly valid configuration that allows unnecessary access or assumes an exception is harmless without testing it. Supporting evidence: a policy-allowed case, a negative access case, policy-evaluation details and an inspectable activity trail. Prepare the complete objective because the payload does not assume how many tasks or questions represent it.
Preparation tips
Build preparation for “Manage user security” around context, action, failure, and proof. Exercise: Start from least privilege, add only the access required by the scenario, and verify both expected access and expected denial. The checklist must expose an outwardly valid configuration that provides broader access than required or never exercises an exception path. Required proof: a positive access case, a denied case, the effective rule path, plus audit evidence suitable for independent review. Finish with a handoff checklist for “Manage application deployment resources”.
Manage application deployment resources
Candidates preparing “Manage application deployment resources” should frame it around reliable repetition, step sequencing, inputs, idempotence, exceptions, rollback, and controlled change. The objective is met when they can show that the workflow reaches the required end state again without drift, and reports failure clearly enough for recovery. In the published sequence, it follows “Manage user security” and precedes “Manage storage in Red Hat OpenStack Platform”.
Question notes
Question or task wording for “Manage application deployment resources” may hide its decisive constraint because the performance environment may join this objective to work elsewhere in the system. Required negative check: hidden dependency order, a rerun that changes the result, inadequate handling of failure, or a rollback that does not restore the prior condition. Supporting evidence: run history, state comparison, error output, rollback evidence, and a successful repeat run. Prepare the complete objective without assuming an unpublished percentage, item allocation, or timing.
Preparation tips
Keep a short decision journal for “Manage application deployment resources.” Complete this exercise: Execute the same change twice and inspect whether the second run is safe, predictable, and free of unintended work. Record whether you detected or prevented hidden ordering, a rerun that changes the result, unhandled exceptions, or a recovery path that does not return to a safe state. Attach run history, state comparison, error output, recovery record, and a successful repeat run. Record the signal that would expose an error later in “Manage storage in Red Hat OpenStack Platform”.
Manage storage in Red Hat OpenStack Platform
“Manage storage in Red Hat OpenStack Platform” tests whether a candidate understands data shape, ownership, lifecycle, consistency, and impact on dependent work of a change. That understanding must support an ability to track state across creation, ownership, transformation, consumption, update, and removal. In the published sequence, it follows “Manage application deployment resources” and precedes “Manage networking”.
Question notes
Before acting on “Manage storage in Red Hat OpenStack Platform,” read the full scenario; one practical scenario may exercise this skill together with neighboring objectives. Test the response for unnoticed corruption, information drift, missing accountability, or unverified schema and lifecycle rules. Confirm the outcome with a recorded state comparison, an information trail, reconciled-state evidence, and behavior verified by a dependent system. This objective has no separately claimed time allowance or item quantity.
Preparation tips
Build preparation for “Manage storage in Red Hat OpenStack Platform” around context, action, failure, and proof. Exercise: Model the data or state transition, apply a controlled change, and inspect every downstream effect before accepting it. The checklist must expose hidden information loss, information drift, missing accountability, or unverified schema and lifecycle rules. Required proof: before-and-after state, provenance, state-comparison findings, and results seen by a dependent system. Close by tracing the effect on “Manage networking”.
Manage networking
The “Manage networking” objective treats interfaces, trust boundaries, sequencing, response to failure, and observability between components as a connected responsibility rather than an isolated topic. Candidates should learn to reason from the contract and required outcome through connectivity, security, retries, and recovery. In the published sequence, it follows “Manage storage in Red Hat OpenStack Platform” and precedes “Manage compute node operations”.
Question notes
Prepare “Manage networking” within the credential's wider flow, since the performance environment may join this objective to work elsewhere in the system. A defensible response accounts for a timeout, retry loop, incompatible contract, routing fault, or missing operational signal. Its support should include transaction traces, logs, contract checks, health information, and recovered end-to-end behavior. Prepare the objective as a whole because no dedicated question count or duration is supplied.
Preparation tips
For “Manage networking,” use this drill: Introduce a contract or connectivity failure, observe retry and error handling, and verify clean recovery after correction. Negative test: a timeout, retry loop, incompatible contract, routing fault, or missing operations-visible alert. Evidence to retain: transaction traces, logs, contract checks, health information, and recovered end-to-end behavior. Use the completed work to challenge a decision in “Manage compute node operations”.
Manage compute node operations
“Manage compute node operations” defines an applied capability within Red Hat Certified Specialist in Cloud Infrastructure: the purpose of “Manage compute node operations,” the context that determines it and the checks that expose a merely plausible answer. Success depends on being able to apply “Manage compute node operations” under a deliberately modified condition and notice when the original logic stops applying. In the published sequence, it follows “Manage networking” and precedes “Monitor operations”.
Question notes
Before acting on “Manage compute node operations,” read the full scenario; the objective can surface inside a larger administration or development sequence. Test the response for a plausible “Manage compute node operations” response that has no adequate defense after an independent review of inputs, effects, and verification. Confirm the outcome with before-and-after observations for “Manage compute node operations,” plus a traceable decision record and proof that acceptance conditions were met. Neither isolated timing nor item volume is inferred for this part of the outline.
Preparation tips
Study “Manage compute node operations” through contrasting cases. Start with this exercise: Turn “Manage compute node operations” into a practical scenario, predict the outcome, work it without prompts, and document how you checked the result. Build the weaker case around using a familiar “Manage compute node operations” pattern despite failing to verify alignment with the role, objective, and operating context. Separate the two results using an observable outcome for “Manage compute node operations,” its underlying assumptions, and proof that the material constraints were addressed. Review what this outcome changes for “Monitor operations”.
Monitor operations
The “Monitor operations” portion of Red Hat Certified Specialist in Cloud Infrastructure focuses on observable symptoms, known-good behavior, disciplined fault isolation, an appropriate correction, and evidence that the symptom cleared. A complete response should trace the fault with logs, metrics, and tests before intervening, then verify that the original symptom is gone. In the published sequence, it follows “Manage compute node operations” and precedes “Automate cloud application deployment”.
Question notes
Expect “Monitor operations” to appear in context because a task is not finished when commands return; candidates must verify the resulting platform state. Do not accept a “Monitor operations” response until it rules out altering multiple variables at once, losing the reference state, jumping from coincidence to root cause, or omitting post-change confirmation. Evidence to look for: recorded metrics, event data, and checks, a hypothesis trail, and post-change validation. The position of this objective does not support a question estimate, so only published numbers are retained.
Preparation tips
Build a proof-based study note for “Monitor operations.” Exercise: Capture a healthy baseline, introduce or select one fault, narrow the cause with evidence, apply a correction, and confirm recovery. Risk to document: making simultaneous untracked changes, diagnosing without comparison data, mistaking association for cause, or stopping before the symptom is retested. Proof to preserve: metrics, logs, and test results, a hypothesis trail, and post-change validation. Trace a deliberately introduced error forward into “Automate cloud application deployment”.
Automate cloud application deployment
At the center of “Automate cloud application deployment” is consistent reruns, dependency order, inputs, idempotence, exceptions, rollback, and controlled change. The credential therefore evaluates whether a candidate can show that the workflow reaches the intended state again without drift, and reports failure clearly enough for recovery. In the published sequence, it follows “Monitor operations” and precedes “Troubleshoot operations”.
Question notes
Prepare “Automate cloud application deployment” within the credential's wider flow, since successful work combines command execution with evidence that the platform reached the requested state. A defensible response accounts for hidden ordering, unsafe repeated execution, poor exception behavior, or recovery that leaves partial state behind. Its support should include run history, state comparison, error output, rollback evidence, and a successful repeat run. Prepare the complete objective without assuming an unpublished percentage, item allocation, or timing.
Preparation tips
Keep a short decision journal for “Automate cloud application deployment.” Complete this exercise: Introduce a mid-workflow failure, perform rollback or recovery, and compare the resulting state with the original baseline. Record whether you detected or prevented hidden execution order, unsafe repeated execution, a failed step without a controlled response, or recovery that stops too early. Attach recorded sequence of execution, state comparison, error output, evidence of restored state, and a successful repeat run. Reassess the result from the viewpoint of someone handling “Troubleshoot operations”.
Troubleshoot operations
At the center of “Troubleshoot operations” is measurable symptoms, reference behavior, evidence-led hypotheses, fault isolation, corrective work, and post-change validation. The assessable outcome is not recall, but an ability to trace the fault with logs, metrics, and tests before intervening, then verify that the initial symptom is gone. It draws on work established in “Automate cloud application deployment”.
Question notes
Knowing the heading “Troubleshoot operations” is not sufficient; the performance environment may join this objective to work elsewhere in the system. The principal risk is making simultaneous untracked changes, losing the reference state, jumping from coincidence to root cause, or omitting post-change confirmation. The response should be supported by telemetry, logs, and validation results, a hypothesis trail, and post-change validation. Coverage is preserved without inventing numerical emphasis, assessment inventory, or a time block.
Preparation tips
For “Troubleshoot operations,” use this drill: Investigate a realistic alert, separate root cause from secondary symptoms, and document why the recovery check is sufficient. Negative test: altering multiple variables at once, overlooking normal behavior, selecting a cause too early, or accepting recovery without evidence. Evidence to retain: baseline measures, diagnostic records, and tests, a hypothesis trail, and post-change validation. Explain how this work closes or exposes a risk originating in “Automate cloud application deployment”.