Browse Exams — Mock Exams & Practice Tests

1Z0-1109-25 Syllabus — Learning Objectives by Topic

Learning objectives for OCI 2025 DevOps Professional (1Z0-1109-25), organized by topic with quick links to targeted practice.

Use this syllabus as your checklist for 1Z0‑1109‑25.

What’s covered

Topic 1: DevOps Foundations on OCI (Environments, IAM, Secrets)

Practice this topic →

1.1 Environment strategy: compartments, separation, and governance

  • Design environment separation (dev/stage/prod) using compartments/projects and explain why it reduces risk.
  • Given a scenario, choose a compartment strategy that supports ownership and least privilege for pipelines.
  • Use tagging and naming conventions to support operational visibility and cost attribution.
  • Recognize the risk of mixing production and non-production resources in the same governance boundary.
  • Given a scenario, choose guardrails (quotas/budgets) to prevent accidental overspend.
  • Recognize that governance includes review/approval workflows for high-risk changes.

1.2 IAM for CI/CD and automation (principals, policies, least privilege)

  • Design IAM policies for pipeline identities using least privilege (minimal verbs, minimal scope).
  • Given a scenario, choose workload identity (dynamic groups/principals) over long-lived user credentials.
  • Interpret policy statements and identify subject, verb, resource-family, and compartment scope.
  • Recognize common automation pitfalls: broad permissions and untracked credential sprawl.
  • Given a scenario, design access so build systems can fetch artifacts and deploy without human keys.
  • Recognize the role of audit/logging in change accountability and investigations.

1.3 Secrets management and secure configuration

  • Choose Vault for secret storage and rotation instead of embedding secrets in code or build scripts.
  • Given a scenario, design secure configuration management across environments (no hard-coded values).
  • Recognize the difference between secrets (credentials) and configuration (feature flags, endpoints) conceptually.
  • Identify common secret-handling anti-patterns (shared keys, plaintext logs, public repos).
  • Given a scenario, choose a design that supports key rotation with minimal downtime (concept-level).
  • Recognize that pipeline logs must avoid leaking secrets and sensitive data.

Topic 2: CI/CD Pipelines and Artifacts

Practice this topic →

2.1 Pipeline stages: source, build, test, package

  • Explain a standard CI pipeline flow (source → build → test → package) and why each stage matters.
  • Given a scenario, choose gates that prevent untested code from being deployed to production.
  • Recognize that repeatability requires versioned source and deterministic builds (concept-level).
  • Identify where to add quality checks (lint/tests/security scans) conceptually.
  • Given a scenario, choose a pipeline structure that supports fast feedback and safe releases.
  • Recognize the need to capture build metadata for auditability (commit SHA, version, artifact ID).

2.2 Artifact strategy and versioning

  • Explain why artifacts should be immutable and versioned for reliable deployments (concept-level).
  • Given a scenario, choose artifact repositories/registries appropriate to the workload (containers vs binaries).
  • Recognize how artifact versioning supports rollback and incident response.
  • Identify the risk of “latest” tags and non-versioned deployments (concept-level).
  • Given a scenario, choose a strategy that supports promotion across environments (dev → prod).
  • Recognize that access to artifacts must be controlled by IAM and audited.

2.3 Release governance: approvals, checks, and promotion

  • Design approval workflows for production releases based on risk tolerance (concept-level).
  • Given a scenario, choose automated checks (tests, policy validations) before promotion.
  • Recognize that separation of duties improves security and reduces accidental releases.
  • Identify how to keep deployment history and traceability for compliance (concept-level).
  • Given a scenario, choose a promotion model that supports quick rollback.
  • Recognize the need to document changes and maintain runbooks for common failure cases.

Topic 3: Deployment Strategies (Rolling, Canary, Blue/Green)

Practice this topic →

3.1 Strategy selection based on risk and rollback needs

  • Differentiate rolling, canary, and blue/green deployments and identify their trade-offs.
  • Given a scenario, choose canary for blast-radius control and blue/green for fast cutover/rollback.
  • Recognize that the correct answer must include rollback and verification signals.
  • Identify workload characteristics that influence strategy choice (stateful vs stateless, traffic patterns).
  • Given a scenario, choose a deployment strategy that minimizes downtime and risk.
  • Recognize that deployment strategies require monitoring to validate success.

3.2 Load balancers, health checks, and traffic shifting

  • Explain health checks conceptually and why they gate rollout success.
  • Given a scenario, use load balancer routing/weights (concept-level) to shift traffic gradually.
  • Recognize that traffic shifting requires safe defaults: small initial canary percentage and clear abort conditions.
  • Identify common rollout failure causes (bad config, dependency issues, schema changes) conceptually.
  • Given a scenario, choose a design that prevents deploying broken versions to all instances at once.
  • Recognize that rollback must also be tested and not only assumed.

3.3 Database and schema changes in releases (concept-level)

  • Recognize database migrations as a frequent deployment risk and plan compatibility (concept-level).
  • Given a scenario, choose backward-compatible schema changes to support gradual rollouts.
  • Explain why coordinated rollouts across services may be required (contract/versioning) conceptually.
  • Identify the risk of irreversible migrations without rollback plans (concept-level).
  • Given a scenario, choose a release approach that reduces downtime during schema changes.
  • Recognize observability signals needed to detect migration issues quickly.

Topic 4: Infrastructure as Code (Terraform / Resource Manager)

Practice this topic →

4.1 IaC lifecycle: plan, review, apply, drift

  • Explain IaC benefits: repeatability, reviewability, and reduced manual drift (concept-level).
  • Given a scenario, choose a plan/review gate before applying changes to production.
  • Recognize drift as configuration divergence and why it increases incident risk (concept-level).
  • Identify safe patterns: small changes, clear ownership, and rollback strategy.
  • Given a scenario, choose IaC to standardize environment provisioning across teams.
  • Recognize that IaC state and credentials must be secured and access-controlled.

4.2 State management and environment separation

  • Explain why state is sensitive and must be protected (secrets, resource topology).
  • Given a scenario, separate state per environment to reduce blast radius.
  • Recognize the risk of sharing state across teams and how to mitigate (concept-level).
  • Identify how tagging/naming standards support consistent IaC modules and governance.
  • Given a scenario, choose a structure that supports promotion of infrastructure changes safely.
  • Recognize that access to state should follow least privilege and be audited.

4.3 Automation and policy checks (concept-level)

  • Given a scenario, choose automated policy validations (security baseline checks) before apply.
  • Recognize that automation pipelines should capture who changed what and when (auditability).
  • Identify the need to test infrastructure changes in non-prod first (concept-level).
  • Given a scenario, design automation with break-glass procedures for emergencies (concept-level).
  • Recognize that secrets used by automation must be handled securely (Vault, short-lived creds).
  • Given a scenario, choose an approach that balances speed with safety.

Topic 5: Observability, Monitoring, and Troubleshooting

Practice this topic →

5.1 Monitoring and alerting essentials

  • Choose key SLO-ish signals (latency, errors, saturation) conceptually for monitoring.
  • Given a scenario, define alert thresholds and escalation paths to support on-call response.
  • Recognize that alert fatigue is a risk and choose actionable alerts (concept-level).
  • Identify why dashboards are necessary for fast diagnosis during incidents.
  • Given a scenario, choose monitoring that validates deployment success (not just uptime).
  • Recognize the need to monitor dependencies and connectivity, not only application instances.

5.2 Logging and traceability

  • Design logging that supports debugging and auditability (structured logs, correlation IDs) conceptually.
  • Given a scenario, centralize logs to support cross-team incident response.
  • Recognize the difference between service logs, application logs, and audit logs (concept-level).
  • Identify how to retain logs appropriately for compliance and troubleshooting needs (concept-level).
  • Given a scenario, choose a logging strategy that helps root-cause common deployment failures.
  • Recognize that logs must avoid leaking secrets and sensitive data.

5.3 Troubleshooting common failure modes (concept-level)

  • Given a scenario, identify whether the issue is build-time, deploy-time, or runtime.
  • Recognize common deploy failures: bad config, missing permissions, wrong network placement (concept-level).
  • Identify signals for rollback vs forward-fix decisions (concept-level).
  • Given a scenario, choose steps that reduce time-to-diagnosis (check logs, health checks, alarms).
  • Recognize the importance of postmortems and action items to prevent repeats (concept-level).
  • Given a scenario, choose an approach that restores service first, then investigates safely.

Topic 6: Reliability, Recovery, and Continuous Improvement

Practice this topic →

6.1 Rollback, recovery, and DR awareness

  • Design rollback strategies for deployments and explain why they reduce mean time to recovery.
  • Given a scenario, choose blue/green or canary to enable fast rollback for critical systems.
  • Recognize that DR requires tested runbooks, not just replication configuration (concept-level).
  • Identify the difference between backups (corruption recovery) and replication (failover) conceptually.
  • Given a scenario, choose recovery strategies aligned with RTO/RPO requirements.
  • Recognize that recovery requires ownership, alerting, and periodic testing.

6.2 Change management and risk reduction

  • Explain why small, frequent changes reduce risk compared to large infrequent releases (concept-level).
  • Given a scenario, choose gates and approvals appropriate to change risk.
  • Recognize the value of feature flags and gradual rollout to reduce user impact (concept-level).
  • Identify how to track change history for compliance and troubleshooting (concept-level).
  • Given a scenario, choose a release process that balances speed and safety.
  • Recognize that continuous improvement includes addressing root causes, not only symptoms.

6.3 Security and compliance in the delivery lifecycle

  • Given a scenario, include security checks in CI/CD (scans, policy validation) conceptually.
  • Recognize least privilege as a delivery requirement for pipeline identities.
  • Identify auditability needs: who deployed what, when, and with which artifact version.
  • Given a scenario, choose Vault for secrets and avoid leaking credentials in build logs.
  • Recognize compliance concerns: log retention, change approvals, and separation of duties (concept-level).
  • Given a scenario, choose a process that is secure by default and operationally sustainable.
Study Plan
Cheat Sheet