I am on the journey of a fun certification of Oracle Cloud Infrastructure, 1Z0-1085-20 – Oracle Cloud Infrastructure Foundations 2020. Trying to make some useful notes as I prep, hopefully will be useful to someone on a similar journey.
Please do take advantage of oracle cloud free certifications available in your organisations to upskill appropriately.
SLA is a Service Level Agreement. An SLA is a financially-backed commitment to provide a minimum level of service to customers.
An SLA is generally defined as a number of nines for a particular month and a percentage credit. SLAs typically are written as 99.9% or also referred to as triple nines. Credits as a percentage, 10% credit, 25% credit, 100% credit. The SLAs are combinations which include tiers and definitions which cover these different nines and different percentages for the credits.
Monthly Uptime Percentage is calculated by subtracting from 100%, the percentage of minutes during the calendar month in which the service was unavailable. It’s always a month. You take out the number of minutes the service is unavailable, and that basically gives you the Monthly Uptime Percentage.
x=Number of minutes the service should be availabile
y= Number of minutes the service was unavailabile
Monthly Uptime Percentage = (x-y)/x * 100
What is an example of service unavailablility ?
Unavailablility means that there are no valid API calls that successfully perform an operation.
Sample combination of SLA :
99<x<100 —- 10% Service Credits
95> x <98 —- 25% Service Credits
x < 95% —- 100% Service Credits
The end user needs to calculate how many minutes the service was unavailable, calculate the percentage, and then further calculate the expected credits based on that.
How to request for credits ?
As a customer, you are responsible for monitoring your availability and so does the vendor or the cloud provider. You can log a request to Oracle, and then you work with Oracle to get these credits. Most importantly they have historical information about the target service and refer to the same to respond to your request. I am currently looking for more information on this topic.
Couple of key pointers
Customers need to file for the SLA claim and provide the supporting evidence of the SLA failure.
Claims for service credits must be filed by customers within 30 calendar days from when the issue occurred that caused the named Oracle Cloud Infrastructure Service not to meet the applicable Service Commitment. Oracle will use commercially reasonable efforts to process claims within 60 days of Oracle’s receipt of a claim.
Types of SLA’s
OCI offers SLAs covering performance, availability and manageability.
Availability basically also referred to as Data Plane — services are in operation with uptime and connectivity commitments. Data plane is about the usage of the resources. Every service has at least a date plane, SLA.
Manageability also refers to as Control Plane SLA, it basically means ability to manage, monitor, and modify OCI resources, in short administration of OCI resources.
The third one is performance where services consistently perform as expected.
Brief list of Resources covered by the 3D SLA plane
OCI Status is available on the dashboard where you can view all the services listed by regions and confirm whether they are running or not running or if there is a prevalent incident affecting a particular service. Incident history worth 1 year is also displayed here.
If you’re using Support for the very first time, you have to trigger a set of steps. Beginning with, sign up for an Oracle Support account which is also referred to as My Oracle Support, MOS.
Oracle does not charge extra for Support, it is already part of your licensing agreement. You don’t pay that as you do with, let’s say, other cloud vendors, but you have to sign up for an Oracle Support account.
Customer– Support Identifier i.e. the CSI number, this is your unique identifier by which Oracle Support will engage with you on any support issues. So if you go to this particular link, you can see the different steps you have to follow to use support for the first time.
Only paid accounts can open service requests. Customers who are using Always Free resources are not eligible for Oracle Support. Limited support is available to Free Tier accounts with Free Trial credits. You have to change convert these into a pay-as-you-go account, and then you can access Support.
There are four or five different things you can you Support requests for.
Resolve Technical Issues – Cloud Customer Connect
Unlock / Reset / Change Account for Tenancy Administrator
Service Limit Increases
What do you primarily need while raising a Support request ?
A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls.
For instance, maybe you have an application running
in a virtual machine that needs to store data in Google Cloud
Storage, but you don’t want to let just anyone on the Internet have access
to that data, only that virtual machine.
So, you’d create a service account to authenticate
your VM to cloud storage. Service accounts are named with an email
But instead of passwords, they use cryptographic keys to access resources. This way the service account is the identity of the service, and the service account’s permissions control which resources the service can access.
A service account is identified by its email address, which is unique to the account.
Differences between a service account and a user account
Service accounts do not have passwords, and cannot log in via browsers or cookies.
Service accounts are associated with private/public RSA key-pairs that are used for authentication to Google.
Cloud IAM permissions can be granted to allow other users (or other service accounts) to impersonate a service account.
Service accounts are not members of your G Suite domain, unlike user accounts. For example, if you share assets with all members in your G Suite domain, they will not be shared with service accounts. Similarly, any assets created by a service account cannot be owned or managed by G Suite admins.
Cloud Identity & Access Management lets you grant granular access to specific Google Cloud resources and helps prevent access to other resources. Cloud IAM lets you adopt the security principle of least privilege, where you grant only necessary permissions to access specific resources.
Primitive Roles are broad and impact all resources in the project. They are roles which existed prior to existence of Cloud IAM.
These roles are concentric, owner includes the permissions of editor and editor includes the permission of viewer.
Viewer – Permissions for read-only actions that do not affect state, such as viewing (but not modifying) existing resources or data.
Editor – All viewer permissions, plus permissions for actions that modify state, such as changing existing resources.
Owner – All editor permissions, plus Manage roles and permissions for a project and all resources within the project. Set up billing for a project.
4. Billing Administrator Role
someone to be able to control the billing for a project without the right to change the resources in the project.
In addition to the primitive roles, Cloud IAM provides additional predefined roles that give granular access to specific Google Cloud Platform resources and prevent unwanted access to other resources.
Organization policies are needed to enforce what resources are available in a Google Cloud trust boundary (folder, project, or other organizational level).
Cloud Identity and Access Management (IAM) enables you to manage access control by defining who (identity) has what access (role) to which resource.
Top to bottom : Resources inherit the policies of their parent resource.
Google Cloud Platform Policies are set at the highest level, like the organisation node are cascaded down to the project.
Inheritance is transitive, all the resources in a project inherit the policy.
However policies implemented at a higher level in this hierarchy can’t affect the access that’s granted exceptionally at a lower level.
Policy A – Enforced at the Organisation Level – Users can view cloud storage buckets.
Policy B – Enabled at the Project Level – User can modify cloud storage buckets.
Since Project Level Policy B is granting a more generous access at a lower level, it shall take effect and override Policy A.
An IAM policy has the following :
a “can do what” part, and
an “on which resource” part.
The “who” part of an IAM policy can be defined either by a
a. Google account
b. Google group
c. Service account
d. G Suite
e. Cloud Identity domain.
Can Do What – Role
The “can do what” part is defined by an IAM role which is a collection of permissions.
To do any meaningful operations, you need more than one permission.For example, to manage instances in a project, you need to create, delete, start, stop, and change an instance.
permissions are grouped together into a role that makes them easier to
There are three kinds of roles in Cloud IAM:
Primitive roles: Roles historically available in the Google Cloud Console. These roles are Owner, Editor, and Viewer. Avoid using these roles if possible, because they include a wide range of permissions across all Google Cloud services.
Predefined roles: Roles that give finer-grained access control than the primitive roles. For example, the predefined role Pub/Sub Publisher (roles/pubsub.publisher) provides access to only publish messages to a Pub/Sub topic.
Custom roles: Roles that you create to tailor permissions to the needs of your organization when predefined roles don’t meet your needs.
Projects, Folders, Organisation Node are the binding blocks of the Google Cloud Hierarchy.
Policies are inherited downwards in the hierarchy. All Google Cloud platform resources belong to a project.
Projects are the basis for enabling and using GCP services like managing APIs, enabling billing and adding and removing collaborators and enabling other Google services.
Each project is a separate compartment and each resource belongs to exactly one.
Projects can have different owners and users – they’re built separately and they’re managed separately.
Project ID / Name / Number
Project has three identifying attributes
Each GCP project has a name and a project ID that you assign.
Project ID : Globally unique : Chosen by you : Immutable
The project ID is a permanent, unchangeable identifier and it has to be unique across GCP. You use project IDs in several contexts to tell GCP which project you want to work with. In general, project IDs are made to be human readable strings and you’ll use them frequently to refer to projects.
It is a a unique identifier for your project, composed of the project name and a randomly assigned number.
Project Name : Need not be unique : Chosen by you : Mutable
On the other hand, project names are for your convenience and you can assign them.
Project Number : Globally Unique : Assigned by GCP : Immutable
GCP also assigns each of your projects a unique project number and you’ll see a display to you in various contexts. It is a number that’s automatically generated by the server and assigned to your project.
You can organize projects into folders, although you don’t have to. For example, you can use folders to represent different departments, teams, applications or environments in your organization.
Folders let teams have the ability to delegate administrative rights,
so they can work independently.
The resources in a folder inherit IAM policies from the folder.
So, if project three and four are administered by the same team by design,
you can put IAM policies into folder B instead.
Doing it the other way, putting duplicate copies of those policies on
project three and project four would be tedious and error prone.
To use folders, you need an organization node at the top of the hierarchy.
You probably want to organize all the projects in your company into a single structure. Most companies want the ability to have centralized visibility on how resources are being used and to apply policy centrally. That’s what the organization node is for. It’s the top of the hierarchy.
In part the answer depends on whether your company is also a G Suite customer.
If you have a G Suite domain, GCP projects will automatically belong to your organization node. Otherwise, you can use Google Cloud Identity to create one.
When you get a new organization node, it lets anyone in the domain create projects and billing accounts just as they could before. That’s to avoid surprises and disruption.
But it’d be a great first step with a new organization node to decide who on your team should really be able to do those things.
Once you have an organization node, you can create folders underneath it and put it in projects.