Browse Exams — Mock Exams & Practice Tests

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

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

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

What’s covered

Topic 1: Multicloud Foundations (Governance, Responsibility, Boundaries)

Practice this topic →

1.1 Multicloud objectives and shared responsibility (concept-level)

  • Explain why organizations adopt multicloud (risk, regulatory, product fit) at a conceptual level.
  • Recognize shared responsibility boundaries and how they differ across providers (concept-level).
  • Given a scenario, identify which concerns must be solved across clouds (identity, network, data, operations).
  • Recognize the operational cost of multicloud and why standardization matters (concept-level).
  • Given a scenario, choose a design that reduces unnecessary complexity while meeting requirements.
  • Recognize common multicloud anti-patterns: duplicating everything, unmanaged data movement, inconsistent governance.

1.2 Governance across boundaries (compartments, tags, cost attribution)

  • Design governance boundaries in OCI (compartments/tags) that align with enterprise structure.
  • Given a scenario, choose consistent tagging to support cross-cloud cost attribution and reporting.
  • Recognize budgets/quotas/limits as guardrails to prevent resource sprawl.
  • Identify the need for consistent naming and ownership across environments for operability.
  • Given a scenario, choose a governance approach that supports compliance requirements.
  • Recognize that governance includes audit/log retention and access control for observability data.

1.3 Security baseline consistency (least privilege, keys, auditability)

  • Apply least privilege consistently across clouds and explain why it reduces blast radius.
  • Given a scenario, choose customer-managed key strategies where compliance requires it (concept-level).
  • Recognize auditability as a baseline requirement in multicloud (who did what, where, when).
  • Identify the risks of credential sprawl and prefer federation/short-lived identities where possible (concept-level).
  • Given a scenario, choose a design that keeps sensitive resources private and tightly controlled.
  • Recognize that baseline security includes detection/alerting and an owned response path.

Topic 2: Connectivity Patterns (VPN, FastConnect, Routing, DNS)

Practice this topic →

2.1 Connectivity selection: VPN vs FastConnect (concept-level)

  • Differentiate VPN and FastConnect conceptually (latency, bandwidth, reliability).
  • Given a scenario, choose VPN for quick setup and FastConnect for predictable performance needs.
  • Recognize that connectivity design should include redundancy for availability (concept-level).
  • Identify why overlapping IP ranges complicate multicloud connectivity and how planning avoids it.
  • Given a scenario, choose the simplest connectivity approach that meets requirements.
  • Recognize that connectivity decisions impact cost (egress) and security boundaries (concept-level).

2.2 Routing intent and segmentation across networks

  • Explain routing vs security: route tables/DRG provide reachability, NSGs/security lists provide control.
  • Given a scenario, design segmentation that reduces lateral movement risk across connected networks.
  • Recognize hub-spoke patterns as a way to reduce network sprawl (concept-level).
  • Identify the need to control transitive routing and avoid unexpected paths (concept-level).
  • Given a scenario, choose a routing approach that supports shared services access safely.
  • Recognize that monitoring connectivity paths is required for production reliability.

2.3 DNS, service discovery, and endpoint strategy

  • Recognize DNS as a core dependency for multicloud service discovery and routing (concept-level).
  • Given a scenario, choose consistent naming to reduce operational mistakes across environments.
  • Explain split-horizon/private DNS intent in hybrid/multicloud environments (concept-level).
  • Given a scenario, choose DNS/traffic steering approaches that support failover and resilience (concept-level).
  • Recognize that endpoints should be stable and versioned where possible (concept-level).
  • Identify security considerations for DNS and endpoints (access control, logging) conceptually.

Topic 3: Identity Federation & Access Management

Practice this topic →

3.1 Federation goals and patterns (concept-level)

  • Explain federation intent at a high level: centralized identity and reduced credential sprawl.
  • Given a scenario, choose federation over separate local users for enterprise SSO (concept-level).
  • Recognize that authorization is still enforced in OCI via policies and compartment scope.
  • Identify trust boundary risks and why least privilege must be applied in each system.
  • Given a scenario, choose an approach that supports separation of duties across clouds.
  • Recognize the need for logging/audit of federation and access events for investigations.

3.2 Workload identity and cross-environment access

  • Given a scenario, prefer workload identity approaches that avoid long-lived credentials (concept-level).
  • Design policies for application identities that are scoped to required compartments/projects.
  • Recognize that cross-cloud access increases risk and must be tightly controlled and audited.
  • Identify the risk of shared secrets across clouds and how to reduce it (concept-level).
  • Given a scenario, choose an approach that supports rotation and minimizes blast radius.
  • Recognize common mistakes: broad roles, unmanaged keys, and missing ownership.

3.3 Governance and compliance for access (auditability)

  • Given a scenario, ensure access changes are auditable (who changed what, where, when).
  • Recognize that compliance may require log retention and controls around privileged actions.
  • Identify break-glass access intent and how to control it (approvals, monitoring) conceptually.
  • Given a scenario, choose controls that prevent privilege creep over time.
  • Recognize that identity governance includes periodic access reviews (concept-level).
  • Given a scenario, choose an approach that balances operational needs and compliance requirements.

Topic 4: Data Placement, Replication, and Integration

Practice this topic →

4.1 Data locality, egress cost, and latency trade-offs

  • Explain data locality and why it drives latency and cost (egress) in multicloud designs.
  • Given a scenario, minimize cross-cloud data movement unless requirements demand it.
  • Recognize that data transfer introduces security and governance risks (encryption, access, audit).
  • Identify when caching or replication is more appropriate than synchronous cross-cloud calls (concept-level).
  • Given a scenario, choose a design that meets latency requirements without excessive data movement.
  • Recognize that data movement plans must include ownership and monitoring.

4.2 Replication strategy and consistency (RPO/RTO alignment)

  • Use RTO and RPO to drive replication strategy and standby posture (concept-level).
  • Given a scenario, choose asynchronous replication when strict consistency is not required.
  • Recognize that replication frequency and lag must be monitored to maintain DR readiness.
  • Identify the difference between backup/restore (corruption recovery) and replication (failover) conceptually.
  • Given a scenario, choose a replication approach that meets business continuity needs.
  • Recognize that encryption/key management responsibilities must be explicit for replicated data.

4.3 Integration patterns (ETL, events, APIs) — concept-level

  • Given a scenario, choose batch ETL vs event-driven integration based on latency needs.
  • Recognize that event-driven integration requires idempotency and retry-safe consumers (concept-level).
  • Identify schema/versioning as a long-term integration requirement (concept-level).
  • Given a scenario, choose APIs for synchronous needs and events/streams for decoupled pipelines.
  • Recognize governance needs: lineage, retention, and auditability for integrated data.
  • Given a scenario, choose integration patterns that are operationally sustainable.

Topic 5: Resilience & DR Across Clouds

Practice this topic →

5.1 Failure modes and resilience planning

  • Identify common multicloud failure modes: connectivity outage, provider outage, identity failure, data inconsistency (concept-level).
  • Given a scenario, choose designs that degrade gracefully when a dependency is unavailable.
  • Recognize the need for redundancy in connectivity and DNS/endpoint strategies (concept-level).
  • Explain why resilience includes operations: monitoring, runbooks, and tested recovery procedures (concept-level).
  • Given a scenario, choose an architecture that meets availability targets without over-complexity.
  • Recognize that resilience must be validated with testing and game days (concept-level).

5.2 Failover, traffic steering, and recovery execution

  • Given a scenario, choose DNS/traffic steering approaches that support failover (concept-level).
  • Recognize that recovery execution requires runbooks and clear ownership.
  • Identify the need to validate data consistency during failover (concept-level).
  • Given a scenario, choose automation to reduce recovery time and human error.
  • Recognize rollback vs failover as distinct responses depending on the failure type (concept-level).
  • Given a scenario, choose a DR plan that is realistic to operate and maintain.

5.3 Security and compliance during recovery

  • Ensure recovery paths preserve least privilege and do not bypass governance controls.
  • Given a scenario, maintain audit/logging during failover so investigations remain possible.
  • Recognize that key management and encryption responsibilities must remain consistent during recovery.
  • Identify risks of emergency access and break-glass misuse; design controls and monitoring (concept-level).
  • Given a scenario, choose DR practices that satisfy regulatory requirements.
  • Recognize that DR testing should include security validation, not just availability.

Topic 6: Operations & Cost Management Across Clouds

Practice this topic →

6.1 Observability across clouds (logs, metrics, audit)

  • Design an observability baseline that includes metrics, logs, and auditability across environments (concept-level).
  • Given a scenario, choose centralized visibility for faster incident response and investigations.
  • Recognize the need to monitor connectivity paths and shared dependencies.
  • Identify the importance of correlation IDs and consistent telemetry naming (concept-level).
  • Given a scenario, choose alerting that routes to the right owners and avoids alert fatigue.
  • Recognize that observability data must be access-controlled and retained appropriately for compliance.

6.2 Cost control: attribution, egress awareness, and guardrails

  • Identify egress/data transfer as a common hidden multicloud cost driver (concept-level).
  • Given a scenario, reduce cost by minimizing cross-cloud data movement and avoiding chatty designs.
  • Use tagging and project boundaries to enable cost attribution and chargeback/showback (concept-level).
  • Recognize budgets/quotas as guardrails that prevent accidental overspend.
  • Given a scenario, choose a design that meets requirements with sustainable ongoing costs.
  • Recognize that cost control must be continuous (monitoring, alerts, governance processes).

6.3 Operating model: standards, automation, and risk management

  • Explain why standard patterns and automation reduce multicloud operational risk (concept-level).
  • Given a scenario, choose IaC approaches to standardize provisioning and reduce drift.
  • Recognize that change management and approvals scale better than ad-hoc manual operations.
  • Identify the need for shared runbooks and incident processes across teams.
  • Given a scenario, choose an operating model that supports compliance and rapid recovery.
  • Recognize that multicloud success depends on clarity of ownership and responsibility boundaries.