CCNA Governance And Administration Questions

The tenancy is the root container created when you sign up for OCI. It holds all compartments, users, and groups, and defines the top-level logical and security boundary within which every other resource is organised and access is governed.

OCI Events consumes Audit log entries as a source, letting you match rules on API activity and route them to Functions, Notifications or Streaming. This satisfies the requirement to act on audit data automatically rather than merely store or inspect it.

OCI policies are purely additive: every statement in the hierarchy is a grant, and no explicit deny exists, so a child compartment cannot subtract from or weaken a root-level grant. Higher-level permissions therefore always remain in force.

OCI policies attach permissions to groups, so adding the user to the finance group immediately grants the same effective access as every other member. This is the intended, scalable way to manage access and requires no new policy statements. Removing the user later from the group revokes access cleanly, which simplifies offboarding and audits.

API signing keys authenticate programmatic CLI and SDK requests through RSA key pairs, where the public key is stored in OCI and the private key signs each request. This satisfies the stem's requirement for a user authentication method, distinct from browser-based federation, by verifying identity for non-interactive access.

Compartment quotas set hard service limits, such as maximum OCPU count for compute instances, within a compartment. They constrain provisioning independently of IAM policy permissions, so developers cannot exceed four OCPUs in Staging even if their policies otherwise allow it.

Scoping policies to the department's compartment and its descendants enforces least privilege and isolates the department from other tenants of the same tenancy. This limits blast radius, simplifies audits, and aligns with Oracle's recommendation to grant access at the narrowest scope that satisfies the requirement.

Cost-tracking tags are metadata key-value pairs applied to OCI resources that appear in Cost Analysis and cost reports, enabling spend to be grouped and allocated by business unit. They satisfy the requirement to attribute operational costs across compartments, unlike free-form tags, which are not used for cost reporting.

With SAML 2.0 federation, OCI delegates authentication entirely to the corporate IdP. Disabling the account there means the IdP rejects the assertion, so no valid SAML token reaches OCI and access fails at the source, satisfying immediate revocation.

Cost Analysis lets users group and filter actual cost data by dimensions such as compartment, service, and tag, and it supports saving custom reports that can be shared with other users. This delivers the consolidated, near-real-time compartment-level view the finance team wants without manual spreadsheet exports.

OCI Audit automatically records all API calls against your tenancy, capturing the identity of the caller, timestamp, source IP and the exact action performed. Querying it filters the VCN deletion event, satisfying the auditor's need for precise who-deleted-what history from yesterday.

Moving a VCN between compartments requires authorisation in both: the source compartment to detach it, and the destination to attach it. Oracle Cloud Infrastructure evaluates IAM policies against the resource's current and target compartment, so lacking manage rights in either blocks the move, satisfying the stem's prerequisite.

OCI Cost Analysis provides interactive dashboards that break down spending by compartment, service, and tag, letting you visualise historical trends and forecast future costs. It directly satisfies the stem's requirement to analyse and track spending, using granular cost data rather than billing invoices alone.

The Audit Log Configuration in the OCI Console includes an option to export audit events to an Object Storage bucket, enabling long-term retention. This directly satisfies the stem's requirement to archive all Audit log events to Object Storage for compliance.

Scoping the statement to autonomous-databases in compartment DevCompartment grants management of Autonomous Databases only there, excluding every other resource type in that compartment. Broadening to all-resources or tenancy-level scope would breach the least-privilege requirement in the stem.

CSV is a plain-text, comma-delimited format that spreadsheet and BI tools parse natively, satisfying the stem's ingestion requirement. OCI Usage Reports are delivered as CSV files, so financial teams can import them directly without conversion.

Managing instances in Dev grants full lifecycle control over compute, including create and delete. Granting only read on virtual-network-family lets developers see the VCN and its security rules for troubleshooting but prevents any modification, since read is non-mutating. Together they satisfy both the operational need and the restriction on changing security rules.

Tags apply user-defined key-value pairs directly to OCI resources, satisfying the stem's requirement for granular tracking and automation. Unlike compartments, which provide hierarchical isolation, or defined tags, which are governed by tag namespaces, freeform tags let any user categorise resources immediately for cost tracking, filtering and policy-driven automation.

The Limits, Quotas and Usage page in the OCI Console displays current service limits and consumption, and provides the request mechanism for increases. It satisfies the stem's requirement for a single location to view limits, usage and submit increase requests.

Defined tags use a namespace and predefined key-value schema governed by policies, enabling consistent, controlled tagging across compartments. This satisfies the question's requirement for a supported tag type in Oracle Cloud Infrastructure, distinct from the unstructured free-form alternative.

OCI Cloud Guard continuously monitors resources against security best practices and industry benchmarks, satisfying the stem's diagnostic and compliance requirement. It detects misconfigurations and insecure activity through configurable detector recipes, then raises problems and responds automatically. Unlike posture-only tools, it also triggers corrective actions, directly meeting the continuous monitoring constraint.

Tag Defaults attach the specified namespace and key automatically to resources created in a compartment, so every new compute instance inherits Department and CostCenter without developer action. This satisfies the constraint of removing manual tagging input while enforcing consistent cost allocation.

Granting the Auditors group `inspect all-resources in tenancy` at the tenancy root satisfies the read-only, tenancy-wide constraint: the verb `inspect` permits listing and viewing resource metadata without create, update, or delete rights, and scoping to the tenancy covers every compartment. This avoids per-compartment policies, making it the most efficient approach.

Defined tags must belong to a pre-created tag namespace managed by administrators.

OCI IAM federation supports SAML 2.0 identity providers, allowing users to authenticate against an external directory and then assume OCI roles through group mappings. Federating with an existing enterprise IdP lets the new engineer sign in with corporate credentials, eliminating the need for a locally managed OCI password.

OCI Usage Reports automatically generate daily CSV reports of billing and usage, delivered to an Object Storage bucket you specify. This satisfies the daily automated export requirement without custom scripting, enabling downstream financial analysis and reporting.

OCI Budgets evaluate spend against thresholds and route alerts through the Notifications service, which fans out to email, PagerDuty, Slack and similar subscriptions. This satisfies the requirement that alerts reach recipients beyond the Console, enabling proactive cost governance.

OCI Monitoring ingests metric data from resources such as compute instances and emits alarms when thresholds are breached, satisfying the requirement for native metric monitoring with threshold-based alerting. It provides the metrics namespace, alarm rules and notifications that the scenario demands, without third-party tooling or manual polling.

The policy scopes the manage verb on compartments to AppCompartment, letting the architect create and manage sub-compartments beneath it. Because the grant is confined to that compartment rather than the tenancy root, full tenancy administration rights are not conferred.

Responder recipes define automated actions that Cloud Guard triggers when a detector identifies a problem, enabling remediation without manual intervention. This satisfies the requirement for features that actively secure the tenancy, rather than merely reporting posture.

Compartments are logical partitions within a tenancy used to isolate and delegate administration of resources. Separate compartments for networking, security tooling and application workloads give each team scoped IAM policies, matching the required administrative boundaries.

Dynamic group membership alone confers no access; permissions require an IAM policy binding that names the group as principal. Without such a policy, matching rules populate membership but grant nothing, so instances receive no permissions — exactly the missing-policy constraint described in the stem.

IAM policies in Oracle Cloud Infrastructure cascade downward through the compartment hierarchy, so a policy granting access at ParentComp also applies to ChildComp. This satisfies the stem's inheritance question: child compartments automatically receive the parent's policy permissions without a separate statement.

Service limits are hard quotas capping consumption of a resource within a tenancy or region, such as compute cores or load balancers. This matches the stem's description directly, distinguishing limits from compartment quotas and from capacity availability.

Tag Defaults apply predefined tags automatically to resources at creation, based on compartment or tenancy rules. This satisfies the requirement for project-code tagging without manual user action, unlike defined tags or policies that only enforce compliance.

Budgets allow you to set financial limits and configure automated alerts when forecasted or actual spend crosses set percentages.

In OCI, MFA is configured within Identity Domains, where administrators enable it per user or group and users enrol their authenticators. Managing MFA here satisfies the requirement to ensure users configure it for their accounts, since Identity Domains governs authentication policy for the tenancy.

Tag Defaults reference defined tag keys that belong to a tag namespace in the tenancy. The administrator selects an existing defined tag key and supplies the default value, then associates it with a compartment so new resources inherit the tag automatically.

Every OCI IAM policy statement must name the compartment or tenancy where the policy applies, scoping which resources the rule governs. Without this location element the statement cannot be evaluated, so it satisfies the required-component constraint alongside subject, verb and resource-type.

Cost Analysis in the OCI Console provides interactive charts of monthly spend trends, with filters for compartments and breakdowns by individual service. It satisfies all three stated needs: trend visualisation, compartment filtering and per-service expense examination.

Identity & Security hosts the Identity service, where administrators create groups, compartments and IAM policies under the tenancy. This satisfies the stem's requirement to manage access governance centrally, since compartments and policies are defined within Identity rather than Compute or Networking.

OCI Vault centrally stores and manages encryption keys and secrets, with policies governing their lifecycle and access. This satisfies administrative governance by centralising cryptographic material control, separating key custody from the workloads that consume those keys.

Group-based policy assignment centralises permission management, so onboarding or offboarding a user means changing group membership rather than editing many individual policies. This reduces drift and orphaned grants, satisfying the maintainable IAM structure the question asks for.

Resource Locks prevent deletion or modification of a resource regardless of user privileges, including administrators, until the lock is removed. Applying a lock to production-tagged resources satisfies the requirement to block accidental deletion by any user.

OCI Resource Manager is a managed Terraform service that runs infrastructure-as-code stacks natively within your tenancy, storing state and configurations. It satisfies the requirement to define and run Terraform without external tooling or self-managed state.

OCI Resource Manager runs Terraform configurations as managed stacks, tracking state and enabling repeatable, version-controlled provisioning. This satisfies the stem's requirement for organising and managing infrastructure configuration, since Terraform declaratively defines resources and Resource Manager applies, plans and destroys them consistently across compartments.

OCI best practise caps compartment nesting at six levels beneath the tenancy root. A seven-level structure exceeds this limit, complicating policy inheritance and IAM management, so six levels is the recommended maximum depth for the hierarchy.

The OCI Audit service automatically records all API activity in the tenancy, including Object Storage operations such as DeleteBucket, and retains events for 90 days by default. Filtering by compartment and event type surfaces the principal identity, source IP, and timestamp, which directly answers who deleted the bucket and when.