This post covers the Q/A’s & Review from the Day2 of Oracle Cloud Infrastructure Architect Training covering IAM (Users, Groups, Principal, Authentication, Authorization, Policies, and Compartments)
For Q/A’s & Review from Day1, please check here
The below image will help you to understand what you should learn or look for when preparing for Oracle Cloud Infrastructure Architect.
In this session, We covered Module 2: Identity & Access Management (IAM) Service which includes the following lessons
The course which is available on the Membership Portal looks like below. We encourage trainees to go through the well-done recorded videos before coming to the Live session so that they can come prepared with their doubts & can clear the doubts during the session to make it more Interactive.
Below are some of the questions asked during live interactive session related to Module 2 IAM in OCI
[Q/A] Instance Principals
We covered different type of Users i.e. Principal in OCI, here are some of the questions related to Principal (3 different types of Users) in OCI
Q1) Can you please Describe more about Instance Principals?
Ans: There are 3 types of Principals that are used to authenticate and interact with OCI resources:
- Root users
- IAM Users & Groups
- Instance Principals
Example of Instance principal is when a compute instance wants to connect to storage for backup. The IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources. Each compute instance has its own identity, and it authenticates using the certificates that are added to it. These certificates are automatically created, assigned to instances and rotated, preventing the need for you to distribute credentials to your hosts and rotate them.
- To know more about Instance Principals, click here
We will cover Instance Principals in detail in Module 10: Advance IAM
Q2) So I assume if I need to use other OCI resources such as storage etc, then I need instance principals?
Ans: Yes, Instance principal is one of the methods to connect but you can connect to storage using normal userID password too. Please refer to Question 1 above to know more on Instance Principal.
[Q/A] Groups and Policies in OCI
A Group in OCI is the collection of users on which you apply IAM Policy, whereas Policy is a set of rule that dictates who can access what resource (Compute, Storage, Network, Database, etc) in OCI. Here are a few questions related to Groups & Policies covered on Day2 of OCI Training.
Q3) What is a Dynamic Group?
Ans: A special type of IAM group that contains instances that match rules that you define (thus the membership can change dynamically as matching instances are terminated or launched). These instances act as “principal” actors and can make API calls to Oracle Cloud Infrastructure services according to IAM policies that you write for the Dynamic Group.
We will cover Dynamic Groups in detail in Module 10: Advance IAM
- To know more about Dynamic Group, click here
Q4) How can we restrict access on a Group so members of a group can access only selected OCI Resources?
Ans: Root user can control this access via IAM Policies. For issue on creating policies, please click here
Q5) What is Aggregate resource-type in IAM policies?
Ans: Aggregate means collection of resources like in Network Family we have a Load balancer, VCN, Subnet, etc. these represent the aggregate resource-types.
Q6) How do we create an IAM policy?
Ans: A policy specifies who can access which Oracle Cloud Infrastructure Resources (Compute, VCN, Object Storage, Database, etc). A policy allows a group to work in certain ways with specific types of resources under a particular Compartment
Policies are comprised of one or more statements.
It specifies which groups can access, what resources. Also, it plays a role in the level of access users have in a particular group.
Policy, attached to a group defines who can access what under a Tenancy or Compartment.
Note: For more information on creating IAM policy follow our step by step Activity Guide, click here
[Q/A] API keys & Auth Token
On Day2 we also covered various Authentication methods like Username/Password, API Singing Keys, and Auth Token. Here are some of the questions related to API Keys & Auth Tokens in OCI, so here we are educating that we covered this in class.
Q7) How many API sign keys a user can have.
Ans: A credential for securing requests to the Oracle Cloud Infrastructure REST API.
You can have up to three API key pairs per user.
In an API request, you specify the key’s fingerprint to indicate which key you’re using to sign the request.
Q8) Is Auth Token permanent or available for a period of time?
Ans: It is permanent as long as you keep and don’t delete from the account. Please refer to the Activity Guide which is covered in our DBA to Cloud DBA Training for Module 7 Activity Guide 6 from here.
Q9) If we lost the API key is there a way to recover or recreate it?
Ans: API keys can be generally recreated, best practice is to create multiple backups of your API keys
Q10) In Cloud Account there is “SMTP Credentials”, What is this?
Ans: Simple Mail Transfer Protocol (SMTP) credentials are necessary to send emails through Email Delivery. Each user is limited to a maximum of two SMTP credentials. If more than two are required, SMTP credentials must be generated on other existing users or more users must be created.
A security best practice is to generate SMTP credentials for a new user instead of your Console user that already has permissions assigned to it.
- For detailed instructions check here
[Q/A] Compartments in OCI
We also covered Compartments in OCI in detail as Compartments are one of the most important and critical in designing security on OCI.
- A Compartment is a logical container to organize and control access to your OCI Resources (Compute, Storage, Network, Load Balancer, etc). When creating resources (compute, storage) it is decided in which Compartment to place them.
- The compartment is global meaning they span across Regions. When Tenancy is provisioned a root compartment is created, each resource belongs to a single compartment but resources can be shared across compartments.
Q11) As we are saying Compartment can be renamed, so if we rename the Compartment, then what will happen to the policy created on Compartment?
Ans: Policy will remain the same on the Compartment as there is OCID for Compartment and OCID will not change, on change of name so access will stay as it is.
Q12) What is the business case for nested Compartment or to ease of billing?
Ans: It is for granting access (delegated access). As policies are hierarchical so whatever parent Compartment has access that will be accessible by child Compartments also.
As we covered nested compartment in OCI so there were some questions related to it
Q13) Is it a general practice to put each application in its own Compartment? It is a common requirement to have applications exchange data.
Ans: You need to decide who needs to access what resource and what privilege and based on that you put an application in a specific Compartment. Access to a resource in different Compartments can be granted via Policy.
Q13B) Can the resources of one Compartment can be accessed by a resource/compute in another Compartment?
Ans: Yes, as long as there are appropriate access policies, you can access the resources in another Compartment
Q14) As per the client, I have created department wise Compartments as per the example 3 (Root/Fin, Root/HR, Root/Eng.), under that created a network, etc. My question is during OAC do I need to transfer data from one to another, do I need to have all in the same region or is it fine?
Ans: VCN can be created in one region, you can create a different VCN in another region and connect through VCN peering. If you are deploying in the different region there is a concept of remote VCN peering so you can connect two different applications in different regions. We will be covering this in the Networking and Advanced Networking Module.
Q15) If we do not use where clause then Compartment A will inherit root Compartment privileges?
Ans: No, the root Compartment contains the Compartment A and has the privileges for Compartment A also. If the parent Compartment has access to the child Compartment will also have access.
Q16) Can u explain the usability of Tags in detail? Real-time use cases, as it can be seen everywhere while creating resources.
Ans: When you have many resources (for example, instances, VCNs, load balancers, and block volumes) across multiple Compartments in your tenancy, it can become difficult to track resources used for specific purposes, or to aggregate them, report on them, or take bulk actions on them. Tagging allows you to define keys and values and associate them with resources. You can then use the tags to help you organize and list resources based on your business needs.
- To know more about Tags, please click here
- [Q/A] Oracle Cloud Infrastructure Architect Training Day 1 Review
- Download the Step-By-Step Activity Guide to Register for an Oracle Cloud Trial Account.
- Oracle Cloud Infrastructure (OCI): Week 1 Learning Path Cloud Concepts & IAM Concepts
- Oracle Cloud Infrastructure (OCI) Architect Live Training.
- Oracle Cloud Infrastructure Architect: Step-By-Step Activity Guides To Clear Exam
Next Task For You
- Download the Step-By-Step Activity Guide to Register for an Oracle Cloud Trial Account.
- Create Compartments and Policies in Oracle Cloud, to know more about Compartments please check here
- Begin your journey towards becoming an Oracle Cloud Architect by Joining, FREE Masterclass on How To Become Oracle Certified Cloud in 8 Weeks.